Hreflang is an annotation that tells search engines which language and regional versions of a page exist and which version should be shown to which audience. In technical SEO, it is the standard mechanism for connecting equivalent pages across languages or countries, so that a searcher in Austria sees the German page for Austria rather than the German page for Germany or the English original.
The annotation does not translate anything and does not decide rankings on its own. It works as a swapping signal: once a search engine has decided that one member of a page set deserves to rank, hreflang helps it substitute the most appropriate version for the searcher’s language and location.
How hreflang annotations work
Every page in a set of alternates lists all versions of itself, including its own URL, each paired with a language code and an optional region code. The search engine reads these lists, builds a cluster of equivalent pages, and uses the cluster when it serves results to users with different language settings and locations.
The most important rule is reciprocity. If the English page names the French page as an alternate, the French page must name the English page in return. Missing return links cause the engine to ignore the unconfirmed pair, because one-sided claims could otherwise be used to hijack another site’s audience.
Values follow a fixed syntax, summarized in the next table.
| Value | Format | Meaning |
|---|---|---|
| en | Language only, ISO 639-1 | English speakers in any country |
| en-GB | Language plus ISO 3166-1 Alpha-2 region | English speakers in the United Kingdom |
| es-419 | Language plus UN M.49 region | Spanish for Latin America, not supported by every engine |
| zh-Hant-TW | Language, script and region | Traditional Chinese for Taiwan |
| x-default | Reserved value | Fallback for users who match no listed version |
The region code is never used alone. A value such as uk means Ukrainian as a language, not the United Kingdom, and gb is not a valid language code at all. Errors of this kind are among the most frequent reasons why hreflang sets fail silently.
Three ways to implement hreflang
Hreflang can be delivered in the HTML head, in HTTP response headers or in the XML sitemap. All three are equivalent for search engines, so the choice depends on the site’s technology and on how many versions each page has.
| Method | Best suited for | Main drawback |
|---|---|---|
| HTML link elements | Small and medium sites with few language versions | Adds weight to every page head; hard to maintain at scale |
| HTTP Link header | PDFs and other non-HTML documents | Requires server configuration; invisible in page source |
| XML sitemap | Large sites with many versions per page | Errors are less visible; sitemap must stay in sync with content |
Mixing methods is technically allowed but makes debugging harder, because a contradiction between the head and the sitemap can break the cluster. A single, centrally generated source of hreflang data is the safer design for sites with dozens of markets.
Each hreflang URL must be absolute, return status 200, and be the canonical version of that page. Annotations that point to redirects, noindexed pages or non-canonical variants are discarded, which often leaves an entire market without a working alternate.
Hreflang compared with related technical signals
Hreflang is often confused with canonical tags, geotargeting and the HTML lang attribute. Each of these answers a different question, and they work together rather than as substitutes.
| Signal | Question it answers | Relationship to hreflang |
|---|---|---|
| Hreflang | Which equivalent version suits this user | Primary mechanism for version swapping |
| Canonical tag | Which URL represents a duplicate set | Each language version should be canonical to itself |
| HTML lang attribute | What language this document is written in | Helps accessibility and detection, not version swapping |
| Country-code domain | Which country the whole site targets | Strong geographic signal; hreflang refines it per page |
| Content-Language header | Language of the response | Largely ignored by major search engines |
The most damaging conflict arises when translated pages carry a canonical pointing to the original language. The engine then treats the translations as duplicates and may drop them from the index, so the hreflang cluster has nothing left to swap.
Planning an hreflang setup
Good hreflang starts with a market map: a list of every language and region the business genuinely serves, with the URL pattern for each. Only versions that are real equivalents belong in one cluster; a product page should not be paired with a country homepage.
- Use language-only values when content is identical across countries, for example a single German version for all German speakers.
- Add region-specific values only when content really differs, such as prices, currency, legal text or delivery terms.
- Assign x-default to a language selector or to the most widely understood version.
- Keep one URL per version; parameters or cookies that switch language on the same URL cannot be annotated reliably.
Search engines do not all treat hreflang the same way. Google and Yandex support it, while Bing relies mainly on other signals, such as the HTML lang attribute and content-language meta information, so multi-engine strategies should not depend on hreflang alone.
Common hreflang errors and fixes
Hreflang has no visible effect on the page, so errors can persist for months. A regular audit with a crawler that validates return links, codes and status codes catches most problems before they cost traffic.
| Symptom | Likely cause | Fix |
|---|---|---|
| Wrong country version ranks | Missing return links | Make every annotation reciprocal |
| Annotations ignored | Invalid codes such as en-UK | Use ISO codes, for example en-GB |
| Translations not indexed | Canonical points to the original | Set self-referencing canonicals |
| Cluster partly broken | Alternate URLs redirect or return 404 | Point only to live canonical URLs |
| Users see a mismatched page | No fallback defined | Add an x-default entry |
Automatic IP-based redirects are a related risk. Crawlers mostly request pages from a limited set of locations, so forced redirection can hide whole language versions from them. Suggesting a version with a banner is safer than redirecting.
Stripped to the essentials
Hreflang works like a set of labeled doors to the same room. Each door is a different language. The website tells the search engine that the English, French and Spanish pages say the same thing. The search engine then opens the right door for each visitor.
It does not translate anything. It does not make pages rank higher either. It simply helps people land on the version written for them, so they do not have to hunt for a language switch.
Where it is applied
An outdoor equipment retailer sells in Germany, Austria, Switzerland and the United Kingdom. The German and Austrian stores show different prices and delivery terms, while the Swiss store also lists prices in Swiss francs. Before any changes, Austrian searchers often landed on the German store and abandoned their carts after seeing wrong shipping costs.
The team generates hreflang entries in the XML sitemap from the product database: de-DE, de-AT, de-CH and en-GB, plus an x-default pointing to an international selector page. Every product URL lists all five entries, each version has a self-referencing canonical, and a weekly crawl checks return links. Within a few recrawl cycles, search results in Austria show the de-AT pages, and the share of sessions starting on the correct country store rises noticeably.