SSL/TLS Certificates

DV vs OV vs EV, wildcard vs SAN, Let's Encrypt and free automated issuance, certificate chain failures, expiration and auto-renewal, and what breaks for users vs crawlers when a certificate is invalid — the certificate-level deep dive under the HTTPS hub.

First published: Jul 3, 2026 · Last updated: Jul 17, 2026 · Advanced
AIAuthored byAI v2

Google doesn't document a ranking difference between DV, OV, and EV certificates, or between free Let's Encrypt certs and paid ones — as long as the HTTPS is valid, they all get treated the same; a pricier certificate buys human/organizational trust, not ranking. Validation depth (DV/OV/IV/EV) and coverage scope (single-domain, wildcard, SAN) are separate decisions, and neither is a documented ranking factor. Where certificates actually affect SEO is failure: an expired, self-signed, hostname-mismatched, or chain-broken cert throws browser warnings that drive users away, can flip Google's normal HTTPS-over-HTTP canonical preference back to HTTP (HSTS can't override that), and — if HTTPS errors pile up — can prompt Google to stop crawling your HTTPS pages entirely. With certificate lifetimes shrinking toward a 47-day maximum by 2029, automated renewal is now mandatory, not optional.

TL;DR — Google doesn’t document a ranking difference between DV/OV/EV validation depth or free-vs-paid issuance — a pricier certificate buys human/organizational trust, not rankings. Validation depth (DV/OV/IV/EV) and coverage scope (single/wildcard/SAN) are two independent decisions; neither is a documented ranking factor. Let’s Encrypt and free automated (ACME) issuance are not a compromise — same encryption, same treatment. Where certificates hit SEO is failure: an expired, self-signed, hostname-mismatched, or chain-broken cert breaks the page for users, can flip Google’s normal HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'-over-HTTP canonical preference back toward the HTTP version (HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. cannot override that), and — per Google’s own docs — enough HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' issues “can prompt Google to stop crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. your HTTPS pages” entirely. With CA/Browser Forum cutting max validity to 47 days by 2029, automated renewal is now mandatory. The HTTPS hub introduces that a free DV cert gets the same signal as OV/EV; this is where that gets its full treatment.

The HTTPS hubHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' makes the case that HTTPS is at most a tiebreaker signal, that Google checks the scheme and not the certificate, and that a free DV certificate earns the same signal as an expensive OV/EV one. This article picks up exactly where that leaves off and goes one layer deeper — into the certificate itself. I’m not going to re-argue whether HTTPS helps rankings; assume you’ve read the hub. Here I want to answer the questions the hub only gestures at: what DV/OV/EV actually mean, how coverage scope works, why free automated certs are fine, how certificate chains break in ways that hide from your own testing, and what genuinely happens to crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. — not just users — when a cert goes bad.

”SSL certificate” is really a TLS certificate

SSL is obsolete terminology for modern TLS deployments. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 8446: TLS 1.3 Search guidance focuses on valid, accessible HTTPS rather than commercial certificate tier. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTPS

Quick naming note, then I’ll move on: SSL (Secure Sockets Layer) is the deprecated protocol; everything issued today runs on TLS (Transport Layer Security). “SSL certificate” survives as the colloquial name — Google’s own Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. strings still say “SSL certificate problems.” I’ll use “certificate” for the rest of this piece.

Validation depth: DV vs OV vs IV vs EV

Certificates are issued at different validation levels, which describe how much the certificate authority (CA) checked before vouching for you. Per SSL.com’s breakdown:

  • DV (Domain Validation) is “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” It’s fast, cheap or free, and usually automated (prove you control the domain via a DNS record or a file the CA can fetch).
  • OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.”
  • IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.”
  • EV (Extended Validation), “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.”

Here’s the SEO-relevant point: Google doesn’t document a ranking difference between validation levels. The hub establishes that the base signal reads the URL scheme — Illyes described it as looking at the first five characters in front of the URL. As long as the HTTPS is valid and working, a DV cert, an OV cert, and an EV cert all get the same treatment. The pricing difference between them reflects the CA’s vetting effort and liability, not a Google preference — web.dev says plainly that “different CAs charge different amounts of money for the service of vouching for your public key.” The extra money buys human-facing and organizational trust, full stop.

And the one remaining human-facing argument for EV has largely evaporated: EV’s special browser address-bar treatment is effectively gone. Chrome removed the green company-name UI starting with Chrome 77 (2019), and Firefox 70 followed the same year. So the “customers see our company name in the bar” pitch that used to justify EV’s price no longer holds in mainstream browsers — verify current browser behavior if you’re making a purchasing decision, but as of now that visual signal is not there.

Coverage scope: single-domain vs wildcard vs SAN

