Multilingual SEO and hreflang: how to tell Google which version to show each user

What hreflang is and what problem it solves

hreflang is an attribute that tells search engines a page has equivalent versions in other languages or for other regions, and what the URL of each one is. It is not a ranking factor: it does not make a page rank higher. What it does is help Google choose which of the equivalent versions to show, based on the language and location of the person searching.

It solves two specific problems:

• The wrong version in the results. Without hreflang, a user in Germany may see the English version of your page simply because it has attracted more links.
• Near-identical content across regions. If you have one English page for the UK and another for Ireland that differ only in currency and contact details, hreflang makes it clear they are not accidental duplicates but variants intended for different audiences.

It is worth being clear about its scope. Google uses hreflang; other search engines treat it differently. Bing, for example, has said in its documentation that it relies more on signals such as the HTML lang attribute or the content-language meta tag. A robust implementation therefore combines hreflang with a correct lang attribute on every page. If you want a refresher on the basic terms, you will find them in our SEO glossary.

Before hreflang: choosing a site structure

hreflang sits on top of a URL architecture. Before writing a single tag, decide how you are going to organise languages and countries. There are four common options:

Structure	Example	Advantages	Drawbacks
Country-code domain (ccTLD)	example.de, example.fr	Very clear geographic signal; local trust	Each domain builds authority separately; higher management overhead
Subdirectory	example.com/de/	Shares the domain's authority; easy to maintain	The country signal is less obvious without hreflang
Subdomain	de.example.com	Each version can be hosted or managed separately	Usually takes more work to consolidate authority
Parameters	example.com/?lang=de	Quick to implement	Not recommended: hard to crawl, segment and measure

For most mid-sized companies working from Spain into several European markets, subdirectories are the most balanced option: one domain, one pool of authority and the ability to add languages without multiplying infrastructure. ccTLDs make sense when there are genuine local operations (a legal entity, logistics, customer service) and the budget to treat each market as a project in its own right.

Two rules apply whichever structure you choose:

• One URL per language or region. Never serve different languages on the same URL based on cookies or IP address: Google crawls mostly from the United States and would only ever see one version.
• No automatic redirects based on IP or browser language. If you want to suggest another version, use a banner the user can dismiss. Forced redirects prevent the crawler from reaching every version.

If the decision involves changing existing URLs, treat it as a migration and read our guide to migrating a website without losing SEO.

Language and region codes: the correct format

An hreflang value is made up of a language code in ISO 639-1 format and, optionally, a region code in ISO 3166-1 alpha-2 format, separated by a hyphen.

• en: English, for any English-speaking user.
• en-GB: English for users in the United Kingdom (not en-UK, which does not exist).
• en-IE: English for users in Ireland.
• es-ES: Spanish for users in Spain.
• de-AT: German for users in Austria.

Points that regularly cause mistakes:

• Language is mandatory; region is optional. A value such as GB or ES on its own, with no language, is invalid.
• Do not invent combinations. Codes such as en-EU or es-LA do not correspond to countries, and Google ignores them.
• Upper and lower case. Values are not case-sensitive, but the convention (en-GB) makes them easier to read and review.
• Only target regions when there are real differences. If your English content is the same worldwide, en is enough. Creating en-GB, en-IE and en-US with identical text multiplies maintenance without giving users anything extra.

Three ways to implement hreflang

Google supports three equivalent methods. Choose one per set of pages: combining them adds nothing and multiplies the chances of contradictions.

1. Link elements in the HTML <head>

This is the most common method. Each page includes one element per version, including itself:

<link rel="alternate" hreflang="en" href="https://example.com/en/services/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/servicios/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services/" />

The advantage: it is visible and easy to audit. The drawback: on sites with many languages the block grows and adds weight to every page; and if the CMS injects the tags with JavaScript, you depend on rendering working correctly.

2. HTTP headers

For non-HTML files such as PDFs, the annotation is sent in the response's Link header:

Link: <https://example.com/en/guide.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/es/guia.pdf>; rel="alternate"; hreflang="es"

It is configured on the server or CDN. It is useful for downloadable documents, but harder to check at a glance.

3. XML sitemap

On large sites this is the cleanest option: annotations are centralised in the sitemap and do not bloat the HTML. Each <url> entry lists all of its alternates, including itself:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/services/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/services/"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/servicios/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/services/"/>
  </url>
  <url>
    <loc>https://example.com/es/servicios/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/services/"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/servicios/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/services/"/>
  </url>
</urlset>

The drawback is that the annotations live "outside" the page, so you need to make sure the sitemap is regenerated every time a URL is published, removed or translated.

