Hreflang Errors That Send International Visitors to the Wrong Page

First separate a search-result mismatch from an actual redirect

If a UK searcher sees the US URL in Google results, faulty or absent hreflang relationships may be involved. But the same outcome can occur when Google has not indexed the UK version, has selected an unexpected canonical, or has limited evidence that the pages are distinct local alternatives.

If the user clicks the UK URL and the browser immediately moves to a US URL, investigate the site’s redirect rules, CDN, geolocation scripts, or browser-language detection. Hreflang itself cannot perform that redirect. This distinction prevents a common wasted fix: changing annotations while leaving a forced country redirect untouched.

For a suspected redirect, inspect the destination with the Bulk HTTP Status and Redirect Checker, then compare that result against a normal browser visit.

The locale code must identify a language before a region

The language is usually an ISO 639-1 code such as en, fr, or de. A region, when included, normally uses an ISO 3166-1 alpha-2 country code. The format is language first, region second, joined by a hyphen. An optional supported script code can also be used where relevant.

Codes are not the full language-detection mechanism: Google uses page content to determine language, not the hreflang value alone. A page labelled fr-FR whose main text remains in English is not repaired simply by correcting its tag.

A valid three-page hreflang cluster, with return links

Suppose three equivalent shipping guides are published at these fictional addresses:

• https://www.example.com/en-us/shipping/ for US English.
• https://www.example.com/en-gb/shipping/ for UK English.
• https://www.example.com/fr-fr/livraison/ for French in France.

The following same set of three alternate links should appear in the document <head> of each localized page, including a reference to the page itself:

<link rel="alternate" hreflang="en-US"
      href="https://www.example.com/en-us/shipping/">
<link rel="alternate" hreflang="en-GB"
      href="https://www.example.com/en-gb/shipping/">
<link rel="alternate" hreflang="fr-FR"
      href="https://www.example.com/fr-fr/livraison/">

The URLs are absolute, use HTTPS, and refer to equivalent content rather than language homepages. This example intentionally omits x-default, because a fallback page is optional.

If the US page includes the UK URL but the UK page does not refer back to the US page, the relationship is incomplete. Google documents that pairs without mutual references can have their hreflang annotations ignored. When a large cluster becomes hard to maintain, focus first on bidirectional links between each newly added variant and the main established language page; do not publish one-way declarations and assume they will work.

Missing return links are a relationship error, not just a missing line

An hreflang check must inspect both ends of an asserted pair. A valid-looking en-US annotation on one page does not prove the target acknowledges that relationship. Common failures include a translated template that forgot to output tags, stale URLs after a site migration, and country folders generated by different WordPress installations.

A robust manual check compares the full collection of locale-to-URL pairs on each page. The lists should identify equivalent destinations consistently. When you add a fourth language, update the group on the other versions rather than only the newest page.

Do not let canonicals cancel your language targeting

Hreflang says that two URLs serve different audiences. Canonicalization identifies the preferred URL when duplicate or very similar pages compete. If the UK page points its canonical to the US page, while the hreflang cluster declares the UK page a separate alternate, the signals may conflict.

For independently useful, indexable localized pages, a clear default is that each version points its canonical to its own preferred URL. For example, the UK page could contain:

<link rel="canonical"
      href="https://www.example.com/en-gb/shipping/">

This canonical is separate from the hreflang annotations. Check real canonical values using the Canonical Tag Checker; do not assume a self-referencing tag automatically makes Google select that canonical. Very similar same-language regional duplicates can require deliberate consolidation and localization decisions.

Five defects that cause hreflang associations to fail

Check whether destination URLs resolve directly to a useful page. A regional URL returning a 404 or redirecting visitors to a different locale should be investigated before modifying more markup. The Website Indexability Checker can support a separate review of indexability signals, while the Robots.txt Generator and Tester is relevant when crawling restrictions are suspected.

Which implementation method should you use?

Google supports three equivalent ways to declare language alternatives: HTML <link> elements, HTTP Link response headers, and XML sitemap annotations. You do not need all three. Choose the method your site can maintain accurately, then audit the published output.