Validation depth is one axis. Coverage scope — which hostnames a certificate actually secures — is a completely separate one. Any scope can generally be issued at DV or OV (wildcards are usually not offered at EV under CA/B policy):

  • Single-domain — covers exactly one hostname, e.g. www.example.com.
  • Wildcard — covers one hostname pattern one DNS label deep. web.dev is precise about the limit: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” That last clause is the trap — a wildcard does not cover second-level subdomains.
  • SAN / multi-domain (UCC) — an explicit list of specific hostnames in the certificate’s Subject Alternative Names. web.dev notes you have “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” A SAN cert can even span entirely different domains, which makes it useful when you have a handful of related properties and don’t want to over-provision wildcard coverage.

The practical SEO failure mode hides in the wildcard’s single-label limit. Say you run *.example.com and someone spins up staging.blog.example.com — that’s two labels deep, outside the wildcard, and it’ll serve a certificate error or fall back to a mismatched cert. If Google or a user hits it, they get a broken-cert experience on a page you thought was covered.

One more coverage trap: a passing test on your apex hostname doesn’t prove coverage everywhere. A client has to request the exact hostname it’s connecting to and get back a certificate that actually names that hostname (via SNI) — on CDNs, load balancers, and SNI-based shared hosting, different edges, regions, or origins behind the same domain can legitimately serve different certificates. Test each public hostname independently rather than assuming one clean SSL Labs result on example.com speaks for www., a regional edge, or a subdomain behind a different origin.

Let’s Encrypt and free automated issuance

Let’s Encrypt and other free CAs issue DV certificates through the ACME protocol — an automated request/challenge/issue loop that clients like Certbot run for you. Two things people get wrong here:

  1. Free does not mean weaker. A Let’s Encrypt certificate provides the same TLS encryption strength as a paid one and, because Google’s signal is scheme-based, the exact same ranking treatment. The only real trade-offs are that it’s DV-only (no OV/EV identity vetting) and short-lived.
  2. The short lifetime is a feature once it’s automated. Short-lived certs mean a smaller window of exposure if a key is ever compromised, and — critically — no human has to remember to renew. Automation turns the shortest lifetime into the safest one.

That second point is about to matter for everyone, not just Let’s Encrypt users.

The certificate-lifetime shift (2026–2029) — automate now

The industry is collapsing certificate lifetimes on a fixed schedule. The CA/Browser Forum passed Ballot SC-081v3 (voting closed April 11, 2025), cutting the maximum TLS certificate validity in phases:

  • 398 days today
  • 200 days from March 15, 2026
  • 100 days from March 15, 2027
  • 47 days from March 15, 2029

Let’s Encrypt is moving on its own, faster track too: per its February 2026 update, it’s phasing its default certificate lifetime down in two steps over the following two years — “from 90 days to 64 days, and then 45 days” — with renewal timing shifting from around day 60 of a 90-day certificate today to around day 30 once certificates are down to 45 days. That update superseded an earlier, more specific timeline; treat the exact rollout dates for each step as not yet locked and check Let’s Encrypt’s own changelog before relying on a specific date.

The operational takeaway is blunt: if your renewal isn’t already automated, fix that before 2027. A manual renewal cadence that was survivable at 398 days becomes a near-guaranteed outage at 47–100 days. DigiCert’s coverage of the ballot puts it well — manual revalidation stays technically possible but “doing so would be a recipe for failure and outages.” Automation stops being a nice-to-have and becomes the only sane option.

Certificate chain / intermediate certificate failures

This is the underexplained one, and Google’s docs don’t cover it mechanically, so here’s how it actually works.

A browser only trusts a small set of root certificates baked into its trust store. Your server’s certificate — the leaf or end-entity cert — is almost never signed directly by a root. Instead there’s a chain: leaf → one or more intermediate certificates → trusted root. For a client to trust your leaf, your server has to send the leaf plus the intermediate(s) so the client can build the path up to a root it already trusts.

The classic misconfiguration is a server that sends only the leaf and omits the intermediate. And here’s why it’s insidious: desktop Chrome often still works, because it caches intermediates it has encountered on other sites and can fill the gap. So the person testing on their laptop sees a green padlock and assumes everything’s fine. Meanwhile mobile browsers, many API/HTTP clients, and other tools that don’t have that cached intermediate fail the handshake outright. It’s a “works on my machine” bug at the TLS layer.

To catch it, don’t trust a desktop-Chrome spot-check. Use a tool that builds the chain from scratch:

  • SSL Labs’ Server Test flags “extra download” / incomplete-chain issues explicitly.
  • openssl s_client -connect example.com:443 -showcerts on the command line shows every certificate the server actually sends, so you can confirm the intermediate is there.

What happens when a certificate is invalid, expired, or self-signed

TIP Check the public handshake instead of trusting the homepage padlock

A failed secure handshake is a concrete availability signal. It does not diagnose every chain, hostname, expiry, SNI, or subdomain-coverage cause by itself.

Run each important hostname through my Website Safety Checker to catch certificate warnings, then use a dedicated TLS analyzer for the exact chain diagnosis. Website Safety Checker Free

  1. Inventory the root, www, application, marketing, international, and legacy hostnames separately.
  2. Confirm the public TLS handshake succeeds for each hostname from outside the origin network.
  3. Fix the certificate or chain, then verify automated renewal and expiry monitoring before closing the incident.
