Hreflang Guide

What is hreflang?

Hreflang is an HTML attribute that tells search engines which language and regional version of a page to show to users. When you have the same content available in multiple languages or tailored for different countries, hreflang tags create a map between those versions so Google, Yandex, and other search engines can serve the right one.

The attribute was introduced by Google in 2011 [1] and has since become the standard mechanism for signaling language and regional targeting. It uses a simple rel="alternate" hreflang="x" syntax to declare relationships between pages.

Here is a basic example. If you have an English page and a Spanish translation, you would add these tags to both pages:

<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="es" href="https://example.com/es/page" />

Each tag says: "This URL is the en (or es) version of this content." Search engines read these annotations and use them to serve the correct version based on the searcher's language and location.

Hreflang is not limited to translations. You can also use it to differentiate between pages written in the same language but targeting different regions. A site with separate pages for US English and UK English would use hreflang="en-us" and hreflang="en-gb" respectively.

For a deeper introduction, see our article on what hreflang is and how it works.

Why hreflang matters for international SEO

If you run a multilingual or multi-regional website without hreflang tags, you are leaving search engines to guess which version of your content to show. That guessing often goes wrong.

The duplicate content problem

Search engines may see your English, French, and German pages as duplicate or near-duplicate content. Without hreflang signals, Google might consolidate those pages and pick one version to index, burying the others. This is especially common when the pages share a similar structure or template, even if the text differs. Our guide on hreflang and duplicate content covers this in detail.

Wrong language in search results

Users searching in French might land on your English page. Users in Australia might get your US pricing page. These mismatches increase bounce rates and hurt conversions. Hreflang tags let you tell Google exactly which page to surface for each language-region combination.

Cannibalization between regional pages

Without hreflang, your US and UK pages compete against each other in search results. Google may rank the wrong one, or split authority between them. Hreflang consolidates those signals so the appropriate regional version ranks for its target audience.

Real impact on traffic

Google's John Mueller has stated that hreflang helps Google understand the relationship between pages and serve the right version, though he has also noted that hreflang is a signal, not a directive [2]. Getting it right can lead to measurable improvements in international organic traffic by reducing mismatches and ensuring each regional page gets surfaced to the right audience.

For a complete walkthrough of hreflang's SEO implications, see our hreflang tags guide.

The three implementation methods

There are three ways to implement hreflang tags: HTML <link> elements, HTTP headers, and XML sitemaps. Each method is equally valid from Google's perspective [1]. The right choice depends on your site's technical setup.

Method 1: HTML link tags

The most common approach. You place <link> elements in the <head> section of every page that has alternate language or regional versions.

<head>
  <link rel="alternate" hreflang="en" href="https://example.com/" />
  <link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
  <link rel="alternate" hreflang="de" href="https://example.com/de/" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/" />
</head>

When to use this method:

You have a standard HTML website with server-rendered pages.
Your CMS or framework supports adding tags to the <head>.
You have a manageable number of language versions (under 20 or so per page).

Limitations:

Every alternate version must be listed on every page, so the <head> can get bloated if you support many languages.
Requires access to modify the HTML <head> of every page.

For code examples across different setups, see our hreflang HTML examples.

Method 2: HTTP headers

For non-HTML resources like PDFs, or when you cannot modify the HTML <head>, you can specify hreflang through HTTP response headers.

HTTP/1.1 200 OK
Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/fr/file.pdf>; rel="alternate"; hreflang="fr",
      <https://example.com/de/file.pdf>; rel="alternate"; hreflang="de"

When to use this method:

You need hreflang on PDF files or other non-HTML documents.
You cannot modify the page's HTML but have control over server headers.

Limitations:

Can become unwieldy with many language versions.
Not all hosting environments make it easy to set custom Link headers per resource.

Method 3: XML sitemap

You can declare all hreflang relationships in your XML sitemap using <xhtml:link> elements nested inside each <url> entry.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/" />
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
  </url>
  <url>
    <loc>https://example.com/fr/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/" />
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
  </url>
</urlset>

When to use this method:

You have a large site with many language/region combinations.
You want to manage hreflang centrally rather than on each page.
You already use XML sitemaps and have a build process that generates them.

Limitations:

