Building Arabic Websites: RTL Design and Bilingual SEO That Works

There is a version of an Arabic website that technically exists and that nobody wants to use. The layout is flipped, the strings are translated, the fonts are whatever the browser defaults to, and every sentence reads as though it was written in English first — because it was. Visitors leave, and search engines rank it below competitors who wrote for the language rather than converting into it.

Doing this properly is not much more expensive. It is mostly a matter of making a handful of structural decisions correctly at the start, because each of them is painful to change later.

Decide your URL structure first

This is the decision everything else depends on, and the one most frequently made by accident.

The common shortcut is to serve both languages from a single URL and switch with JavaScript — hiding one language's elements with CSS. It is quick to build and it is the wrong choice for anything you want ranked. One URL cannot carry two canonical languages, hreflang has nothing to point at, a search result cannot land a user on the right version, and nobody can share a link to the Arabic page.

Use separate, crawlable URLs per language. Two structures work well:

• Subdirectories — example.com/ar/page and example.com/en/page. Recommended for most organisations. All authority consolidates on one domain, and it is simple to host.
• Subdomains — ar.example.com. Workable, and reasonable if the two sites are genuinely operated by different teams with different content.

Country-code domains are a heavier commitment that mostly makes sense when you are targeting specific markets with separate legal entities and distinct offerings.

Getting hreflang right

Every page must declare its alternates, including itself, and the declarations must be reciprocal — if the English page points to the Arabic one, the Arabic page must point back. One-directional declarations are ignored.

Two details that catch people out. First, use ar for general Arabic and add a region only where the content genuinely differs by market — ar-SA and ar-AE are only worth separating if the pages differ in substance, not merely in an address in the footer. Second, declare an x-default for users whose language you do not serve.

Direction is a layout property, not a text property

Setting dir="rtl" on the html element is the start, not the solution. What follows is a set of decisions about what should mirror and what should not.

Mirror: reading order, navigation order, text alignment, list markers, table column order, progress and step indicators, and directional icons such as back and forward arrows.

Do not mirror: numbers, clock faces, media playback controls, and any icon representing a physical object whose orientation is fixed. A play button points the same way in every language.

Modern CSS makes most of this nearly free, and it is worth adopting as a default rather than maintaining a separate RTL stylesheet. Use logical properties — margin-inline-start rather than margin-left, padding-inline-end rather than padding-right, inset-inline-start rather than left, and text-align: start rather than left. Written this way, the same stylesheet serves both directions correctly, and new components inherit the behaviour without anyone remembering to think about it.

Bidirectional text

The genuinely hard part is mixed content: Arabic sentences containing Latin product codes, order numbers, prices, URLs or brand names. The Unicode bidirectional algorithm handles most cases, but punctuation at boundaries — parentheses, colons, slashes — lands in visually surprising places.

Isolate embedded foreign-script runs rather than leaving them to the algorithm. Wrap them in an element with dir="ltr", or use unicode-bidi: isolate. This matters most in exactly the places where mistakes are expensive: order references, invoice numbers, IBANs and phone numbers.

Arabic typography deserves its own decisions

Arabic is not Latin text in different glyphs. It is cursive, letters change shape by position, and it has no capital letters — which removes a signalling device Latin typography relies on heavily.

• Choose a real Arabic typeface, not a Latin font with an Arabic fallback bolted on. The mismatch in weight and rhythm between a carefully chosen Latin face and an arbitrary fallback is visible to any Arabic reader, and it reads as carelessness.
• Increase line height. Arabic ascenders and descenders extend further than Latin ones, and diacritics need vertical room. Comfortable Latin line height is cramped in Arabic — expect to add meaningfully to it.
• Size up slightly. Arabic letterforms carry more detail at small sizes. A size that reads cleanly in Latin often needs a small increase in Arabic.
• Do not letter-space Arabic. It is cursive; adding tracking breaks the joins between letters and produces text that looks broken rather than airy. Any global letter-spacing rule in your stylesheet must be disabled for Arabic.
• Be careful with faux bold and italics. Synthesised weights distort Arabic letterforms badly. Use a typeface with real weights, and prefer weight or colour over italics for emphasis.

Translate the intent, not the sentences

The SEO consequence of literal translation is that you rank for phrases nobody searches. Keyword research has to be done independently in each language, because the way people search differs in more than vocabulary.

Specifically: Arabic searchers frequently use different terms than the direct translation of the English keyword, often mixing in the English technical term itself. Search volumes distribute differently across MSA and dialect phrasing. And a topic that has high commercial intent in English may be researched informally in Arabic, which changes what content should rank for it.

Practical implications:

• Write titles and meta descriptions natively in each language. A translated title is optimised for the wrong phrase and usually the wrong length.
• Do not force a URL slug to be a transliteration of the English one. Either use a meaningful Arabic slug or a clean transliterated one — but choose it for the Arabic keyword, not for symmetry with English.
• Accept that the two language versions may not be a one-to-one match. Some topics deserve depth in Arabic that they do not warrant in English, and vice versa. Forcing perfect parity produces thin pages in one language.

Technical points that are easy to miss

• Language attributes on the element, per page. lang and dir set correctly and statically in the served HTML, not applied by JavaScript after load.
• A sitemap declaring alternates. Include hreflang annotations in your XML sitemap alongside the on-page tags.
• Structured data in the page's own language, with inLanguage set. Do not emit English schema on an Arabic page.
• Localised open graph tags, including og:locale and its alternates, so shared links preview correctly.
• Font loading. Arabic webfonts are often larger than Latin ones. Subset them, and use font-display: swap so text is readable while they load.
• Forms and inputs. Phone numbers, IBANs and email addresses should be left-to-right input fields even on an RTL page. Placeholder and validation messages need translating too — these are the strings that are always forgotten.
• Do not auto-redirect by browser language. Detect and offer, but let the user choose and remember the choice. Forced redirection prevents crawlers from seeing both versions and irritates bilingual users, who are most of your audience in the Gulf.

The test that matters

Have a native Arabic speaker who has never seen the English site use the Arabic one. Not review it — use it, to complete a real task. Every awkward phrase, every place where the layout fights the reading direction, and every English string that survived will surface in ten minutes. It is the cheapest quality check available, and remarkably few teams run it.