• HTML tags: Usually practical when a CMS controls the document head of every localized page. Confirm the tags appear inside a valid <head>.
• HTTP headers: Useful for localized files such as PDFs that have no HTML head. Verify the actual server response, not a template setting.
• XML sitemaps: Useful when the site can centrally maintain variant mappings. Each URL entry needs the matching full alternate list and the correct XML namespace.

If you maintain sitemap annotations, audit the file with the XML Sitemap Validator and confirm that the URLs represent the published canonical versions. A syntax-valid sitemap is not proof that its hreflang groupings are correct.

A repeatable workflow for locating the broken variant

1. Choose one real page group. List the corresponding pages, not every translated page on the site. A shipping guide must map to the shipping guide in other languages, not to their homepages.
2. Record the expected audience. Write down each URL alongside its language, optional region, and intended page purpose.
3. Inspect the published annotations. Start with the Hreflang Generator and Checker and independently inspect source or response markup. Its shortcode is registered in the supplied tool inventory; confirm the live checker interface before relying on a particular feature.
4. Compare each pair. Check self entries, absolute target URLs, reciprocal references, and consistency across the group. An isolated single-page report cannot establish all return links.
5. Check target responses. Confirm the final URL, status code, and public availability. Avoid hreflang destinations that lead through an unexpected redirect chain.
6. Review canonical and robots signals. Determine whether Google is being told to index and prefer another URL. Resolve conflicts rather than adding another hreflang layer.
7. Inspect the page Google receives. Use Search Console URL Inspection for representative alternatives. Check Google-selected canonical and other indexing information where available. A live test does not prove that the newest change has already been indexed.
8. Retest the complete group after publishing. A template fix can repair one locale and break another. Recheck all affected pages after caching and deployment.

The proper role of x-default and generic-language URLs

An x-default entry can indicate a fallback page for visitors whose language or region is not otherwise covered. Common choices include a worldwide page or a language selector. It is optional; its absence is not, by itself, a technical SEO failure. When used, keep its destination consistent in the same cluster.

A generic en page serves a different purpose: it denotes English content without assigning a specific region. It can be useful alongside country-specific English pages. Neither x-default nor en means that Google will force every unmatched visitor to that URL.

WordPress and international-site mistakes worth preventing

In WordPress, hreflang often comes from a multilingual plugin, theme integration, SEO extension, or a custom template. Duplicate output from two systems can create conflicting annotations. Verify the actual generated source after plugin upgrades and migration work, not just the settings screen.

Also avoid automatic locale redirects that prevent users and crawlers from opening a different regional URL. Google recommends distinct URLs for distinct languages and visible links that allow people to switch. If a new language version uses JavaScript to generate its head links, compare initial and rendered markup with the Source vs Rendered HTML Comparison workflow instead of assuming Google reads the same markup your browser displays.

Frequently asked questions about hreflang problems

Can hreflang force Google to show one country page?

No. It is a signal that helps Google choose the appropriate localized URL. Google can consider other factors, and hreflang does not guarantee a result for every query or user.

Does every page need hreflang?

No. Use it where genuine language or regional alternatives of a page exist. A site published for one language with no corresponding alternate versions generally does not need it.

Are reciprocal tags required?

Google’s documentation says alternate page pairs should reference each other; otherwise those annotations can be ignored. The simplest maintainable approach is a complete, consistent list on every page in the group.

Is x-default mandatory?

No. It is an optional fallback annotation, most useful for general entry points or locale-selection pages.

Can I use hreflang between different domains?

Yes. Alternatives can live on separate domains or subdomains if their URLs are fully qualified and their relationships are accurate and reciprocal.

How long does it take Google to notice a fix?

There is no universal deadline. Google must recrawl and process the affected pages. Use Search Console evidence and subsequent search observations, not an invented fixed number of days.

The deciding test

A healthy hreflang setup is a consistent map of accessible, localized, canonical URLs that confirm their relationships. Check the language code, the destination, the return link, and the actual page signals before assuming a ranking or redirection problem. Fix the smallest demonstrable mismatch, publish the correction across the affected cluster, and verify what Google can access.

For the next part of this audit, see the purpose of hreflang x-default and checking reciprocal hreflang tags. These connected guides cover the complementary checks without repeating this workflow.