Building Bilingual Arabic/English Websites That Actually Work

Most failed bilingual sites were not translation failures. The English was good, the Arabic was accurate, and the client still went away unhappy. The problem was that nobody treated Arabic as a different language to design for rather than a different language to translate into.

Arabic is written right to left. That is not a cosmetic difference. It changes where navigation sits, which way arrows point, how grids order themselves, where a price aligns on a receipt, and which side of a card the icon belongs on. We have built multiple bilingual sites and developed a systematic approach to it. This is that approach.

Rule 1: separate content, not conditional strings

The most damaging decision is putting both languages in one file and switching with JavaScript. It feels efficient. It produces three separate failures.

• Search engines see one page. Google may never discover the Arabic version, or may treat it as duplicate content and index only one.
• It depends on JavaScript. A crawler that does not execute it, or a visitor on a slow connection, sees the wrong language.
• Every URL serves every language. You cannot link to a specific page in Arabic, so you cannot put that link in a campaign, a WhatsApp message or a printed brochure.

Give each language its own real URL. /services/ in English, /ar/services/ in Arabic. Now every page is linkable, indexable and shareable in the language it is written in.

Rule 2: let the browser handle direction, then stop fighting it

The modern approach to RTL is not to mirror everything by hand. You set the direction once and then use CSS logical properties so the browser resolves direction for you.

/* Declare the language once */
<html lang="ar" dir="rtl">

/* Then never use left/right again */
.card { padding-inline-start: 24px; margin-inline-end: 16px; }
.layout { display: grid; grid-template-columns: 1fr 2fr; }
.icon-arrow { transform: scaleX(-1); }  /* only for directional icons */

Logical properties such as padding-inline-start, margin-inline-end and border-start-start-radius automatically resolve to the correct physical side in both directions. Your stylesheet becomes direction-agnostic, and the Arabic version mirrors correctly because the browser did it — not because you wrote a second set of rules and hope you found them all.

Resist the urge to write margin-left "temporarily". Every one of those is a bug waiting for an Arabic visitor.

Rule 3: mirror the layout, not just the text

Once direction is set, text aligns correctly and the reading order flows. But grid and flex layouts will still place the first column on the left unless you account for it. In practice you will find a handful of places where a two-column section looks right in English and backwards in Arabic — most often a section with an image beside a paragraph.

Verify each of these visually in the Arabic version rather than assuming. The reliable method is to compare the two versions side by side at desktop width and confirm the Arabic one is a true mirror. If an image that sits left in English sits right in Arabic and the text still reads correctly, you are done.

Be selective about what you mirror. A clock or a chart with labelled axes should not be flipped. A back arrow should. A phone number should not be reordered.

Rule 4: pick fonts that actually have Arabic glyphs

A Latin font silently falls back for every Arabic character, often to a system font with very different metrics. Line heights, weights and letterforms all shift, and the page looks like two different designs joined together.

Load a font with genuine Arabic coverage — and be aware that many excellent Arabic fonts are variable, which means one file covers all weights. Verify in the browser that no fallback is happening: if the rendered Arabic does not match the intended design, you are probably looking at a system font.

Rule 5: hreflang, and making the language switch honest

Each page needs to declare its language relationships, and every language version needs a self-reference:

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

These must be reciprocal — the English page points to the Arabic page and the Arabic page points back. One-directional tags are treated as invalid and ignored.

The language switcher in the header has a job people forget: it must take you to the same page in the other language, not to that language's homepage. A visitor reading Arabic pricing who clicks "English" and lands on the English homepage has been thrown back to the start. Link /ar/services/ to /services/, page for page.

One exception worth knowing: the logo in the header should link to the home page of the current language, not to the site root. Linking to the root from the Arabic page silently switches the visitor's language.

Rule 6: untranslated pages are the hardest problem

Adding a language is easy when you have twelve pages. It gets hard when a client launches, then adds services, then adds posts — and every new page needs translating before release. Miss a few and you have an English page sitting inside an Arabic site, reachable from Arabic navigation.

The discipline that works: the Arabic navigation should only ever link to pages that exist in Arabic. Better a smaller Arabic site that is complete than a larger one dotted with English pages.

A quick pre-launch checklist

• lang and dir set correctly on every page
• Every page has its own URL in both languages
• hreflang tags present, reciprocal, and including x-default
• Zero physical left/right properties left in the stylesheet
• Layout visually verified as a mirror at desktop width
• Language switcher goes page-to-page, not homepage-to-homepage
• Arabic-capable font loading with no fallback
• Every Arabic navigation link resolves to an Arabic page
• Forms, dates, numbers and currency formatting verified in Arabic