3 min read
What happens to SEO when a TLS certificate expires?
By CrawlWarden, which builds the monitoring described at the foot of this article.
Published , sources last re-read .
Every visitor gets a full-page browser interstitial, and Googlebot cannot complete the TLS handshake - so the site becomes uncrawlable rather than merely slower. Pages do not drop out of the index immediately; Google retries for a while before it starts removing URLs. The practical cost is traffic and trust during the outage, plus a recovery crawl afterwards. Automated renewal has made expiry rarer and has not made it rare, because renewal jobs fail silently.
The failure is rarely the expiry date itself
- An incomplete chain. The server sends the leaf certificate but omits an intermediate. Chrome often repairs this from its own cache, so it works on the machine you test from and fails in curl, on older Android, and for crawlers and API clients.
- A certificate that no longer covers the hostname. A SAN list regenerated without a subdomain is a valid certificate for the wrong name.
- A renewal job that stopped. An ACME client whose HTTP-01 challenge path started redirecting, or whose credentials rotated, keeps failing on a cron schedule that nobody reads.
- An unexpected issuer. A certificate suddenly issued by a different authority can be a legitimate infrastructure change - or the first visible sign of a domain or DNS compromise.
What Google actually does
Googlebot will not complete a handshake it cannot validate, and treats the fetch as a failure. Short outages are absorbed; Google retries. A sustained failure is eventually treated as the site being unavailable, and URLs start falling out of the index.
HTTPS is a confirmed, lightweight ranking signal in its own right, but that is not the mechanism that hurts here. Being unfetchable is.
What to watch, beyond the date
| Signal | What a change means |
|---|---|
| Days to expiry | The renewal job has stopped and nobody has noticed. The only signal with a deadline attached. |
| Issuer | Either a planned infrastructure change or an unplanned one. Both are worth a sentence of explanation. |
| SAN list | A hostname you serve may no longer be covered. |
| Chain completeness | Works in Chrome, fails in curl, on older clients, and for crawlers. |
| CAA record | Controls which authorities may issue for the domain at all. A change here precedes a certificate change. |
Why a calendar reminder is not the control
Certificates are now routinely issued for 90 days or less and renewed automatically, which means the renewal is machine-driven and the failure mode is a machine failing quietly. The thing worth alerting on is the number of days remaining falling below a threshold - which only goes wrong when automation has already gone wrong.
The checks that report this
CrawlWarden watches a list of URLs you choose and reports what changed. It does not diagnose and it does not score. Severity is a property of the check rather than a setting: the number below is how many consecutive runs must see the new value before it becomes an email, and it is never less than two, because one observation is noise.
Certificate expiryconfirmed over 2 consecutive runs
Watches days remaining against a threshold, so a stalled renewal is caught before the deadline rather than after it.
Certificate issuerconfirmed over 3 consecutive runs
Reports when the certificate starts coming from a different authority.
Certificate chainconfirmed over 3 consecutive runs
Reports an incomplete chain - the case that works in Chrome and fails elsewhere.
Certificate SANsconfirmed over 3 consecutive runs
Reports when the certificate stops covering a hostname you watch.
Every check is available on every plan, including the free one. CrawlWarden pricing, per site rather than per URL.
Questions
- How quickly does Google deindex a site with an expired certificate?
- Not immediately. Google retries failed fetches for a period before treating a URL as gone, so a few hours is usually recoverable and a few days is not free. The lost traffic during the outage is the certain cost; deindexing is the risk.
- Why does the site work in Chrome but fail in curl?
- Almost always an incomplete chain. Chrome can fill in a missing intermediate from certificates it has seen before; curl, older Android, and most crawlers cannot. Testing only in Chrome hides the entire class of problem.
- Does HTTPS itself help rankings?
- Slightly, and it has been confirmed as a lightweight signal for over a decade. It is not why this matters. Being unreachable is.
Related
Sources
What was checked, and where. An entry with no link is something that could not be verified, named here rather than left out.
Google: Network and DNS errors
What Google does when it cannot reach a server at all: "already indexed URLs that are unreachable will be removed from Google’s index within days". This is the closest documented case; Google does not document a failed TLS handshake separately.
Google Search Central: HTTPS and Google Search
That Google expects HTTPS and treats it as a signal, behind the cost described in the second section.
Certificate Transparency: How CT works
That issuance is logged publicly, which is what makes a misissued or unexpected certificate detectable from outside.
Not verified: a Google-published timeline for TLS failures specifically
The "within days" figure above is documented for unreachable servers in general. Google publishes nothing separate for certificate failures, so the page does not claim a number for them.
Not verified: search volume for this query
No keyword volume tool is connected to this project. Demand was judged from a live depersonalised US SERP.
Know the moment this happens to you
Give CrawlWarden a domain, keep the pages it suggests, and the first check runs immediately. Free forever for one site.