What Is International SEO and How hreflang Works

International SEO is the practice of structuring and signalling a multi-language or multi-region website so search engines serve the right version to the right user — the British English page to someone in the UK, the Canadian French page to a francophone in Quebec. The mechanism that makes this work is hreflang, a set of annotations that map your language and region variants to each other so Google knows which one to show. The two decisions that matter most are: which URL structure to use (country-code domains, subdomains, or subdirectories) and how to implement hreflang correctly (reciprocal, with valid codes, plus an x-default). This guide covers both, with the common mistakes that quietly break international setups.

It builds on core technical SEO; if you are new to the foundations, start with what is technical SEO and how to audit it.

What international SEO is (and what it is not)

International SEO is about serving the most appropriate version of your content to users in different countries and languages. It is not simply translating your site — translation is one part — and it is not a ranking trick. It is a set of structural and signalling decisions that help search engines understand your site's geographic and linguistic intent and route each user to the version meant for them.

There are two distinct dimensions, and conflating them causes most of the confusion:

• Language targeting — serving content in the user's language (English, French, German). A single language can span many countries.
• Country/region targeting — serving content tailored to a specific country or region (prices in local currency, local shipping, region-specific products), regardless of language.

Some sites need only language targeting (a documentation site offered in five languages worldwide). Others need both (a retailer with distinct stores for the US, the UK, and France, where the US and UK stores share a language but differ in currency, stock and shipping). Knowing which you need shapes everything that follows.

Step one: choose a URL structure

Before any hreflang, decide where each international version lives. There are three mainstream options, each a trade-off.

Country-code top-level domains (ccTLDs) — example.fr, example.de, example.co.uk. These send the strongest geo-targeting signal: a .fr domain clearly targets France. They are unambiguous to users and search engines. The cost: each domain is a separate entity that must build its own authority, they are more expensive and complex to maintain, and you cannot easily consolidate domain strength.

Subdomains — fr.example.com, de.example.com. These separate each market under the main domain. They are moderately easy to set up and can be geo-targeted, but search engines may treat subdomains as somewhat separate from the root, so authority does not always flow as freely as you would like.

Subdirectories (subfolders) — example.com/fr/, example.com/de/. These keep everything on one domain, so all your link authority and reputation consolidate on a single strong property. They are the easiest to manage and the most common pragmatic choice, especially for organisations that do not want to build authority for several domains in parallel. The trade-off is a slightly weaker per-country geo signal than a ccTLD, which you compensate for with hreflang and other targeting.

Here is the comparison at a glance.

Structure	Example	Geo signal	Authority	Maintenance
ccTLD	example.fr	Strongest	Split per domain	Highest cost/complexity
Subdomain	fr.example.com	Moderate	Partly separate	Moderate
Subdirectory	example.com/fr/	Moderate (lean on hreflang)	Consolidated on one domain	Easiest

For most businesses without a large international team, subdirectories on one strong domain are the sensible default; reserve ccTLDs for cases where a powerful local-domain signal or legal/brand reasons justify the overhead.

Step two: understand hreflang

hreflang is the annotation that tells Google, for a given page, what language and (optionally) region it targets, and where the equivalent pages for other languages and regions live. It resolves the core problem of international sites: you have several pages with the same purpose in different languages, and you need Google to (a) not treat them as duplicates and (b) show each user the right one.

A few rules define correct hreflang:

• The language code uses ISO 639-1 (two letters): en, fr, de, es.
• The optional region code uses ISO 3166-1 Alpha-2 (two letters), combined with a hyphen: en-GB, en-US, fr-CA, pt-BR. Region without language is not valid — it is always language or language-REGION.
• Every page in a set must declare the entire set, including itself (a self-referential hreflang).
• The annotations must be reciprocal: if the English page points to the French page, the French page must point back to the English page. Missing return tags are the most common reason Google ignores hreflang.

A worked example for a page available in UK English, US English and French, with an international fallback:

<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/page" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

Every one of those four pages should carry this same block (each listing all four, including itself). That reciprocity is what makes the set valid.

The x-default value

x-default is a special hreflang value that names the fallback page for users whose language or region you do not specifically target. If your set covers en-GB, en-US and fr, and someone in Japan searching in Japanese encounters your content, none of your targeted combinations match them — x-default tells Google what to show instead. It commonly points to an international/generic English page or a language-selector landing page that lets users choose. It is optional, but adding it is good practice because it removes ambiguity about the catch-all case rather than leaving Google to guess.

hreflang is targeting, not ranking

A crucial expectation to set: hreflang does not boost rankings. It is a targeting and disambiguation signal. It does not make a page rank higher; it helps Google serve the correct language or regional version to the right user, and it stops your localised versions from being treated as competing duplicates of one another. The benefit is real but indirect — users land on the appropriate version, which improves relevance and reduces the bounce that comes from hitting the wrong-language page — but no one should implement hreflang expecting a direct ranking lift. If you want ranking improvements, that comes from the usual levers: quality content, authority, and the fundamentals in how to write SEO-friendly content.

Three ways to implement hreflang

hreflang can be declared in three places. Pick one method and apply it consistently — mixing them invites errors.

1. HTML <link> tags in the <head>. The most common method, shown in the example above. Each page's head lists the whole set. Simple and visible, but adds markup to every page, which can get heavy if you have many language variants.

2. HTTP headers. For non-HTML files (such as PDFs) that have no HTML head, the server sends Link: headers expressing the same hreflang relationships. This is the right tool when the content is not an HTML page.

