Hreflang setup: why a multiregional site loses traffic
When a multiregional site serves the same content across several language or country versions, search engines see duplicate pages and do not understand which version to show to a user from a specific region.
Without correct hreflang setup, the signals about language and geographic targeting are lost: the robot picks one page as the main one, the rest go into supplementary results and stop collecting traffic.
Externally, this looks like "the site exists, but there are no rankings" — while the content and link profile are fine.
Then SERP cannibalization kicks in: regional versions compete with each other for the same queries, blur relevance and reduce trust in the domain as a whole.
Geotargeting misses the mark — a user from the desired region is shown a version with the wrong language or currency, bounce rate grows, conversion drops.
This is especially painful on sites with dozens of regions, where manually setting up links between pages no longer scales and easily gets out of sync with every release.
The cost of the mistake accumulates: some pages drop out of the index, some get the wrong region, and fixing it retroactively requires re-crawling and re-evaluating the entire cluster.
The longer a site lives with incorrect links, the longer it takes the search engine to rebuild the trust map for the regional versions.
Below we break down how this is solved: correct reciprocal links between versions, a single source of truth for languages and regions, automatic markup generation at build time, and control that does not break when a new region is added.
What correct hreflang setup delivers and how it is implemented
Correct hreflang setup removes the main problem of a multi-regional site — competition between its own versions in search results.
When the relationship between language and country copies is not defined, the search engine itself chooses the "main" page and shows it to everyone: a user from the desired region lands on the wrong version, and relevant pages lose positions. Explicit reciprocal links return each version to its audience.
Three implementation methods and their effect
Markup in the page code — tags in <head> specifying the language, region, and URL of each version. Works immediately after indexing, is easy to check on a single page.
Limitation: on large catalogs, the markup must be generated by a template, otherwise discrepancies between versions accumulate.
Sitemap — blocks listing all regional URLs in a single file. Convenient for sites with thousands of pages: rules are set centrally, no need to edit the template. Limitation: changes are picked up more slowly, and an error in the sitemap affects the entire section at once.
Server response headers — the relationship between versions is passed at the HTTP level. Suitable for PDFs, images, and pages without HTML markup. Limitation: harder to debug, requires access to the server configuration.
| Option | When it fits | Limitations |
|---|---|---|
| Markup in the code | Medium sites, individual pages | Manual maintenance as the catalog grows |
| Sitemap | Large catalogs, many regions | Update delay, errors scale |
| Server headers | Non-HTML files, API responses | Requires config access, harder to verify |
What we check after implementation
Each version must link to all the others and to itself — the search engine ignores one-way links. Separately, we verify that the language and region code matches the actual page content, and that the canonical URL does not conflict with hreflang.
On a project with dozens of regional versions, such a check reduced the share of pages with incorrect markup from a third to isolated cases, and duplicate versions stopped pushing each other out.
For automatic verification of link reciprocity and code validation, we use Screaming Frog SEO Spider — the report shows broken links before they enter the index.
Implementation stages: from markup audit to handover of settings
Setting up hreflang is working with a graph of relationships between regional versions, and an error in one node breaks the whole scheme: a search engine either merges the versions into one or shows the user the wrong language and region.
That is why we run it as an engineering project — from inventorying the current state to handing over a reproducible configuration, rather than as a "by eye" template edit.
- Markup audit. We collect all regional and language versions, compare the current tags against the actual URL structure, and check canonical addresses and the sitemap. We record conflicts: duplicates, orphaned versions, discrepancies between markup and redirects.
- Designing the relationship scheme. We define the "language × region" matrix, choose the code format (language, language-region, regional code), and decide where to place the tags — in the page markup or in the sitemap. The scheme is agreed upon before edits begin, so that templates don't have to be redone twice.
- Implementing hreflang. We write the relationships on all versions, including the self-reference, and synchronize them with canonical addresses and redirects. For large catalogs we move the markup into the sitemap — it's easier to maintain and update that way.
- Markup validation. We run the graph for symmetry: every pair references each other, there are no broken or extraneous addresses, and the codes are valid. Separately, we check that regional versions do not compete with each other in the search results.
- Post-launch monitoring. We track how search engines reindex the versions and verify that the right page is shown for each region. We handle discrepancies in a targeted way, without rewriting the entire scheme.
- Handover of settings. We provide documentation: the relationship map, rules for adding new regions, and a validation checklist for releases. The client's team can extend the scheme without us.
The order of the stages is no accident: auditing and design are cheaper than edits, and checking the graph for symmetry catches most errors before they make it into the index. Describe your region structure — we'll come back with an estimate and a work plan.
How hreflang differs from the canonical tag and geotargeting
These are three different tools, and confusing them is the most common reason why a website's regional versions compete with themselves in search results.
The canonical tag answers the question "which page is the primary one when content is duplicated" and works within a single language.
The hreflang setup solves a different task: it tells the search engine that a page has versions for other countries or languages, and which one to show to a user from a specific region.
Geotargeting, in turn, is a signal at the level of the entire site or subfolder that says "this section is aimed at such-and-such country," without marking up individual URLs.
The key difference is that canonical collapses several URLs into one, while hreflang preserves them and links them together.
If you set a canonical tag from a regional page to a general one, you are effectively telling the search engine "the regional version does not exist" — and it will drop out of the index.
The reverse mistake — a canonical pointing to itself on every language version without cross hreflang links — leads to the versions being perceived as duplicates, and a random one remains in the search results.
Conflicts between the tags also arise in the details: hreflang with a relative URL instead of an absolute one, links going only one way without reciprocity, a mismatch between the language code and the region, markup on a page that is closed from indexing.
Each such case breaks the whole bundle, because the search engine requires that all versions link to each other consistently.
The correct combination of tools looks like this: geotargeting sets the general direction for a section, hreflang marks up specific regional versions with absolute URLs and reciprocal links, and canonical is used only to eliminate real duplication within a single language version — for example, when the same product is available at several URLs with parameters. These three signals do not replace but complement each other.
In practice, we start with a map of regional versions: which languages, which countries, which URLs correspond to them.
Then we check that each URL returns the correct language and region code, that the hreflang links are reciprocal and absolute, and that canonical does not conflict with the regional markup.
After that, we monitor how search engines crawl the versions and which one is shown to a user from the desired region.
Case study: how markup brought regional versions back into search results
The client is a chain of service centers with site versions for five countries. The content was translated, but the markup had a single shared canonical pointing to the main domain and not a single hreflang.
The search engine saw five nearly identical pages, picked one, and showed it to all regions. Local versions dropped out of search results, and users landed on the wrong language and left.
The audit revealed three causes: a conflict between canonical and the regional URLs, missing reciprocal hreflang links between pairs, and mismatched language codes (en-GB versus en-UK).
On top of that, x-default was not set — the search engine had nowhere to send queries from outside the target regions.
What was changed
We built a "page × region" matrix and generated the hreflang block from a single source — the locale map. Each version received links to all the others, including itself, and a correct x-default. The canonical was rewritten to each locale's own URL instead of the shared one.
The markup was added both to the sitemap and to <head> — this way the search engine sees the relationships even when crawling the sitemap. Language codes were brought to the standard, and duplicate pairs were removed.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Regional versions in search results | 1 of 5 | 5 of 5 |
| Duplicates in the index | 40+ pages | a handful |
| Bounce rate on local versions | high | halved |
| Organic traffic by region | baseline | grew severalfold over the quarter |
The effect holds as long as the locale map is synchronized with the content. We built hreflang validation into the release pipeline — a new locale won't make it to production without valid links.
Google Search Central specifically warns: hreflang does not rank pages, it only helps the search engine choose the right version for a region. That is why we always supplement the markup with local content and a correct URL structure — otherwise the signal won't work.
Doubts before implementation: compatibility, rollback, access
Setting up hreflang does not break existing markup: tags are added to <head> alongside canonical, not instead of it.
If the site already serves a correct canonical and sitemap, we extend them — canonical remains self-referencing for each language version, and xhtml:link with alternate URLs is added to the sitemap. We check compatibility with the current site engine on a copy before making changes in production.
What if a rollback is needed? We make all changes in separate commits with descriptions: <head> markup, server configuration rules, sitemap files. A rollback means reverting to the previous commit or switching to the previous config, without manual edits on the live site. Before deployment, we take a backup of the current templates and configs.
What about access? We need access to the repository or template files, to the server control panel for editing the configuration, and to the webmaster panel for checking indexing.
If there is no access, we work through your engineer and hand over ready-made patches and application instructions.
What if the site is on a CMS without access to templates?
The markup can be served through a module or plugin, or through server-level rules — then no edits to templates are needed. We determine this during the analysis stage and choose the method that does not require rebuilding the CMS core.
After delivery, you receive:
- ready-made hreflang markup for all language and regional versions;
- an updated sitemap with alternate links;
- server configuration rules, if the markup is served at its level;
- a mapping table: language, region, URL, canonical;
- instructions for adding new language versions without us;
- a post-release check checklist: link reciprocity, response codes, indexing;
- a description of the rollback procedure with return points.
Describe your task — we will come back with an estimate and a plan: what access will be needed, what will be included in the first stage, and in what form we will hand over the artifacts.
Hreflang implementation timelines by stage
Hreflang implementation is rarely a one-off template edit: it is a sequence of stages, where each subsequent stage builds on the result of the previous one. Below are approximate timelines for a typical multi-regional project with 3-5 language versions.
If there are more versions or the site is built on several platforms, the timelines stretch proportionally to the scope.
The order of the stages matters: if you start with the markup without understanding the structure, you will have to redo the links after the very first audit. That is why designing the link map comes before implementation, and validation comes before indexing.
What if the site is on a CMS without flexible templates? We add the markup via a module or by editing the output template — this extends the implementation stage, but does not change the overall logic.
What if the language versions already exist? The audit will show which links work and which conflict with canonical — this shortens the design phase, but does not cancel validation.
Describe your site structure and the number of regions — we will get back to you with an estimate and a stage-by-stage plan.
