Web Design · 13 min read

Bilingual Arabic/English Website Design: 18 Decisions That Matter

A bilingual Arabic/English website looks deceptively simple — just translate the content, right? In practice, decisions ranging from URL structure to typography to form direction compound into either an experience that feels native to Saudi users or one that obviously was English-built and Arabic-bolted-on. This is the decision-by-decision guide based on what actually moves engagement and SEO performance for Saudi audiences.

By RankRush Team ·

Why "just translate" doesn't work

The biggest mistake we see on Saudi-targeted bilingual sites is treating Arabic as a translation layer on top of English design decisions made for English audiences. The result: sites that technically have Arabic content but feel foreign to Arabic-first users.

The structural issues with translation-only approaches:

01
Reading direction affects design composition
Arabic reads right-to-left. Hero compositions, button placements, navigation orders, and visual hierarchy assumptions all need to flip. Just translating text inside an English layout leaves the visual flow backwards for Arabic readers.
02
Arabic typography needs different fonts and sizing
Latin fonts that look elegant in English ("Inter", "Helvetica", "Roboto") often render Arabic poorly. Arabic-optimized fonts ("Cairo", "Tajawal", "IBM Plex Arabic") render Arabic beautifully but render Latin characters acceptably-but-not-great. The choice of font affects perceived quality dramatically.
03
Word and sentence lengths differ
Arabic sentences are typically 30-40% shorter than English equivalents. A button labeled "Get Started Now" might be a single Arabic word; a 60-character English headline might be a 35-character Arabic headline. Layouts built for English text often look loose and awkward when filled with shorter Arabic text.
04
Content priorities differ
Saudi audiences often want different information emphasized vs English audiences. Trust signals, family/social proof, religious considerations (where relevant), Saudi-specific compliance — these may need more prominence in Arabic content than translation from English would suggest.
05
Cultural references and idioms don't translate
English idioms ("game-changer", "no-brainer", "low-hanging fruit") translated literally into Arabic read as nonsensical. Arabic content needs to be written natively in Arabic, not translated from English source material.

The shorthand: Arabic content needs to be designed and written for Arabic readers, not adapted from English material for Arabic readers. The economic implication: bilingual sites cost more than translated sites because they need separate design and content effort for each language, not a translation pass.

Decision 1 — URL strategy

The single highest-impact decision is how you structure URLs for the two languages. Three options:

Bilingual URL Strategy Options

StrategyExampleProsCons
Subdomainar.example.com / en.example.com"Clean separationindependent SEO""Splits domain authoritymore setup"
Subfolderexample.com/ar/ / example.com/en/"Single domain authorityeasier hreflang""Default language must be chosen"
Single URL with queryexample.com?lang=ar"Simple setup""Bad for SEOsearch engines see one page"
No URL difference (cookie-based)example.com (content varies)"Simplest""Terrible for SEOcan't link to specific language"

The strong recommendation for Saudi-targeted bilingual sites is subfolder (example.com/ar/ and example.com/en/). It consolidates domain authority, has clean hreflang implementation, and is well-supported by all SEO tools and frameworks.

The decision that follows from URL strategy: which language is the default? For Saudi-targeted bilingual sites, Arabic should typically be the default — meaning example.com/ shows Arabic content, and English is at example.com/en/. This signals "Saudi-first" to both search engines and users.

The reverse default (English at root, Arabic at /ar/) is common but suboptimal — it suggests English is primary and Arabic is secondary, which is opposite to how most Saudi users read your site.

Decisions 2-5 — Language switcher and detection

How users switch between languages, and what defaults users see on first visit:

01
Decision 2 — Switcher placement
The language switcher should be in the top-right of the page (for English layouts) or top-left (for Arabic layouts). Avoid burying it in the footer or behind a menu — Saudi users who want to switch will look for it immediately and abandon if they can't find it. The switcher should show the other language, not the current one: when on Arabic content, the switcher button should say "English"; when on English content, it should say "العربية".
02
Decision 3 — Switcher labeling
Use the language's own name in its own script. Arabic users recognize "العربية" instantly; "Arabic" in English text registers slower. Same logic for "English" appearing in English. Don't use country flags — Saudi users speak Arabic, but so do Egyptians, Lebanese, etc. Country flags imply nationality not language.
03
Decision 4 — Default language detection
First-time visitors should see content in the language that matches their browser/IP signal. Saudi IPs and Arabic browser language defaults should get Arabic content. International IPs and English browser defaults should get English content. Users who manually switch should have their preference remembered via cookie.
04
Decision 5 — Remember language choice
Once a user picks a language, that choice should persist via cookie for at least 30 days. Forcing repeated language selection on every visit is annoying. Some sites get this wrong and re-detect language on every page load — never do this.

Decisions 6-9 — RTL implementation

