Part of the Website Security Checklist for SEO series. This post goes deep on the single most common point of failure: HTTPS that's "technically on" but quietly broken.
Why HTTPS Mistakes Are More Common Than You Think
"We have HTTPS" is one of the most confidently wrong statements in SEO. A green padlock on the homepage doesn't mean the rest of the site is clean. I've audited sites that installed an SSL certificate years ago and never checked again — accumulating mixed content, broken redirect chains, and silent certificate issues the whole time.
None of these mistakes require an attacker. They're configuration drift: a plugin update that hardcodes an old HTTP image URL, a CDN that was set up before the migration, a redirect rule someone added and forgot about. Each one is small. Together, they add up to real ranking and trust damage.
Mixed Content Errors
Mixed content happens when an HTTPS page loads any resource — image, script, stylesheet, font, iframe — over plain HTTP. Modern browsers block "active" mixed content (scripts, stylesheets) outright and flag "passive" mixed content (images) with a warning icon in the address bar.
- Check every page type — homepage, blog posts, product pages — not just one sample
- Search your database or CMS for hardcoded
http://URLs, especially in older content - Update embedded third-party widgets (maps, video embeds, fonts) to their HTTPS versions
- Use protocol-relative or absolute HTTPS URLs going forward, never hardcoded HTTP
Ads, Widgets & Embeds That Break HTTPS
Your own files can be perfectly clean while a third party still breaks the padlock. Ad tags, chat widgets, review badges, map embeds and old tracking pixels load from servers you don't control, and a provider that serves content over HTTP or with a broken certificate triggers mixed-content blocking or certificate errors on your pages.
- Open the browser console on pages that carry third-party tags and look for blocked or insecure requests
- Replace any tag that still references an
http://address with the provider's HTTPS version - Remove tags for services you no longer use; they fail silently and add risk for no benefit
- If a provider can't serve its content securely, replace the provider rather than weakening your own security settings
A blocked ad or widget doesn't look like an SEO problem, but it can leave an empty gap in the layout and fill the console with errors that hide real issues.
Expired & Misconfigured Certificates
Free certificates from Let's Encrypt auto-renew every 90 days — but only if the renewal automation is actually working. I've seen renewal cron jobs silently fail for months until the certificate finally expired and took the whole site offline with a browser security interstitial.
- Confirm auto-renewal is actually executing, not just configured
- Certificate covers every subdomain in active use (wildcard SSL if you have several)
- Certificate chain is complete — missing intermediate certificates cause errors on some browsers/devices even when others show no issue
- Set a calendar reminder to manually verify status every 60 days regardless of automation
Don't trust "it worked last time." Certificate automation is exactly the kind of thing that fails silently. A 5-minute manual check every two months catches it before visitors do.
Certificate Lifetimes Are Getting Shorter
Under a schedule agreed by the CA/Browser Forum, publicly trusted TLS certificates can no longer be issued for as long as they once were. Since 15 March 2026 the maximum validity is 200 days. It falls to 100 days in March 2027 and to 47 days in March 2029.
For site owners the practical meaning is simple: renewing a certificate by hand once a year is no longer a workable plan. Rely on automated renewal (most hosts, CDNs and Let's Encrypt clients handle this), monitor the expiry date from outside your server, and get an alert well before it lapses. If you buy certificates from a paid provider, ask how it handles renewal and reissue under the shorter limits.
Note: shorter lifetimes don't change your rankings. They raise the cost of a missed renewal, because an expired certificate shows visitors and crawlers a security error instead of your page.
Redirect Chain Problems
Every redirect hop adds latency and dilutes link equity. The classic failure pattern looks like: http://example.com → http://www.example.com → https://www.example.com → https://example.com. That's three redirects to reach the final URL, when it should be one.
- Pick one canonical version (HTTPS + your preferred www/non-www) and redirect everything else directly to it
- Test old URLs, old sitemaps, and backlinks — they often still point to outdated HTTP versions
- Use 301 (permanent) redirects, never 302, for protocol and domain canonicalization
- Re-check after any domain or hosting migration — this is when chains most often appear
Canonicals, Sitemaps & Structured Data Still Pointing at HTTP
A redirect isn't the end of an HTTPS migration. Every place your site names its own URLs has to agree with the version you want indexed. When canonical tags say http:// but the page loads on HTTPS, you are giving Google two different answers about which address is the real one.
- Canonical tags: use the full HTTPS URL, with your chosen www or non-www host
- XML sitemaps: list only final HTTPS URLs, not addresses that redirect
- Internal links: update navigation, footer and in-content links so visitors and crawlers don't pass through a redirect on every click
- Structured data and social tags: check the
urlandimagevalues in JSON-LD, andog:urlandog:imagein the page head - Hreflang, feeds and robots.txt: if you use them, make sure the sitemap line and every alternate URL use HTTPS
In Search Console, the Pages report can show "Duplicate, Google chose different canonical than user" when these signals disagree. If you see it on pages that should be unique, mismatched URLs are a likely cause.
Missing HSTS & Security Headers
HSTS (HTTP Strict Transport Security) tells browsers to never even attempt an HTTP connection to your domain again, closing the brief window where a user's first request could be intercepted before the redirect fires.
- HSTS header is present and includes subdomains if applicable
- Consider HSTS preload listing once you're confident the configuration is stable
- X-Content-Type-Options and X-Frame-Options headers are set as a baseline
Rolling Out HSTS Without Locking Yourself Out
HSTS is powerful because browsers remember it. That also makes mistakes expensive: if you enable it for a long time and then find a subdomain that doesn't support HTTPS, visitors can't reach it until the setting expires. Roll it out in stages:
- Confirm HTTPS everywhere first. Every page and every subdomain you use should load over HTTPS with no mixed content.
- Start with a short max-age. Use a few minutes, then raise it to a day, a week and a month while you watch for problems.
- Add
includeSubDomainsonly when every subdomain is ready, including ones used for email tools, staging or old campaigns. - Move to a long max-age of at least one year when you're confident.
- Treat preloading as a one-way door. Preload lists ship inside browsers, require a one-year max-age plus
includeSubDomains, and removal can take months.
Some hosts and CDNs already send an HSTS header. Check the response headers before adding your own so you don't send conflicting values.
A Safe HTTP-to-HTTPS Migration, Step by Step
If you are still moving a site to HTTPS, or have inherited a half-finished migration, this order avoids most of the damage:
- Install a valid certificate that covers every hostname you use, and confirm automatic renewal works.
- Fix mixed content in templates, the database, stylesheets and third-party tags before switching on redirects.
- Add one-hop 301 redirects from every HTTP and alternate-host URL to its HTTPS equivalent.
- Update canonicals, sitemaps, internal links and structured data to the final HTTPS URLs.
- Check Search Console. A Domain property covers HTTP and HTTPS together; if you use URL-prefix properties, add the HTTPS one and resubmit the sitemap.
- Update external references: ad campaigns, analytics settings, social profiles, email signatures and any listings that link to your site.
- Monitor for a few weeks. Watch crawl errors, indexed pages and traffic, and keep the redirects in place long term.
How to Audit Your Site for HTTPS Issues
| Tool | What It Catches | Cost |
|---|---|---|
| SSL Labs Server Test | Certificate chain, protocol support, configuration grade | Free |
| Screaming Frog | Site-wide mixed content and redirect chains | Free up to 500 URLs |
| Browser DevTools Console | Mixed content warnings, per-page | Free |
| Google Search Console | Indexing issues tied to redirect problems | Free |
Run a full crawl, fix what surfaces, then fold a quarterly re-check into the broader security checklist routine. HTTPS isn't a box you tick once — it's a setting that quietly drifts if nobody's watching.
Frequently Asked Questions
Yes. It has been a confirmed signal since 2014 and remains baseline expectation — browsers actively warn users away from HTTP sites, which hurts engagement metrics that feed into rankings indirectly.
It's when an HTTPS page still loads some resources — images, scripts, fonts, iframes — over plain HTTP. Browsers block or flag these, breaking functionality and showing security warnings.
No. Let's Encrypt provides free, browser-trusted certificates. The ranking signal is binary — HTTPS or not — so a paid certificate offers no SEO advantage over a free one.
Use SSL Labs' Server Test for certificate configuration, and your browser's DevTools Console (or Screaming Frog) to surface mixed-content warnings across the whole site.
Publicly trusted certificates have been limited to 200 days since March 2026 under the CA/Browser Forum schedule, falling to 100 days in 2027 and 47 days in 2029. Automatic renewal is now essential, not optional.
Yes. Choose one version, for example https://example.com, and 301 every other variant straight to it so there is one hop, not a chain. Match your canonical tags, sitemap and internal links to that version.
Yes, once every page and subdomain you use works on HTTPS. Start with a short max-age and increase it gradually, because browsers remember HSTS and it is hard to undo. Test before you commit to a long duration or preloading.
Worried a Hack Could Tank Your Rankings?
Security audits, malware cleanup, and hardening — so a breach never costs you the rankings you've worked for.
Get a Free Security Consultation