HTTPS & Security Headers
HTTPS is a baseline requirement for SEO, not an optional upgrade. Serving your site over a valid HTTPS connection protects trust signals, prevents rendering…
5 min read · updated 2026-08-10
HTTPS is a baseline requirement for SEO, not an optional upgrade. Serving your site over a valid HTTPS connection protects trust signals, prevents rendering failures, and keeps search engines from seeing broken or incomplete pages. On its own, HTTPS won't lift your rankings — but misconfigured certificates, redirect chains, mixed content, or overly strict security headers can quietly damage how your site is crawled and rendered.
Get the protocol and certificate right
HTTPS is mandatory. Beyond that, modern protocols like HTTP/2 and HTTP/3 (QUIC) are preferred: search engines now crawl over HTTP/2 and HTTP/3, and the efficiency of these protocols aids crawl throughput.
Your certificate needs to be valid, auto-renewed so it never expires, and served with its full chain. A missing intermediate certificate is a common and deceptive failure — it may work in some browsers while failing stricter validation used by search crawlers. If a crawler can't validate your certificate, it can't reliably fetch your pages.
Certificate coverage is another frequent trap. A certificate issued for www only, while the apex domain is also served, produces a mismatch. Make sure your certificate's coverage spans both your apex and www hostnames, plus any relevant subdomains you serve.
Redirect HTTP to HTTPS in a single hop
Every HTTP URL should 301 redirect to its HTTPS equivalent, ideally at the edge, in one hop. The problem to avoid is redirect chains that pass through multiple stops, for example:
http://example.com → https://example.com → https://www.example.com
Each extra hop wastes crawl budget and adds latency. Collapse these into a single redirect that sends the visitor and crawler straight to the final canonical HTTPS URL. For a broader treatment of clean redirect setups, see Redirects for SEO.
Use HSTS — but test your subdomains first
HTTP Strict Transport Security (HSTS) tells browsers to only ever connect to your site over HTTPS. A strong configuration looks like this:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
That sets a two-year max-age, applies the policy to subdomains, and marks the domain for the HSTS preload list, which you can then submit to.
The includeSubDomains directive is where caution matters. If you have a legacy subdomain that still only serves HTTP, applying HSTS across all subdomains can break it. Test your subdomains before enabling includeSubDomains, and only add preload once you're confident every subdomain is HTTPS-ready — preload-list membership is hard to reverse.
Security headers and rendering
Security headers don't directly rank your pages. But when they're misconfigured, they cause mixed-content and rendering issues that erode trust signals and can prevent search engines from seeing your full page. The headers worth setting:
| Header | Purpose |
|---|---|
Content-Security-Policy | Controls which resources the browser is allowed to load. |
X-Content-Type-Options: nosniff | Stops the browser from guessing content types. |
Referrer-Policy: strict-origin-when-cross-origin | Limits how much referrer data is shared cross-origin. |
Permissions-Policy | Gates access to browser features. |
The header that most often causes SEO trouble is Content-Security-Policy. An overly strict CSP can block a search crawler from loading the JavaScript or CSS it needs to render your content. A classic example: a default-src 'self' policy that blocks a CDN-hosted JS bundle the crawler needs to render the page. If your render-critical resources are served from a CDN or third-party origin, your CSP has to allow them.
Verify that resources fetched by search crawlers aren't being blocked by your CSP. If rendering depends on JavaScript, this check is not optional — a blocked bundle can mean the crawler sees an empty or half-built page. Rendering quality also feeds into performance, which you can explore further in Core Web Vitals.
Mixed content breaks rendering
Mixed content happens when an HTTPS page loads HTTP resources — images, scripts, or stylesheets. Browsers block these insecure resources, which breaks rendering, and the result is that a search engine may see an incomplete page.
The reliable way to catch this is to inspect the rendered DOM, not just the raw HTML. Parse the fully rendered page and flag any http:// resource references appearing on HTTPS pages. Because mixed content often creeps in through hardcoded URLs in templates, third-party embeds, or legacy content, it's worth checking after every significant template or content change.
How your pages are crawled and rendered ties directly into the wider technical foundation — see Crawlability and Indexability for the surrounding context.
What to check regularly
Treat these as recurring health checks rather than one-time setup tasks:
- Certificate validity and expiry — alert well before expiry (a 30-day window is a sensible threshold), and confirm the full chain is served.
- Host match — confirm certificate coverage spans www, apex, and any relevant subdomains.
- Redirect verification — confirm every HTTP URL 301s to HTTPS in a single hop with no chains.
- HSTS — check the header is present, that max-age is at least a year, and confirm preload-list membership if you've submitted.
- Mixed content — scan rendered pages for any
http://resources. - CSP — simulate a crawler's fetch and flag any render-critical resources the policy blocks.
- Protocol support — confirm HTTP/2 or HTTP/3 negotiation works.
What to do
- Confirm every page is served over HTTPS with a valid, auto-renewing certificate and the full certificate chain, including intermediates.
- Check that your certificate covers both your apex and www hostnames, plus any subdomains you serve, so there's no host mismatch.
- Consolidate all HTTP-to-HTTPS redirects into a single 301 hop that lands on the final canonical URL.
- Add an HSTS header with a long max-age, but test every subdomain before enabling
includeSubDomainsor submitting to the preload list. - Set
X-Content-Type-Options,Referrer-Policy, andPermissions-Policy, and review yourContent-Security-Policyso it allows the JS and CSS crawlers need to render your content. - Scan your rendered pages for mixed content and fix any HTTP resources loading on HTTPS pages.
- Verify HTTP/2 or HTTP/3 support to keep crawling efficient.
- Put these checks on a recurring schedule and re-run them after any template, CDN, or certificate change.
For the full picture of how these pieces fit together, start with Technical SEO and the broader LLMRanks Learn library.
save this card
Download card1080×1350 · post it anywhere
put it to work
See how ChatGPT, Gemini and Google AI actually talk about your brand.