Hreflang vs Canonical Conflicts

Your hreflang setup looks correct. Every page in the cluster links to every other page, the return tags check out, the language codes are valid. And yet Google Search Console still shows your German page as "Alternate page with proper canonical tag" and it never shows up for German searchers at all.

Nine times out of ten, the hreflang markup isn't the problem. The canonical tag is quietly undoing it — pointing that German page back to the English original, which tells Google the two pages aren't independent at all, no matter what the hreflang tags claim. Two correct-looking signals, sent from the same page, saying opposite things.

What is a hreflang/canonical conflict?

Hreflang and canonical tags exist to solve two different problems, and most of the time they coexist without issue. A conflict appears specifically when a page's canonical tag points somewhere other than itself, while that same page is also listed as a distinct hreflang alternate.

• Canonical says "I'm not the main version." A canonical tag pointing away from a page tells Google to consolidate ranking signals into a different URL — effectively deprioritizing the page it's on.
• Hreflang says "I'm the version for this audience." A hreflang entry claims the same page as an intentional, independently rankable localized version for a specific language or region.
• The two can't both be true. A page can't simultaneously defer its ranking to another URL and expect to rank on its own for a different market.
• It's almost always accidental. The usual cause is a canonical tag left pointing at the primary-market page, often copied from a template that was never adjusted for translated versions.

The rule that resolves nearly every case: every page inside a hreflang cluster should carry a self-referencing canonical, pointing to its own URL, not to any of its alternates.

Why it matters

A conflicting canonical doesn't just create a warning in Search Console — it changes what actually shows up in search results:

• The localized page can disappear from its own market. If Google consolidates signals to the canonical target, the localized URL may never surface for searches in its intended language or country.
• Hreflang gets disregarded for that URL. Google generally treats the canonical as the stronger of the two signals, so the hreflang annotation on a conflicting page is often ignored rather than overridden.
• It's invisible until you check Search Console. The pages still exist, still render correctly, and still pass most manual checks — the conflict only shows up in crawl and indexing reports.
• It undermines an otherwise correct setup. Teams often spend effort perfecting return tags and language codes while one canonical line quietly cancels the entire cluster for a given page.

Step-by-step: auditing and fixing the conflict

1. List every URL in each hreflang cluster. Pull the full set of localized pages that reference each other as hreflang alternates.
2. Check each page's canonical tag. Confirm whether it points to itself or to a different URL in the cluster — a different URL is the conflict.
3. Set every canonical to self-reference. Update the canonical href on each localized page to match that page's own URL exactly.
4. Re-verify the hreflang return tags. While you're auditing, confirm every page in the cluster still links back to every other page, including itself.
5. Recrawl and resubmit. Request indexing on the corrected pages or wait for the next crawl, since a cached conflicting canonical can persist briefly after the fix.
6. Confirm in Search Console. Check the International Targeting report and Coverage report to verify the "Alternate page with proper canonical tag" warning clears for those URLs.

Common mistakes that cause the conflict

1. Canonical pointing to the default-language page

The most frequent cause: a translated page's canonical tag is left pointing at the English or primary-market original, usually inherited unchanged from a shared template.

2. Treating translated pages as duplicate content

Canonicalizing a Spanish page to its English counterpart makes sense for near-duplicate tracking-parameter URLs, but translated content is not duplicate content — it needs its own canonical, not a consolidated one.

3. CMS or plugin defaults that auto-canonicalize

Some multilingual CMS setups default every translation's canonical to the "original" post ID unless manually overridden, silently creating the conflict at scale across an entire site.

4. Fixing hreflang without checking canonical

Teams that troubleshoot a hreflang warning often re-verify language codes and return tags while never checking whether the canonical tag on the flagged page is the actual cause.

5. Query parameters or trailing slashes mismatched with canonical

Even a self-referencing canonical can conflict if it doesn't exactly match the hreflang href — a missing trailing slash or an extra tracking parameter is enough to break the match.

Real-world examples

How the conflict shows up across different kinds of multilingual and multi-region sites:

The pattern across all four: the hreflang markup was rarely wrong. The canonical tag, added for an unrelated reason, was the actual point of failure.

Hreflang vs canonical: what each one does

They're often confused because both live in the page head and both affect indexing — but they answer different questions.

Generate your hreflang tags right now — free

The Rebrixe Hreflang Generator builds a complete, return-tag-safe set of hreflang link tags for every page in your cluster, including x-default, so you can pair it with correctly self-referencing canonicals and avoid this conflict from the start. No account, no watermark.

Frequently asked questions