Hreflang is the only part of technical SEO where a completely correct implementation looks, from the outside, like nothing happened. Nobody notices it working. Everyone notices when the German page outranks the English one in London, or when six near-identical country pages fold into one result and the rest disappear.

It is also the tag most often implemented from memory rather than from the specification, which is why the same five errors show up on almost every international site I audit. This guide covers what hreflang does, how to implement it without breaking things, and how to verify it afterwards.

What Is Hreflang?

Hreflang is an HTML attribute that tells search engines which language and optional regional version of a page to serve to a given user. It does not affect ranking directly; it swaps the URL shown in results for the matching alternative, reducing duplicate content conflicts between versions and improving relevance for international audiences.

Two consequences follow from that definition, and both are routinely misunderstood.

• Hreflang is not a ranking signal. It will not make your Australian page rank where it otherwise would not. It determines which of your already-ranking pages is displayed.
• Hreflang is a hint, not a directive. Google treats correct annotations as a strong signal but can override them, particularly when other signals contradict.

When You Actually Need It

Scenario	Hreflang Needed?	Notes
One site, one language, one country	No	Nothing to disambiguate
Same language, several countries	Yes	The highest-value case — UK, US, AU English
Fully translated versions	Yes	Prevents the wrong language being served
Partially translated site	Yes, on translated pages only	Never annotate pages that do not exist
Currency or price differences only	Usually yes	Regional variants of one language
Separate brands per market	No	Different sites, not alternates

The same-language, multi-country case is where hreflang earns its keep. Without it, three near-identical English pages compete with each other and Google picks one — often the wrong one for the market that matters most to you.

Getting the Syntax Right

The value is a language code, optionally followed by a region code. The language uses ISO 639–1, the region uses ISO 3166–1 Alpha 2, and they are joined by a hyphen.

• Language only: en, fr, de, es. Valid on its own and often the right choice.
• Language plus region: en-gb, en-us, fr-ca, pt-br.
• Region alone is invalid. There is no such value as uk or us on its own.
• The United Kingdom is gb. The code en-uk does not exist and is silently ignored.
• x-default marks the fallback page for users whose language or region you have not covered.

Codes are case-insensitive but stay consistent for your own sanity. The full reference for the attribute is documented in Google's localised versions guidance, which is worth reading in full before implementing.

Three Places to Put It

Method	Best For	Trade-offs
HTML head link elements	Small to mid-sized sites	Simple to inspect; bloats the head on many-language sites
XML sitemap annotations	Large sites, many locales	Keeps HTML clean; harder to spot-check, needs a reliable generator
HTTP headers	Non-HTML files such as PDFs	The only option for files without a head section

Pick one method and use it everywhere. Mixing head tags and sitemap annotations for the same URLs is legal but makes debugging considerably harder, and conflicting values between the two are a common source of errors.

The Four Rules That Prevent Most Errors

1. Annotations Must Be Reciprocal

If page A lists page B as an alternate, page B must list page A. Google discards one-directional annotations entirely. This is the single most common failure, and it usually appears when a new locale is launched and the existing pages are never updated to point at it.

2. Every Page Must Reference Itself

Each page in a cluster includes a self-referencing hreflang tag alongside the alternates. A three-locale cluster therefore has three tags on each of the three pages, not two.

3. Use Absolute URLs

Always the full URL including protocol and domain. Relative paths are not valid here, and a switch to HTTPS with relative hreflang left behind produces a set of annotations pointing at URLs that redirect.

4. Hreflang and Canonical Must Agree

Each page canonicalises to itself, and hreflang points at other pages that also canonicalise to themselves. Pointing the English-Australian page's canonical at the English-US version while also annotating them as alternates gives Google two contradictory instructions, and the annotations lose.

Common Implementation Mistakes

• Invalid codes. en-uk, zh-cn used loosely, or a made-up regional code. Validate against the ISO lists.
• Pointing at redirects or 404s. Every target URL must return a 200.
• Annotating noindexed pages. A page excluded from the index cannot be an alternate.
• Missing x-default. Not mandatory, but without it Google guesses for unmatched users.
• Automatic IP redirects. Forcing users and crawlers to a locale by IP prevents Googlebot, which mostly crawls from the US, from ever seeing your other versions. Suggest, do not force.
• Trailing slash inconsistency. The annotation must match the canonical URL exactly, slash and all.
• Assuming hreflang fixes duplicate content. It manages near-duplicates across locales; it does nothing for duplicates within one locale, which needs the approach in my guide to fixing duplicate content issues.

I have written a longer diagnostic walkthrough on fixing hreflang implementation errors which covers each of these with the specific fix.

Choosing Your International URL Structure

Hreflang sits on top of whatever structure you choose, so make that decision first.

Structure	Example	Strengths	Weaknesses
Country domains	example.de	Strongest geo signal, clear to users	Authority must be built separately for each
Subdirectories	example.com/de/	Shares domain authority, simplest to maintain	Weaker standalone geo signal
Subdomains	de.example.com	Flexible hosting and infrastructure	Authority sharing is less predictable
URL parameters	example.com?loc=de	None worth having	Avoid entirely

For most businesses, subdirectories are the pragmatic choice: one domain to build authority on, one technical setup, and hreflang doing the disambiguation. Country domains make sense when you have genuine local operations, local teams and separate budgets for each market. The wider effects of this decision are covered in my piece on website architecture.

