Technical SEO for Bilingual Arabic-English Websites in Saudi Arabia

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

Writing genuinely Arabic-native content is one decision, covered elsewhere. Getting the underlying architecture right so that Arabic and English pages both get crawled, indexed, and attributed to the right audience is a separate, purely technical job — and it's where a lot of otherwise well-written bilingual Saudi sites quietly lose visibility. This guide covers the build layer: server-side rendering, hreflang, canonicals, Arabic URL/slug handling, sitemaps, and RTL-specific technical rendering issues.

A bilingual Arabic-English Saudi website is technically sound when: the core content of both language versions is present in the initial server-rendered HTML (not injected client-side only); each page has a self-referencing canonical and reciprocal hreflang tags to its counterpart plus an x-default; Arabic URLs/slugs are either properly encoded or transliterated consistently (never inconsistently mixed); the sitemap lists both language versions as distinct, indexable entries; and RTL rendering is verified across the whole page — including structured data, mixed-direction strings, and third-party embeds — not just the main text column.

Key Takeaways

  • SSR (or equivalent server-side content presence) matters more for bilingual sites than single-language ones, because losing one language version to client-side-only rendering effectively halves your indexable content.
  • Self-referencing canonicals on every page, in both languages, prevent a common failure mode where the Arabic page accidentally canonicals to English (or vice versa) and disappears from independent ranking.
  • hreflang must be reciprocal — Arabic pointing to English and English pointing back to Arabic, plus one page designated x-default — a one-directional hreflang tag is functionally broken.
  • Arabic URL/slug handling has two valid approaches (percent-encoded Arabic script, or consistent Latin transliteration) — the failure mode is mixing both inconsistently across the same site.
  • Sitemaps should list each language version as its own <url> entry with its own <xhtml:link> alternates, not merge them into one ambiguous entry per piece of content.
  • RTL technical issues extend beyond text direction — check structured data (JSON-LD) rendering with Arabic strings, mixed Arabic/number/Latin-script text, and any third-party widgets or embeds that may not respect page-level RTL.

Steps

1

Verify server-rendered content for both languages

View the raw HTML source (not the browser-rendered DOM) of both the Arabic and English version of a page and confirm the actual page text — not just a loading shell — is present before JavaScript executes.

2

Audit canonical tags page by page, per language

Check that every Arabic page's canonical points to itself (its own Arabic URL), and every English page's canonical points to itself — neither should point to the other language's URL, even when the content is a direct counterpart.

3

Confirm hreflang is reciprocal and complete

For each page pair, verify the Arabic version has hreflang tags for both ar and en (pointing to the English counterpart) plus x-default, and the English version has the mirrored set — a hreflang tag only on one side of the pair doesn't work.

4

Standardize Arabic URL/slug handling

Pick one approach — percent-encoded Arabic-script slugs or consistent Latin transliteration — and audit existing URLs for consistency. Fix any pages using a different scheme than the rest of the site, using redirects rather than silently changing live URLs.

5

Check sitemap structure for language pairs

Confirm the sitemap (or sitemaps, if split by language) lists Arabic and English URLs as separate entries with correct <xhtml:link rel="alternate" hreflang=...> references between them, matching the in-page hreflang tags exactly.

6

Test RTL rendering beyond the main text block

Load Arabic pages and specifically check structured data output, breadcrumb direction, mixed-direction strings (Arabic sentences containing numbers, English brand names, or email addresses), and any embedded third-party widgets for correct RTL behavior.

Which option fits you?

If your Arabic content already reads as natively written and researched but organic performance still lags the English version, the issue is very likely architectural — start with the canonical and hreflang audit above before revisiting the content itself. If, on the other hand, the Arabic content is a direct translation of the English draft, that's a content-strategy problem covered in Dfeelings' Arabic-native SEO guide, and fixing the architecture alone won't solve it.

Frequently Asked Questions

Yes — set inLanguage to 'ar' on the Arabic page's structured data and 'en' on the English page's, and make sure each page's schema references its own URL and its own headline/description text, not a shared or English-only version copied across both.
Not inherently — both percent-encoded Arabic-script URLs and consistent Latin transliteration are workable approaches used by real sites. The actual risk is inconsistency: mixing both schemes across the same site confuses canonicalization and makes URL patterns harder to maintain.
The most common causes are: the tags aren't reciprocal (only one language points to the other), the referenced URL returns a redirect or error instead of the actual page, or the hreflang value doesn't match the canonical URL exactly (including protocol/trailing slash). Check all three before assuming hreflang itself is the problem.
No — this guide covers architecture (how the pages are built and served), not content quality or keyword research in Arabic. A technically perfect bilingual site built on translated, non-native Arabic content will still underperform on the content side; the two issues are separate and both need addressing.

Need help putting this into practice?

Our team can handle this for you, end to end.

Explore this service