Hreflang without tears and the international SEO basics
Hreflang has a reputation problem. It is one of the most misunderstood pieces of markup in SEO, and audits regularly turn up implementations that are confidently, completely wrong. The frustrating part is that the concept itself is simple. The execution is where everyone bleeds.
This guide walks through what hreflang actually does, the one rule that breaks most setups, and the honest answer to a question almost nobody asks: do you even need it?
What hreflang solves (and what it does not)
Hreflang tells Google which version of a page to show to which audience. That is it. If you have an English page for the US and a nearly identical English page for the UK, hreflang is how you tell Google to serve the .co.uk version to searchers in London instead of the .com version.
What hreflang is not: a ranking boost. Adding hreflang annotations will not make your German pages rank better in Germany. It will not fix a weak site. It is a serving signal, not a ranking signal. It swaps the correct URL into a position your site already earned. If your French pages do not rank in France, hreflang is not your problem.
It also helps with duplicate content across regions. Two English pages targeting different countries look like duplicates to a crawler. Hreflang tells Google they are deliberate alternates, not accidental copies competing with each other.
Reciprocity, the rule that breaks everything
Here is the rule that kills most implementations: hreflang annotations must be reciprocal. If page A points to page B as its Spanish alternate, page B must point back to page A. No return tag, no deal. Google may ignore the annotation entirely.
This is why hreflang fails so often on large sites. Templates get updated on one locale but not another. A page gets removed in Germany but the French version still points at it. One CMS plugin manages the English site, a different one manages the Japanese site, and neither knows the other exists. Each scenario silently breaks the annotation, with no loud error, just quiet non-compliance.
A useful mental model: hreflang is a handshake, not an announcement. Every page in the cluster must list every other page in the cluster, including itself. A self-referencing hreflang tag is not optional decoration, it is part of the spec.
x-default, your fallback for everyone else
The x-default annotation tells Google which page to show users who do not match any of your specified language or region targets. A searcher in Brazil hits your site, you have no Portuguese version, x-default decides where they land.
Point it at your most universal page. Usually that is your global English version or a language-selector page. Do not overthink it, but do not skip it either. Without x-default, Google guesses, and Google guessing is exactly the situation hreflang exists to prevent.
The errors that keep showing up in audits
Almost every broken hreflang setup fails in one of a few predictable ways:
Relative URLs. Hreflang requires absolute URLs, protocol and all. href="/de/page" is invalid. It must be https://example.com/de/page.
Invented region codes. The language must be ISO 639-1 and the region ISO 3166-1 Alpha 2. en-UK is wrong (it is en-GB). en-EU is wrong (the EU is not a country). la for Latin America does not exist as a region.
Language and region reversed. It is language-region, so es-MX, never mx-es.
Missing return tags. The single most common failure, worth repeating.
Pointing at redirects or noindexed pages. Every URL in a hreflang cluster should be a live, indexable, canonical page. If the annotation points at a URL that 301s or carries a noindex, the cluster degrades.
Hreflang conflicting with canonicals. If your UK page canonicalizes to the US page, you have told Google the UK page does not really exist, which contradicts the hreflang annotation on the same page. Pick a story and stick to it.
Sitemap vs head implementation
You can implement hreflang three ways: link elements in the head, HTTP headers (mostly for PDFs and other non-HTML files), or XML sitemaps. In practice the decision is between head tags and sitemaps.
Head tags are easier to spot-check. View source, see the annotations, done. But they add weight to every page, and on a site with 40 locales that is 40+ link elements in every single head.
Sitemap implementation keeps the markup out of your pages and centralizes the cluster logic in one place, which makes it far easier to generate programmatically and to validate. The downside is visibility: nobody looks at sitemaps, so errors hide longer. The general advice: small site with a handful of locales, head tags are fine. Large site with many locales, generate hreflang in your sitemaps from a single source of truth and audit it with Screaming Frog, which validates clusters and flags missing return tags out of the box.
Whatever you choose, pick one method. Mixing head tags and sitemap annotations that disagree with each other is a mess that takes real effort to untangle.
When you do not need hreflang at all
Many sites implementing hreflang do not need it.
One language, one audience. A single English site serving the whole world needs zero hreflang. There are no alternates to point at.
Different languages with fully distinct content. If your German site is genuinely different content (not a translation), Google can generally figure out language targeting on its own from the content and the URL structure. Hreflang still helps, but it is not urgent.
Translated pages with no regional overlap. One English version, one Spanish version, one Japanese version: hreflang is nice to have, and cheap to add, but the wrong-language-serving risk is low because the languages themselves disambiguate.
The setups that truly need hreflang are the ones with same-language regional variants: en-US vs en-GB vs en-AU, or es-ES vs es-MX. That is where Google genuinely cannot tell the versions apart and serves the wrong one, and where UK users keep landing on US pricing pages until the annotations go in.
Keep it boring
Good hreflang is boring hreflang. Absolute URLs, valid codes, full reciprocity, self-references, an x-default, one implementation method, and a quarterly crawl to catch drift. None of it is clever. All of it is maintenance. The sites that get this right treat hreflang as infrastructure, not as a one-time SEO task, because every release that touches URLs can quietly break a cluster. Budget for that, and hreflang stops making you cry.