SSL Certificate Errors That Quietly Cost You Rankings

Most ranking drops don't announce themselves. You don't get an email from Google saying "your cert expired at 2 AM on a Saturday and we've been demoting you for three weeks." You get a slow bleed in impressions, a confused client, and a support ticket from their hosting company saying "SSL renewed, should be fine now." It's not fine.

SSL issues aren't just a security problem. They're a crawling problem, a link equity problem, and an indexing problem that agencies consistently underweight because the site "looks fine" in a browser that auto-accepted the cert warning.

HTTPS as a Ranking Signal

Google confirmed HTTPS as a ranking signal in 2014. That's not the interesting part. The interesting part is what happens when HTTPS is broken in ways short of a full cert failure: mixed content, redirect splits, incomplete chains. These degrade trust signals without triggering the full browser warning, so they sail through client reviews unnoticed.

Googlebot follows redirects and respects HTTPS. But it won't crawl pages that fail SSL validation. If your cert is self-signed, expired, or issued for the wrong domain, Googlebot logs a crawl error and moves on. The page stays indexed from cache until it times out—which can take weeks.

Use Recon's SSL Certificate Checker to surface cert issues before they show up in Search Console as crawl anomalies.

Expired Certificates: The Silent Killer

A cert that expired yesterday isn't a problem you need to diagnose. But a cert that expires in 11 days while your client is on vacation? That's your problem.

Certificate expiry timelines matter:

