Hreflang and Canonical Conflict: A Safe WordPress Fix

A hreflang canonical conflict occurs when a WordPress site tells search engines that one URL is the preferred version while its language or regional markup points to a different URL. This commonly happens on multilingual sites, translated product pages, country-specific landing pages, or staging-to-production migrations.

The fix is not to remove canonical tags or hreflang blindly. Each signal has a different job: the canonical tag identifies the preferred version of substantially similar pages, while hreflang connects equivalent pages intended for different languages or regions. They should support the same URL structure rather than contradict it.

What canonical and hreflang tags each do

A canonical tag looks like this:

<link rel="canonical" href="https://example.com/fr/produit/" />

It tells search engines which URL should represent a page when several URLs contain duplicate or near-duplicate content. A page should normally have a self-referencing canonical unless there is a deliberate reason to consolidate it elsewhere.

Hreflang markup connects equivalent pages for different audiences. For example:

<link rel="alternate" hreflang="en" href="https://example.com/product/" /><link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/" /><link rel="alternate" hreflang="x-default" href="https://example.com/product/" />

These URLs are alternatives, not duplicates to be collapsed into one page. Google may use the markup to show the appropriate language or regional version, but hreflang does not force indexing and does not replace canonicalization.

How a hreflang and canonical conflict happens

One language page canonicals to another language

Suppose the English page is /product/ and the French page is /fr/produit/. If both pages use the English URL as their canonical, the French page is effectively asking search engines not to treat it as an independent indexable version.

At the same time, hreflang may identify the French URL as the French alternative. Those instructions do not work well together because the French page does not clearly establish itself as a valid member of the language set.

Hreflang URLs redirect or return errors

Hreflang should point directly to final, indexable URLs. Problems arise when the URLs:

• redirect from HTTP to HTTPS or between www and non-www;
• redirect to a different language;
• return a 404, 403, or server error;
• are blocked by robots.txt or a security rule;
• contain tracking parameters or temporary query strings;
• are on a staging domain or an old site address.

Only some language versions reference one another

Hreflang annotations should be reciprocal. If the English page references French, the French page should reference English. Missing return references can make the language cluster unreliable, especially when a translation plugin generates markup inconsistently.

Two systems output different tags

A translation plugin, SEO plugin, theme, custom code, or server-side integration can each add language or canonical markup. The browser may then receive multiple canonical tags or conflicting hreflang sets. Search engines may choose one signal, but the result is unpredictable.

Run a safe diagnosis before changing settings

Do not start by editing theme files. First identify what the public page actually sends to visitors and crawlers.

1. Open the affected URL in a private browser window.
2. View the source, not only the rendered inspector. Search for rel="canonical" and hreflang.
3. Record every canonical URL and every language or regional URL.
4. Open each referenced hreflang URL and confirm that it is the final intended address.
5. Check whether each page links back to the other language versions.
6. Compare the markup for logged-out visitors with the markup seen after clearing caches.

There should generally be one clear canonical declaration in the document head. If you find multiple canonical tags, treat that as a separate configuration problem and trace which plugin, theme, or custom function creates each one. The guide to multiple canonical tags in WordPress explains that investigation in more detail.

Use one consistent URL set

Create a simple table for each language or region before making changes:

• Language: such as English or French.
• Public URL: the final HTTPS address.
• Canonical: normally the same URL for that page.
• Hreflang code: such as en, fr, or en-GB.
• Indexability: whether the page is allowed to be indexed.

For genuinely equivalent pages, the desired pattern is usually:

English page: canonical = https://example.com/product/French page:  canonical = https://example.com/fr/produit/

Both pages should then reference the complete set of alternatives:

English page:en       - https://example.com/product/fr       - https://example.com/fr/produit/x-default - https://example.com/product/

French page:en       - https://example.com/product/fr       - https://example.com/fr/produit/x-default - https://example.com/product/

The exact language codes depend on your targeting. A country-specific version may use a code such as en-GB rather than only en. Use the language and region your content actually serves; do not create country variants merely to add more tags.

Fix the conflict in the system generating the tags

When an SEO plugin controls canonicals

Open the page-level SEO settings and check the canonical field. Leave it blank if the plugin automatically generates a self-referencing canonical and the page should stand on its own. Add a custom canonical only when consolidation is intentional.

Then inspect the plugin’s global settings for taxonomy, attachment, parameter, or multilingual rules. Exact labels vary by plugin version. Avoid adding a second canonical through a header-injection field or theme snippet.

When a translation plugin controls hreflang

Use the translation plugin’s official URL and language settings as the source of truth. Confirm that every translation has a stable public URL and that translated pages are not set to noindex unless that is deliberate.

