Building Bilingual Arabic and English Websites

Most bilingual websites I am asked to fix were built as an English site with Arabic added afterwards. You can usually tell within seconds: the layout mirrors but the spacing does not, the Arabic sits in a font that was never designed for it, and the language switcher throws you back to the homepage instead of the page you were reading.

Arabic is not a translation layer. It changes reading direction, mirrors layout, needs its own typography and doubles the content you have to keep current. Planned during design it is straightforward. Retrofitted onto a finished left-to-right design it is genuinely painful.

I have built projects where this was the central constraint rather than an afterthought — a healthcare company website built in Arabic and English and a bilingual agency site for Saudi clients among them. The lesson from both was the same: decide the bilingual strategy first.

The short answer

Treat Arabic as a first-class version of the site rather than a translation of it. Use CSS logical properties so a single stylesheet mirrors correctly, choose typefaces designed for Arabic, give each language its own URL, translate metadata as well as body content, and keep the two versions genuinely in parity. Machine translation alone is not a bilingual strategy.

Right-to-left layout

Arabic reads right to left, and so does the interface around it. Navigation, logos, icons, form labels, progress indicators, sliders and alignment all mirror.

Do it with logical properties

The technical foundation is CSS logical properties. Writing margin-inline-start instead of margin-left, or padding-inline-end instead of padding-right, means the browser resolves the direction from the document rather than from a hard-coded side.

The payoff is that one stylesheet serves both languages. The alternative — a second stylesheet overriding every directional rule — works initially and then drifts, because every future change has to be made twice and eventually will not be.

What should not mirror

Mirroring is not universal, and over-mirroring looks as wrong as under-mirroring:

• Numbers and dates keep their reading order.
• Media controls — play buttons still point the way playback moves.
• Logos and brand marks stay as designed.
• Photographs are not flipped.
• Code and technical content stays left to right.
• Icons representing physical objects generally stay put; directional arrows generally mirror.

Arabic typography

This is where most bilingual sites visibly fall down, and it is not a small detail — it is the difference between a site that looks designed for Arabic readers and one that looks translated at them.

• Use a typeface designed for Arabic. Latin fonts with bolted-on Arabic glyphs render letterforms and joins badly. Arabic is cursive; letters change shape by position and must connect correctly.
• Increase line height. Arabic has ascenders, descenders and diacritics that need vertical room. Line spacing tuned for Latin text feels cramped.
• Expect different visual weight. At the same nominal size Arabic often reads smaller, so type scales usually need adjusting per language rather than shared.
• Do not fake bold or italic. Arabic has no italic tradition, and synthesised bold distorts letterforms. Use a real weight from the family or find emphasis another way.
• Budget for the extra font files. Two script systems means more font data — relevant to performance, and a reason to be strict about how many weights you load. Keeping a site fast covers font loading in more detail.

Text expansion and layout

Translated text is rarely the same length as the original, which breaks layouts built to fit one language exactly.

Design components to tolerate content of varying length: buttons that grow rather than truncate, navigation that reflows, headings that wrap gracefully. Fixed-height cards sized precisely around English copy are the classic failure — the Arabic version either overflows or gets awkwardly cut.

Test with real translated content rather than placeholder text. Problems that are invisible with dummy copy become obvious the moment genuine content arrives, and by then the design is signed off.

Navigation and language switching

The switcher is small and gets more wrong than almost anything else.

• Stay on the same page. Switching language on a service page should take you to that service page in the other language, not to the homepage. This is the most common and most irritating failure.
• Label each language in its own script — "العربية" and "English" — rather than relying on flags. Flags represent countries, not languages, and Arabic is spoken across many.
• Make it easy to find and consistent in position across both versions.
• Remember the choice for the visit, but do not trap people — an automatic redirect based on browser language with no way back is genuinely frustrating.
• Do not hide it behind a menu on mobile. Someone who lands in the wrong language needs it immediately.

URLs and site structure

Each language version needs its own URL. Serving both from one URL and switching with JavaScript means search engines only ever see one version.

The common approaches are a subdirectory per language, a subdomain, or separate domains. For most businesses a subdirectory is the pragmatic choice — everything stays on one domain, so authority is not split and there is only one property to manage.

Whichever you choose, be consistent, keep the structure parallel so equivalent pages are predictable, and make sure each language version is genuinely reachable through internal links rather than only via the switcher.