Language Selectors Still Matter

Even with perfect annotations, some users will land on the wrong version — from a shared link, a bookmark, or a market you have not annotated. Give them a visible selector in the header or footer, using plain crawlable links rather than a JavaScript dropdown that produces no anchors. Label options by language name in that language, not by flag: a flag represents a country, and Spanish is not the property of Spain. Those links also give crawlers a straightforward path between locales, which helps discovery on newly launched markets.

Testing and Monitoring

Before Deployment

• Build the cluster map in a spreadsheet first: one row per page, one column per locale, filled with the exact absolute URLs.
• Check every URL returns 200 and canonicalises to itself.
• Verify reciprocity programmatically rather than by eye — a short script over the spreadsheet catches what reading cannot.
• Deploy to one template on staging and crawl it before rolling out site-wide.

After Deployment

• Crawl with Screaming Frog or Sitebulb, which both report missing reciprocal links, invalid codes and non-200 targets directly.
• Watch Search Console by country and by page, checking whether the right URL is being served in each market.
• Search from the target market using a VPN or the country parameter, and confirm which version appears.
• Re-crawl after every locale launch, since adding a market invalidates reciprocity across the entire existing cluster.

Hreflang problems are frequently mistaken for indexing problems, so if pages are missing entirely rather than being served to the wrong market, start with my guide on why a website is not indexing and the wider technical SEO checklist before assuming the annotations are at fault.

What Hreflang Does Not Do

A surprising share of international SEO problems get blamed on hreflang when the cause is elsewhere. Ruling these out first saves days.

It Does Not Build Authority in a New Market

Launching a French version and annotating it correctly gets the page eligible to be shown. Whether it ranks at all depends on the usual things: relevance, content quality, and links from French-language sites. A new locale on a strong domain still needs its own local link acquisition, and treating hreflang as the whole international strategy is why so many market launches produce nothing for a year.

It Does Not Replace Geotargeting Signals

Hosting location, local business listings, a local phone number and address, local currency, and links from sites in the target country all contribute to how Google associates a page with a market. Country code domains carry an implicit signal; subdirectories and subdomains do not, so the other signals matter more when you use them. Check what each property reports in Google Search Console rather than assuming.

It Does Not Fix a Thin Locale

If your Spanish site is forty pages against a competitor's four hundred, correct annotations will not close that gap. Hreflang is plumbing. The content decision — which markets deserve genuine investment and which are better served by one well-localised global page — comes first, and is usually the more valuable conversation.

It Does Not Survive Neglect

Clusters break through ordinary work: a URL is changed, a page is retired, a translation is unpublished, a market is added. Each of those silently invalidates reciprocity across every page that referenced the affected URL. Put a monthly crawl on the calendar and treat hreflang errors as release-blocking, in the same way you would treat a broken canonical or a stray noindex.

Hreflang at Scale

A site with 5,000 pages in eight locales carries 40,000 annotations. At that size, three things become non-negotiable.

• Generate, never hand-write. The tags must come from your CMS locale relationships, so publishing a translation updates the whole cluster automatically.
• Handle partial translation properly. When a page exists in four of eight locales, the cluster contains four entries. Generating tags for pages that do not exist is worse than omitting them.
• Watch page weight. Eight locales in the head is manageable; forty is not, and that is where sitemap annotations become the right answer.

Crawl budget also becomes a factor once locale count multiplies your URL total. My notes on optimising crawl budget apply directly, and it is worth checking how crawling works if large sections of a new locale are slow to appear.

Content, Not Just Tags

Machine-translated pages with correct hreflang still perform badly, because the annotation only decides which weak page gets shown. Localisation means translated copy reviewed by a native speaker, local currency and units, local contact details, and keyword research done in the target language rather than translated from English. The search terms people use in Germany are frequently not the German words for the English terms.

Why Work With Sadekur Rahman

International setups fail quietly, which is why they tend to run broken for a year before anyone investigates. What I do is map the full locale cluster, verify reciprocity and canonical agreement programmatically, fix the URL structure if it is working against you, and put monitoring in place so the next market launch does not silently break the last one.

If you are running or planning a multi-market site, look at my SEO services and case studies, compare plans and pricing, or book a meeting to review your current implementation.

Frequently Asked Questions

Does hreflang improve my rankings?

Not directly. It has no independent ranking weight. What it does is ensure the correct regional or language version of a page is shown to each audience, which improves click-through and engagement, and it reduces the risk of your own locale versions competing against one another.

Do I need hreflang if all my pages are in English?

Only if you have separate pages for different English-speaking markets. If one English page serves everyone, there is nothing to disambiguate. If you run distinct UK, US and Australian pages with different pricing or contact details, hreflang is what stops Google picking one and suppressing the others.

Should I use x-default?

Yes, in almost every case. It nominates the page shown to users whose language or region does not match any of your annotated versions. A global English page or a language selector page are both reasonable choices for it.

How long before hreflang changes take effect?

Google has to recrawl every page in the cluster before the annotations are processed, so expect a few days on a small site and several weeks on a large one. Submitting updated sitemaps helps, and monitoring which URL appears in each target market is the only reliable confirmation.