International SEO: hreflang and Site Structure
International SEO is work with versions of a site for different languages and regions, and its main tool is hreflang annotations. They tell Google which pages are localized variants of the same content. It is important to understand what hreflang does not do: Google does not detect a page’s language from it, and without it Google does not “guess wrong” in every case. Below, per Google’s help page on localized versions and the guide to multi-regional sites: how to write the annotations, the codes, URL structure, what not to do and which popular claims are not supported.
Why indicate versions
Google may find language versions on its own, but the help page advises indicating them explicitly: that helps Search point users to the most appropriate version by language or region. It is recommended in these cases: the main content is in one language and only the template (navigation, footer) is translated, as on forums with user-generated content; small regional variations in one language (for example, English for the US, GB and Ireland); a fully translated site. Localized versions are considered duplicates only if the main content of the page remains untranslated (duplicate content).
Three ways to indicate versions
Google supports three ways: tags in HTML, an HTTP header and a sitemap. They are equivalent from Google’s perspective, so choose the convenient one. You can use all three, but it brings no benefit in Search, and maintaining three implementations is harder.
<head> <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="en" href="https://example.com/en/page/" /> <link rel="alternate" hreflang="de" href="https://example.com/de/page/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" /> </head>
- HTML:
<link rel="alternate" hreflang="…">elements in<head>; the set of links is identical in every version and includes a link to the page itself. Don’t combine hreflang with other attributes (for examplemedia) in a single tag. - HTTP header: suitable for non-HTML files such as PDFs; a
Linkheader with all versions, including the requested one. - Sitemap: for each URL,
<xhtml:link rel="alternate" hreflang="…">entries for all versions, including itself (XML sitemap).
Rules for all methods
- Each version lists itself and all the others.
- Links must be reciprocal. If two pages don’t both point to each other, the tags are ignored: that way someone on another site cannot declare themselves a version of your page. If a full set is hard to maintain, you can omit some languages on some pages; but newly added versions must be linked bidirectionally to the original ones.
- URLs are fully qualified, with the protocol:
https://example.com/foo, not//example.com/fooor/foo. Alternates may be on other domains. - A fallback page. If you have specific versions for one language in different locales (
en-IE,en-CA,en-AU), provide a generic one (en) for the rest. For unmatched languages, especially on language selector pages or auto-redirecting home pages,x-defaultis suggested. The help page says “consider”, not “without it Google does not know what to show”.
Language and region codes
An hreflang value consists of a language code in ISO 639-1 and an optional region code in ISO 3166-1 Alpha 2, separated by a dash. Only codes from these standards are supported: for example es-419 is not. Case does not matter, but region codes are conventionally uppercase (en-GB). You cannot specify a country by itself: the first code stands for the language, and Google does not derive the language from a country. So for Belgium: de-BE, nl-BE, fr-BE, while a plain be is the Belarusian language. A language alone (de) is allowed, and so are script variants — zh-Hant, zh-Hans. Thus ru and ru-RU are different entries: the first is for the language regardless of region, the second for users in Russia.
How Google determines a page’s language
Google does not use hreflang or the lang attribute to detect a page’s language: it looks at the visible content. Help it: use a single language for content and navigation on each page, without side-by-side translations. If only the template is translated and the main text stays in one language, a user may see the same content in results with different wrappers.
URL structure
The help page recommends separate URLs for each language version rather than adjusting content through cookies or browser settings. Dynamic switching can mean Google does not find all the versions: Googlebot usually originates from the USA and sends requests without an Accept-Language header. The structure options:
| Option | Pros | Cons |
|---|---|---|
| Country domain (example.de) | clear geotargeting; server location is irrelevant; easy separation of sites | expensive, needs infrastructure, strict domain requirements; one country only |
| Subdomain (de.example.com) | easy to set up; servers can be located differently | users may not tell from the URL whether it is a language or a country |
| Subdirectory (example.com/de/) | easy to set up, low maintenance on one host | geotargeting is less obvious from the URL; one server |
Subdomain names such as en-gb are not used by Google to determine the target audience: you must map the audience explicitly with hreflang. More on domains is in the lesson on domains and subdomains.
What not to do
- Do not automatically redirect users to another language version based on a guessed language: it can prevent users and search engines from seeing all the versions (redirects). Add links to other versions instead.
- Do not use IP analysis to adapt content: it is unreliable, and most Google crawls originate from the US.
- Do not rely on “automatic translation at scale”. The spam policies name as scaled content abuse, in particular, creating many pages from scraped content, including through automated transformations such as synonymizing and translating, where little value is provided to users (spam policies, lesson). This text contains no ban on any machine translation, but value for the reader is required.
- Do not specify non-existent URLs: links must lead to working pages without redirects (canonical of each version points to itself).
How to check the effect
The absence of hreflang is not necessarily an error, and its presence is no guarantee. Check on data: by country and query in Search Console and by sessions in analytics. Make changes by plan with control (SEO experiments). Claims such as “without hreflang Google often errs” and figures like “CTR 0.5% and 90% bounce” are individual cases, not documentation.
Checklist
- Each language version has its own URL; the main content is translated.
- One way of indicating versions is chosen: HTML, header or sitemap.
- Each version lists itself and all the others; links are reciprocal; URLs are fully qualified.
- Codes: ISO 639-1 plus an optional ISO 3166-1 Alpha 2; a region is not specified alone.
- There is a generic or fallback version (
x-default) for unmatched languages. - No auto-redirects by language and no IP-based substitution; there are links to other versions.
Mistakes
- Assuming hreflang determines a page’s language.
- Specifying hreflang on only one version or leaving the page itself out of the set.
- Writing
beinstead offr-BEores-419. - Connecting all three methods at once and diverging in data.
- Mass-generating translations with no value for the reader.
What next
Next comes the research module: start with SEO experiments to check such changes on data rather than on stories.