Method	Best for	Main risk
HTML head	Small and mid-sized sites, CMSs with multilingual plugins	Tags injected by JavaScript or incomplete templates
HTTP header	PDFs and other non-HTML files	Configuration forgotten after server or CDN changes
XML sitemap	Large sites, catalogues, many languages	Sitemaps out of sync with the actual content

x-default, self-references and return links

x-default

x-default tells Google which URL to show when none of the declared versions matches the user's language or region. It usually points to the international version (often English) or to a language-selector page. It is not mandatory, but it is recommended: without it, Google decides on its own which version to show a user in, say, Poland, if you have no Polish version.

Self-reference

Every page must include itself in its own set of annotations. The Spanish version lists the Spanish one, the English one and the rest; the English version lists exactly the same set.

Return links (reciprocity)

This is the rule that is broken most often: if page A points to page B as an alternate, B must point back to A. If the relationship is not reciprocal, Google may ignore the annotations. This prevents a third party from declaring their page an "alternate version" of yours.

Rule of thumb: the set of hreflang tags should be identical on every page in the group. If you copy it from one version to another and something differs, there is a mistake.

hreflang and canonical tags: how they coexist

A canonical tag indicates the preferred URL within a group of duplicates. hreflang links equivalent pages in different languages. The two are compatible as long as you respect one rule: every language version must have a self-referencing canonical.

The classic mistake is to canonicalise every version to the main one, for example giving the German page a canonical pointing to the English version. That tells Google the German page is a duplicate that should not be indexed, which contradicts the hreflang annotation. The usual outcome is that the German version disappears from the results.

Other frequent situations:

• Parameterised URLs. If /en/services/?utm_source=x has a canonical to /en/services/, hreflang annotations must always use the canonical URL, never the parameterised variant.
• Pagination and filters. Only indexable URLs should carry hreflang. If a page is noindex or canonicalised to another, leave it out of the group.
• Near-identical regional versions. If en-GB and en-IE share their text, each keeps its own canonical and hreflang links them. Google may cluster them, but it will show the appropriate URL in each market.

Translation is not localisation

hreflang tells Google which page to show, but it does not make that page deserve to rank. Markets search differently: a British buyer looking for a home in Marbella does not use the same words as a Dutch buyer, and neither literally translates what a Spanish buyer would type.

• Keyword research per market. Do not translate your keyword list: research it in each language, with tools set up for each country.
• Local elements. Currency, date and phone formats, units, legal references, payment methods and social proof from that specific market.
• Translated metadata and URLs. Title, meta description, headings, alt text and, where possible, slugs in the page's language.
• Native review. Machine translation is a good starting point, but commercial pages need review by a native speaker.
• Consistent internal linking. Links in each version should lead to pages in the same language. A visible language selector on every page completes the system.

This localisation work is at the heart of our international SEO service and ties in with what we describe for international companies.

Common mistakes we find in audits

1. Missing return links. A new version is published with hreflang, but the existing versions are never updated to point to it.
2. Invalid codes. en-UK, es-LA, regions without a language, or underscores instead of hyphens (en_GB).
3. URLs that do not return 200. Annotations pointing to redirects, 404 pages or URLs blocked by robots.txt.
4. Contradictory canonicals. Language versions canonicalised to another version, or to the home page.
5. hreflang to non-equivalent pages. Linking a Spanish product page to the English home page because the product does not exist in English. If there is no equivalent, simply do not declare one.
6. Relative URLs. href values must be absolute URLs, including protocol and domain.
7. Mixed and contradictory methods. Tags in the HTML saying one thing and the sitemap saying another.
8. Untranslated content. Pages with a translated template but body copy in the original language: Google may decide they are not really a version in that language.

How to verify your implementation

Search Console no longer offers the old International Targeting report, so verification relies on other tools:

1. A full crawl with a crawler such as Screaming Frog or Sitebulb, which flag missing return links, invalid codes, non-indexable URLs and canonical conflicts.
2. URL Inspection in Search Console, to check which canonical Google has selected for each version and whether it matches yours.
3. The Page indexing report, to spot versions marked as "Duplicate" or "Alternate page with proper canonical tag".
4. Performance by country in Search Console: filter by country and check which URLs are getting impressions. If English URLs are appearing in Germany, something is wrong.
5. A review after every release. Add hreflang to your deployment checklist; our SEO checklist is a good starting point.

Conclusion

hreflang is a small part of a larger system. It works well when the URL structure is clear, each version has its own canonical, annotations are reciprocal and the content is genuinely adapted to each market. It fails when it is bolted on at the last minute to a half-translated website. If you are preparing to expand into new languages, or suspect Google is showing the wrong version in some countries, an SEO audit is the place to start, so that you find the problem before investing in more content.