Do redirects really outweigh the HTTPS signal when it comes to choosing the canonical URL?

What is canonicalization and why does Google prioritize signals?

Canonicalization refers to the process by which Google chooses which version of a URL to index and display in the results when multiple variants exist. The same content can appear with or without www, in HTTP or HTTPS, with or without a trailing slash.

Google cannot index all these variants without creating duplicate content. It must therefore make a decision. For this, it uses a series of weighted signals: redirects, canonical tags, XML sitemaps, internal links, HTTPS protocol, etc. What Illyes reveals is the hierarchy among these signals — and it is significant.

Why does a redirect take precedence over HTTPS?

The logic is ultimately quite simple: a 301 or 302 redirect explicitly informs Google (and the browser) that the requested URL is no longer correct. The end user will see the destination of the redirect, not the original URL.

HTTPS is merely a preference signal. Google favors secure versions, certainly, but if you actively redirect to an HTTP version (rare, but it happens in legacy configurations), then that destination becomes canonical. A redirect is a direct order, whereas HTTPS is a ranking suggestion.

What does this practically change for a site migrating to HTTPS?

If you are migrating to HTTPS and your 301 redirects are well configured (HTTP → HTTPS), Google will follow the redirect and index the HTTPS version. The HTTPS protocol then becomes a secondary signal that reinforces the choice, but it is the redirect that does the heavy lifting.

Conversely, if your redirects are all over the place — some HTTP pages redirect to HTTPS, others do not, or worse, there are redirect loops — Google will struggle to determine the canonical version. The HTTPS signal will never compensate for a poorly structured redirect architecture.

• A 301/302 redirect always trumps the HTTPS signal in the choice of the canonical version
• The HTTPS protocol remains a ranking factor (slight), but it does not surpass a direct redirect directive
• Failed HTTPS migrations are often due to inconsistent redirects, not an SSL certificate issue
• This hierarchy also applies to other signals: canonical, sitemap, internal links — redirect remains the strongest signal
• Understanding this weighting can help avoid authority consolidation mistakes during redesigns or migrations

Does this statement align with field observations?

Yes, and it’s even a welcome confirmation. In the field, it has been observed for years that properly configured 301 redirects systematically enforce canonicalization, even when other signals (canonical tags, sitemaps) point elsewhere. Google follows the chain of redirects to the final destination.

What is interesting is that it finally clarifies why some HTTPS migrations stagnate: if the redirects are not 100% consistent, Google may hesitate between multiple versions. The HTTPS signal alone is not sufficient to make a determination. We regularly see sites with impeccable SSL certificates but with HTTP → HTTPS redirects that do not cover all the variants (www/non-www, trailing slash, URL parameters).

In what cases does this rule not strictly apply?

Be cautious, this hierarchy works under normal conditions. However, if you create a redirect chain of 8 jumps or a redirect cycle, Google will simply give up and choose arbitrarily. Similarly, if your redirects are served with a 200 code instead of 301 (yes, this happens with poorly configured CMS), the signal is no longer interpreted as a redirect.

Another edge case: JavaScript or meta refresh redirects. Google can follow them, but they carry less weight than a true server 301. In these situations, other signals (canonical, HTTPS) may take precedence. [To be confirmed] if you are using JS redirects on a large scale — observations vary by niche.

What nuances should we add to this statement?

Illyes does not clarify if this hierarchy applies in the same way to 302 vs 301 redirects. In theory, both are followed, but a 302 indicates a temporary nature — therefore, Google might retain the original URL in memory for longer before fully switching over.

Another point: the phrasing “much more important” remains vague. We would like to know if it’s a 10/1 ratio, 50/1, or if it’s binary (redirect = absolute priority). Without numbers, it’s difficult to model complex cases precisely. What we know is that a well-configured redirect consistently overrides the HTTPS signal — the rest is interpretation.

What should you check after a migration to HTTPS?

First priority: audit all your HTTP → HTTPS redirects with a crawler (Screaming Frog, Oncrawl, Botify). Look for redirect chains (A → B → C), loops, and pages that still return a 200 code instead of 301. A single missing redirect can be enough to keep an HTTP version in the index.

Next, ensure that your internal links directly point to the final HTTPS version. If your internal links go through a redirect, you waste crawl budget and dilute authority. Google follows the redirect, of course, but each jump costs in efficiency.

What mistakes should you avoid to maintain the canonicalization signal?

Avoid multiplying contradictory signals. If you redirect HTTP to HTTPS, your canonical tags should point to the HTTPS version, your XML sitemap should only contain HTTPS URLs, and your internal links should be updated. Each inconsistency gives Google grounds to hesitate.

Also avoid cascade redirects: HTTP → HTTPS → www → trailing slash. Consolidate this into a single direct redirect. Google follows up to about 5 jumps, but beyond 2-3, you lose effectiveness and crawl budget. And above all, never allow 301 and 302 redirects to coexist pointing to different destinations — it guarantees erratic canonical choices.

How can you ensure that Google has indexed the correct version?

Use the Search Console to check which URL Google considers canonical. In the URL inspection tool, check the line “Canonical URL selected by Google.” If it doesn’t match your target HTTPS version, it means a stronger signal (misconfigured redirect, conflicting canonical) is pulling in the opposite direction.

You can also run a site:yourdomain.com in Google and visually check that all indexed URLs are indeed HTTPS. If you still see HTTP URLs in the results several weeks after migration, delve into server logs to understand why Googlebot continues to crawl them.

• Audit all HTTP → HTTPS redirects with a professional crawler
• Ensure that no redirect chain exceeds 2 jumps maximum
• Update all internal links to point directly to the final HTTPS version
• Make sure sitemap, canonical, and redirects point to the same version
• Check in Search Console that Google has indexed the HTTPS URLs as canonical
• Monitor server logs for any HTTP URLs still crawled after migration