The hreflang attribute is an HTML tag that tells search engines which language and regional version of a page to show users based on their location and language prefereThe hreflang attribute is an HTML tag that tells search engines which language and regional version of a page to show a given user. Browser language and location decide which one that is. The attribute stops similar pages in different languages from competing with each other, and keeps visitors on content they can actually read. If you run a multilingual site or serve several markets, hreflang is one of the few tools with which you genuinely steer what Google shows where.
What hreflang is, and why it matters for international SEO
Hreflang is a technical element in your page code that identifies the language and geographic audience of that page. Search engines use it to show the right version of your content to someone searching in another language or from another country.
Think of it as a hint for the crawler. When someone in Spain searches for your content, hreflang suggests that Google should show the Spanish version rather than the English one. Without it, the search engine chooses on its own, and its choice need not match yours.
The attribute solves two problems at once.
The first concerns the reader. A visitor should land on content they can read and use. Clicking a search result and arriving on a page in an unfamiliar language ends in a return to the results. The second problem is technical. Without hreflang, a search engine may treat your English, Spanish and French versions as duplicate content competing for the same position.
For sites serving several markets this has a direct commercial dimension. A visitor from the UK should see prices in pounds and local regulatory terms. A visitor from Germany needs prices in euro and German documentation. Hreflang makes sure each of them gets the version that makes sense for them. Multi-market iGaming platforms are a textbook case of this — see SEO for iGaming: boosting your organic traffic.
One expectation is worth setting straight away. Hreflang is a signal, not a directive. Google treats it as a strong hint but weighs it against other signals: URL structure, page content, indexing history. A correct implementation raises the probability of the right match. It does not guarantee it.
When you actually need hreflang
You need hreflang when the same site publishes content in several languages, or targets the same language at different regions. The second case covers separate pages for British and American English, or Spanish for Spain and for Mexico.
Situations that call for it:
Several language versions of the same content, for example Polish, German and English pages covering one topic
Regional variants in one language: en-GB for the United Kingdom, en-US for the United States, de-AT for Austria
Partially translated sites, where some content exists in several languages and some in one
Separate domains or subdomains per market, for example example.pl, example.de, example.com
How those separate domains are actually hosted is a related architecture decision — see can multiple WordPress sites use the same database? You do not need hreflang if the site exists in one language and serves one market. An English site aimed only at the UK gains nothing. It also will not help where translation happens automatically in the browser and no separate URLs are created. With no distinct addresses there is nothing to annotate.
How hreflang works in WordPress
Hreflang tags are annotations describing the relationships between versions of the same page. WordPress does not generate them on its own, so they have to be added by a plugin, custom code, or a solution built by your development team.
The attribute can sit in three places:
In the <head> of the HTML document, using <link> elements. This is the most common method.
In HTTP headers, for non-HTML files such as PDFs.
In the XML sitemap, as an alternative to on-page tags.
The relationship between hreflang and WordPress’s own language features is a common source of confusion. WordPress has built-in localisation that translates the admin interface and supports multilingual content. That does not create hreflang tags. Setting the language tells WordPress what language the content is in. Hreflang tells the search engine how that content relates to the other versions. These are two separate layers.
In practice most sites use a multilingual plugin such as WPML or Polylang, which manage translations and generate the tags. Some SEO plugins, Yoast SEO Premium among them, handle hreflang on their own, which makes sense for regional variants within a single language. In more complex architectures a custom solution works better, because it gives full control over when and which tags appear.
Correct hreflang syntax
The correct form is hreflang="language-REGION". The language uses an ISO 639-1 code, the optional region an ISO 3166-1 Alpha 2 code. Language is always lowercase, country always uppercase, separated by a hyphen.
The common variants:
Language only: hreflang="pl" covers all Polish-speaking users regardless of country
Language and region: hreflang="en-GB" covers English speakers in the United Kingdom
Same language, different regions: hreflang="es-ES" for Spain, hreflang="es-MX" for Mexico
Default version: hreflang="x-default" names the page shown when no other version matches
A complete implementation in HTML looks like this:
<link rel="alternate" hreflang="pl" href="https://example.com/pl/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Typical syntax errors are incorrect language codes (eng instead of en), a missing self-referencing tag, and reversing the order of language and country. Every address named in a tag must exist and return a 200 status code, not a redirect and not an error.
The x-default attribute deserves separate attention. It works as the fallback for users whose language and location match no declared variant. On globally reaching sites it usually points to the English version or to a language selector.
The most common hreflang mistakes
Missing return tags are the most frequent error in hreflang implementations. If the Polish page points to the German one, the German page must point back to the Polish one. The relationship is reciprocal and mandatory, and with more languages it is easy to miss one.
Other frequent mistakes:
Incorrect language codes: pl_PL instead of pl-PL, or codes outside the ISO standard
Conflict with the canonical: hreflang names one address while the canonical tag names another
Incomplete reciprocal relationships: page A references page B, but page B does not reference page A
Missing self-reference: every version must include a tag pointing to itself
Wrong URL format: relative addresses instead of absolute ones, or mixing HTTP and HTTPS
Pointing at addresses excluded from indexing: the tag leads to a page with noindex or blocked in robots.txt
There is a separate category of errors that only appear over time. Tags implemented correctly at launch drift apart when the URL structure changes, when one language version is removed, or after a domain migration. That is an argument for building validation into the deployment process rather than into an audit calendar.
How to check whether hreflang is working
Verification covers two layers: whether the tags are technically correct, and how the search engine interprets them. Start with the page source. Confirm the tags are in the <head>, use correct syntax, and form a complete set of reciprocal relationships.
One important change here, which older guides still get wrong. Google Search Console used to have an International Targeting report that flagged hreflang errors across a whole site. That report was retired on 22 September 2022. Google still supports and uses hreflang. What disappeared is the central validation in Search Console, along with the ability to set a target country manually for the entire site.
The current verification path therefore looks like this:
Search Console, URL Inspection: shows how Google sees a specific page, including the canonical it selected
Search Console, Page Indexing report: surfaces cases where Google chose a different canonical than the one you declared, which often means a conflict of signals
Screaming Frog SEO Spider: crawls the whole site and reports missing return tags and format errors
Ahrefs Site Audit and Sitebulb: report hreflang errors in the context of the whole site, and Sitebulb also maps the relationships between versions
The hreflang validator at TechnicalSEO.com, formerly the Merkle tool: a quick check of individual addresses and sitemaps
Manual verification helps too. Check search results with language and country parameters to see which version appears. Confirm that clicking through from results in a given country leads to the right language version.
Google’s response time varies. Individual changes are sometimes processed in days. Rebuilding a multilingual structure on a large site takes weeks, occasionally months. Google has to recrawl every related page and confirm the reciprocal relationships before it acts on the new declarations.
Hreflang on large sites: where the real problems start
With a handful of pages, hreflang is an afternoon’s work. Scale changes the nature of the problem, because the number of relationships grows quadratically. Five language versions across two hundred pages is already four thousand reciprocal relationships to maintain. Manual checking stops making sense.
The patterns we see most often in audits:
Multi-brand groups. Several brands, several markets, shared infrastructure. Hreflang tags get implemented per brand, by different teams, at different times. The result: regional variants of one brand link to versions of another, or the relationships stop at an installation boundary.
B2B e-commerce across several markets. The product catalogue changes daily. New variants appear faster than the team maintains the tags. Partially translated versions create gaps where hreflang points at addresses that do not exist yet or return a redirect.
Publishing portals and education platforms. High content volume, archives counted in thousands of URLs, content available in only some languages. Without central management of the relationships, old content keeps stale tags after every structural change.
There is one common denominator. Hreflang treated as a plugin setting works until the first significant change to the site. Treated as part of the information architecture it keeps working, because the tags are generated from a single source of truth about language versions, and validation is part of the deployment process. We have made that change on multilingual sites many times, and it always starts with sorting out the URL structure, not with configuring a plugin.
In summary
Hreflang demands precision, but the return on that work is measurable. Implemented correctly it lets a search engine show the right content to the right audience, protects language versions from competing with each other, and shortens the path between a user and the information they came for.
The order of work we recommend:
Establish whether your site needs hreflang at all, and which variants should be declared
Sort out the URL structure before you start generating tags
Choose one implementation method and one source of truth about language versions
Build validation into the deployment process, not into an audit calendar
Monitor conflicts between hreflang and canonical tags after every structural change
FAQ about hreflang
Does hreflang affect search rankings?
Not directly. Hreflang is not a ranking factor. It affects which version of a page the search engine shows to a given user, which in turn affects click-through rate and what the user does after arriving. It also protects language versions from being treated as duplicates.
Does hreflang replace the canonical tag?
No. Both work in parallel and must agree. Every language version should carry a canonical pointing to itself, while hreflang describes its relationships with the other versions. A conflict between them is one of the most common reasons Google ignores the declarations.
Is hreflang in the sitemap enough on its own?
It is, provided the sitemap is complete and current. This is a sensible approach on very large sites, where adding tags to every page burdens the templates. It does require discipline in generating the sitemap. Do not mix methods: contradictory declarations in the HTML and in the sitemap create noise.
Do I need separate tags for en-GB and en-US?
Only where the content genuinely differs, for example in pricing, delivery terms or regulatory information. If both versions are identical, hreflang="en" is enough. Regional variants without content differences add complexity without benefit.
What happens when a return tag is missing?
Google usually ignores the whole declaration. A one-sided tag does not work, because the search engine has no confirmation that both pages belong to the same language group. That is why reciprocal relationships are a condition rather than a good practice.
Are WPML and Polylang enough?
In standard implementations, yes. Both generate correct tags including self-references and reciprocal relationships. Problems start with non-standard content types, several WordPress installations, domain migrations, and structures where some content exists in only a few languages. That is when you need control over the tag generation logic.
Is your multilingual site losing traffic to the wrong language versions? We start with an audit of the URL structure and international signals. → Request an audit