Google must crawl and process the sitemap for changes to take effect, which can introduce delays.
Sitemaps can become very large on sites with thousands of pages and many language variants.

For a dedicated walkthrough, see our guide on hreflang in XML sitemaps and the companion piece on hreflang sitemaps from Instant Sitemap.

You can combine methods (for example, HTML tags plus a sitemap), but keep them consistent. Conflicting signals between methods can confuse search engines.

For step-by-step instructions on all three approaches, see how to implement hreflang.

Language and region codes

Hreflang values follow a specific format: a language code, optionally followed by a region code. These are defined by two ISO standards.

Language codes (ISO 639-1)

The language portion uses ISO 639-1 two-letter codes [3]. Some common examples:

| Code | Language | |------|-----------| | en | English | | fr | French | | de | German | | es | Spanish | | pt | Portuguese| | ja | Japanese | | zh | Chinese | | ar | Arabic | | ko | Korean | | nl | Dutch |

Region codes (ISO 3166-1 Alpha-2)

The optional region portion uses ISO 3166-1 Alpha-2 two-letter country codes [4]. You append it after a hyphen:

| Hreflang value | Meaning | |---------------|----------------------------| | en-us | English for the US | | en-gb | English for the UK | | en-au | English for Australia | | pt-br | Portuguese for Brazil | | pt-pt | Portuguese for Portugal | | zh-cn | Chinese for mainland China | | zh-tw | Chinese for Taiwan | | fr-ca | French for Canada | | es-mx | Spanish for Mexico |

When to use language-only vs. language-region

Use language-only codes (en, fr, de) when:

You have one version per language with no regional variations.
The content is not specific to any country.

Use language-region codes (en-us, en-gb) when:

You have multiple versions of the same language for different countries.
Content differs by region (pricing, spelling, legal information, product availability).

Format rules

Codes are case-insensitive, but lowercase is conventional (en-us, not EN-US).
Always use a hyphen as the separator, not an underscore (en-us, not en_us).
The language part is required. You cannot specify a region without a language.
You cannot use a language code alone when you have regional variants. If you have en-us and en-gb, you should not also have a bare en tag unless that page genuinely serves all English speakers not covered by the regional variants.

These codes follow the broader BCP 47 / RFC 5646 standard for language tags [5].

For a complete reference of valid codes, see our hreflang language codes resource.

x-default explained

The x-default value is a special hreflang annotation that designates a fallback page. It tells search engines: "If none of the other hreflang values match the user's language or region, show this page."

<link rel="alternate" hreflang="x-default" href="https://example.com/" />

When to use x-default

The most common uses:

Language selector pages. If your homepage detects the user's language and redirects them, the language selector or landing page should be the x-default.
Primary language fallback. Many sites set their English version as x-default since English serves as the broadest fallback.
International landing pages. A page that lets users choose their country/language before entering the site.

x-default and language tags together

A page can be both a specific language version and the x-default. This is common when your English page also serves as the general fallback:

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

Here, https://example.com/ is both the English version and the default fallback.

Do you need x-default?

Google's documentation lists x-default as optional [1]. That said, it is strongly recommended. Without it, search engines have no explicit fallback and must guess which page to serve for unsupported language-region combinations.

For a full breakdown, see our x-default guide.

Self-referencing hreflang tags

Every page in a hreflang set must include a tag that points to itself. This is called a self-referencing hreflang tag, and skipping it is one of the most common implementation errors.

If your English page lists alternates for French and German but does not include a tag pointing to itself as the English version, Google may ignore the entire hreflang annotation set for that page.

Here is the correct setup for the English page at https://example.com/:

<!-- This tag points to itself (self-referencing) -->
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />

And the French page at https://example.com/fr/ must include:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<!-- This tag points to itself (self-referencing) -->
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />

The key principle: every page in the set lists all pages in the set, including itself. This applies regardless of which implementation method you use.

For more on this requirement, see self-referencing hreflang tags.

Hreflang and canonical tags

One of the trickiest areas of hreflang implementation is how hreflang tags interact with canonical tags. Getting this wrong can cause search engines to ignore your hreflang entirely.

The basic rule

The rel="canonical" tag on each page should point to itself (a self-referencing canonical). The hreflang tags should also point to canonical URLs. If these two signals conflict, Google will likely ignore the hreflang annotations.