Making the site genuinely right-to-left for Arabic content, not just rendering Arabic text in a left-to-right layout.

01
Decision 6 — `dir="rtl"` attribute on Arabic pages
The HTML attribute `dir="rtl"` on the body or html element tells the browser to flip layout direction. Every Arabic page needs this. Browsers will then automatically handle text alignment, list bullet positioning, table column order, and many other directional defaults.
02
Decision 7 — CSS logical properties
Modern CSS supports "logical properties" that adapt to direction: `margin-inline-start` instead of `margin-left`, `padding-inline-end` instead of `padding-right`. Using these instead of physical properties means your CSS works for both directions without duplicate stylesheets. This is the modern approach; the old approach of duplicate `.ltr` and `.rtl` stylesheets is no longer necessary.
03
Decision 8 — Icon flipping
Some icons need to flip for RTL contexts (arrows pointing direction, "next" / "previous" controls), others must not flip (logos, brand marks, content icons like trash cans or settings gears). Audit your icon set and explicitly flip the directional ones, leave the others alone. The common mistake is flipping all icons (looks weird) or flipping no icons (arrows point the wrong way).
04
Decision 9 — Number and currency display
Arabic content sometimes uses Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) and sometimes Latin numerals (0123456789). Saudi convention in modern digital contexts is Latin numerals — both Arabic and English content typically uses Latin numerals for prices, dates, quantities. Setting CSS `direction: ltr` on number-containing elements within RTL content ensures Latin numerals render in the expected order.

Decisions 10-12 — Typography

Font choice is one of the most under-considered bilingual decisions, and one of the most visible.

01
Decision 10 — Font pairing strategy
Use a font that handles both Arabic and Latin well, OR use language-specific fonts that work together visually. Common high-quality options:

The decision matters because mismatched fonts look amateurish even if individual fonts are nice. Test your bilingual content with the actual fonts before committing.

01
Decision 11 — Arabic font sizing
Arabic characters render visually larger at the same point size as Latin equivalents, AND Arabic readers prefer slightly larger text for readability. Convention: Arabic body text 16-18px (vs 15-16px for English), Arabic headlines 1.0-1.1x larger than English equivalents. Don't use the same font sizes for both languages — they don't read equivalently.
02
Decision 12 — Line height adjustments
Arabic text needs more line height than Latin text because of the descenders and connecting letters. CSS `line-height: 1.5` works for English; Arabic typically needs `line-height: 1.7-1.9`. Apply language-specific line-height in CSS for proper readability.

Decisions 13-15 — Forms and inputs

Forms are where bilingual sites most commonly break for Arabic users.

01
Decision 13 — Form input direction
Text input fields should accept both Arabic and Latin input, with the cursor and text direction adjusting automatically. Use `dir="auto"` on input fields rather than forcing a direction. This lets the browser detect what the user is typing and align accordingly. Critical for fields like "Name" where Saudi users might type in either language.
02
Decision 14 — Label-to-field positioning
In RTL layouts, labels go to the right of the input, and inputs themselves should be right-aligned by default. Required-field asterisks should be on the right side. Validation messages should appear in the appropriate direction.
03
Decision 15 — Phone number handling
Saudi phone numbers (+966 5xx xxx xxxx) should display with the country code on the left even in RTL layouts (since phone numbers are inherently LTR). Use `dir="ltr"` on phone input fields explicitly. This matters for both display and validation.

Decisions 16-18 — Content and SEO

The content-level decisions that determine whether your bilingual site is SEO-effective.

01
Decision 16 — Content parity vs language-specific content
Two approaches:

The strict parity approach is operationally simpler and SEO-cleaner. The language-specific approach is more authentic but creates SEO complexity (no hreflang for pages without translations).

For most Saudi-targeted bilingual sites, the right answer is near-parity with strategic differences: core pages (homepage, services, contact, products) in both languages with proper hreflang; certain content (Saudi-specific local content, English-specific international content) language-only with no hreflang on those pages.

01
Decision 17 — Hreflang implementation
Every page that exists in both languages needs hreflang tags pointing each version at the other:

```html <link rel="alternate" hreflang="ar-SA" href="https://example.com/ar/page/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/page/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" /> ```

The `x-default` should point to the version that should appear for users not matching either language (typically the English/international version).

01
Decision 18 — Translation quality
Use native Arabic speakers for Arabic content, not translation services. Saudi Arabic also has dialect considerations — Modern Standard Arabic (MSA) for formal/written contexts, with light Saudi dialect for marketing/conversational contexts. Google Translate output is recognizable to Saudi readers as machine-translated and erodes trust. Budget for proper Arabic content from native writers; the quality difference is visible and the SEO impact is measurable.

Common bilingual implementation failures

Patterns we see frequently when auditing bilingual sites:

