Hreflang and Links: Making International Link Building Count

Hreflang is an annotation that tells search engines which language or regional version of a page to show to which users. It does not pass link value itself, but it decides which of your page versions actually appears in each market’s results. For anyone building international links, that makes it essential to get right before spending on outreach, because a broken hreflang setup can quietly waste a whole batch of otherwise good links.

What hreflang actually does

Each language or country version of a page lists all its alternates, including itself, using language codes and optional country codes. A simplified example for a German page with an Austrian variant and a global default:

Tag	Meaning
hreflang=”de-de”	German language, Germany
hreflang=”de-at”	German language, Austria
hreflang=”x-default”	Fallback shown to users who match no listed language or region

Search engines use these tags to show the Austrian version to users in Austria rather than the German one, and vice versa, provided both pages reference each other correctly.

How hreflang interacts with links

• Pages inside an hreflang cluster are treated as alternates of one another, so authority earned by one version helps the cluster to some degree.
• Local relevance still comes mainly from local links: an Austrian page benefits most from Austrian-read publishers linking to it, not from German ones.
• If hreflang is broken, the wrong version can rank in a given country, and links built to the “correct” version may appear not to work at all, when the real problem is technical.

Common implementation errors

• Missing return tags — every page in a cluster must reference all the others, and each of those must reference it back; a one-way reference is ignored.
• Wrong codes — using “en-UK” instead of the correct “en-GB”, or supplying a country code with no language code at all.
• Hreflang pointing at redirected or non-canonical URLs, which search engines may simply disregard.
• Canonical tags pointing every language version at one page, which directly contradicts what the hreflang tags claim.
• Sitemaps and on-page tags disagreeing with each other after a migration or replatform.

A pre-launch checklist for link builders

1. Confirm the target page version is indexed and its hreflang cluster is valid before building links to it — see technical SEO before links for the wider pre-flight list.
2. Point each market’s links at its own page version, never at a default-language fallback.
3. Use the local brand name and local-language anchors rather than translated anchors reused across markets (anchor text strategy).
4. Re-check the cluster after any site migration, since hreflang breaks silently more often than most other technical elements.

Testing and monitoring

Search engine webmaster tools report hreflang errors directly, and it is worth checking this before and after any major international push, not just once at launch. A cluster that validated a year ago can quietly break after a URL structure change, a new page template, or a migration to a new CMS, so treat hreflang as something to re-verify periodically rather than a one-time setup task. Set a recurring reminder to pull the hreflang report at least quarterly, and always immediately after any replatforming project, since that is when most breakages happen.

Hreflang and canonical tags together

Canonical tags and hreflang tags serve different purposes but are frequently confused during implementation. A canonical tag says “this is the authoritative version of this specific content”; hreflang says “here is the equivalent version for this language or region.” Each market version of a page should canonicalise to itself, not to a single “master” language version, while still cross-referencing its alternates through hreflang. Getting this backwards — canonicalising every version to one language — is one of the more damaging mistakes because it can quietly remove market versions from the index even while hreflang tags look correct on the surface.

What happens when hreflang is simply absent

Sites with no hreflang at all are not necessarily penalised, but search engines are left guessing which version to show based on server location, language of the content and other weaker signals. For a single-language site this rarely matters. For a site with several genuinely distinct market versions, the absence of hreflang means your carefully built local links may end up reinforcing the wrong version of a page, or a version that isn’t indexed at all, which wastes both the outreach effort and the link itself.

Working with developers on this

Hreflang is usually implemented in templates or in the sitemap rather than hand-coded per page, so changes should go through the same review process as any other technical SEO change. Flag hreflang explicitly in any migration or replatforming brief, since it is easy for a development team unfamiliar with international SEO to treat it as optional metadata rather than something that actively determines which page ranks where.

Where this fits in the wider strategy

Hreflang is one piece of a broader plan; for the full picture of structuring and pacing international campaigns, see international link building. If you are building out market-specific publisher lists at the same time, the marketplace‘s language and country filters make it straightforward to match publishers to the exact hreflang version you are trying to strengthen.

Where to go next

Pair a valid hreflang setup with the market guides for German, French and Spanish sites, and revisit organic traffic as a metric before choosing which publishers to link from in each cluster.

Frequently asked questions