The certificate is what makes the padlock appear and HTTPS work. When it expires, is issued to the wrong name, or serves over an outdated protocol, the browser stops trusting the site and warns visitors away. Here is each failure and its fix.
A TLS certificate is what proves your site is who it says it is and encrypts the connection. If it fails, the browser does not degrade gracefully, it throws a full-page warning that most visitors will not click past.
This is the harshest failure in an audit. A broken title costs some clicks; a broken certificate costs almost all of them, instantly, and it applies to every page on the domain at once. The most common cause is the least dramatic: a certificate simply expires because the auto-renewal that was supposed to run quietly failed, and nobody was watching the expiry date. Certificates are valid for a fixed window, often 90 days, and the day they lapse the whole site shows as insecure.
Beyond expiry, the certificate can be issued to the wrong hostname, served over an outdated protocol version that modern browsers reject, negotiate a weak cipher, or be undermined by the page itself loading assets over plain HTTP. Each one erodes the trust HTTPS is supposed to provide.
Each check the audit runs against the transport layer.
The certificate has lapsed, or falls within the 21-day expiring-soon window the audit checks against. Fix by renewing, and then fixing the renewal itself: automate it (an ACME client such as Certbot renews and reloads automatically) so it never depends on someone remembering. The audit flags "expiring soon" ahead of time precisely so renewal happens before the outage, not after.
The certificate is issued to a different hostname than the one being served, for example a cert for example.com serving www.example.com, or a wildcard that does not cover a subdomain. Fix by reissuing a certificate that lists every hostname you serve, or covering them with a wildcard plus explicit entries.
The server negotiates TLS below version 1.2, or negotiates a cipher suite on the recognised weak list. Fix in the server or CDN TLS config: require TLS 1.2 as a minimum, prefer 1.3, and disable the legacy cipher suites. Most hosts have a one-line "modern" TLS profile that does this. A related, quieter check is SNI support: a server that can't select the right certificate by requested hostname is limited to one certificate per IP.
The certificate is fine, but an HTTPS page loads an image, script or stylesheet over plain http://, so the browser downgrades the page to "not fully secure". Fix by switching every asset URL to https:// or protocol-relative paths, then re-crawl to confirm none remain.
Nearly every certificate outage is a renewal that silently failed.
Certificate problems are unusual in that the best fix is not a code change but a process. The overwhelming majority of "site is not secure" incidents are simply an expired certificate whose auto-renewal broke, quietly, weeks earlier. The renewal cron did not run, or ran but failed to reload the server, and no alert fired, so the first sign of trouble is the outage itself.
Two things prevent it. First, automate renewal end to end, including the server reload, so a fresh certificate is installed without human involvement. Second, monitor the expiry date independently of the renewal, so that if automation fails, you are warned with days to spare rather than discovering it when traffic falls off a cliff. The audit's "expiring soon" check exists to be that independent early warning.
In the short term, an expired certificate does not directly lower your rankings, but it does something worse: it stops visitors reaching the pages at all, because the browser warning blocks them before the page loads. Bounce and abandonment spike immediately.
If the outage persists, the secondary effect follows. Google re-crawls, cannot establish a trusted connection, and can start treating pages as unreachable, which over time does affect indexing. The fix is always urgent: a lapsed certificate is one of the few SEO issues measured in minutes, not weeks.
There is no ranking difference between a free certificate from a provider like Let's Encrypt and a paid one. Google treats the connection as secure or not; it does not read the price of the certificate. Paid certificates buy longer validity, organizational validation, and support, none of which is a ranking factor.
What matters for SEO is only that the certificate is valid, matches the hostname, and serves over a current protocol. A free, correctly-configured, auto-renewing certificate satisfies every check in this category.
Mixed content is fiddly because the offending asset is often not in the page's own template but in something it pulls in: an embedded widget, an old image URL hard-coded with http://, or a third-party script. The browser console lists each blocked or downgraded resource by URL, which is the fastest way to trace it.
Fix them at the source by updating the asset URLs to HTTPS. A Content-Security-Policy that only allows HTTPS sources then acts as a backstop, blocking any future HTTP asset before it can downgrade the page again.
Within 21 days of the certificate's expiry date, the audit flags it as expiring soon, ahead of the harder failure of it actually lapsing. That window is meant to leave enough time to fix a broken renewal before any visitor sees a warning.
TLS 1.2 as the floor, TLS 1.3 preferred where supported. TLS 1.0 and 1.1 are legacy protocols with known weaknesses that modern browsers increasingly refuse outright, and a server still offering them is flagged regardless of whether any client actually negotiates down to it.
Expiry is a timing failure: valid once, not any more. A name mismatch is a scope failure: the certificate is current but wasn't issued to cover the exact hostname served, such as a cert for example.com answering for www.example.com. Both throw the same browser warning despite the different cause, which is why the audit checks them separately.
One on the recognised list of insecure suites with known cryptographic weaknesses that modern clients avoid by default. If a server still offers and negotiates one when a permissive client allows it, that's flagged, even if most real visitors' browsers would have preferred a stronger option and never triggered it.
Yes, for any host serving more than one certificate from the same IP, which is the default on shared hosting and most CDNs. SNI lets the server present the right certificate for the hostname the client asked for during the handshake. A server that can't do this is limited to one certificate per IP, worth knowing even where it isn't yet causing a visible error.
No. Google treats the connection as secure or not; it doesn't read the certificate's price or issuer tier. A free, correctly configured, auto-renewing certificate satisfies every check here as well as a paid one does. Paid certificates buy longer validity and organizational validation, not ranking weight.
Free to start. The audit checks certificate expiry, name, protocol and mixed content on every run.
Start my free audit