HTTPS, SEO and Site Security

Hypertext Transfer Protocol Secure (HTTPS) is the encrypted version of HTTP, the protocol used to send data between a web browser and a website. Its direct role in Google rankings is smaller and less certain than often stated: Google announced HTTPS as a ranking signal in August 2014,¹ and since March 2024 its page experience guidance says aspects beyond Core Web Vitals “don’t directly help your website rank higher”.² Its indirect role is larger. Since Chrome 154, released on 22 September 2026, Chrome asks for the user’s permission before the first visit to any public site that does not support HTTPS,³⁴ so for any site published in 2026 HTTPS is a precondition, not an enhancement.

What HTTPS does

HTTPS encrypts the connection between a user’s browser and the server. Without it, anyone on the network path (Wi-Fi network operators, ISPs, malicious intermediaries) can read the contents of every request and response, modify them in transit, and impersonate the site.

The encryption is provided by a TLS certificate, signed by a trusted certificate authority. Modern certificate authorities (Let’s Encrypt, ZeroSSL) issue certificates free of charge. There is no longer any cost barrier to HTTPS implementation.

What does Chrome do when a site has no HTTPS?

From Chrome 154, the “Always Use Secure Connections” setting is on by default for public sites. Chrome “prompts users by default when they connect to a site over an insecure (http) connection”,³ and the prompt asks the user’s permission before the page loads.⁴ Google says it warns only on a site that is new to the user or not recently visited, and exempts private addresses such as local IP addresses and single-label hostnames like intranet/. The same announcement planned an earlier start, Chrome 147 in April 2026, for users of Enhanced Safe Browsing.⁴

The warning targets a small remainder. Google’s HTTPS transparency report put Chrome page loads over HTTPS at “around the 95-99% range around 2020”, after which “progress has largely plateaued”.⁴ W3Techs finds HTTPS as the default protocol on 90.1% of the websites it surveys, as at September 2026.⁵ Google also names HTTP addresses that exist only to redirect to an HTTPS site, “an insecure interaction which was previously completely invisible to users”,⁴ so any hostname your links pass through, such as an old subdomain or a tracking domain, needs HTTPS too.

Implementation basics

The migration to HTTPS, for a site previously on HTTP, involves:

1. Obtain a certificate. Most hosting providers, CDNs, and platforms (Cloudflare, Netlify, Vercel, WP Engine, and most managed WordPress hosts) provision and renew TLS certificates automatically. If yours does not, free certificates from Let’s Encrypt with automated renewal via Certbot cover the great majority of remaining cases. Wildcard certificates cover all subdomains; standard certificates cover a single domain or a defined set.
2. Configure the web server. Listen on port 443; serve the certificate; redirect all HTTP traffic to the equivalent HTTPS URL via 301.
3. Update internal references. All internal links, asset references, canonical tags, and structured data should use HTTPS URLs.
4. Update sitemap and robots.txt. Sitemap URLs should be HTTPS; the robots.txt sitemap directive should reference the HTTPS sitemap URL.
5. Update Search Console. Add the HTTPS property in Search Console; the HTTP property continues to exist but should now show declining traffic.
6. Update third-party tools. Analytics, ad networks, marketing tools, anything referencing the site URL should be updated to HTTPS.

Mixed content

Mixed content is a common HTTPS implementation problem. It occurs when an HTTPS page loads sub-resources (images, scripts, stylesheets) over HTTP. Browsers either block the resources (active mixed content like scripts) or downgrade the security indicator (passive mixed content like images).

Audit for mixed content via:

• Browser DevTools console. Mixed content warnings appear automatically.
• Crawler reports. Screaming Frog and Sitebulb both flag mixed content during a crawl.
• Search Console security issues. Reports systemic problems.

Fix by updating all sub-resource URLs to HTTPS. For third-party resources that don’t support HTTPS (rare in 2026), either find an alternative or remove the dependency.

HSTS