• 90-day certs (Let's Encrypt default) need auto-renewal working reliably
• 1-year certs (common on cPanel hosting) expire quietly if email notifications go to a defunct address
• Multi-domain (SAN) certs fail for ALL domains when the cert expires, not just one

When a cert expires, modern browsers show a hard block. Googlebot shows the same error in coverage reports. The page goes non-crawlable. Any links pointing to it stop passing equity until the cert is restored and Google re-crawls.

# What you see in a crawl log when SSL fails
2026-04-03 03:22:11 ERROR ssl_certificate_verify_failed
URL: https://example.com/services/
SSL Error: certificate has expired
Issued: 2025-01-15, Expired: 2026-04-01

Check renewal confirmation emails exist, auto-renewal is enabled, and the hosting account email is monitored.

Mismatched Certificates

A certificate issued for www.example.com does not cover example.com. A cert issued for example.com does not cover shop.example.com. When the hostname doesn't match the cert's Common Name or Subject Alternative Names (SANs), you get a mismatch error.

Common mismatch scenarios agencies encounter:

• Site migrated to a new domain, old cert still active on a redirect chain
• Subdomain added (blog, shop, app) without updating the SAN cert
• CDN or load balancer terminating SSL with a shared cert that doesn't list the client's domain

# OpenSSL check for SAN coverage
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# Output showing mismatch:
# DNS:www.example.com
# (example.com without www is NOT listed — mismatch)

If the cert doesn't list both example.com and www.example.com, one of those variants will throw a mismatch error for visitors and crawlers using the non-covered version.

HTTP→HTTPS Redirect: The Link Equity Split

Here's the scenario that kills more link equity than any other cert issue: a site has valid HTTPS, but inbound links pointing to http:// don't redirect properly to https://.

Every link posted to http://example.com/page/ that hits a 301 to https://example.com/page/ should pass equity with minimal loss. But if that redirect goes through two hops—http:// → https://www. → https:// (or any similar chain)—you're bleeding PageRank at every hop.

Worse: if there's no redirect at all, http://example.com and https://example.com become two separate URLs in Google's eyes. Links split between them. Neither version gets full credit.

The correct configuration is exactly one redirect:

# Nginx: HTTP → HTTPS in a single hop
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Verify this with a redirect trace tool. You should see one hop, status 301, destination is the canonical HTTPS version.

Mixed Content: Broken After Migration

HTTPS migrations that don't update every asset reference leave mixed content: a page served over HTTPS that loads images, scripts, or stylesheets over HTTP. Browsers block active mixed content (scripts, stylesheets) entirely. They warn on passive mixed content (images, iframes).

Google treats mixed-content pages as partially insecure. More practically, blocked scripts often mean broken functionality that tanks conversion rates.

<!-- Mixed content: page is HTTPS, image is HTTP -->
<img src="http://example.com/wp-content/uploads/hero.jpg" alt="Hero">
 
<!-- Fixed: protocol-relative or HTTPS explicit -->
<img src="https://example.com/wp-content/uploads/hero.jpg" alt="Hero">

WordPress sites are the most common culprit. The siteurl and home options in wp_options often stay set to http:// after a migration, which causes every media upload URL to render as HTTP. Fix with:

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl', 'home');

Then run a content search for src="http:// and href="http:// across the database to catch hardcoded asset URLs.

Intermediate Certificate Chain Issues

A cert is issued by a Certificate Authority (CA), which is itself trusted by a root CA. The intermediate cert is the link between your site cert and the root. When the intermediate cert isn't included in the server's cert bundle, some clients—particularly older mobile devices, automated crawlers, and API clients—can't verify the chain and refuse the connection.

Browsers often compensate by fetching missing intermediates automatically. Googlebot doesn't. If the chain is incomplete, Googlebot logs a verification failure.

# Check chain completeness with openssl
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -subject

# Check the full chain
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E "^(s:|i:)"

A complete chain shows: your cert → intermediate CA → root CA. If it jumps straight from your cert to root, the intermediate is missing.

Fix: download the full chain bundle from your CA and configure your server to serve it. For Apache, this is the SSLCertificateChainFile directive. For Nginx, concatenate the intermediate cert into your cert file.

Self-Signed Certificates

Self-signed certs are appropriate for internal development environments. They are never appropriate for production sites. A self-signed cert will throw a hard browser error for every visitor and a crawl error for every bot.

Agencies encounter these most often on:

• Staging environments accidentally made public
• Client sites migrated to new hosts where SSL wasn't set up properly
• Old subdomains (mail, internal, legacy) that still resolve publicly

# Identify self-signed certs
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject | grep -c "issuer=.*subject="
# Output of 1 means issuer == subject == self-signed

If a staging URL shows up in Search Console (it happens), and it's running a self-signed cert, you have a dual problem: unintended indexing and crawl failures.

What to Skip in Cert Audits

Skip obsessing over certificate transparency logs unless you're dealing with a client in financial services or healthcare. CT logs matter for compliance, not rankings.

Skip extended validation (EV) certs as an SEO recommendation. EV certs used to show a green company name in the browser bar. Browsers removed that UI in 2019. EV certs are now a compliance/brand choice, not an SEO factor.

Skip the "just force HTTPS in .htaccess" shortcut without checking whether it creates redirect chains. A blanket redirect rule that doesn't account for existing redirects will chain-stack and compound the problem.

Monitoring Cert Expiry Proactively

Cert expiry monitoring is a deliverable you should include in any retainer. Minimum setup:

• Uptime Robot or Better Uptime with SSL expiry alerts at 30 days and 7 days
• cron-job.org or similar for a weekly check against /api/ssl-check?domain=
• Search Console integration review monthly for new SSL-related crawl errors

The typical agency first learns about a cert expiry when a client calls saying "our site is showing a security warning." That's 48-72 hours of lost traffic and trust. Proactive monitoring turns that into a 5-minute renewal task.

Running the Audit

For any new prospect site, run Recon's SSL Certificate Checker as the first technical check. It validates: cert validity, expiry date, SAN coverage, chain completeness, HTTP→HTTPS redirect, and mixed content indicators. You get a graded output that maps directly to a proposal line item.

Most client sites have at least one SSL issue. The question is whether it's a minor config note or an active crawling problem.

The audit one-liner for SSL: Expired, mismatched, and chain-incomplete certificates block Googlebot from crawling your pages entirely—fix these before any other technical SEO work, because nothing else matters if the page can't be fetched.

Related reading

• Security Headers Every Website Needs
• Robots.txt Mistakes That Are Tanking Rankings
• The Most Common Audit Failures