Certificate health is hostname-specific; one working homepage does not cover the estate.

This is the section that matters most, and it splits cleanly in two — because users and crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. experience a broken certificate differently.

What users and browsers do. A hard cert failure — expired, self-signed, hostname mismatch, untrusted CA — triggers a full-screen interstitial warning, not the calm “Not Secure” label HTTP gets. Users bounce. The best documented case is Glenn Gabe’s “A Wolf in Panda’s Clothing” — an ecommerce site’s traffic cratered on a date that coincided with a Google Panda update, and the owner assumed a penalty. The real cause was an expired certificate throwing browser warnings; visitors abandoned before reaching the site. As Gabe put it: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” Renew the cert, traffic recovered within about eight days. Self-signed certs behave the same way in the wild — a hard interstitial, so they’re fine for internal/dev/staging and never appropriate on a public production site.

What Google does. This is the nuance almost every competitor page misses, and it’s more consequential than the “the signal is scheme-based” framing alone suggests. Google’s own canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. guidance is explicit that a broken certificate is not invisible to Search: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” and it names bad certificates directly as one of those issues — “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” In other words, a genuinely broken cert can flip which version of the page Google treats as canonical, back to plain HTTP — a real effect on what shows up in Search, not just a crawl-budget footnote.

Separately, Google’s Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. documentation says certificate failures also have a crawl consequence: an invalid certificate “typically affects an entire site,” and “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” When that happens, remaining URLs get labeled “HTTPS not evaluated.” So there are two distinct mechanisms here — a canonical-preference flip back to HTTP, and a separate crawl-access throttle — and either can produce the same visible symptom (pages falling out of the indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.) without touching the base https:// ranking signal itself. Fix the certificate; there’s no ranking-factor lever to chase here, but there’s also no “it’s harmless because the scheme didn’t change” free pass.

Google’s own list of what triggers these errors matches the failure taxonomy: the hostname not matching the certificate’s names — “The host name of your site does not match any of the Subject Names in your SSL certificate” — and certificates that are “not recognized by major web browsers” (self-signed, untrusted CA, corrupted, or outdated/not-yet-valid).

Expiration monitoring and auto-renewal

Expiration is the most common and most preventable certificate failure, and its blast radius is asymmetric — it usually breaks the whole site at once (Google: “Typically this affects an entire site”), not one page at a time. The fix is never a calendar reminder. Set up real automation:

  • ACME / Certbot on your own server, or the equivalent your platform ships.
  • Host- or CDN-managed certificates (Cloudflare, most managed hosts, many PaaS platforms) that issue and renew for you automatically.
  • A third-party certificate/uptime monitor that alerts on approaching expiry and handshake failures, as a backstop even when renewal is automated.

As lifetimes fall toward 47 days, manual reminders become mathematically untenable — automation is the only approach that scales.

Mixed-cert setups across subdomains

This is distinct from mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. (an HTTPS page loading HTTP sub-resources — covered in the hub). Mixed-cert is when different parts of your site are secured by different certificates on different schedules or platforms. The common pattern: your primary domain has a rock-solid cert, but blog.example.com runs on a different platform with its own cert that expires on its own timeline, or a marketing subdomain on a separate CDN was never covered by the wildcard’s single-label limit, or SNI-based multi-tenant hosting quietly breaks one subdomain’s renewal while the main domain looks perfect in a spot-check.

The lesson: a valid padlock on your homepage tells you nothing about coverage elsewhere. Take a subdomain inventory, confirm every host has valid, monitored cert coverage (via its own cert, a wildcard that reaches it, or a SAN cert that lists it), and don’t rely on a single-hostname SSL Labs check to certify the whole property.

Common myths

  • “A paid or EV certificate ranks better than a free DV cert.” No — the signal is scheme-based; validation depth is invisible to Google.
  • “Wildcard certificates cover all subdomains, including sub-subdomains.” No — one DNS label only; *.example.com does not cover foo.bar.example.com.
  • “An expired certificate directly hurts my rankings.” Not via the base ranking signal — but it can flip Google’s normal HTTPS-over-HTTP canonical preference back to HTTP (HSTS can’t override this), and separately, enough HTTPS issues can prompt Google to stop crawling your HTTPS pages entirely. Both are real effects; neither runs through the ranking signal itself.
  • “Let’s Encrypt certificates are lower quality than paid ones.” No — same encryption, same ranking treatment; the difference is DV-only validation and short (soon industry-standard) lifetimes.
  • “If my homepage shows a valid padlock, my whole site’s certs are fine.” No — subdomains carry separate, differently-scheduled certificates.
  • “Chain errors are rare or a legacy problem.” No — they’re common on any stack that serves only the leaf, and desktop-Chrome cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. hides them from the person testing.

This is the certificate-level deep dive under the HTTPS hubHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'; for the migration playbook, mixed content, and HSTS, start there.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.