Hreflang for WordPress: A Practical Guide

If your WordPress site serves more than one language, or the same language to more than one region, hreflang is the tag that tells search engines which version belongs in front of which searcher. Get it right and a French visitor in Montreal lands on your fr-CA page instead of fr-FR. Get it wrong and search engines quietly ignore the signal, fall back to their own guess, and you end up with the wrong version ranking in the wrong market, or worse, two versions competing against each other for the same query.

What hreflang actually does and the problem it solves

Hreflang is an HTML attribute, not a ranking factor. It does not make a page rank higher. What it does is tell search engines, at the level of a single URL, which language and optionally which region that URL is written for, and which other URLs on your site are equivalent versions in other languages or regions. Search engines use that information to decide which version of a page to display to a given searcher based on their language settings and location.

The problem hreflang solves is specific: without it, a search engine has to guess which version of your content is relevant to a given searcher, usually based on the content's own language and whatever signals the crawl picks up. That guess is often wrong, especially when the same language is served to multiple regions. A US-English page and a UK-English page look nearly identical to a crawler unless something explicitly separates them. Hreflang is that separator.

This matters more than it looks like on paper. If your German page ranks in Austria instead of your Austria-specific page, or your Spanish-for-Spain page shows up in Mexico ahead of your Spanish-for-Mexico page, you are not just losing a ranking position, you are showing searchers pricing, currency, shipping terms, or cultural references that do not apply to them. That is a conversion problem wearing an SEO costume. If your site also needs help with the structured data layer alongside multilingual signals, see Schema and structured data.

The syntax, explained with a real example

Hreflang is typically implemented as a set of link tags in the head of your page, one for each language or region variant, plus one special tag called x-default. Each tag has two parts: an href pointing to the URL of that variant, and an hreflang value made of a language code and, optionally, a region code, separated by a hyphen. The language code follows ISO 639-1 (en, fr, de) and the region code follows ISO 3166-1 Alpha 2 (US, GB, CA). The critical rule is that every page in the group must carry the full set of tags, including a tag that points back to itself.

<link rel="alternate" hreflang="en-us" href="https://example.com/us/pricing/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/pricing/" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/tarifs/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

This block would appear identically on the US page, the UK page, and the French page. Each page references all four URLs, itself included. The x-default tag is not a language at all, it is a fallback that tells a search engine which version to show when none of the specific language-region tags match the searcher, commonly a language selector page or your default market's page.

Two details trip people up here. First, hreflang values are not case-sensitive, but the convention is lowercase language, uppercase region, written lowercase in the tag (en-us is fine, EN-US is fine, they mean the same thing to search engines, but consistency prevents human error during audits). Second, hreflang works as a set: if page A lists page B, page B must list page A back. A one-way reference is treated as invalid and is usually just ignored.

The most common hreflang mistakes

Most hreflang problems are not exotic. They are a small number of repeat offenders that show up on almost every multilingual site audit.

Missing reciprocal links

Hreflang is a confirmation handshake, not a one-way pointer. If your English page links to your Spanish page, but the Spanish page does not link back to the English page, search engines cannot confirm the relationship and will typically disregard the annotation entirely. This is the single most common failure mode on hand-built multilingual sites, and it usually happens because someone added a new language variant later and updated the tags on the new page without going back and updating every existing page to reference it. Every page in the set needs a complete list of every variant, including itself.

Wrong language-region codes

hreflang uses ISO 639-1 for language and ISO 3166-1 Alpha 2 for region, and mixing these up is easy. A common error is using a region code where a language code belongs, for example writing en-UK instead of en-GB (the correct ISO region code for the United Kingdom is GB, not UK). Another is specifying a region without a language, which is not valid syntax, hreflang always requires the language component. These errors do not usually throw a visible error on your site, the tag just silently fails to match anything, which is what makes them hard to catch without a dedicated check.

Hreflang pointing to a redirect instead of the final URL

Every hreflang href should point directly to the final, canonical URL of the target page, not to a URL that redirects somewhere else. This happens often after a URL structure change, a domain migration, or when old language-prefixed URLs are left in place as redirects for backward compatibility. Search engines generally will not follow a redirect chain to resolve an hreflang target the way they follow one for a normal crawl, so a stale redirect target effectively breaks that entire language relationship until the tags are updated to the live URL.

How WPML and Polylang generate hreflang automatically

This is the part where WordPress earns its keep. Both WPML and Polylang manage translation relationships between posts and pages as structured data, not as loosely connected content, and both can use that structure to generate hreflang tags automatically without you writing a single link tag by hand.

WPML tracks which translated posts belong to the same translation group and, when hreflang output is enabled, generates the full reciprocal set of tags across that group on each page in it, keeping the region-specific language codes consistent with how you have configured your site's languages. Because WPML treats language switching as a first-class site feature, its hreflang output stays synced automatically as you add, remove, or update translated versions of a page, rather than needing a manual resync.

Polylang works from the same underlying idea, connecting posts across languages through its own translation relationships, and generating matching hreflang tags for each connected group. The practical benefit in both cases is the same: the reciprocal-linking requirement that trips up manual implementations is handled structurally, because the plugin already knows every member of the translation group and updates all of them together when the group changes. For sites building out this kind of setup alongside broader SEO tooling, see Multilingual and builders for how Rankwyn layers on top of WPML, Polylang, and TranslatePress specifically.

How to verify your hreflang is actually correct

Because hreflang failures are silent, verification is not optional. Start by viewing the page source of a few key pages in each language and confirming the full set of link tags is present, that every URL is the live final URL, and that the codes match what you expect. Then check reciprocity directly: open each linked variant and confirm it lists every other variant back, including the page you started from.

After a manual spot check, run your key templates through a dedicated hreflang testing tool to catch code errors and broken reciprocal links at scale rather than page by page. Finally, monitor performance by country and language in Google Search Console over the following weeks. A working hreflang setup shows up as the right country's traffic landing on the right regional page, if a market's traffic is still landing on the wrong variant weeks after setup, that is a sign the tags are not being picked up correctly and need another look.

If you are setting hreflang up for the first time, it is worth doing this verification pass before you scale to more languages, since a mistake in your first two variants will just get copied into every language you add afterward. For sites weighing the cost of getting all of this right manually against a tool built for it, see pricing.