HTTP Strict Transport Security (HSTS) is an HTTP response header that tells browsers to always use HTTPS for the domain, refusing to attempt HTTP connections even if the user types http:// explicitly.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000 (one year) is the conventional duration. includeSubDomains extends the policy to all subdomains. preload opts the domain into the HSTS preload list maintained by browser vendors, removing even the first-visit window where downgrade attacks are theoretically possible.

HSTS is a strong commitment. Once enabled, it cannot be quickly reversed, because browsers cache the policy. Implement carefully on production sites, and only after confirming HTTPS works reliably across all subdomains and asset paths.

Other security headers worth setting

Content-Security-Policy (CSP). Restricts which sources of scripts, styles, and other resources the browser will execute. Significantly reduces XSS attack surface. Requires careful configuration to avoid breaking legitimate functionality.

X-Content-Type-Options: nosniff. Prevents browsers from second-guessing the declared MIME type of a response. Mitigates a class of attacks that exploit MIME type confusion.

Referrer-Policy. Controls how much referrer information is sent with outbound requests. strict-origin-when-cross-origin is a sensible default.

Permissions-Policy. Controls which browser features (camera, microphone, geolocation, etc.) the page can request. Most sites should explicitly disable features they don’t use.

X-Frame-Options: SAMEORIGIN or frame-ancestors in CSP. Prevents the site from being embedded in iframes on other domains, mitigating clickjacking.

These headers don’t directly affect SEO rankings, but they affect security posture, user trust, and (in some cases, like CSP-related JS errors) page rendering.

HTTPS and rankings

The direct ranking effect of HTTPS was small from the start, and Google put a number on it at launch: “a very lightweight signal, affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content”.¹ Google said at the time it might “decide to strengthen it”. Its guidance has since moved the other way. In March 2024 it rewrote its page experience documentation to say “Core Web Vitals are used by our ranking systems” and “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher”, on a page that lists “Are your pages served in a secure fashion?” among those aspects.² Google has not said in terms that HTTPS is no longer a ranking signal, so the accurate reading is that any direct effect is small or absent. The indirect effects are larger:

• Chrome’s warning stands between an HTTP site and every new visitor using Chrome.
• Mixed content errors trigger browser security warnings and can break functionality when active resources are blocked.
• Insecure connections prevent the site from using modern web platform features (HTTP/2, HTTP/3, service workers, push notifications).

The cumulative effect of being on HTTPS is much larger than any direct ranking effect.

Common HTTPS problems

Problem	Effect
Mixed content	Browser warnings, blocked sub-resources
Certificate expiry	Site inaccessible until renewed; trust collapse
Wrong certificate domain	Security warnings; users abandon
HTTP not redirecting to HTTPS	Indexing fragmentation; duplicate content
Internal links still pointing to HTTP	Wasted redirects; equity loss
HSTS misconfiguration	Subdomains inaccessible; difficult to reverse

Frequently asked questions

Do I need an EV (Extended Validation) certificate?

No. EV certificates were once distinguished by browsers via a green address bar; that distinction has been removed. Standard DV (Domain Validation) certificates from Let’s Encrypt are functionally equivalent for SEO purposes.

Does HTTPS slow down the site?

The cryptographic overhead of HTTPS is negligible on modern hardware. HTTPS is also a precondition for HTTP/2 and HTTP/3, which are significantly faster than HTTP/1.1. Net effect on performance is positive.

Should I use HTTP/2 or HTTP/3?

Both. Most CDNs and modern web servers support both. HTTP/3 (over QUIC) provides additional performance improvements over HTTP/2, especially on lossy connections. There is no SEO downside to using either.

Footnotes

1. HTTPS as a ranking signal — Google Search Central Blog ↩ ↩²

2. Understanding page experience in Google Search results — Google Search Central ↩ ↩²

3. Chrome 154 release notes — Chrome for Developers, stable release 22 September 2026. ↩ ↩²

4. HTTPS by default — Google, 28 October 2025. ↩ ↩² ↩³ ↩⁴ ↩⁵

5. Usage statistics of Default protocol https for websites — W3Techs, as at 28 September 2026. ↩