Technical SEO for Bilingual Arabic and English Websites in Saudi Arabia
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
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.
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 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.
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.
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
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, so why isn't Google respecting them?
Does this guide replace the need for native Arabic content writing?
Related
Need help putting this into practice?
Our team can handle this for you, end to end.
Explore this service