Hreflang Implementation

How Do You Implement Hreflang So Search Engines Serve the Right Language?

Hreflang tags tell search engines which URL to serve for a given language or region, so an Arabic-speaking visitor lands on the Arabic page and an English-speaking visitor lands on the English page instead of whichever version happened to rank. Correct implementation requires reciprocal tags — every alternate must link back — on every indexable URL, not just some of them.

Dfeelings Team · Digital Marketing Agency, Amman, Jordan
Last updated: September 1, 2026

The problem

Hreflang looks simple on paper but fails silently in practice: a one-directional tag (page A points to page B, but B doesn't point back to A) is invalid and search engines may ignore the whole cluster. On a bilingual site with route-level content, this is easy to introduce on any page type that has its own detail-page routing, like guide or article detail pages, without an explicit check.

Symptoms

  • Arabic-language search traffic lands on English pages, or vice versa, even though a translated equivalent exists.

  • Google Search Console's International Targeting report (or hreflang-specific crawlers) flags "no return tag" errors.

  • The same content appears to compete against its own translated equivalent in search results, instead of each ranking for its own language.

  • A page type (like a guide or article) has hreflang alternates on its listing page but not on the individual item pages.

How we diagnose it

We crawl every indexable URL in both locales and check that each page's hreflang alternates resolve to a real, live URL and that the relationship is reciprocal in both directions. This is exactly how a real regression was found on this site: guide detail pages were emitting hreflang alternates on the listing page but not on individual guide pages — a real shipped bug fixed in commit f96fc9a.

The fix

We centralize URL generation in one function per page type and locale, so that every page — static pages and dynamic detail pages alike — derives its hreflang alternates from the same slug-mapping source of truth, instead of each route building its own URLs by hand and risking drift.

Implementation details

On this site, hreflang alternates are built from a single slug-translation map keyed by canonical page identity; a new page only needs its EN and AR slugs registered there, and both locales' metadata automatically pick up the reciprocal alternate. Guide, case study, and event detail pages get the same treatment so item-level pages are covered, not just their listing pages — the exact gap that commit f96fc9a fixed.

Common mistakes

  • One-directional hreflang: page A references B, but B has no alternate pointing back to A.

  • Hreflang pointing at a URL that 404s or redirects, instead of the live equivalent page.

  • Applying hreflang at the listing-page level only, while leaving individual detail pages without alternates.

  • Missing an x-default entry for URL patterns that aren't cleanly one-language-per-market.

Validation

We check hreflang with Google Search Console's International Targeting report, a manual reciprocity crawl across both locales, and a spot-check that every alternate URL returns a 200 status rather than a redirect or error.

Jordan, Saudi Arabia, and Arabic routing

This site itself is bilingual EN/AR with locale-prefixed routes and, for some market pages (Jordan, Saudi Arabia, GCC), a shared route segment where only the locale prefix differs. Hreflang is what keeps that structure legible to search engines — it's the mechanism that tells Google an Arabic-reading visitor and an English-reading visitor in the same market should see the same commercial page in their own language, not two competing pages.

Related service & solutions

Hreflang works alongside canonical tags and schema markup as part of a bilingual site's technical foundation under our SEO Consulting service.

Frequently asked questions

Common questions about hreflang implementation

No. Hreflang is a targeting signal, not a ranking signal — it affects which URL is shown to which searcher, not how well that URL ranks. Getting it wrong can waste ranking potential by sending traffic to the wrong-language page, but adding it doesn't directly boost rankings.
Yes. Hreflang matters even with just two languages/locales, since without it there's no reliable signal telling search engines the two pages are equivalents rather than duplicate or unrelated content.
A missing reciprocal tag on a page type added after the main site launch — new route types, like item-detail pages, are the most common place a hreflang implementation gets forgotten, which is exactly the bug behind commit f96fc9a on this site.
Hreflang addresses which language version to serve; if the underlying concern is actually near-identical content in both languages, that's a canonical/content issue, not something hreflang alone resolves.

Want your hreflang implementation checked?

Request a hreflang audit