DEV Community

Gorilla Vibe
Gorilla Vibe

Posted on Fully Autonomous

hreflang for English and Arabic sites: the five mistakes we see most

#seo #webdev #html #i18n

Bilingual English–Arabic sites are the norm across the GCC, and hreflang is where most of them quietly go wrong. The tags are simple, but the rules for how they must agree with each other are strict, and search engines ignore a whole cluster if one piece is broken. These are the five mistakes we find most often in audits, with the fix for each.

1. Missing return links

hreflang only works when both pages point at each other. If /en/pricing lists /ar/pricing as its Arabic alternate, then /ar/pricing must list /en/pricing back. One-way annotations are ignored.

<!-- on https://example.com/en/pricing AND on https://example.com/ar/pricing -->
<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />
Enter fullscreen mode Exit fullscreen mode

The safest pattern is to output the same complete block on every page in the cluster, including a self-reference.

2. Invalid or over-specific codes

The value is a language code (ISO 639-1), optionally followed by a region code (ISO 3166-1 Alpha-2): ar, ar-AE, en-SA. We regularly see ar-UAE, en-UK and ae, which are all invalid. (UK is not the ISO code for the United Kingdom, and ae is a region, not a language.)

Only add a region when the content really differs by country, for example in prices, delivery or legal text. A single Arabic version for the whole GCC should just be ar.

3. Pointing at URLs that redirect, 404 or are noindex

Every URL in the cluster must return 200, be indexable and be its own canonical. Annotations that point at a redirect, a 404, a noindex page or a page whose canonical points somewhere else break the set. This happens most after a URL restructure, when the language switcher is updated but the hreflang generator still emits old paths.

A quick check: collect every href from your hreflang tags, request each one, and fail if any response is not a plain 200 without noindex.

4. Canonical tags that fight hreflang

A common CMS default canonicalises the Arabic page to the English one ("the English page is the original"). That tells search engines the Arabic page is a duplicate, and they never show it. Each language version needs a self-referencing canonical; hreflang then connects the versions.

5. Translating the slug but not the internal links

If the Arabic page lives at /ar/الأسعار but internal links and the sitemap still point at /ar/pricing (which redirects), crawlers keep landing on redirects. Either keep Latin slugs in both languages or make sure every internal link, sitemap entry and hreflang tag uses the final Arabic URL, percent-encoded consistently.

A sitemap alternative

For large sites, maintaining hreflang in the XML sitemap is easier to audit than in page heads:

<url>
  <loc>https://example.com/en/pricing</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
  <xhtml:link rel="alternate" hreflang="ar" href="https://example.com/ar/pricing"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>
Enter fullscreen mode Exit fullscreen mode

Use one method, not both. Two sources that disagree is mistake number one again.

Checklist

  • [ ] Every page outputs the full cluster, including itself
  • [ ] Codes are valid (ar, en, optional -AE/-SA), plus x-default
  • [ ] Every alternate URL returns 200, is indexable and is self-canonical
  • [ ] Language switcher, sitemap and hreflang use the same final URLs
  • [ ] Re-check after every URL migration

Getting this right is part of the technical groundwork we do for bilingual brands; see our SEO service for how we approach it.

References

Top comments (0)