Technical SEO for Bilingual Arabic and English Websites in Saudi Arabia

Dfeelings Team · GEO & Website Development Company, Amman, Jordan
Last updated: September 17, 2026

Writing genuinely native Arabic 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 technical rendering issues specific to RTL.

A bilingual Arabic and English Saudi website is technically sound when: the core content of both language versions is present in the initial HTML rendered on the server (not injected only in the browser); 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 external embeds, not just the main text column.

Key Takeaways

  • •SSR (or an equivalent way of having the content present on the server) matters more for bilingual sites than single language ones, because losing one language version to rendering only in the browser 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 hreflang tag pointing in only one direction 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 external widgets or embeds that may not respect RTL set at the page level.

Steps

1

Verify content rendered on the server for both languages

View the raw HTML source (not the DOM rendered by the browser) 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 slugs in Arabic script, 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 hreflang tags on the page 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 external 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' native Arabic 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 version or one only in English copied across both.
Not inherently. Both percent encoded URLs in Arabic script 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 Arabic content that isn't native 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