Correct setup:

On https://example.com/fr/:

<!-- Canonical points to itself -->
<link rel="canonical" href="https://example.com/fr/" />

<!-- Hreflang tags -->
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />

Broken setup:

On https://example.com/fr/:

<!-- Canonical points to the English version (WRONG) -->
<link rel="canonical" href="https://example.com/" />

<!-- Hreflang tags -->
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />

If the French page canonicalizes to the English page, you are telling Google "this French page is a duplicate of the English page." Google will then ignore the French page's hreflang entirely because a canonicalized page cannot be an alternate.

Cross-domain canonicals

If you use separate domains for different languages (like example.fr and example.de), each domain's pages should have self-referencing canonicals. Cross-domain canonical tags pointing all versions to one "main" domain will break your hreflang.

Parameter handling

If your URLs have tracking parameters or session IDs, make sure hreflang tags point to the clean canonical URL, not the parameterized version. Consistency between canonical and hreflang URLs is essential.

For the full picture, read hreflang and canonical tags.

Common hreflang errors and how to fix them

Even experienced SEO teams make hreflang mistakes. Here are the most frequent errors, why they happen, and how to fix them.

1. Missing return links

This is the single most common hreflang error. If Page A declares Page B as an alternate, Page B must also declare Page A as an alternate. If it does not, Google treats the annotation as unconfirmed and may ignore it.

Example of the problem:

English page includes:

<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />

But the French page does not include:

<link rel="alternate" hreflang="en" href="https://example.com/" />

Fix: Audit every page in each hreflang set to verify that all pages reference all other pages (including themselves). This is where automation through tools or sitemap-based implementation pays off.

For a dedicated guide on this issue, see hreflang missing return links.

2. Wrong language or region codes

Using uk instead of en-gb for British English. Using jp instead of ja for Japanese. Using three-letter codes. These are all invalid and will be ignored.

Fix: Always verify codes against ISO 639-1 (language) and ISO 3166-1 Alpha-2 (region). The hreflang language codes reference has a complete list.

3. Conflicting canonical and hreflang signals

As covered in the previous section, pointing a canonical to a different language version while also using hreflang will cause Google to disregard the hreflang annotations.

Fix: Every page should have a self-referencing canonical, and hreflang tags should only point to canonical URLs.

4. Non-200 URLs in hreflang tags

If an hreflang tag points to a URL that returns a 301 redirect, 302 redirect, 404, or any non-200 status, Google will ignore that annotation.

Fix: All hreflang URLs must resolve to 200 status codes. If you have moved pages, update the hreflang tags to point to the new URLs. For context on how redirects interact with hreflang, see the redirect chains explained guide from Redirect Trace.

5. Mixing HTTP and HTTPS

If your canonical URLs use HTTPS but your hreflang tags reference HTTP versions (or vice versa), Google sees these as different URLs.

Fix: Use the exact same protocol, domain, and path in hreflang tags as in your canonical tags.

6. Trailing slash inconsistencies

https://example.com/fr and https://example.com/fr/ are technically different URLs. If your site resolves both but your canonical uses the trailing slash version, your hreflang tags must also use trailing slashes.

Fix: Pick one URL format and use it consistently across canonicals, hreflang, and sitemaps.

7. Using hreflang on non-indexable pages

If a page has a noindex robots meta tag, Google will eventually drop it from the index and its hreflang annotations with it.

Fix: Only apply hreflang to pages you want indexed.

Hreflang errors are silent. Google does not surface warnings in Search Console when hreflang annotations are invalid. The only way to catch issues is through testing and validation tools.

For a comprehensive list, see common hreflang mistakes.

Platform-specific implementation guides

How you implement hreflang depends heavily on your CMS or framework. Here are the most common platforms and the recommended approach for each.

WordPress

WordPress does not support hreflang out of the box. You need a multilingual plugin.

WPML (WordPress Multilingual Plugin):

WPML automatically generates hreflang tags for all connected translations. Once you link a post or page to its translations within WPML's translation management interface, the plugin handles the <link> tag output in the <head>.

Key settings to check:

Verify that WPML is outputting hreflang tags (some SEO plugins can interfere).
If using Yoast SEO alongside WPML, the WPML SEO add-on manages the handoff.
Check that x-default is assigned to the correct language.

