Hreflang and International SEO
Last updated
International SEO is the discipline of running a site across multiple languages and regions in a way that surfaces the right version to the right user. Following hreflang best practices and investing in international link building for each target market are the two activities that most directly determine performance across regions. The technical centrepiece is hreflang, an attribute that tells Google which language and region each URL targets.
What does hreflang do?
When a site has multiple versions of substantially the same content (English for the UK, English for the US, French for France, French for Canada), Google needs a way to know which version to surface for which user. Without explicit signals it guesses, and often serves the wrong regional version.
Be careful about what hreflang is not, because two claims commonly attached to it are wrong. It does not consolidate or protect ranking signals across versions: that is what canonicalisation does, and Google states that canonical annotations carrying hreflang “are not used for canonicalization”.1 And translated pages are not a duplicate content problem in the first place, since “localized versions of a page are only considered duplicates if the main content of the page remains untranslated”.1 Hreflang decides which version is served, not how much authority each one has.
hreflang annotations declare the language and (optionally) regional targeting of each URL, and the relationships between language/region versions of the same content.
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />x-default declares the fallback URL for users who don’t match any specific hreflang.
Implementation methods
Three ways to declare hreflang. Google treats them as interchangeable: “the three methods are equivalent from Google’s perspective and you can choose the method that’s the most convenient for your site”.1 Pick one and apply it consistently, but note the reason. Using more than one is not a conflict and does not create competing signals. Google’s point is that “while you can use all three methods at the same time, there’s no benefit in Search (in fact, it maybe be much harder to manage three implementations instead of just picking one)”.1 The argument for picking one is maintenance cost, not risk.
HTML link tags. In the <head> of each page, list every language/region version. Most flexible; easiest for small to medium sites; most prone to drift on large sites because every page must list every other language version.
HTTP headers. For non-HTML resources (PDFs, images), declare hreflang via Link headers. Less common but valid.
XML sitemap entries. In the sitemap, each URL entry can include xhtml:link elements declaring its hreflang relationships. Best for very large sites; centralises hreflang management; reduces per-page maintenance burden.
For most sites under 1,000 URLs, HTML link tags are simplest. For larger sites with many language combinations, sitemap-based hreflang is more maintainable.
Hreflang rules
Self-reference. Every page must include an hreflang tag pointing to itself. Pages that only list alternate versions without self-reference are invalid.
Reciprocity. If page A declares page B as its French version, page B must declare page A as its English version. Google’s rule is that “if two pages don’t both point to each other, the tags will be ignored”.1
Google does allow a partial set, which matters at scale and is rarely mentioned: “if it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other”. It adds a priority worth following: “it is important to link newly expanded language pages bidirectionally to the originating/dominant language(s)”.1 So a hub-and-spoke pattern, with new market pages linked bidirectionally to your dominant-language pages, is a legitimate fallback when a full mesh is impractical.
Use ISO 639-1 for language and ISO 3166-1 alpha-2 for region. en for English, fr for French. en-GB for English in the UK, fr-CA for French in Canada. Region codes are uppercase by convention (Google accepts either case but uppercase is the standard). Two traps: the language code always comes first, and “you can’t specify the country code by itself”; and only codes in those two standards work, so es-419 for Latin American Spanish is not supported.1 For script variations, Google derives the script from the country where it can, but you can state it explicitly with ISO 15924, as in zh-Hant and zh-Hans.1
Provide a generic version of a language. Where you have several variants of one language, Google advises a catchall: “if you have specific URLs for English speakers in Ireland (en-ie), Canada (en-ca), and Australia (en-au), provide a generic English (en) page for searchers in the US, UK, and all other English-speaking locations”.1 This is distinct from x-default, which is a fallback across all languages rather than within one.
One-to-one mapping. Each unique (language, region) combination should map to exactly one URL. Listing two URLs for the same hreflang value is invalid.
Match the page content. Hreflang declares targeting; the page itself should be in the declared language. Google determines language from the visible content rather than from your annotation,1 so a mismatch means the annotation is describing something the page isn’t.
Common URL structures for international sites
ccTLDs. Separate top-level domains per country: example.co.uk, example.de, example.fr. Strongest geo-targeting signal; expensive to maintain; SEO authority doesn’t transfer between domains.
Subdomains. uk.example.com, de.example.com. Moderate geo-targeting signal; Google treats each as a separate property.
Subdirectories. example.com/en-gb/, example.com/de/. Easiest to maintain; SEO authority consolidated on a single domain; the dominant pattern for new builds.
URL parameters. example.com/?lang=de. Discouraged; harder for Google to crawl efficiently; weaker geo-targeting signal.
For new builds, default to subdirectories. Use ccTLDs only when there’s a strong business case (legal requirements, distinct local brand presence, dedicated local infrastructure).
Hreflang works across separate domains
Hreflang annotations are not limited to URLs within the same domain: Google states that alternate URLs "do not need to be in the same domain". If your site operates across separate ccTLDs, for example a .co.uk and a .com.au serving British and Australian English respectively, hreflang should be implemented across them, with each domain's pages annotating the equivalents on the other. Without cross-domain hreflang, Google has nothing connecting the two as versions of the same content, so it is more likely to serve the wrong one to a given user. Note that this is about which version gets served, not about pooling authority between the domains, which hreflang does not do.
Geo-targeting signals
Google removed the International Targeting report from Search Console in September 2022, including the manual country-targeting setting.2 Geo-targeting now relies on signals Google reads automatically. Its documentation lists four groups:3
- ccTLDs, which “provide a strong signal to both users and search engines that your site is explicitly intended for a certain country”. Note the exception: Google treats around twenty vanity ccTLDs as generic, including
.ai,.co,.io,.meand.tv, plus.euand.asia. - hreflang statements, “whether in tags, headers, or sitemaps”.
- Server location, through the server’s IP address, which Google notes “is not a definitive signal” given CDNs and hosting choices.
- Other signals, including “local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, or signals from your Business Profile”.
Two things follow. For subdomain and subdirectory sites, hreflang is the strongest explicit lever, but it is not the only signal and the page’s own content does real work. And Google states it “ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes”,3 so those are not an alternative.
One clarification that catches people out: hreflang does not tell Google what language a page is in. “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language”,1 working from the visible content.3 Hreflang declares who a page is for; the content determines what language Google thinks it is.
Common hreflang problems
| Problem | Effect |
|---|---|
| Missing self-reference | Annotations ignored |
| Non-reciprocal annotations | Annotations ignored on the missing side |
Wrong region code (e.g. en-UK instead of en-GB) | The region part is ignored, so it silently degrades to en |
Region code with no language (e.g. de intended to mean Germany) | Invalid; the first code is always the language |
| Relative or protocol-relative URLs in annotations | Invalid; URLs must be fully qualified including https |
| Hreflang pointing to noindexed or redirected URLs | Annotations weakened or ignored |
| Multiple URLs for the same language/region | Invalid |
| Hreflang on pages that aren’t actually in the declared language | Ignored; possible quality concern |
How do you audit hreflang?
Start from the fact that catches most people out: Google no longer reports hreflang errors anywhere in Search Console. The International Targeting report was the hreflang monitor, and it went in September 2022.2 Nothing replaced it. Google’s Page Indexing documentation states plainly that “alternate language pages are not detected by Search Console”,4 and its URL Inspection documentation does not mention hreflang at all.5 Advice telling you to audit hreflang in the Pages report or URL Inspection is out of date, however commonly it is repeated.
Google’s own answer is to use third-party tools. Its hreflang documentation has a “Debugging hreflang errors” section that says “there are many third-party tools available that you can use to debug hreflang annotations”, and names two, with the caveat that “these tools are not maintained or checked by Google”.1
Crawler audits. Screaming Frog, Sitebulb, and similar tools crawl the site and report hreflang issues at scale: missing self-references, non-reciprocal annotations, broken target URLs. This is the only practical way to audit a large set.
Hreflang tags testing tool (Merkle) and Aleyda Solis’s hreflang tags generator. Both are the tools named in Google’s documentation.1 Useful for spot-checking or generating annotations for specific pages.
Search Console, indirectly. You can’t see hreflang errors, but you can see their consequences: pages missing from the index, or regional variants consolidated onto a single canonical. Note that where variants are consolidated, performance data reports against the canonical URL, so flat per-market numbers may reflect consolidation rather than an hreflang fault.6
Frequently asked questions
Do I need hreflang if I only have one language?
No. Hreflang is for managing multiple language or regional versions. A single-language site doesn’t need it.
Can the same content rank in multiple regions?
Often, but not guaranteed, and the exception is worth knowing. Where variants are genuinely different, each version becomes eligible to rank in its declared region. Where they are near-identical and in the same language, Google commonly groups them and picks one as canonical. This came up in a May 2025 exchange in which John Mueller addressed Belgian French (fr-be) pages appearing in France, clarifying that hreflang is a suggestion rather than a guarantee, that canonical selection can override it, and that same-language pages may be grouped.6 A practical consequence: don’t assume hreflang alone will produce separate performance data per region, since reporting follows the canonical.6 If you want separate regional versions to persist, give them genuinely different content.
Does hreflang improve rankings?
No, and there is no indirect mechanism either. Hreflang determines which version is served to which user; it does not make you rank where you otherwise would not. Motoko Hunt puts it well: hreflang “has always been a switcher, not a booster. If your brand lacked organic authority in Australia before implementing the tag, adding the en-au attribute wouldn’t magically improve your rankings in Sydney.”7 Getting it wrong, however, does actively damage international performance, which is why it is worth doing properly.
Footnotes
-
Tell Google about localized versions of your page — Google Search Central ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
-
The International Targeting report is deprecated — Google Search Console Help ↩ ↩2
-
Managing multi-regional and multilingual sites — Google Search Central ↩ ↩2 ↩3
-
Google reminds that hreflang tags are hints, not directives — Search Engine Journal ↩ ↩2 ↩3
-
AI search, market relevance and hreflang — Search Engine Land ↩