hreflang and SEO

Search engines need to be told that two pages are the same content in different languages, otherwise they may treat them as competing or duplicate pages.

That is what hreflang annotations do. The rules that matter:

• Annotations must be reciprocal — if the English page points at the Arabic one, the Arabic page must point back. One-directional annotations are commonly ignored.
• Every version should reference itself as well as its alternates.
• Use correct language codes, and only add a region when you genuinely serve different content for that region.
• Consider an x-default for visitors whose language you do not cover.
• Each version should carry a self-referencing canonical — not a canonical pointing at the other language. Canonicalising Arabic to English tells Google to ignore the Arabic version entirely.

That last point is a genuinely damaging mistake and I see it regularly. The rest of the structural work is the same as any site, covered in the technical SEO checklist.

Translate the metadata too

Body content usually gets translated. Everything around it frequently does not, and it is all visible to users and search engines:

• Page titles and meta descriptions
• Open Graph and Twitter metadata, so shared links render correctly in each language
• Image alt text
• Form labels, placeholders, validation messages and success confirmations
• Button and link text
• Error pages, including the 404
• Email notifications sent by the site
• The lang and dir attributes on the page itself

A visitor who reads the whole page in Arabic and then hits an English validation error has been reminded which version was the real one.

Images and text in graphics

Text baked into an image cannot be translated without producing a second image, and cannot be read by search engines or screen readers in any language.

Keep text as text wherever possible — it translates, scales, and stays accessible. Where a graphic genuinely needs embedded text, produce both versions and swap them with the language. Also check that photographs and illustrations are culturally appropriate for the audience; imagery that works for one market can read oddly in another.

Mobile right-to-left usability

Most traffic in the region is mobile, and right-to-left introduces issues that only appear on small screens: gestures and swipe directions that should mirror, drawer menus that should open from the correct side, horizontal scrolling that starts at the wrong end, and mixed Arabic and Latin text — brand names, phone numbers, email addresses — that can render in a confusing order if the markup does not mark direction properly.

Test on real devices in both languages. A resized desktop browser will not surface these.

Content parity and machine translation

Two versions of a site means twice the content to maintain, and the second version quietly falls behind unless someone owns it. A visitor who finds the Arabic pages are a year out of date has learned something about how seriously that audience is taken.

On machine translation, the honest position: it is a useful drafting tool and a poor publishing strategy. Automatically generated translation published without human review produces text that is often technically correct and tonally wrong, and Google's guidance is clear that using automation to generate content at scale without adding value falls under its scaled content abuse policies.

The workable middle ground is machine translation as a first draft, reviewed and corrected by someone fluent — particularly for marketing copy, where tone carries as much as meaning. If you cannot commit to maintaining a language properly, launching it is not obviously better than not launching it.

A practical checklist

• Bilingual strategy decided before design begins
• Layout built with CSS logical properties, not mirrored overrides
• A typeface genuinely designed for Arabic, with adjusted line height
• Components tolerant of text expansion, tested with real translations
• Language switcher that stays on the equivalent page
• Languages labelled in their own script, not by flag
• Separate URL per language, parallel structure
• Reciprocal hreflang annotations, including self-references
• Self-referencing canonical on each language version
• Metadata, alt text, forms, errors and emails all translated
• Correct lang and dir attributes
• Text kept out of images where possible
• Tested on real mobile devices in both languages
• An owner assigned for keeping both versions current

Which platform handles this best?

Both can do it properly; the work differs.

On WordPress, mature multilingual plugins handle the content model, translation workflow and hreflang generation. The build work is in the theme — ensuring layout genuinely mirrors and typography is handled per language rather than shared.

On a Next.js project, internationalised routing is built in and you control exactly how content is fetched and rendered per locale. More control, more to build, and the same design considerations apply either way.

The technical layer is rarely the hard part. The hard part is deciding early, designing for both languages simultaneously, and committing to maintain both.

Where to go next

If you are planning a bilingual site, the single most valuable thing you can do is settle the language strategy before design starts. Retrofitting right-to-left support into a finished left-to-right design is the expensive path, and it is the one most projects take by default.

You can see the bilingual work in my portfolio, read about the technical SEO side, or get in touch to talk through what your audience actually needs.