- Choose a structure (ccTLDs, subfolders or subdomains) before you build content.
- Hreflang tells search engines which language or regional version to show; it is a hint, not a redirect.
- Every hreflang tag needs a return tag, and codes must use the correct formats.
- Translate and localize content properly. Machine translation alone rarely ranks well.
Choose your structure first
| Structure | Example | Pros and cons |
|---|---|---|
| Country domains (ccTLDs) | example.de, example.fr | Strongest country signal, but each domain builds authority separately and costs more to run. |
| Subfolders | example.com/de/ | Shares the main domain’s authority and is easiest to manage. Our usual recommendation. |
| Subdomains | de.example.com | Flexible for separate hosting, but often treated more like separate sites. |
How hreflang works
Hreflang annotations tell search engines that a set of pages are equivalents in different languages or regions. For example, an English page for the United States and one for the United Kingdom, plus a German page:
hreflang="en-us"for the US English pagehreflang="en-gb"for the UK English pagehreflang="de"for the German pagehreflang="x-default"for the fallback page shown to everyone else
Language codes use ISO 639-1 (for example en, de, es) and optional region codes use ISO 3166-1 alpha-2 (for example us, gb). Note that the United Kingdom is gb, not uk.
Three ways to add hreflang
- Link tags in the HTML head: simple for most websites.
- HTTP headers: for non-HTML files such as PDFs.
- XML sitemaps: practical for large sites with many versions.
Use one method consistently. Mixing them makes errors more likely.
The most common hreflang mistakes
- Missing return tags. If page A points to page B, page B must point back to page A.
- Pointing to redirected, noindexed or non-canonical URLs. Each hreflang URL should be the indexable, canonical version.
- Wrong codes, such as
en-ukor using a country code without a language. - Forgetting the self-reference. Each page should include a tag for itself.
- Automatic redirects by IP address that stop search engines from seeing all versions.
A simple hreflang example
Imagine a services page in three versions: US English, UK English and Spanish. The head of each version would contain the same set of four annotations: one for en-us, one for en-gb, one for es and one x-default pointing to the version you want to show everyone else. Because every version lists all the others and itself, the return-tag rule is satisfied.
How to test hreflang
- Crawl the site with an SEO crawler that reports hreflang errors, such as missing return tags or non-canonical targets.
- Check the Pages report in Google Search Console to make sure every language version is indexed.
- Look at the Performance report filtered by country to confirm users in each country land on the right version.
Signals beyond hreflang
Hreflang is not the only way search engines understand which market a page is for. Local language and currency, local addresses and phone numbers, links from websites in the target country, and reviews from local customers all reinforce the signal. For businesses with physical presence in several countries, separate Google Business Profiles per location help too.
When you do not need hreflang
If you have a single language version and sell to everyone the same way, hreflang adds nothing. It becomes necessary when you create alternative versions of pages for different languages or regions.
Localize, do not just translate
Use local currencies, spelling, units, phone numbers and examples. Research keywords in each language, because people in different countries describe the same product in different ways. We have seen this firsthand on international and multilingual projects.
Planning an expansion? See our international SEO service.
MD. TAMZID ULLAH is the Founder & CEO of ITCore and a Top Rated SEO expert and AI search visibility (AEO & GEO) strategist with 6+ years of experience. Meet the team.