Hreflang, implemented so it actually works.
Hreflang is the signal that tells Google which language and country each page serves. It is easy to get subtly wrong, and wrong is invisible until it costs you the market you built the page for.
Hreflang is an HTML attribute that tells search engines which language and, optionally, which country a given page is meant for, so the right version is shown to the right searcher. It is a set of reciprocal annotations: every page in a cluster must point at every other version, including itself, using the correct language and region codes, and every one of those pointers must be returned by the page it names. When the return tags, codes or canonicals disagree, Google ignores the lot and picks a page on its own. We implement it against the ways it actually fails, then verify it rather than trust that a generator got it right.
Hreflang, in full.
Hreflang is the small piece of markup that decides which version of a page a searcher in a given country or language actually sees. It is the mechanism underneath every serious multi-market site: the thing that tells Google your German page is for German speakers, your en-GB page is for the UK and your en-US page is for the States, so the right one wins the impression instead of a near-duplicate fighting it for the same query. Get it right and each market reaches its own audience. Get it wrong and Google quietly disregards your intent and serves whichever page it prefers, which is rarely the one you meant.
It matters commercially because the failure is silent. Hreflang does not throw an error when it breaks. A missing return tag, a stray region code, a conflict with the canonical: none of it shows up as a warning on the page, it just leaks qualified demand to the wrong market or splits your own authority across pages that should be distinct. For a business that has already paid to translate, localise and host pages for several countries, broken hreflang means that investment reaches the wrong audience or none at all, and the symptom looks like generically weak international rankings rather than a specific, fixable fault.
We treat hreflang as an implementation discipline, not a plugin you switch on. Most of the damage is done in the detail: the reciprocity that has to be complete, the codes that have to be exact, the canonical that has to agree, and the return tags that have to be returned. We build the full set of annotations for the structure you actually run, whether that is on-page tags, HTTP headers or an XML sitemap, and then we verify it against Search Console and a crawl rather than assume the generator did its job. It is senior work precisely because the errors are subtle and a validator that says pass on the page can still fail in Google's index.
Hreflang, broken down.
Reciprocity and return tags
Every page in a cluster must point at every alternate and at itself, and each of those pages must point back. A single missing return tag makes Google discard the annotation, so we build and check the whole set rather than a partial one.
Explore →Language and region codes
Language uses ISO 639-1, region uses ISO 3166-1 Alpha-2, and the two combine as en-GB or de-AT. The common errors, en-UK, a country where a language was meant, an unsupported code, quietly void the cluster. We get them exact.
Choosing the delivery method
Hreflang can live in the HTML head, in HTTP headers for non-HTML files, or in an XML sitemap. Each suits a different site. We pick the one that fits your platform and scale, because a sitemap is often the maintainable choice for large or templated sites.
Explore →Canonical and hreflang agreement
Hreflang and canonical tags must not contradict each other. A page that canonicalises elsewhere while hreflanging to itself sends Google two conflicting instructions, and it resolves the conflict by ignoring your annotations entirely.
The x-default fallback
The x-default value names the page to serve when no language or region matches, typically a global or language-selector page. Used well it catches the searchers your specific clusters do not, rather than leaving Google to guess.
Validation and ongoing drift
Templates change, pages get added, redirects creep in, and hreflang decays. We validate against Search Console's International Targeting and a recurring crawl so breakage surfaces early instead of after a market has quietly dropped.
Explore →The way we run Hreflang.
Audit the current implementation
We crawl the existing hreflang and pull Search Console's reports to find missing return tags, wrong codes, canonical conflicts and orphaned clusters before we change anything, so the fix targets the real fault.
Map the clusters and codes
We list every market and language variant, decide the exact language and region codes each needs, and settle whether any target a language without a country, so the annotation matches how your markets actually split.
Choose the delivery method
We recommend on-page tags, HTTP headers or an XML sitemap based on your platform, page count and how the site is maintained, then agree it before implementing so the choice is deliberate.
Implement the full annotation set
We build reciprocal, self-referencing tags across every cluster, add an x-default where it earns its place, and make sure the canonical on each page agrees with its hreflang rather than fighting it.
Verify against Google
We validate the live implementation with a crawl and Search Console, because a set that parses cleanly in the source can still be rejected in the index. We do not call it done until Google reads it as intended.
Monitor for drift
New pages, template edits and migrations reintroduce hreflang errors, so we keep it checked on a recurring basis and correct breakage the moment it appears rather than after rankings move.
How we approach Hreflang.
Reciprocal, self-referencing tags
Every page in a language cluster must reference every other version and itself. We build the full set so there are no missing return tags for Google to reject.
Correct language and region codes
ISO 639-1 for language, ISO 3166-1 Alpha-2 for region, and never a made-up code like en-UK where en-GB is meant. Small errors here silently void the whole cluster.
No conflict with canonicals
A page cannot canonicalise to one URL and hreflang to another. We make sure the two signals agree, which is the single most common reason a correct-looking setup does nothing.
Verified, not assumed
We validate the implementation against Search Console reports and crawl data after it ships, because hreflang that looks right in the source can still be broken in Google's eyes.
What Hreflang puts on your desk.
Who implements your hreflang, and how we verify it
Hreflang is where a tiny, invisible error costs a whole market, so it is handled by the senior practitioners rather than passed to a junior with a plugin. Our team of four brings around forty years of combined agency experience, and the person who audits your implementation is the person who rebuilds and verifies it. We work against the specific ways hreflang fails, reciprocity, codes, canonical conflicts, and we confirm the result in Search Console rather than trust that a generator got it right.
Senior hands, first-hand practice
The audit, the implementation and the validation are done by the same senior people. There is no handoff to a junior and no template applied without judgement about your specific market structure.
Built against the failure modes
We know the errors that quietly void hreflang, missing return tags, en-UK for en-GB, a canonical that disagrees, and we implement to avoid them rather than discover them later.
Verified in Google, not just the source
A set that parses cleanly on the page can still be rejected in the index, so we confirm the implementation in Search Console and a crawl before we consider it working.
Hreflang: common questions.
What is hreflang and what does it actually do?
Hreflang is an HTML attribute that tells search engines which language and, optionally, which country a page is intended for. It does not affect ranking directly; its job is to make sure the correct language or regional version is the one shown to a given searcher, so your German page reaches German speakers rather than being outranked by a near-identical English one.
Why does my hreflang look correct but still not work?
Almost always because of a broken return tag, a wrong region code, or a conflict with the canonical. Hreflang is reciprocal: every page must point back at the ones that point to it, and if one link in that chain is missing or contradicts the canonical, Google discards the whole annotation and chooses a page itself. It can parse perfectly in the source and still fail in the index, which is why we validate against Search Console rather than the page alone.
Do I need hreflang if all my pages are in English?
Often yes. If you run separate pages for the UK, US and Australia in English, hreflang with region codes like en-GB, en-US and en-AU tells Google which market each serves and stops them cannibalising one another. Without it, Google may show US visitors your UK pricing or let two of your own pages compete for the same query.
What is the difference between hreflang and a canonical tag?
A canonical names the single preferred version of duplicate or near-duplicate content; hreflang names equally valid alternatives for different audiences. They must agree: each language version should canonicalise to itself and hreflang to its siblings. When a page canonicalises to one URL but hreflangs to another, the signals conflict and Google resolves it by ignoring your hreflang, which is one of the most common reasons a setup does nothing.
Where should hreflang go: the page, the HTTP header or the sitemap?
Any of the three works, and they suit different sites. On-page tags in the head are simplest for small sites; HTTP headers suit non-HTML files like PDFs; an XML sitemap is usually the maintainable choice for large or heavily templated sites because it centralises the annotations. We pick the method that fits your platform and how the site is maintained, and we never mix them for the same pages.
What is x-default and do I need it?
The x-default value tells search engines which page to serve when no listed language or region matches the searcher, typically a global homepage or a language-selector page. It is optional but useful: it catches the audiences your specific clusters do not cover, rather than leaving Google to guess a fallback for them.
How do I check whether my hreflang is actually valid?
You cannot tell reliably from the page source alone. We crawl the site to confirm the annotations are complete and reciprocal, cross-check the language and region codes, verify they do not conflict with canonicals, and read Search Console's International Targeting reporting to see how Google actually interprets them. Validation in the index, not just the markup, is the part most implementations skip.
Can hreflang target a language without a specific country?
Yes. You can specify language alone, such as es for Spanish or fr for French, which suits an audience spread across several countries. You only add a region code when you genuinely run country-specific pages. We match the annotation to how your market actually splits rather than forcing a country onto a language that does not need one.