01
English-default with poor Arabic implementation
The site loads in English by default for Saudi users, the language switcher is hidden, and the Arabic version is a basic translation in a left-to-right layout. This is the worst-case implementation but unfortunately common.
02
Arabic-default with no English fallback
The opposite extreme — Saudi-targeted sites that don't bother with English at all, missing both international visitors and Saudi users who prefer English (younger educated demographics often do).
03
Mixed directionality
Pages where some elements flow RTL and others flow LTR within Arabic content, creating visual chaos. Usually caused by incomplete CSS setup and components that don't support RTL properly.
04
Translated buttons but English imagery
Hero images with English text overlaid, screenshots showing English UI, marketing graphics in English. The text gets translated but visual content stays in English, undermining the bilingual experience.
05
Inconsistent language switching
Switching from Arabic to English works on the homepage but returns to default on subpages, or vice versa. Users expect switching to be sticky — switching to English on the homepage should still show English when navigating to other pages.
06
Hreflang errors
Hreflang tags pointing at wrong URLs, missing return-link references, wrong language codes (using `ar` instead of `ar-SA`, using `en-US` instead of generic `en`). Google reports these in Search Console — check regularly.
07
Mobile menu broken for RTL
Hamburger menus, dropdowns, and modal interactions sometimes work in LTR but break in RTL because the JavaScript or CSS wasn't tested in RTL mode. Test every interactive component in RTL mode explicitly.

Testing checklist for bilingual sites

Before launching, verify these items work correctly in both Arabic and English:

For bilingual website builds or audits of existing bilingual implementations, our [web design services](/services/web-design/) include full Arabic/English setup and our [Arabic SEO](/services/seo/arabic-seo/) work covers the SEO side of bilingual implementations specifically.

Related reading

More articles you may find useful

→

Core Web Vitals for Saudi Networks: The Mobile Reality

More from our Web Design writing.

Read article →
→

Landing Page Optimization for Saudi Campaigns: Patterns That Convert

More from our Web Design writing.

Read article →
→

Why Saudi Websites Lose Customers in 5 Seconds (and How to Fix It)

More from our Web Design writing.

Read article →

Want to talk through your project?

Free 30-minute strategy session — no commitment.

Message us on WhatsApp
FAQs

Common questions about Bilingual Arabic/English Website Design: 18 Decisions

Should I launch the English version first and add Arabic later, or build both simultaneously?

For Saudi-targeted sites, build both simultaneously. Retrofitting Arabic onto an English-only site means redoing layout, design, and components for RTL — typically more expensive than building bilingual from the start. The only case for English-first is if you're an international company entering Saudi as a secondary market; even then, plan the Arabic addition within 6-12 months because Saudi-only-English sites consistently underperform.

What about other languages — should I add Urdu, Hindi, Tagalog for migrant workers?

Depends entirely on your target audience. If you serve Saudi nationals and high-income expats, Arabic + English covers ~95% of your traffic. If you serve migrant worker populations (remittance services, mobile top-ups, certain retail categories), adding Urdu, Hindi, Tagalog, or Bengali can be valuable. The same architectural decisions apply but multiply by the languages — adding each language adds significant content and maintenance overhead.

How does mobile bilingual UX differ from desktop?

Mobile-specific considerations: language switcher needs to be accessible without unfolding a menu (Saudi users won't dig for it), tap targets need to be slightly larger for Arabic text rendering, vertical content flow matters more than horizontal (RTL/LTR matters less when content is stacked vertically anyway), and form keyboards need to handle bilingual input. Saudi mobile traffic is overwhelmingly the majority for most sites, so mobile UX is the primary focus, not desktop.

What's the SEO impact of getting bilingual wrong vs right?

Substantial. A proper bilingual setup with subfolder URLs, hreflang, and native Arabic content typically captures 2-3x the Arabic search traffic of an English-only site, and 50-100% more total traffic than a poorly-implemented bilingual site. Bilingual SEO done right also helps for AI search (Perplexity, ChatGPT search) where queries can be in either language. Bilingual done wrong (hreflang errors, mixed content, machine translation) can actually harm SEO via duplicate content issues and quality signals.

How much does proper bilingual implementation typically cost?

For a new build, the bilingual implementation adds roughly 30-50% to the cost of an English-only build. Most of this is content (Arabic content production by native writers), some is design (RTL component design), some is engineering (RTL CSS, hreflang, language switching). For an existing English-only site getting Arabic added, the cost is typically higher (60-100% of original build cost) because of retrofit work. Across all our bilingual builds, costs range roughly 40-120K SAR for small/medium sites, 200K+ SAR for large or complex sites. The investment typically pays back within 6-12 months in additional Arabic traffic + conversion.

Message us on WhatsApp Get Quote