Polylang:

Polylang also generates hreflang tags automatically when translations are linked. It assigns x-default to the language you set as the default in Polylang settings.

Things to watch:

Polylang uses the "default language" setting for x-default.
Some caching plugins can interfere with hreflang output. Clear cache after changes.

For full WordPress setup instructions, see hreflang for WordPress.

Shopify

Shopify has limited native support for hreflang. If you use Shopify Markets to serve multiple languages/regions, Shopify automatically adds hreflang tags based on your market configuration.

For stores using third-party translation apps (Langify, Weglot, etc.), hreflang handling varies by app. Some inject hreflang tags automatically, others require manual theme.liquid edits.

Manual implementation in Shopify:

If you need to add hreflang tags manually, edit your theme.liquid file and add <link> elements in the <head>:

<link rel="alternate" hreflang="en" href="{{ canonical_url }}" />
<link rel="alternate" hreflang="fr" href="{{ canonical_url | replace: 'example.com', 'example.com/fr' }}" />

This is a simplified example. Real implementations need to handle URL structures specific to your store's setup.

For the full Shopify guide, see hreflang for Shopify.

Magento (Adobe Commerce)

Magento 2 supports store views for different languages and regions. Hreflang implementation typically involves:

Built-in store view configuration. Set up store views for each language/region. Magento can generate hreflang tags through extensions or custom template modifications.
Extensions. Several Magento extensions handle hreflang automatically (Amasty, Mageworx, and others). These typically read your store view configuration and output the correct tags.
Custom implementation. Add hreflang tags in the default_head_blocks.xml layout file or through a custom module that reads the store view mappings.

Key Magento considerations:

Make sure store view URLs are correct (subdirectory, subdomain, or separate domain).
Verify that category and product pages get hreflang tags, not just CMS pages.
Test that the default store view is properly set as x-default.

For detailed steps, see hreflang for Magento.

Next.js

Next.js does not include built-in hreflang support, but its architecture makes implementation straightforward.

Using the App Router (Next.js 13+):

In your root layout or page component, use the metadata export or generateMetadata function:

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { locale } = params;

  return {
    alternates: {
      languages: {
        'en': 'https://example.com/en/page',
        'fr': 'https://example.com/fr/page',
        'de': 'https://example.com/de/page',
        'x-default': 'https://example.com/en/page',
      },
    },
  };
}

Next.js will render these as proper <link rel="alternate" hreflang="..."> tags.

Using the Pages Router:

Add hreflang tags via the next/head component:

import Head from 'next/head';

export default function Page() {
  return (
    <>
      <Head>
        <link rel="alternate" hreflang="en" href="https://example.com/en/page" />
        <link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
        <link rel="alternate" hreflang="x-default" href="https://example.com/en/page" />
      </Head>
      {/* Page content */}
    </>
  );
}

Sitemap approach for Next.js:

For large Next.js sites, generating hreflang annotations in a dynamic XML sitemap is often cleaner than embedding them in every page. Use a route handler or next-sitemap package to generate the sitemap with xhtml:link entries.

Static site generators (Gatsby, Astro, Hugo)

Most static site generators do not ship with hreflang support, but their templating systems make implementation manageable.

Gatsby: Use the gatsby-plugin-react-helmet or the newer Head API to inject hreflang <link> tags. You can query your site's locale data at build time and generate the correct tags for each page. The gatsby-plugin-sitemap plugin can be configured to include xhtml:link hreflang entries.

Astro: Add hreflang tags in your layout component's <head> section. Since Astro supports multiple rendering modes, make sure hreflang tags are present in both static and server-rendered output. The @astrojs/sitemap integration supports hreflang through the i18n configuration option.

Hugo: Use Hugo's built-in multilingual mode. When you configure multiple languages in config.toml, Hugo can generate hreflang tags through its RelPermalink and Translations template functions. Add the hreflang <link> tags in your baseof.html or head partial template.

For all static generators, the XML sitemap approach is a solid alternative. Generate the sitemap at build time with full hreflang annotations, keeping your templates simpler.

Testing and validation

Hreflang errors are easy to introduce and hard to spot without dedicated testing. Google Search Console does not provide detailed hreflang error reports, so you need external tools and manual checks.

What to validate

