I put “I speak fluent hreflang” on my About Me page.
I meant it as a flex. But honestly, after watching how many ways international SEO gets implemented incorrectly, it’s less of a flex and more of a survival skill. Hreflang is the one technical implementation that confuses experienced developers, senior SEOs, and confident clients with equal efficiency.
The premise is simple. Your website serves multiple countries, multiple languages, or both. You want Google to show the right version to the right person. A user searching in Germany should see your German page. A user searching in Brazil should see your Portuguese page. A user in Australia should see your English version with Australian pricing, not the US version with dollar signs.
Without hreflang, Google guesses. And Google’s international guesses are often wrong in ways that are genuinely difficult to diagnose because everything looks fine from your own country.
Table of Contents
- What International SEO Actually Covers
- URL Structure Options for International Sites
- What Hreflang Actually Is
- The Non-Negotiable Rules of Hreflang
- Common Hreflang Mistakes That Explain Why Your International Traffic Makes No Sense
- How to Implement Hreflang Correctly
- How to Test Your Hreflang Implementation
- When You Don’t Need Hreflang
- The TL;DR
What International SEO Actually Covers
International SEO is the practice of making sure search engines understand which version of your website is intended for which country, which language, or which combination of both.
The two dimensions are distinct and both matter:
Language targeting means you have the same content in multiple languages. English and French, for example. The content is the same, translated. The intended audience is defined by language, not necessarily by geography.
Country targeting means you have versions of your site for specific countries. An English version for the US and a separate English version for the UK, with different pricing, different phone numbers, different spelling conventions, different legal copy. The content language is the same but the audience is geographically distinct.
Sometimes you have both simultaneously. An English version for the US, an English version for the UK, a Spanish version for Spain, and a Spanish version for Mexico. Four versions, two languages, four geographic targets.
Hreflang is how you communicate all of this to Google explicitly, rather than letting Google guess from IP addresses, domain names, and content signals alone.
URL Structure Options for International Sites
Before getting into hreflang, the first decision is how you structure your international site at the URL level. Three main options:
Country code top-level domains (ccTLDs)yoursite.de for Germany, yoursite.fr for France, yoursite.co.uk for the UK.
The strongest geographic targeting signal available. Each domain is treated as a separate site specifically associated with that country. The downside is that link equity and domain authority don’t consolidate. Building authority for five separate domains is five times the work of building authority for one. Recommended only for large organisations with the resources to treat each country domain as an independent site.
Subdirectories (recommended for most sites)yoursite.com/de/ for Germany, yoursite.com/fr/ for France, yoursite.com/en-gb/ for the UK.
All authority consolidates on the root domain. Hreflang implementation is clean and straightforward. Manageable for most organisations. This is the structure Google recommends for most international sites and the one I recommend to the majority of clients.
Subdomainsde.yoursite.com, fr.yoursite.com, en-gb.yoursite.com.
Technically feasible. Treated by Google as closer to separate sites than subdirectories, so authority consolidation is weaker than subdirectories. Harder to manage than subdirectories with limited upside over them. Not the recommended approach in most cases.
What Hreflang Actually Is
Hreflang is an HTML attribute that tells Google which language and region each version of a page is intended for, and which other versions exist as alternatives.
It lives in the <head> of your page and looks like this:
xml<link rel="alternate" hreflang="en-us" href="https://yoursite.com/en-us/page/" />
<link rel="alternate" hreflang="en-gb" href="https://yoursite.com/en-gb/page/" />
<link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" />
<link rel="alternate" hreflang="es-mx" href="https://yoursite.com/es-mx/page/" />
<link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" />
The language code follows the ISO 639-1 standard (two-letter codes: en, de, fr, es). The region code follows the ISO 3166-1 Alpha-2 standard (two-letter country codes: US, GB, DE, MX). Combined with a hyphen: en-US, en-GB, es-MX.
The x-default value designates the fallback version shown to users whose language or region doesn’t match any specific variant. Usually the primary English version.
The Non-Negotiable Rules of Hreflang
These are not suggestions. These are the rules that, when broken, cause Google to ignore your entire hreflang implementation silently.
Rule 1: Every variant must reference every other variant.
If you have four language versions of a page, every single one of those four pages must contain hreflang tags referencing all four versions, including itself. This is called bidirectional or reciprocal hreflang.
If Page A references Page B but Page B does not reference Page A, Google considers the implementation invalid and ignores it. You cannot do one-directional hreflang and have it work.
This is the most commonly broken rule and the most common reason hreflang implementations fail silently.
Rule 2: Every page must include a self-referencing hreflang.
In the example above, the German page (/de/page/) contains a hreflang tag pointing to itself with hreflang="de". This is not optional. The self-reference is a required part of the implementation.
Rule 3: Hreflang URLs must be absolute, canonical, and indexable.
Every URL in a hreflang annotation must use the full absolute URL including https://, must be the canonical version of that page (not a redirect or a noindexed page), and must be live and returning a 200 status code.
A hreflang tag pointing to a redirected URL, a 404, or a noindexed page is an invalid annotation. Google ignores it.
Rule 4: Canonical tags must not conflict with hreflang.
This one causes specific damage on international sites. If your French page has a hreflang tag declaring itself as the French version, but also has a canonical tag pointing to the English version, you’ve created a direct contradiction.
The hreflang says: “Show this to French users.”
The canonical says: “The authoritative version of this content is the English page.”
Google resolves this conflict by treating the canonical as the stronger signal and largely ignoring the hreflang. Your French pages effectively stop being served to French users.
Every international page variant must self-reference in its canonical tag. The French page canonical points to the French page. The German page canonical points to the German page. Never cross-language canonicalization.
Common Hreflang Mistakes That Explain Why Your International Traffic Makes No Sense
The one-directional implementation. The main English site has hreflang tags pointing to all language variants. The language variants have no hreflang tags at all. The whole thing is invalid.
Missing x-default. No fallback version designated. Users whose region doesn’t match any variant get inconsistent results based on Google’s best guess.
Wrong language codes. hreflang="sp" instead of hreflang="es" for Spanish. hreflang="jp" instead of hreflang="ja" for Japanese. Invalid codes are silently ignored.
Language-only targeting when country-specific versions exist. Using hreflang="en" when you actually have a US version and a UK version that should be distinguished. hreflang="en" with no country code means “this page is for all English speakers globally” which conflicts with having separate US and UK versions.
Hreflang in the sitemap but not on the page. Google accepts hreflang implementation via XML sitemap as an alternative to on-page tags. But if you use both and they conflict, Google uses the on-page version. Stick to one implementation method.
Not updating hreflang when adding new language variants. A site launches with English and German. Six months later, French is added. The English and German pages are updated with a new French hreflang annotation. But the French pages aren’t given reciprocal annotations back to English and German. Incomplete and invalid.
How to Implement Hreflang Correctly
Use the generator: If you want the hreflang code built correctly without writing it by hand, use Subu’s International SEO Hreflang Generator. Enter your page variants, language and region codes, and it outputs ready-to-paste hreflang tags for every version, including the self-referencing annotations and x-default.
On WordPress: Most major SEO plugins (Rank Math, Yoast for multilingual sites with WPML or Polylang) handle hreflang generation automatically once the multilingual plugin is configured. The multilingual plugin manages the relationship between translated pages, and the SEO plugin generates the correct hreflang annotations from those relationships.
Manual implementation: Add the hreflang <link> tags inside the <head> of every page, following the bidirectional rule precisely. For small international sites with a manageable number of pages, this is feasible. For large sites, it should be templated and automated.
Via XML sitemap: Create a sitemap that includes hreflang annotations for each URL. This is an alternative to on-page implementation, accepted by Google. More manageable for large sites where adding <head> tags to every page variant is impractical.
How to Test Your Hreflang Implementation
Subu’s Hreflang Auditor and Tester: Use the Hreflang Auditor and Tester to run a dedicated check on your implementation. It validates your hreflang tags for the most common failure modes: missing reciprocal annotations, invalid language and region codes, canonical conflicts, and missing self-references. Run this immediately after any new implementation or after adding a new language variant to an existing site.
Google Search Console: The International Targeting report in Search Console shows detected hreflang errors and which pages have issues. After implementing hreflang, this is your first monitoring stop.
Hreflang testing tools: Several SEO tools offer hreflang validators that check for the most common errors: missing reciprocal annotations, invalid language codes, canonical conflicts. Run your URL through one of these after any implementation or change.
Manual source code check: On any international page, view the page source and search for hreflang. Verify every variant is listed, each with a valid language-region code, and that the self-referencing annotation is present.
URL Inspection in Search Console: For specific pages, inspect the URL and check the detected hreflang annotations to confirm Google is reading them correctly.
When You Don’t Need Hreflang
Hreflang is not necessary if:
Your website is in one language and targets one country. There are no variants to distinguish.
You have translated content but all versions are on the same domain with different URL paths and Google is already correctly identifying the language from the content itself. In practice, adding hreflang is still recommended to prevent future issues as the site grows.
You’re targeting multiple countries but all in the same language with no content, pricing, or regional differences between the versions. A single en hreflang annotation without country codes may be sufficient.
The TL;DR
- International SEO ensures Google shows the right language and region version of your site to the right user
- URL structure options: ccTLDs (strongest geo signal, hardest to maintain), subdirectories (recommended), subdomains (middle ground)
- Hreflang tags tell Google explicitly which version is for which language and region
- Non-negotiable rules: every variant references every other variant (bidirectional), every page self-references, all URLs are canonical and indexable, canonical tags must never point cross-language
- Most common failure modes: one-directional implementation, canonical conflicts, missing x-default, wrong language codes, not updating when new variants are added
- Test via Search Console’s International Targeting report and a hreflang validator tool
Hreflang is not beginner territory. But on any site serving multiple languages or regions, getting it right is the difference between Google confidently serving the correct version to the correct audience and Google quietly doing whatever it wants.
Running an international site where the wrong language version keeps appearing in search results in the wrong country? That’s a diagnosable hreflang problem. Drop the details in the comments.
— Subu, SEO by Subu
