Hreflang tags tell search engines which language or regional version of a page to serve a given visitor. On a multilingual or multi-regional WordPress site, getting this right avoids duplicate-content confusion and serves the correct version to the correct audience. A plugin handles this without touching code directly.
Before getting into the how-to, it’s worth being clear about what problem hreflang actually solves, because it’s easy to confuse with a few related but different things. Hreflang isn’t a translation tool, it doesn’t create your language versions for you. It isn’t a redirect mechanism either, it doesn’t automatically send a French visitor to your French page. What it does is annotate the relationship between equivalent pages so a search engine knows “this English page and this French page are the same content in different languages,” and lets the search engine decide which one to show a given searcher based on their language and location. Get the annotation wrong and you risk two common failure modes: the wrong language version ranking for a given search, or search engines treating near-duplicate regional variants (US English versus UK English, for example) as actual duplicate content competing against each other instead of complementary versions.
Using a Plugin to Add Hreflang Tags
Step 1: Choose and Install a Plugin
1. Yoast SEO: Hreflang support is part of the premium version.
Configuring it:
- Once Yoast SEO Premium is active, go to SEO > Search Appearance.
- Check the Content Types or Taxonomies tab, depending on where hreflang is needed.
- Yoast generates hreflang tags automatically based on your existing language/region content.
2. WPML: Built specifically for multilingual sites, with hreflang support included.
Configuring it:
- After activation, go to WPML > Languages.
- Confirm your site’s languages are configured correctly.
- WPML generates hreflang tags automatically from your language setup and translated content.
3. Rank Math: also worth a mention
If you’re already running Rank Math for on-page SEO elsewhere on your site, its multilingual add-on and integration with translation plugins like WPML or Polylang covers hreflang generation without needing Yoast running alongside it. Worth checking your specific Rank Math version and add-on setup, since hreflang handling there is typically delivered either natively or through its integration layer with whichever translation plugin is actually managing your language versions, rather than being a fully standalone feature independent of a translation plugin.
Step 2: Verify the Tags Are Actually There
- Check Page Source: View a page’s source in your browser and look for hreflang tags in the
<head>section. - Use SEO Tools: Screaming Frog SEO Spider or Google Search Console will confirm whether hreflang tags are being recognized and indexed correctly, not just present in the source.
The Return Tag Requirement
This is the single most common hreflang mistake, and it’s worth calling out explicitly because it’s invisible unless you go looking for it. Hreflang tags need to be reciprocal: if your English page points to your French page with an hreflang tag, the French page needs to point back to the English page too. A one-directional link, English pointing to French but French not pointing back, is treated by search engines as invalid and gets ignored entirely. Most well-built plugins handle this automatically as long as your translated content is properly linked as a translation set within the plugin itself, but it’s exactly the kind of thing that breaks silently if a translated page gets unlinked from its original during an edit, a content migration, or a manual page rebuild. Spot-checking the return tags periodically, not just the outbound ones, catches problems that a single-direction check would miss.
The x-default Tag
Alongside language-specific hreflang tags, there’s an optional but genuinely useful tag: hreflang="x-default". This tells search engines which version to show a visitor whose language or region doesn’t match any of your specific hreflang entries, someone browsing in a language you haven’t built a dedicated version for. Without an x-default set, search engines make their own guess, which isn’t always the page you’d have chosen. Most multilingual plugins let you designate this, usually pointing at either your primary language version or a language-selector landing page, and it’s worth setting deliberately rather than leaving to a default guess.
Hreflang and Canonical Tags Working Together
A point of genuine confusion for a lot of site owners: hreflang and the canonical tag serve different purposes and shouldn’t be set up as if they conflict. The canonical tag tells search engines which URL is the authoritative version when multiple URLs show similar or duplicate content. Hreflang tells search engines which URL is the right version for a specific language or region, they’re not duplicates of each other, they’re legitimately different content in different languages, and it’s normal for each language version to canonical to itself rather than all pointing to one master URL. Setting every translated page’s canonical tag to point back at the original-language page, a mistake some manual setups make, actively tells search engines to ignore your translations entirely, which defeats the entire purpose of having them.
Regional Variants, Not Just Languages
Hreflang isn’t limited to language differences, it also handles regional variants of the same language, US English versus UK English versus Australian English, for instance, using codes like en-us, en-gb, and en-au instead of a plain en. If your site has meaningfully different content for different English-speaking regions, different pricing, different spelling conventions, region-specific examples, setting these up properly avoids the search engine treating near-identical regional pages as duplicate content competing against each other rather than distinct, appropriately targeted versions. If your regional content is genuinely nearly identical with no real localization difference, it might be worth asking whether you need separate regional pages at all rather than one page with a broader en tag.
Common Mistakes Worth Checking For
- Missing self-referencing tags. Each language page should include an hreflang tag pointing to itself, not just to its counterparts. Skipping the self-reference is a common oversight in manual implementations.
- Inconsistent URL formats. Mixing http and https, or trailing slash and no trailing slash, across your hreflang set can cause search engines to treat what should be a matched pair as unrelated URLs.
- Wrong language or region codes. A typo in an ISO code, or using a region code where a plain language code was intended, quietly breaks the whole relationship for that page without throwing any visible error.
- Hreflang set on noindexed pages. If a page is set to noindex, its hreflang relationships to other pages become meaningless since search engines aren’t indexing it in the first place.
Testing Tools Beyond Screaming Frog and Search Console
Google Search Console’s International Targeting report (where available) and the Screaming Frog crawl are the two most direct diagnostic sources, but a handful of free third-party hreflang tag testers online will validate a single URL’s tag set quickly without needing a full crawl, useful for spot-checking a specific page after an edit rather than running a whole-site crawl every time. Whichever tool you use, the goal is the same: confirm the tags exist, confirm they’re reciprocal, and confirm the codes are valid ISO language and region codes rather than a typo that happens to look plausible.
Step 3: Monitor and Update
Recheck periodically, especially after adding a new language or regional version, hreflang configuration doesn’t always update itself when the underlying content structure changes.
A plugin handles the mechanics here reliably; the part that actually needs ongoing attention is verifying the tags are correct after every content or language change, not just trusting they were set up right once.
Hreflang and Content Freshness
One detail that’s easy to overlook: hreflang relationships need to stay accurate as content evolves, not just at the moment a translation is first published. If your English source article gets a substantial update, new sections, revised advice, updated data, and the French and German versions don’t get the same update, the hreflang relationship technically still holds (they’re still marked as translations of each other), but the actual content is now meaningfully out of sync across languages. That’s not a technical hreflang failure, the tags are still correct, but it does mean visitors landing on the outdated translated version are getting a worse experience than the English source. Treating translation updates as part of your content refresh workflow, not a one-time task, keeps the multilingual experience actually equivalent across languages rather than just technically linked.
What Happens If You Get It Wrong
Worth being clear that hreflang mistakes aren’t usually catastrophic, they’re a missed opportunity rather than a penalty. A broken or missing hreflang setup doesn’t get a site penalized the way, say, cloaking or a security issue would. What actually happens is subtler and easy to miss without specifically checking: the wrong language version shows up in search results for a given user, potential visitors bounce because the page isn’t in their language, and you never see that lost traffic reflected anywhere obvious because it simply never converted into a click in the first place. That makes hreflang the kind of technical SEO issue that’s worth auditing periodically precisely because nothing visibly “breaks” when it’s wrong, the cost shows up as underperformance you have to go looking for rather than an error you’ll be alerted to.
Two Ways to Deliver Hreflang: HTML Head vs. XML Sitemap
Most WordPress plugins default to placing hreflang tags in the page’s <head> section, which is what the walkthrough above covers. There’s a second, less commonly used method worth knowing about: declaring hreflang relationships inside an XML sitemap instead of on each individual page. The sitemap approach can be more efficient to generate and update on very large multilingual sites, since it centralizes the relationships in one file rather than embedding them across thousands of individual page templates. For a typical WordPress site running Yoast, WPML, or Rank Math, the head-tag method is simpler to set up and verify, and it’s what those plugins default to, so there’s rarely a reason to switch to sitemap-based hreflang unless you’re managing a genuinely large multilingual catalog where page-by-page head tags start to strain server resources.
Subdirectory vs. Subdomain vs. Separate Domain Structures
How you’ve structured your multilingual URLs, example.com/fr/, fr.example.com, or an entirely separate example.fr, affects a few things beyond hreflang itself, but hreflang works across all three structures the same way. What matters for hreflang specifically is that each version has a stable, crawlable URL and that the plugin managing your translations can correctly map each URL to its language and region. A subdirectory structure is generally the easiest to manage inside a single WordPress install with a plugin like WPML, since everything lives under one domain and one set of hosting resources. Subdomains and separate domains introduce more moving parts, DNS, potentially separate hosting, and are usually chosen for reasons beyond SEO (a genuinely separate country-specific business entity, for example) rather than because they handle hreflang any better.
Hreflang on an E-Commerce Site
Product pages add a layer of complexity worth flagging specifically. If the same physical product is sold across multiple regional storefronts with different pricing, currency, and availability, each region’s product page should carry its own hreflang set, the same way a content page would, pointing to its regional counterparts. The common mistake on e-commerce multilingual setups is translating product descriptions but forgetting to extend the same hreflang and translation-linking treatment to category pages, filtered search results, and other templated page types beyond the individual product page itself. A thorough hreflang audit on a store needs to cover every indexable template type, not just the product detail page, since a language mismatch on a category page can misdirect just as much traffic as one on a product page.
A Quick Example Worth Walking Through
Say you’re running a site with English, French, and German versions of the same blog post. The English version’s head section should include three hreflang tags: one pointing to itself (en), one pointing to the French version (fr), and one pointing to the German version (de). The French version needs the identical set of three tags, pointing to itself and both siblings, and so does the German version. That’s nine total tag entries across three pages, three tags per page, all pointing at the same three URLs consistently. If you’re checking this manually rather than trusting a plugin, that’s the pattern to verify: every page in the set references every other page in the set, including itself, with matching URLs across all three.
Frequently Asked Questions
Does hreflang directly boost search rankings?
Not directly, and it’s worth being precise about that rather than overselling it. Hreflang doesn’t function as a ranking factor the way page speed or backlinks do. What it does is make sure the right version of your content is the one showing up for a given searcher, which affects click-through rate and relevance rather than raw ranking position. Getting hreflang right doesn’t push a page up the results, it makes sure the page that is showing is actually the one that should be showing for that specific visitor.
Do I need hreflang if I only have one language but multiple regions?
Yes, if the regional content genuinely differs, pricing, spelling, region-specific examples or offers. If it’s the exact same content just served under different regional URLs with no actual difference, hreflang using regional codes is still the correct way to signal that relationship rather than leaving search engines to guess which regional URL is the “right” one to show.
Can hreflang tags conflict with a caching plugin?
This is worth checking specifically if you’re running an aggressive page-caching setup. Since hreflang tags are generated dynamically based on your translation plugin’s data, a cached page snapshot taken before a translation link changes can serve stale hreflang tags until the cache clears. If you’re actively managing translations, adding new language versions, unlinking old ones, it’s worth manually clearing cache for the affected pages rather than waiting for the cache to expire naturally, so the hreflang set stays accurate in what’s actually being served to visitors and crawlers.
What if a translated page doesn’t exist yet for every language?
Only include hreflang tags for language versions that actually exist and are published. Pointing an hreflang tag at a URL that doesn’t resolve, a translation that’s still in draft, for example, creates a broken relationship that search engines will flag rather than helping your SEO. Most translation plugins handle this correctly on their own by only generating tags for published, linked translations, but it’s worth spot-checking if you’re managing translations in batches with some intentionally left unpublished for a while.
A Note on Plugin Conflicts
Running two SEO or multilingual plugins simultaneously that both try to generate hreflang tags is a common, avoidable source of duplicate or conflicting tags in the page source. If you’re migrating from one setup to another, from Yoast to Rank Math, or adding WPML to a site that previously used a different translation approach, deactivate the old hreflang source completely before activating the new one, and check the page source afterward to confirm there’s exactly one set of hreflang tags rather than two competing sets left over from the transition.
Building Hreflang Checks Into Your Regular SEO Routine
Because hreflang problems fail silently rather than throwing visible errors, it’s worth building a periodic check into whatever SEO review cadence you already run, alongside broken-link checks, sitemap validation, and the rest of your standard technical audit. A quarterly crawl with Screaming Frog specifically looking at hreflang consistency, checking for missing return tags, mismatched codes, and orphaned translations, catches drift before it accumulates into a meaningfully large chunk of misdirected international traffic. This matters more the faster your site is adding new content or new language versions, since every new page is a new opportunity for the hreflang set to fall slightly out of sync if it’s not being actively maintained.