Do not manually add a second hreflang set if the plugin already outputs one. Duplicate or incomplete sets are more likely to create errors than solve them.

When custom code adds markup

Search the active theme, child theme, must-use plugins, and custom snippets for:

• rel_canonical;
• wp_head;
• hreflang;
• wpseo_canonical or similar SEO filters;
• hard-coded domain names from a previous migration.

Make changes in a child theme or a maintained custom plugin, not directly in a parent theme. Keep a backup and record the original code so the change can be reversed.

Check redirects, sitemaps, and internal links

Tags alone cannot repair inconsistent URL architecture. Every canonical and hreflang URL should resolve directly to a final page with the correct language content.

Review redirects for:

• HTTP versus HTTPS;
• www versus non-www;
• trailing slash differences;
• uppercase and lowercase paths;
• old translated slugs;
• domain changes after migration.

Your XML sitemap should contain the canonical URLs you want discovered, not obsolete redirected URLs or parameter variations. Internal links should also use the same final URL format. If one page links to an old address while its canonical points elsewhere, update the internal link rather than relying on a redirect.

If the issue appeared after changing SSL or a CDN, check for URL mismatches before changing SEO settings. A redirect configuration problem can affect every language version; the guide to WordPress redirect errors after SSL or Cloudflare changes covers that broader diagnosis.

Validate the corrected markup

After saving changes, purge the relevant page, plugin, server, and CDN caches. Then check the public source again from a logged-out session. Confirm all of the following:

• each page has one intended canonical;
• the canonical is a final HTTPS URL;
• the canonical is not unexpectedly pointing to another language;
• hreflang URLs use the same final URL format;
• language codes match the content and audience;
• language pages reference one another;
• the referenced pages are accessible and indexable when intended;
• the sitemap and internal links use canonical URLs.

Use the official Google documentation for localized versions to verify hreflang syntax and implementation details. Search tools may continue showing old observations until pages are crawled again, so do not undo a correct fix solely because a report does not update immediately.

When canonical and hreflang should not be combined

Not every page needs hreflang. Do not connect pages that are merely similar but serve different purposes, such as a product page and a category page. Do not use hreflang to connect unrelated regional content, thin placeholder translations, or pages that intentionally redirect.

If two URLs are true duplicates and there is no meaningful language or regional distinction, use canonicalization instead of hreflang. For a broader review of duplicate URL signals, see how to fix broken canonical tags and duplicate URL issues.

When to get professional help

Consider assistance if the conflict affects hundreds of URLs, appeared after a migration, involves several translation systems, or keeps returning after cache purges. A specialist can compare server responses, rendered HTML, sitemap entries, redirects, and plugin output without guessing at isolated tags.

For ongoing updates, security checks, and multi-site oversight, WP Fix It Care and Site Manager can be a practical option. If the site is already producing errors or serving the wrong URLs, take a backup before changing global rules.

The safest resolution is a consistent architecture: every language page has its own appropriate canonical, every equivalent page is referenced reciprocally with hreflang, and redirects, sitemaps, and internal links all use the same final URLs.

How to Fix Hreflang Pointing to a Non-Canonical URL

A hreflang URL should normally be the canonical URL of the corresponding language or regional page. If an English page lists a French URL in hreflang, but that French URL canonicals to the English page, the signals disagree. Search engines may ignore the hreflang relationship or choose a different URL for indexing.

Use this comparison to identify the source of the conflict:

• Hreflang target: the exact URL listed for the language or region.
• Canonical target: the URL declared by that target page in its document head.
• HTTP response: whether the target returns a successful response or redirects elsewhere.
• Indexability: whether the target is blocked, marked noindex, or unavailable to crawlers.

For each language version, open the final public URL while logged out and view the raw page source. Confirm that the page has one intended canonical, that the canonical uses the same URL format as the hreflang entry, and that the page references the other equivalent versions. A redirecting URL, a URL with tracking parameters, or a URL that differs only by HTTP, hostname, or trailing slash should be replaced with the final canonical address.

If the source contains duplicate canonicals or multiple hreflang sets, do not delete tags at random. Check which component generates each one: the SEO plugin, translation plugin, theme, custom code, cache layer, or server integration. Disable or reconfigure the duplicate source, then purge page, server, and CDN caches before testing again. Keep one system responsible for canonicals and one consistent system responsible for language relationships whenever possible.

For larger sites, record each affected URL, detected conflict, generating component, recommended change, validation result, and owner in a developer ticket. Crawl reports, XML sitemap comparisons, server responses, and Google Search Console coverage or indexing observations can help prioritize problems affecting many templates. Recheck the raw source after deployment; reports may continue showing older data until the corrected pages are crawled.