hreflang Errors on Multilingual Sites: How to Find and Fix Them

When several language versions of a page exist, Google has to decide which one to show. Hreflang helps with that choice: you list every version explicitly, and the search engine picks the one that fits the user's language or region. Google describes the mechanism in its documentation on localized versions.

Know the limits. Hreflang does not lift a page in the results, does not replace a real translation and does not merge signals from different languages. It is a selection hint, and Google treats it as a hint, not a command. If two versions are nearly identical, for example English for the US and for the UK with the same text, the attribute helps separate them by region.

It also only works when every version can be crawled. If one language page is blocked in robots.txt, redirects elsewhere or carries noindex, the search engine cannot use it, and the annotation becomes a broken reference. So checking hreflang always starts with confirming that every address in the group answers 200 and can be indexed.

The topic sits next to choosing the main address of each page, so it is worth reading about the canonical tag too: the two mechanisms have to agree.

The most common method is link elements in the head of each page. Every version carries the full list of versions, itself included, plus an x-default entry. Here is the set for this article on this site:

<link rel="alternate" hreflang="uk" href="https://seoaudit.com.ua/blog/hreflang-guide">
<link rel="alternate" hreflang="en" href="https://seoaudit.com.ua/en/blog/hreflang-guide">
<link rel="alternate" hreflang="es" href="https://seoaudit.com.ua/es/blog/hreflang-guide">
<link rel="alternate" hreflang="x-default" href="https://seoaudit.com.ua/blog/hreflang-guide">

The same four lines appear unchanged on the Ukrainian, English and Spanish versions of the page. The Ukrainian address serves as both uk and x-default because it is the default language. The x-default value is meant for users whose language is not among the versions, or for a language selector page.

If a language has no translation of a given page, that language is simply left out of the set. Do not point to another language "just in case" and do not send people to the home page. The set should describe only pages that really exist.

Also look at the lang attribute on the html element. It should match the language of the page, for example <html lang="en">. That is a separate signal for browsers, assistive technology and search engines, and it does not replace hreflang.

A hreflang value is an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region code. A region without a language is not allowed. These are the cases that come up in practice:

• uk for Ukrainian. The code ua stands for the country Ukraine, not the language, so it is wrong here. Scanners, including the one on this site, reject ua in favour of uk.
• en for English in general, en-GB for the United Kingdom, en-US for the United States. The value en-UK is wrong because the ISO 3166-1 code for the United Kingdom is GB.
• es for Spanish in general, es-MX for Mexico, es-ES for Spain.
• x-default is not a language but a special value for the fallback version.

Regional variants make sense only when the texts truly differ: currency, legal terms, vocabulary. If you have one Spanish translation for every country, plain es is enough. Adding regions "for completeness" only creates more places to make a mistake.

Do not give one language two different values on the same page either. Two en entries pointing to different addresses create a conflict, and Google will pick one of them.

Google supports three methods, and its documentation advises choosing one.

Link elements in the head

The simplest option for ordinary sites and blogs. The tags are part of each page's HTML and visible in view-source. The drawback is that with many languages the head grows.

HTTP header

Suited to files that are not HTML, such as PDFs. The value travels in the Link header of the server response. For regular pages it is rarely used, because it is harder to notice during a check.

XML sitemap

In the sitemap, each url gets xhtml:link elements listing every version. This is convenient for large sites because the markup lives in one place. The format is covered in the sitemap.xml guide.

The main advice is not to combine methods without a reason. If the HTML says one thing and the sitemap says another, the result is hard to predict. Pick one method, keep one source of truth and generate every version from the same data.

Here are the problems that show up again and again on multilingual sites, and what each one causes.

The last one is sneaky. Technically everything is fine, but a visitor who opens the "English" page sees Ukrainian text. Hreflang cannot fix content problems, so annotate only versions that are fully translated.

Another trap is automatic redirection by IP address or the Accept-Language header. If the server forces visitors and crawlers onto the "right" language, the search engine may never see the other versions. Offer a language switcher with links instead of forcing a choice.

Three mechanisms often collide, so look at them together.

Canonical. Every language version should point its canonical to itself. If the English page declares rel="canonical" pointing to the Ukrainian one, you are telling Google that the English page is not a separate version, and a hreflang entry for it contradicts that. Never canonicalise one language to another. The canonical tag guide explains how to choose the right address.

Noindex. A page with noindex stays out of the index, so referencing it in hreflang is pointless. If a translation is not ready and is kept out of the index, remove it from the set until it ships.

Redirects. An address in hreflang must answer 200 directly. If /en/page redirects to /en/page/, the final address is the one that belongs in the set. This is easy to miss after a URL structure change.

Robots.txt. A page blocked from crawling cannot be checked, so the return link on it will never be read. Make sure no language version falls under a rule in robots.txt.

The general principle is simple: every address in the group is reachable, indexable, self-canonical and answers 200. Most other errors follow from breaking that rule.

For a small site a browser and a terminal are enough.

1. Open each language version and view the page source. Find every hreflang in the head and compare the sets: they must be identical on all versions.
2. Pull the tags out quickly from a terminal:

curl -s https://example.com/en/page | grep -i hreflang

1. For each address in the set, check the response code and make sure there is no redirect, for example with curl -sI.
2. Look at rel="canonical" and the robots meta tag on every version.
3. If hreflang lives in the sitemap, open it and confirm that each url lists every version, itself included.
4. In Google Search Console, use URL Inspection: it shows which page Google chose as canonical and whether the version is indexed.

For a site with dozens of languages or thousands of pages, a manual check does not scale, so generate the set from one data source and test it automatically. The full list of technical checks is in the technical SEO checklist.

The SEOAudit scanner is passive: it reads the address you submit and a few public supporting resources. It is not a crawl of the whole site and not a ranking measurement. For hreflang it checks the following:

• syntax of the values, where the ua code is rejected in favour of uk;
• a reference to the page itself;
• duplicate entries for the same language;
• conflict between hreflang and canonical;
• reciprocity: the scanner fetches at most three alternates declared by the page and checks that they link back, so in a large set only a sample is verified;
• a recommendation to add x-default.

If a page has no hreflang, the check is reported as not applicable rather than passed. The scanner also does not test hreflang in sitemaps or HTTP headers beyond what the page itself declares, and it does not crawl the whole site.

To see the result for your own page, run the free scanner. A wider view of technical checks is on the SEO audit page, related HTTPS and header checks are described on the security check page, and readiness for AI search is covered in AI visibility.