Run through this checklist for every page in your hreflang set:

Return links exist. Every page referenced by a hreflang tag must reference back. If Page A says "my French version is Page B," then Page B must say "my English version is Page A."
Self-referencing tags are present. Every page must include a hreflang tag pointing to itself.
Language and region codes are valid. Use only ISO 639-1 language codes and ISO 3166-1 Alpha-2 region codes.
URLs are absolute. Hreflang tags require fully qualified URLs including protocol and domain. Relative paths will be ignored.
URLs return 200 status codes. No redirects, no 404s, no 5xx errors.
Canonical and hreflang alignment. Each page's canonical URL should match the URL used in hreflang tags.
Consistent protocol and domain. All URLs in a hreflang set should use the same protocol (HTTPS) and the correct domain for each version.
x-default is set. While optional, its absence leaves Google guessing about your fallback page.

Tools for validation

Several tools can audit your hreflang implementation:

Google Search Console. The International Targeting report gives limited hreflang feedback. The URL Inspection tool can show which hreflang tags Google has processed for a specific URL.
Hreflang Generator. Our tool at app.hreflanggenerator.com lets you generate correct hreflang tags and validate existing implementations.
Screaming Frog. The SEO Spider crawls your site and reports hreflang issues including missing return links, invalid codes, and inconsistencies.
Ahrefs Site Audit. Crawls your site and flags hreflang errors as part of its broader audit.
Merkle Hreflang Tag Testing Tool. A free online tool for checking individual pages.

For a comparison of available tools, see hreflang checker tools compared.

Manual spot-checking

Even with automated tools, it helps to manually inspect a few pages:

View the page source and search for hreflang.
Confirm all expected language versions are listed.
Click each hreflang URL and verify it loads the correct language version.
Check that each linked page has the full set of return annotations.

For sites using the sitemap method, download your sitemap and search for the xhtml:link entries. Verify the structure matches the XML sitemap format shown earlier.

Understanding how robots.txt and crawling work is also relevant here, since blocked pages cannot have their hreflang tags processed.

Hreflang and SEO: is it a ranking factor?

A common question: does hreflang directly boost rankings? The answer is nuanced.

Hreflang is not a ranking factor

Hreflang does not directly increase a page's ranking position. Google's John Mueller has addressed this clearly, confirming that hreflang does not boost rankings [2]. It is a serving mechanism, not a ranking signal.

What this means: hreflang tells Google which version to show in search results for a given language/region combination. It does not make any individual page rank higher for a given query.

How hreflang indirectly affects SEO

While not a direct ranking factor, correct hreflang implementation has meaningful SEO benefits:

Reduced cannibalization. Without hreflang, your English US page and English UK page may compete for the same queries. Hreflang tells Google which version to surface where, preventing them from splitting ranking signals.

Improved user experience signals. When users land on the correct language version, they stay longer, bounce less, and convert more. While Google's use of user experience as a ranking input is debated, reducing bounces is always good for business.

Consolidated link equity. Hreflang helps Google understand that your various language versions are related. Links pointing to the French version can benefit the broader set, rather than being treated as links to an unrelated page.

Better crawl efficiency. When Google understands your site's language structure, it can crawl more efficiently and allocate crawl budget more effectively across your language versions.

What Google actually does with hreflang

When Google processes a search query, it considers the searcher's language preference and location. If your hreflang annotations are in place:

Google identifies the cluster of alternate pages.
It selects the best match for the searcher's language and region.
It serves that URL in the search results.

If no hreflang match exists for the searcher's language/region, Google falls back to the x-default page (if specified) or makes its own determination.

Google processes hreflang annotations during indexing, not at query time. This means changes to hreflang tags take effect only after Google recrawls and reprocesses the affected pages.

How long does hreflang take to work?

After implementing or updating hreflang tags, expect a delay before changes are reflected in search results. Google needs to recrawl all pages in the hreflang set, process the annotations, and update its index. For small sites, this can happen within a few days to a couple of weeks. For large sites with thousands of pages, it can take several weeks or even longer.

You can speed up the process by submitting updated sitemaps in Google Search Console and using the URL Inspection tool to request recrawling of key pages. But ultimately, the timeline depends on your site's crawl frequency and size.

Yandex and hreflang

