Technical SEO for Bilingual Arabic-English Websites in Saudi Arabia
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
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.
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.
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.
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.
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.
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
Should our Arabic Article/Product schema use inLanguage, and does it need to differ from the English page's schema?
Is transliterating Arabic URLs into Latin characters bad for SEO?
We already have hreflang tags — why isn't Google respecting them?
Does this guide replace the need for native Arabic content writing?
Need help putting this into practice?
Our team can handle this for you, end to end.
Explore this service