International SEO: Hreflang Tags Explained with Examples

Hreflang tells Google 'this page has alternate versions in these other languages or regions - show the right one to the right user.' Done right, it prevents Google from showing your Spanish page to a French user or your US page to a UK user. Done wrong, it is silently ignored and your localized pages compete against each other on the SERP.

Hreflang does not affect rankings directly. It does not boost the linked pages. What it does is fix the CTR problem that comes from wrong-language or wrong-region snippets in the SERP, and it prevents Google from treating your language variants as duplicate content. Both effects compound over time into meaningful traffic differences.

Hreflang is not a substitute for localization. If your Spanish page is a machine translation of your English page with no adaptation, hreflang will not save you - Google will still consider it low-quality content. The correct workflow is human localization first, then hreflang to signal the relationship.

The format is language[-region], using ISO 639-1 for language and ISO 3166-1 alpha-2 for region. The most common mistakes: using 'uk' for the United Kingdom (correct code is 'gb'), using 'en-uk' (should be 'en-gb'), and capitalizing regions ('EN-GB' works but 'en-gb' is standard).

Language-only codes are valid. hreflang='es' targets Spanish speakers regardless of region. hreflang='es-mx' targets Spanish speakers specifically in Mexico. If you have both, Google uses the more specific one when it applies and falls back to the language-only one otherwise. Include both when the region variant genuinely differs from the base language.

The x-default value is special. hreflang='x-default' points to the fallback page for users whose language and region you do not have a targeted version for. This is usually your main English or global homepage. Every hreflang cluster should include an x-default even if you have many localized versions - it prevents unexpected fallback behavior.

Every page in an hreflang cluster must include an hreflang tag pointing to itself, plus tags for every other version in the cluster. If page A links to page B via hreflang, page B must link back to page A. Missing reciprocity causes Google to ignore the entire relationship, not just the broken half.

Debugging this is tedious because a single missing tag on a single page can break a cluster of 20 pages. The Search Console International Targeting report flags reciprocity errors at scale - check it monthly if you run a multi-region site.

Automation is the only sustainable approach. Never maintain hreflang tags manually across dozens of pages. Either generate them from a translation database at build time, or serve them from a sitemap where a single template loop covers all pages. Manual maintenance guarantees drift.

There are three valid places to declare hreflang: in the HTML head of each page (as link elements), in the HTTP response header (for non-HTML resources like PDFs), or in the XML sitemap (as xhtml:link elements). All three are equally valid to Google. Pick one method per URL and stick with it - mixing methods for the same URL causes confusion in debugging tools.

Sitemap-based hreflang is best for large sites. A single sitemap can declare hreflang for tens of thousands of URLs with cleaner maintenance than editing every page's head. It also makes bulk auditing much easier because you can parse the sitemap directly.

HTML head hreflang is best for small sites or when your sitemap does not include every localized version. It has the advantage that browser dev tools and crawlers see it immediately without needing to fetch a separate sitemap.

You can serve international versions from country-code top-level domains (example.co.uk, example.de), subdomains (uk.example.com, de.example.com), or subfolders (example.com/uk/, example.com/de/). Each has trade-offs. ccTLDs send the strongest geographic signal but require separate domain authority per country. Subdomains are treated as semi-separate sites by Google. Subfolders inherit the main domain's authority most directly.

For most sites, subfolders under a single .com are the pragmatic winner. They consolidate authority, are the simplest to maintain, and Google handles them fine with proper hreflang. Reserve ccTLDs for genuinely separate national businesses (different legal entity, different product catalog, different support team).

The URL structure decision is nearly irreversible - migrating from subfolders to ccTLDs later is a massive project that risks temporary traffic collapse. Choose deliberately at the start of the international project, not iteratively.

The most common error is using the wrong region code. 'en-uk' is invalid (correct: 'en-gb'). 'zh-cn' is deprecated (correct: 'zh-Hans-cn' or just 'zh' if you cannot distinguish scripts). Google silently ignores invalid codes, which means the pages behave as if hreflang were never declared.

The second most common error is broken URLs in hreflang tags. If page A declares an hreflang to page B, but page B returns a 404 or a redirect, Google ignores the tag. Every URL in every hreflang tag must return a 200 with the expected language content.

The third most common error is mismatched language content. If hreflang='es-es' points to a page whose actual content is English, Google detects the mismatch and drops the hreflang relationship. Human-review a sample of your localized pages quarterly to make sure translations have not been reverted or overwritten by a CMS bug.

Hreflang is only one layer of international SEO. Users who land on a localized page still need the full experience localized - prices in local currency, phone numbers in local format, addresses in local convention, dates in local format, and customer support in the local language during local business hours.

Currency detection based on IP is fragile - VPNs and travel break it. Detect currency preference from the user's browser locale as the first choice, fall back to IP as the second, and always give the user an explicit currency switcher in the header. Nothing kills conversion faster than showing a European user prices in USD without a way to change it.

Payment methods matter too. Klarna in Germany, iDEAL in the Netherlands, Alipay in China, PIX in Brazil. Missing the locally-expected payment method is a conversion killer even on a page that ranks and receives clicks. International SEO without international payment support is leaky.