The HTTPS and security guide in this section explains why encryption stopped being optional for SEO. This one goes a level deeper: it assumes you already have a certificate installed and gets into the specific configuration that determines whether that HTTPS actually works in every browser, or just yours. The gap between "it works in my Chrome" and "it works for every client that visits my site" is almost always in the certificate chain, the negotiated TLS version and the HSTS header, three pieces that are rarely reviewed again after the initial install.
The certificate chain: why something can fail without you seeing it
An SSL/TLS certificate is never validated on its own: the browser builds a chain of trust running from your domain's certificate (the leaf certificate) to a root authority (root CA) already built into the operating system or browser, passing through one or more intermediate certificates issued by the certificate authority. The server has to send that full chain, not just the leaf certificate, because the user's browser has no way of knowing in advance which intermediate corresponds to which root.
This is the technical reason a setup "works in one browser and fails in another": modern desktop browsers (Chrome, Firefox) often cache common intermediate certificates they've already seen on other sites, so if your server doesn't send the intermediate, the browser sometimes reconstructs it anyway from that cache and the site looks perfectly secure. A client that doesn't have that cache (a less common mobile browser, an HTTP library in a monitoring script, an SEO crawler, or Googlebot itself under certain conditions) can't complete the chain and treats the connection as untrusted. The failure can therefore go unnoticed for months by a team that only tests in its own desktop Chrome.
# Check the full chain the server is actually sending
# (not what you think it sends, what actually goes over the wire)
openssl s_client -connect www.yourdomain.com:443 -servername www.yourdomain.com -showcerts
# Also verify the chain resolves without relying on the local cache
openssl s_client -connect www.yourdomain.com:443 -servername www.yourdomain.com -verify_return_errorBy far the most common misconfiguration is installing only the leaf certificate and forgetting the intermediate chain file (often a separate file, something like chain.pem or fullchain.pem depending on what the certificate authority provides) in the web server config. With Let's Encrypt, for example, the difference between using cert.pem (leaf only) and fullchain.pem (leaf plus intermediate) in Apache's SSLCertificateFile directive or Nginx's ssl_certificate is exactly this problem, and it's easy to get wrong because both files "work" under shallow testing.
TLS versions: why TLS 1.0 and 1.1 shouldn't still be active
TLS (Transport Layer Security) has several versions with different security levels: TLS 1.0 (1999) and TLS 1.1 (2006) use cryptographic primitives now considered weak and are vulnerable to documented attacks like BEAST and POODLE; TLS 1.2 (2008) is still widely compatible and secure if its ciphers are configured well; TLS 1.3 (2018) simplifies the protocol, reduces the latency of the initial handshake (one fewer round trip) and removes entire families of insecure ciphers that in TLS 1.2 remained, at least in theory, configurable by mistake.
Major browsers disabled support for TLS 1.0 and 1.1 in a coordinated fashion, and payment-industry standards (PCI DSS) have required for years that they not be used in any environment processing cards. Keeping them active on the server adds no real benefit (almost no modern client needs them) while widening the attack surface; the only legitimate reason to keep them is supporting one very specific, known client that can't be updated, never as a default configuration.
# Apache: disable TLS 1.0 and 1.1, keep only 1.2 and 1.3
SSLProtocol -all +TLSv1.2 +TLSv1.3
# Nginx: equivalent
ssl_protocols TLSv1.2 TLSv1.3;The SEO impact here isn't a direct ranking signal (Google doesn't check the negotiated TLS version as a ranking factor), it's indirect and cuts both ways: on one hand, a server misconfigured on TLS that starts failing handshakes with certain clients can produce intermittent crawl errors that are hard to diagnose because they don't fail consistently or with every user-agent; on the other, security audit tools and some browsers show explicit "not fully secure connection" warnings on outdated setups, which erodes user trust the same way a broken padlock from mixed content would.
HSTS in depth: max-age, preload, and why to test it before committing
The HTTPS guide already covers the basic Strict-Transport-Security header. What's missing there is the preload directive and its consequences, because it's the part of HSTS that generates the most irreversible production mistakes:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"Without preload, HSTS only protects a user starting from their second visit: the first request can still travel over http:// before the browser receives the header and memorizes the policy. The HSTS preload list, maintained by Chromium and also adopted by Firefox and Safari, closes that gap by baking the domain directly into the browser itself, so that not even the first visit is ever made over unencrypted HTTP, for any user of that browser anywhere.
The catch is that inclusion on that list is, in practice, nearly irreversible in the short term: once a domain is accepted (after confirming it meets the requirements and has kept HSTS active for a reasonable period), removing it can take months to propagate to every already-updated browser, and in the meantime the entire domain and all its subdomains (via includeSubDomains) are forced onto HTTPS with no exceptions, including test subdomains, staging environments with real names, or any internal service that for whatever reason still doesn't have its own certificate. Before submitting a domain to the preload list (at hstspreload.org), it's worth keeping the header active without preload for weeks, confirming no subdomain still depends on being served over HTTP, and only then taking the step.
Mixed content at scale: auditing the whole site, not one page at a time
Checking the browser console page by page, as the general HTTPS guide suggests, works for a one-off check but doesn't scale to a site with thousands of URLs. Two technical approaches let you catch mixed content site-wide. The first is a full crawl (with a Screaming Frog-style tool, as described in the audit methodology guide) that extracts every src and href attribute from each crawled page and filters those starting with http:// while the page itself is served over https://. The second, more precise because it also captures resources loaded dynamically by JavaScript that a static crawl might miss, is temporarily enabling a report-only Content-Security-Policy, which blocks nothing but sends a report to your own endpoint every time a real browser detects an insecure load:
Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri /csp-report-endpointThis second method has the advantage of reflecting the mixed content real users actually encounter in production (including cases that depend on dynamic data, a specific plugin, or a JavaScript race condition) rather than only what a static crawl can reconstruct.
What actually happens, technically, when a certificate expires
The general HTTPS guide describes the visible symptom (a full-screen warning interstitial). At the protocol level, what happens is that during the TLS handshake the server still presents the certificate as-is, but the client checks the certificate's notAfter field and, finding it in the past, aborts the connection before the key exchange completes: it isn't a server failure in the sense of no longer responding, it's an active, deliberate rejection by the client, which explains why the site looks "down" even though the server is running normally and serving the rest of its infrastructure without issue. For Googlebot, the effect is equivalent: it can't complete the encrypted connection, so the URL starts being logged as a crawl error, and if the situation persists, Google can eventually pull the affected pages from the index because it can no longer verify they still exist and are reachable.
Frequently asked questions
Why does my certificate look fine in Chrome but fail in other tools?
It's almost always an incomplete certificate chain: the server isn't sending the intermediate certificate, and Chrome rebuilds it from its own cache, while tools without that cache (curl, some SEO crawlers, certain mobile browsers) can't complete validation and treat the connection as untrusted.
Can I disable TLS 1.0 and 1.1 without checking anything first?
For the vast majority of sites, yes, with no noticeable impact, because real traffic still depending on those versions is negligible today. If the site receives traffic from very old, known integrations (a legacy payment system, for example), it's worth reviewing server logs by negotiated TLS version before disabling them entirely.
Is it safe to add my domain to the HSTS preload list?
Only after keeping the HSTS header active (without preload) long enough to confirm no subdomain or internal service still depends on unencrypted HTTP, because once included on the list, reversing it takes months to propagate to browsers that have already downloaded it.
Does Content-Security-Policy's report-only mode affect real users?
Content-Security-Policy-Report-Only never blocks any resource, it only logs what a real policy would have blocked. It's the safe way to audit mixed content in production before turning on an actually restrictive policy.