3. XML sitemap. You can declare hreflang in your sitemap using xhtml:link entries, keeping the annotations out of the page markup entirely. This is efficient for large sites with many language variants, because you maintain the relationships in one file rather than in every page's head. The trade-off is that sitemap hreflang is less visible and a little harder to spot-check by eye.

Method	Best for	Trade-off
HTML head <link>	Most sites; straightforward setups	Adds markup to every page
HTTP header	Non-HTML files (PDFs)	Server-level configuration needed
XML sitemap	Large sites, many variants	Less visible; harder to eyeball

Common hreflang mistakes

hreflang is notoriously easy to get subtly wrong, and a broken set is often silently ignored. These are the recurring failures.

Missing return tags (non-reciprocal hreflang). If page A declares page B but page B does not declare page A, Google may disregard the relationship. Every page must reference every other page in the set, plus itself.

Invalid or swapped codes. Using a made-up code, a wrong region (en-UK instead of the correct en-GB), or putting the country first (GB-en) breaks the annotation. Language first, region second, both valid ISO codes.

Pointing to non-canonical or redirecting URLs. hreflang must point to the final, canonical, indexable URL. If it points to a URL that redirects, 404s, or is canonicalised elsewhere, the signal is undermined. hreflang and canonical must also agree — do not canonical a page to a different-language version.

Mixing language-only and language-region inconsistently. Decide whether each market is fr or fr-CA/fr-FR and be consistent. Declaring fr on one page and fr-FR on its counterpart breaks reciprocity.

Self-reference missing. Each page must include an hreflang entry for itself; omitting it is a frequent validator complaint.

Relying on hreflang to fix thin or untranslated content. hreflang routes users; it does not make a machine-translated, low-quality regional page good. Localisation quality still matters.

Content localisation, not just translation

A point that separates mediocre international SEO from good: localisation is more than translation. Real localisation adapts currency, units, date formats, examples, imagery, idiom, legal/compliance details and even product availability to the target market. A US page translated word-for-word into French but still quoting dollars and US shipping serves the francophone user poorly, and search engines increasingly reward genuinely useful, market-appropriate content. Where two markets share a language but differ commercially (en-US and en-GB), the content may be nearly identical in language while differing in price, stock and shipping — which is exactly why region-level hreflang (en-US vs en-GB) exists. Invest in proper localisation; treat translation as the floor, not the ceiling.

How to test your hreflang

Because hreflang is error-prone, validate it rather than trusting it. Google Search Console historically surfaced international targeting and hreflang issues, and its URL Inspection tool helps you confirm which URL Google treats as canonical (which must agree with your hreflang). Dedicated hreflang testing tools — such as hreflang validators and tag-checking tools (Merkle's hreflang tags testing tool is a well-known example) — parse a page's annotations and flag missing return tags, invalid codes and broken references. An SEO crawler that supports hreflang (Screaming Frog and similar) audits the whole site at once, catching non-reciprocal sets and mismatched codes across thousands of pages. And a broad site audit — StackOptic included — can flag international and indexing signals alongside the rest of your technical SEO so you catch issues in context. Run a validator after any change, because a single swapped code can disable a set.

International SEO, AI search and beyond

The same clarity that helps Google serve the right version helps AI answer engines too: unambiguous language and region signals, clean canonical URLs, and genuinely localised content make it easier for any system — classic search or generative — to understand and surface the right page for the right user. As AI answers expand across languages and regions, the structural discipline of good international SEO becomes part of being correctly represented. If AI visibility is on your roadmap, it connects to the broader practice in how to get cited by AI search engines — and the localisation quality bar overlaps with the trust signals there.

An international SEO checklist

• Decide whether you need language targeting, region targeting, or both.
• Choose one URL structure (ccTLD, subdomain, or subdirectory) and apply it consistently.
• Implement reciprocal hreflang: every page lists the whole set, including itself.
• Use valid ISO language codes and, where needed, ISO country codes (en-GB, fr-CA).
• Add an x-default for users you do not specifically target.
• Point hreflang only at final, canonical, indexable URLs.
• Keep hreflang and canonical tags in agreement.
• Pick one implementation method (head, HTTP header, or sitemap).
• Localise properly — currency, units, examples — not just translate.
• Validate with a hreflang testing tool and re-check after changes.

Where to start

If you are setting up international SEO from scratch, begin by choosing your URL structure deliberately — for most teams, subdirectories on one strong domain are the lowest-risk, highest-leverage choice. Then map your markets to language and region codes, deciding consistently whether each is language-only or language-region. Implement reciprocal hreflang on your highest-value page templates first, add an x-default, and immediately run the set through a hreflang validator to catch missing return tags and code errors before they propagate. Confirm in Google Search Console that the canonical Google selects matches your intent. Then expand to the rest of the site, and treat localisation quality — not just translation — as the work that actually wins each market. That order — structure, codes, reciprocal hreflang, validate, then localise — keeps an inherently fiddly setup from collapsing under its own complexity.

Go deeper

• The foundation: what is technical SEO and how to audit it.
• Avoid localised duplication: what is duplicate content and how to fix it.
• The canonical companion: what are canonical tags and how to use them.
• Write content that travels: how to write SEO-friendly content.

Want your international signals checked alongside performance, SEO and AI-readiness? Analyse any URL with StackOptic — one report, free, no sign-up.