Should you really use hreflang between canonical versions in HTTP and HTTPS?

Why does Google emphasize the distinction between canonical versions and hreflang?

Google crawls and indexes pages through a process where each URL is evaluated independently. When a site offers the same content in HTTP and HTTPS, the engine must identify which version to keep in its index. If you deploy hreflang tags pointing to both HTTP and HTTPS, you send conflicting signals.

The concrete risk: Google may index the wrong version, dilute PageRank among duplicates, or completely ignore your hreflang annotations. Mueller clarifies that rel=canonical is specifically designed to resolve this choice before hreflang comes into play. In other words, canonize first, then structure your multilingual annotations.

What is the logical sequence for implementation?

First step: fully migrate to HTTPS if you haven't done so already. Set up rel=canonical from all your HTTP URLs to their HTTPS equivalents. Ensure these canonicals are consistent in the HTML, XML sitemaps, and HTTP headers.

Second step: once this foundation is solid, deploy hreflang exclusively between the canonical versions. If your canonical French version is https://example.fr/, your hreflang from the English version must point to https://example.fr/, never to http://example.fr/. This discipline prevents Google from interpreting your annotations as loops or conflicts.

How does this recommendation differ from a simple best practice?

Many multilingual sites configure hreflang by copying and pasting templates without checking protocol consistency. Some CMS automatically generate relative annotations (without a protocol), while others mix HTTP and HTTPS depending on the site sections. Mueller identifies this as a common source of silent bugs.

The nuance: it is not just a protocol issue. It is a hierarchy of signals. Google first reads rel=canonical to identify the master page, then hreflang to map language variants. Inverting this order or mixing them leads to unpredictable behaviors, especially on high-volume sites.

• Use hreflang only between canonical URLs — never between duplicated HTTP/HTTPS versions
• Use rel=canonical to eliminate protocol duplicates before any hreflang annotation
• Audit consistency: ensure that each hreflang tag points to the URL that Google is actually indexing
• Test via Search Console using the Coverage and Performance reports to detect cross-canonicalization errors
• Don't assume your CMS handles this automatically — many multilingual plugins overlook this detail

Is this guideline strictly enforced by Google?

Field observations indicate that Google tolerates some ambiguity in hreflang/canonical configurations, especially on smaller sites. However, once the number of multilingual pages exceeds a few hundred, inconsistencies create visible symptoms: pages in the wrong language in local SERPs, cannibalization among versions, error messages in Search Console.

Mueller offers a defensive recommendation here. It is not that Google refuses to index a poorly configured site, but it will arbitrate according to its own logic — and you lose control. In practice, I have seen sites where Google indexed the HTTP version of a FR page and the HTTPS version of an EN page, creating a confusing mix that teams took months to rectify.

What nuances should be added to this rule?

First point: this recommendation assumes that you have already migrated to HTTPS. If your site is still serving HTTP in production, correcting hreflang will resolve nothing. The top priority remains a complete SSL migration, including 301 redirects. Hreflang comes after, not before.

Second point: Mueller does not specify how to handle transition periods where HTTP and HTTPS coexist temporarily. [To be verified]: should you wait until 100% of pages are migrated before deploying hreflang, or can it be configured incrementally? Field feedback suggests that migrating in language blocks (all FR pages first, then EN, etc.) limits conflicts, but Google has never officially documented this approach.

When does this rule not apply or become secondary?

If your site has only one language, hreflang does not concern you — only rel=canonical matters for managing HTTP vs HTTPS. Confusion arises on multilingual sites where technical and editorial teams do not share the same vision regarding the canonical architecture.

Another edge case: subdomains or distinct domains by language (e.g., fr.example.com vs en.example.com). Technically, each subdomain can have its own canonization policy. However, the hreflang annotation between them must still point to the versions you want to see indexed. Here, the risk is lower because the URLs are already distinct, but protocol consistency remains critical to avoid redirection loops.

What concrete actions should be taken on an existing site?

First action: crawl your site using a tool configured not to follow redirects (Screaming Frog in "Don't follow redirects" mode). Export all hreflang and rel=canonical tags. Cross-reference the data: identify the lines where hreflang points to an HTTP URL while the canonical is in HTTPS, or vice versa.

Second action: correct the templates responsible for automatic generation. On WordPress, check the settings of plugins like WPML, Polylang, or Weglot. For proprietary CMS, audit the configuration files or scripts that inject these tags. The goal: ensure that each hreflang tag uses the same protocol as the canonical URL of the page.

What errors should be avoided when achieving compliance?

Common mistake: correcting hreflang without addressing redirects. If your HTTP URLs redirect to HTTPS but your hreflang tags still point to HTTP, Google follows the redirect but wastes crawl time and may misinterpret the annotation. Always synchronize both layers.

Another trap: forgetting XML sitemaps. Some sites declare HTTP URLs in their multilingual sitemaps while the HTML points to HTTPS. Google generally favors HTML, but this inconsistency slows down indexing and generates warnings in Search Console. Update your sitemaps to declare only the HTTPS canonical versions.

How can I check if my site is now compliant?

Use the Coverage report in Search Console to spot pages marked as "Detected, currently not indexed" or "Crawled, currently not indexed". Often, these statuses indicate unresolved hreflang/canonical conflicts. Filter by language or site section to isolate issues.

Complement with a manual test on a few key pages: inspect the HTML source code, check that each <link rel="alternate" hreflang="..."> tag points to a URL in HTTPS. Use the "URL Inspection" tool in Search Console to see which version Google has actually indexed. If the indexed URL differs from your declared canonical, you have an issue with consistency to resolve.

• Crawl the site without following redirects to detect HTTP/HTTPS inconsistencies in hreflang and canonical
• Update CMS templates or generating scripts to enforce HTTPS protocol everywhere
• Synchronize the XML sitemaps with the canonical versions declared in HTML
• Verify in Search Console that multilingual pages are indexed in the correct language and version
• Manually test a few representative URLs by inspecting source code and using the URL Inspection tool
• Document the final configuration for future technical teams (CMS change, redesign, etc.)