Back in 2021 I inherited a 14,000-page e-commerce site from a client whose previous agency had "done the international SEO". Three weeks into an audit I found 31,000 hreflang errors in Google Search Console. Thirty-one thousand. The site had seven language variants and every single page was missing its self-referencing tag. The German pages were pointing at French URLs. The x-default was pointing at a URL that 301-redirected somewhere else entirely. Organic traffic from non-English markets had flatlined for eight months and nobody had joined the dots.
That one project is probably the single biggest reason I now treat hreflang implementation as a first-class engineering problem, not an afterthought you bolt on during a translation sprint.
So let's get into it properly.
---
What hreflang Actually Does (and What It Doesn't)
I'll keep this short because most people already have a rough idea. hreflang is an HTML attribute (or HTTP header, or XML sitemap entry) that tells Google which version of a page corresponds to which language and region combination. It doesn't change rankings directly. It changes which URL Google shows to which user in which country.
That's it. It's a signal, not a directive. Google can ignore it if the implementation is broken or contradictory. And it does. Regularly.
What it does not do: it doesn't block users from accessing the wrong regional version, it doesn't replace your content strategy, and it absolutely doesn't compensate for thin translated pages that are just machine-translated copies with no localisation effort.
Worth reading Google's own hreflang documentation before anything else. It's drier than a stale biscuit but it's accurate.
---
The Five Mistakes I See on Nearly Every Audit
Missing Self-Referencing Tags
This is the big one. Every page in an hreflang cluster must include a tag pointing to itself. Not just the other variants. Itself.
If your English page at example.com/en/product/ has tags pointing to /de/product/ and /fr/product/ but forgets the hreflang="en" pointing back to /en/product/, the whole cluster is technically invalid. Google won't necessarily throw a hard error but it will reduce its confidence in the entire signal set.
I've seen this mistake on sites built by developers who read a blog post, saw an example with two variants, and never noticed the self-referencing tag because the example was badly written. Not naming names.
Return Tags Are Missing or Broken
hreflang is a two-way relationship. If your English page points to your German page, the German page must point back to the English page. Miss that return tag and Google sees a broken handshake.
On the 2021 project I mentioned, a developer had added hreflang only in the English template. The German, French, and Spanish templates had no hreflang at all. So Google was receiving half a conversation and sensibly ignoring all of it.
Wrong Language Codes
Use BCP 47 language tags. That means en for English generically, en-GB for British English, en-US for American English. Not en_GB . Not english . Not ENG.
I found lang="english-uk" on a fintech site we audited at Seahawk last year. The developer had clearly just guessed the format. It had been live for 14 months.
x-default Is Either Missing or Wrong
x-default should point to a page that handles users whose language or region doesn't match any of your other variants. Usually your homepage or a language-selection page. It is not just a synonym for "English version". I've seen x-default pointing at a URL that returns a 404, pointing at a redirect chain, and once, memorably, pointing at a staging environment.
If you have no sensible fallback page, it's actually better to omit x-default than to use it incorrectly. But usually you should have one.
Using Canonical and hreflang Incorrectly Together
Your canonical tag and your hreflang tags must not contradict each other. If /en-gb/page/ has a canonical pointing to /en/page/, but also has hreflang declaring itself as en-GB, you've created a signal conflict. The canonical is effectively saying "I'm not the preferred version of this URL" while hreflang is saying "I am the preferred version for British English users". Google has to pick one interpretation and it often picks neither.
---
How to Implement Across Large Sites Without Losing Your Mind
Template-Level vs. Page-Level
On a site with 50 pages, you could handcraft every hreflang tag. On a site with 5,000 pages, you cannot. You need to generate them programmatically.
The cleanest approach I've found is to store your URL mappings in a structured data source (a database table or even a flat JSON file for smaller projects) and generate the tags at render time. In WordPress, Yoast SEO and Rank Math both handle this reasonably well for standard setups, but both fall over when your URL structures differ across languages rather than following a predictable /en/, /de/, /fr/ prefix pattern.
If your URLs are non-uniform (say, translated slugs like example.com/en/running-shoes/ and example.com/de/laufschuhe/), you need an explicit mapping table. No plugin will figure that out automatically. I learned this the expensive way on a sportswear client in 2022 whose translated slugs were completely independent of the English ones.
XML Sitemap Method
For very large sites, I prefer the XML sitemap method over inline HTML tags. It keeps the <head> clean, it's easier to audit programmatically, and you can update the sitemap without touching page templates.
The format looks like this (conceptually, without a code fence): each <url> block contains multiple <xhtml:link> entries, one per language variant including the self-referencing one. The xmlns:xhtml namespace declaration must be present in the <urlset> element or the whole thing breaks silently.
One gotcha: the sitemap method only works if Google has crawled and indexed your sitemaps recently. If you've got crawl budget issues on a large site, the HTML method is more reliable because Googlebot reads tags inline as it crawls each page.
HTTP Headers for Non-HTML Content
Got PDFs or other non-HTML files that need hreflang? Use HTTP headers. Your server returns an Link header with rel="alternate" and hreflang attributes. This is rare in practice but I've seen large legal and financial sites with thousands of multi-language PDF documents where this actually matters.
---
Tooling That Actually Helps
Look, I've used a lot of tools over the years. Here's what I actually reach for:
- Screaming Frog SEO Spider: Run a crawl, go to the hreflang tab. It will flag missing return tags, missing self-references, broken URLs, and invalid language codes all in one place. This is my first stop on every international audit. At £199/year it's the best-value technical SEO tool I know.
- Ahrefs Site Audit: Good secondary check, especially if you want to cross-reference with organic traffic data in the same platform.
- hreflang Tags Testing Tool by Merkle: Free, at https://www.merkle.com/en/merkle-labs/hreflang-testing-tool.html. Paste a URL, it checks the entire cluster. Brilliant for spot-checking specific pages mid-fix.
- Google Search Console: The International Targeting report under Legacy Tools. Slow to update but it's the ground truth for how Google is actually reading your implementation.
- Sitebulb: If you prefer a visual crawler with more beginner-friendly reporting, Sitebulb does a solid job of visualising hreflang cluster relationships.
What I don't use: the hreflang generator tools that produce a static tag block for you to copy-paste. They're fine for learning the syntax. They're useless for anything above 20 pages because you're back to maintaining it manually.
---
Auditing at Scale: A Process That Works
Here's the actual step-by-step I run on every international audit, refined after doing this on 200+ multilingual sites:
- Crawl the site with Screaming Frog, making sure JavaScript rendering is on if the site uses a JS framework.
- Export the hreflang data into a spreadsheet. Group URLs by their intended cluster.
- Check every cluster for: self-referencing tag, return tags from all variants, valid BCP 47 codes, consistent canonical alignment.
- Check x-default URLs for 200 status codes. Not 301s. 200s.
- Cross-reference against your XML sitemaps if you're using the sitemap method. Every URL in the sitemap should return 200.
- Run a sample of 20-30 pages through the Merkle testing tool to verify Google is actually reading what you think it's reading.
- Pull the International Targeting report from Search Console and look for "No return tag" errors specifically. These are almost always the symptom of templates that weren't updated when a new language was added.
- Fix, re-crawl in 2 weeks, verify error count has dropped in Search Console (it can take 4-6 weeks for GSC data to fully reflect fixes).
This isn't a one-time process. Put a recurring crawl in your calendar every quarter. International sites change. New pages get added, old pages get redirected, and hreflang clusters silently break when nobody's watching.
---
When Not to Use hreflang
This gets skipped in most guides and it drives me mad.
If you have one language but multiple regions (say, UK and Australia both in English), hreflang is worth using but only if the content is actually different enough to serve those users distinctly. If your UK and AU pages are 95% identical, you might create more confusion than clarity. Google may choose to show one variant universally and your hreflang signals will be largely ignored anyway.
If you have very low traffic from international markets, spending a week implementing hreflang might not be the best use of time. A well-structured URL hierarchy with <html lang=""> attributes and geotargeting settings in Search Console will cover you adequately until the traffic volume justifies a full implementation.
And if your site is a single-page app with dynamic content loading, get the rendering side right first. I've seen hreflang implemented perfectly in the static HTML shell while the actual page content was JavaScript-rendered and Googlebot was seeing nothing but a loading spinner. Fix the indexability before worrying about the internationalisation signals.
---
FAQ
Do hreflang tags affect rankings directly?
No. hreflang signals tell Google which URL to serve to which user, not how to rank that URL. Indirectly, getting the right page in front of the right user reduces pogo-sticking and improves engagement metrics, which may have a downstream effect on rankings. But there's no direct ranking boost from adding hreflang tags.
How long does it take for Google to process hreflang changes?
Typically 4-8 weeks for changes to fully reflect in Search Console data. Crawl frequency matters here. For large sites with slow crawl rates, it can stretch to 12 weeks. Don't make changes and check results the next day. You'll drive yourself mad.
Can I use hreflang in a Shopify store?
Yes, but Shopify's native internationalisation (via Markets) handles a lot of this for you if you're using subfolders or subdomains. If you're using separate stores for different regions, you'll need to implement hreflang manually via a theme customisation or app. I've used Shopify's own international SEO guidance as a starting point here. It's reasonably complete.
What's the difference between language targeting and country targeting?
Language targeting (e.g., hreflang="es") says: show this to Spanish speakers regardless of where they are. Country targeting (e.g., hreflang="es-MX") says: show this to Spanish speakers in Mexico specifically. Use language-only tags when your content is the same for all speakers of that language. Use language-country tags when pricing, currency, or significant content differs by region.
My hreflang errors went up after I fixed them. Why?
Usually because fixing some tags made Google crawl your pages more aggressively and it's now finding errors it wasn't previously reporting. It's a reporting artifact, not a sign the fixes made things worse. Keep going, re-crawl in 4 weeks.
---
Hreflang is genuinely one of those things where getting it 90% right is almost as bad as getting it 0% right. The broken signals create noise that Google learns to distrust. Take the time to do it properly, audit it regularly, and treat it like the infrastructure it is. Your international organic traffic will thank you quietly, which is the best kind of thanks.