Yandex, the dominant search engine in Russia, also supports hreflang. If you target Russian-speaking markets, hreflang tags help Yandex serve the correct version of your content. Bing does not use hreflang and relies on the content-language meta tag and its own signals instead.

For a deeper analysis, see is hreflang a ranking factor?.

Hreflang best practices summary

To tie everything together, here are the practices that prevent the majority of hreflang issues:

Always include self-referencing tags. Every page must list itself in its own hreflang set.
Confirm return links on every page. Bidirectional confirmation is required for Google to trust the annotation.
Use valid ISO codes. Language codes from ISO 639-1, region codes from ISO 3166-1 Alpha-2. No exceptions.
Keep hreflang and canonical tags aligned. Each page should have a self-referencing canonical, and hreflang tags should point only to canonical URLs.
Use absolute URLs. Always include the full URL with protocol and domain.
Set x-default. Designate a fallback page for users whose language/region does not match any specific version.
Choose one implementation method and be consistent. If you use HTML tags, use them on every page. If you use a sitemap, keep it updated. Mixing methods is fine but requires careful consistency.
Audit regularly. Hreflang annotations can break silently when pages are added, removed, or redirected. Build validation into your deployment process.
Do not use hreflang on non-indexable pages. Pages with noindex directives or non-200 status codes will have their hreflang ignored.
Avoid redirects between hreflang URLs. If you redirect users based on their location, do not apply those redirects to search engine crawlers. Googlebot typically crawls from the US, so aggressive geo-redirects can prevent it from ever seeing your non-US pages. Our guide on hreflang and redirects covers this topic in detail.

If you remember only one thing from this guide: hreflang is a bidirectional confirmation system. Every page must reference every other page in the set, including itself. Missing or incomplete references cause the entire annotation set to fail.

For additional tips, see our hreflang best practices resource and the hreflang glossary for definitions of key terms.

Generate and validate hreflang tags

Create correct hreflang markup for your multilingual site. Validate existing tags and detect errors instantly.

Try Hreflang Generator

References

Google Search Central. "Tell Google about localized versions of your page." https://developers.google.com/search/docs/specialty/international/localized-versions
John Mueller, Google Search Advocate. Comments on hreflang as a signal, not a ranking factor. Google Search Central YouTube channel and various Google Webmaster Hangouts. https://www.youtube.com/googleSearchCentral
ISO 639-1:2002. "Codes for the representation of names of languages, Part 1: Alpha-2 code." International Organization for Standardization. https://www.iso.org/standard/22109.html
ISO 3166-1:2020. "Codes for the representation of names of countries and their subdivisions, Part 1: Country codes." International Organization for Standardization. https://www.iso.org/standard/72219.html
RFC 5646. "Tags for Identifying Languages." Internet Engineering Task Force (IETF), September 2009. https://www.rfc-editor.org/rfc/rfc5646

What is hreflang?

Why hreflang matters for international SEO

The duplicate content problem

Wrong language in search results

Cannibalization between regional pages

Real impact on traffic

The three implementation methods

Method 1: HTML link tags

Method 2: HTTP headers

Method 3: XML sitemap

Language and region codes

Language codes (ISO 639-1)

Region codes (ISO 3166-1 Alpha-2)

When to use language-only vs. language-region

Format rules

x-default explained

When to use x-default

x-default and language tags together

Do you need x-default?

Self-referencing hreflang tags

Hreflang and canonical tags

The basic rule

Cross-domain canonicals

Parameter handling

Common hreflang errors and how to fix them

1. Missing return links

2. Wrong language or region codes

3. Conflicting canonical and hreflang signals

4. Non-200 URLs in hreflang tags

5. Mixing HTTP and HTTPS

6. Trailing slash inconsistencies

7. Using hreflang on non-indexable pages

Platform-specific implementation guides

WordPress

Shopify

Magento (Adobe Commerce)

Next.js

Static site generators (Gatsby, Astro, Hugo)

Testing and validation

What to validate

Tools for validation

Manual spot-checking

Hreflang and SEO: is it a ranking factor?

Hreflang is not a ranking factor

How hreflang indirectly affects SEO

What Google actually does with hreflang

How long does hreflang take to work?

Yandex and hreflang

Hreflang best practices summary

Generate and validate hreflang tags

References

Related Articles