Is your redirect chain preventing Google from choosing the HTTPS version as canonical?

What is a contradictory redirect chain?

A redirect chain becomes problematic when it doesn't consistently point to a single final version. Typically: HTTP → HTTPS → HTTP → HTTPS, or loops where certain internal elements (images, CSS, JS) still load in HTTP while the main page is in HTTPS.

Google follows these redirects to determine which URL should appear in its index. When signals get mixed — internal links pointing to HTTP, server redirects to HTTPS, then resources pulling back to HTTP — the algorithm hesitates. And when Google hesitates, it doesn't necessarily choose the version you want.

Why doesn't Google systematically force HTTPS?

You might think Google automatically prioritizes HTTPS these days. That's wrong. HTTPS is a positive ranking signal, but not an absolute canonicalization criterion.

If your technical signals (redirects, internal links, sitemaps, canonical tags) predominantly point to HTTP, Google can very well index that version. HTTPS migration isn't just about installing a certificate — it requires complete consistency in your architecture.

Which signals influence canonical selection?

• Server redirects: 301, 302, 307 — their direction and number matter
• Internal links: if 80% of your internal linking still points to HTTP, that's a strong signal
• Canonical tags: a tag pointing to HTTP negates the HTTPS effect
• XML sitemap: declared URLs must be in HTTPS
• Hreflang and other international SEO tags: same logic, consistency required
• Indexing history: Google remembers the old version if the transition is mishandled

Is this statement consistent with real-world observations?

Completely. We regularly see sites "migrated to HTTPS" that remain indexed in HTTP months after the switch. Not by accident — by technical inconsistency.

Classic cases: a site properly redirects HTTP to HTTPS with a 301, but the sitemap still declares URLs in HTTP. Or worse: mixed internal linking, with relative links that adapt to the calling page's protocol. Google crawls, sees HTTP everywhere, and prioritizes that version even though the SSL certificate is active.

What nuance should be added to this statement?

Allan Scott discusses "contradictory signals," but doesn't quantify them. [To verify]: what is Google's tolerance threshold? Do 10% of internal links in HTTP suffice to block HTTPS canonicalization? Or do you need 50%?

We lack precise data. What we know from experience: Google doesn't work in all-or-nothing mode. It aggregates signals, weights them, and decides. If the majority of signals point to HTTPS with clean redirects, it works. But as soon as there's hesitation, the risk is real.

In which cases does this rule not apply?

If your site never existed in HTTP — created directly in HTTPS with coherent redirects from the start — you're not affected. Same if you migrated cleanly with a complete before/after audit.

Conversely, multi-domain sites, partial migrations (subdomains in HTTP, main domain in HTTPS), or platforms with poorly configured CDNs are highly exposed. Geolocation-based or cookie-based redirects further complicate matters.

What should you verify first on your site?

First step: crawl your site with Screaming Frog, Oncrawl, or equivalent. Look at the "Protocol" column — all URLs must be in HTTPS. If you see HTTP, that's a direct contradictory signal.

Next, verify your redirects. Manually type your main URLs in HTTP into a browser and follow the chain. It should be direct: HTTP → HTTPS (301), with no intermediate steps. A chain HTTP → HTTP/www → HTTPS/www is already too long.

Which technical errors cause these problems?

• Internal links hardcoded with http: instead of relative or https:
• Canonical tags pointing to HTTP while the page is served in HTTPS
• XML sitemap declaring URLs in HTTP
• robots.txt file with sitemap URLs in HTTP
• External resources (CDN, widgets) called in HTTP on an HTTPS page (mixed content)
• Temporary redirects (302, 307) instead of permanent (301) during migration
• Hreflang or alternative tags pointing to HTTP
• Cached old versions (server, Cloudflare, Varnish) still serving HTTP

How do you fix and secure the HTTPS migration?

Start with a complete redirect audit. Use a tool like Redirect Path or Chrome DevTools (Network tab) to see the exact sequence. Every redirect must be a 301 permanent and point directly to the final HTTPS version.

Next, clean up your internal linking. Use a script or plugin (on WordPress: Better Search Replace) to replace all HTTP links with HTTPS. Also check canonical tags, hreflang, and Open Graph meta tags.

Update your XML sitemap and submit it via Search Console. Verify that Google indexes the HTTPS versions correctly by filtering coverage reports by protocol.