Building a bilingual Arabic and English website that works

A bilingual site works when you treat Arabic as a second edition of the site, not a translation layer added at the end. That means separate URLs for each language, a layout that mirrors itself for right-to-left reading, an Arabic typeface chosen on purpose, copy written for Arabic readers, and search tags added only once the Arabic is ready. We built almahira.me this way, in Next.js with English at / and Arabic at /ar, and the examples below come from that build.

Give each language its own URLs

Google recommends a separate URL for each language version, rather than switching language with cookies or browser settings. It also advises against redirecting visitors automatically based on their presumed language, because that can stop people and search engines from seeing every version.

Google does not recommend URL parameters such as ?lang=ar. For most UAE businesses a subdirectory is the simplest choice: one domain, one host, one codebase.

On our site, English pages have no prefix and Arabic pages live under /ar, so /about becomes /ar/about. We use next-intl with its "as-needed" prefix setting and locale detection switched off, so nobody is redirected because of their browser language. The language switcher links to the same page in the other language. Where a page exists only in English, such as this blog, its Arabic link goes to the Arabic home page instead of a missing page.

Keep slugs in Latin script under /ar unless you have a strong reason not to. Arabic slugs work, but they often turn into long percent-encoded strings when people copy and paste them.

Set the direction once, then write logical CSS

Put lang="ar" and dir="rtl" on the html element of every Arabic page. The W3C recommends declaring direction in markup rather than in CSS, so the text still displays correctly if your styles fail to load. Once dir is set, text alignment and the order of items in flex and grid layouts follow the reading direction.

The rest depends on how your CSS is written. Physical properties such as margin-left, padding-right or left: 0 stay physical and break the mirror. Logical properties, such as margin-inline-start, padding-inline-end, inset-inline-start and text-align: start, follow the reading direction. In Tailwind CSS these are the ms-, me-, ps-, pe-, start- and end- utilities, and the rtl: variant handles exceptions.

Logical properties don't cover everything. These exceptions came up in our build:

• Directional icons. Arrows and chevrons that mean "next" or "back" are flipped with a horizontal scale (rtl:-scale-x-100 in Tailwind). Logos, checkmarks, clocks and photos are left as they are.
• Background images. The arrow on a styled select box is a background image positioned on the right, so it needs an Arabic override.
• Transforms. A mobile menu that slides in from the right edge has to slide in from the left in Arabic.
• Gradients and masks. A decorative fade placed 12% from the left needs a mirrored position.

Before launch, search the codebase for left, right, ml-, mr-, pl- and pr-. Every result is either a deliberate exception or a bug.

Choose an Arabic typeface on purpose

Many Latin typefaces have no Arabic letters at all, and the browser then falls back to whatever Arabic font the device has, which rarely matches your design. Our Latin face, Inter Tight, has none, so the Arabic site uses IBM Plex Sans Arabic, a plain, modern sans-serif that sits well beside it. Noto Sans Arabic is another widely used open-source option. Load the Arabic font only on Arabic pages: ours is excluded from preloading, so English visitors never download it.

Then adjust the typography, not just the font file:

• Remove letter-spacing. Arabic letters join, and the W3C's Arabic layout requirements note that moving joined letters apart gives undesirable results. The negative tracking that tightens Latin headings has to be reset to zero.
• Add line height. Arabic needs room for tall letters, deep descenders and marks above and below the line. We increased line height at every heading level on the Arabic site.
• Replace capitals. Arabic has no upper case, so labels styled in capitals lose their emphasis. Apple's design guidelines suggest setting Arabic slightly larger where it sits next to Latin capitals.
• Check the weights. We use regular, medium and semibold, with Arabic headings in semibold.

If your logo has a custom Latin wordmark, design the Arabic one as its partner rather than as a translation. Our brand design team treats both scripts as one identity, and if the Arabic name will appear on signage or packaging, consider registering it as a trademark too.

Translate, then localise, then review

Translation turns English sentences into Arabic ones. Localisation makes the page work for an Arabic reader: the right terms for government services, natural calls to action and examples that make sense locally. Write in Modern Standard Arabic, the formal written Arabic used on official UAE sites such as u.ae, unless your brand deliberately speaks in dialect.

Machine translation is fine for a first draft. Publishing it unreviewed across a whole site is a risk: Google's spam policies count generating many pages through automated means, translation among them, without adding value for users as scaled content abuse. Our SEO content strategy guide explains how to plan Arabic pages that earn their place.

Keep each page in one language. Google works out a page's language from its visible content and recommends one language per page, warning that translating only the navigation while the main content stays in another language makes a poor experience. On our site, Arabic content overlays the English source and falls back to English wherever a translation is missing. That is convenient during a build, but it produces mixed pages, which is one reason our Arabic pages stay out of the index until they are complete and reviewed.

Have a native Arabic speaker review everything, including buttons, error messages, form labels, emails and text inside images. Short strings are where machine translation fails most visibly, and they are the ones nobody remembers to send for review.

Forms, numbers and mixed text

• Phone numbers and emails run left to right. Give phone, email and URL fields dir="ltr", so a number like +971 5X XXX XXXX doesn't scramble. We do the same for phone numbers shown in text.
• Free-text fields get dir="auto", which the W3C recommends for user input, so an Arabic name and an English company name both display correctly.
• Decide your digits. Arabic is written with Western digits (0 to 9) in some countries and Arabic-Indic digits (٠ to ٩) in others. UAE government sites such as u.ae use Western digits on their Arabic pages, and so do we: numbers are formatted with the ar-AE-u-nu-latn locale in JavaScript's Intl.NumberFormat.
• Never mirror the numbers themselves. Prices, dates and phone numbers read left to right inside Arabic text; only their position in the sentence changes.
• Test mixed strings. A sentence combining Arabic, a brand name in Latin letters and a price can reorder in surprising ways. The W3C recommends isolating inserted text, with the bdi element or dir="auto", when you drop variables into Arabic sentences.
• Translate the edges. Validation messages, thank-you pages, confirmation emails, PDFs and your privacy notice need Arabic versions too; our guide to the UAE data protection law covers what that notice must say.

hreflang and Arabic search

Once both versions are ready, connect them with hreflang. Each page lists itself and its alternate, en and ar, plus an x-default, usually the English page. The annotations must be reciprocal: Google ignores them when two pages don't point to each other.

Give each version a self-referencing canonical. Pointing the Arabic page's canonical at the English page asks Google to treat the Arabic as a duplicate.

hreflang doesn't tell Google what language a page is in. Google says it uses neither hreflang nor the lang attribute for that; it reads the visible content. hreflang helps it show the right version to the right searcher.

On our site, hreflang comes from each page's metadata and the sitemap, not from next-intl's automatic Link header, because some sections exist only in English. A single setting turns on the hreflang tags, the Arabic sitemap entries and indexing of the Arabic pages together, and it stays off until a native speaker has reviewed the Arabic.

Arabic search needs its own keyword research. The phrase Arabic speakers use is often not a word-for-word rendering of your English keyword: our Arabic pages use تأسيس الشركات (company formation) where the English site says business setup. Check real queries in Search Console, filtered to your /ar pages, and in Google Ads Keyword Planner with Arabic as the language.

Write Arabic page titles, meta descriptions and social preview text too. For the local side, including Google Business Profile, see our guide to local SEO for Dubai businesses. Arabic SEO is also part of our marketing and growth work.

Test it like an Arabic speaker would

1. Design with real Arabic copy, not lorem ipsum or English placeholders. Arabic runs at a different length and height.
2. Click through every Arabic page on a phone, in Safari and Chrome, looking for left-aligned blocks, unflipped arrows and clipped diacritics.
3. Use the language switcher on every page type and check that you land on the equivalent page.
4. Fill in every form in Arabic, including Arabic names, and check what arrives in your inbox or CRM.
5. Check Arabic emails, PDFs and link previews in WhatsApp and social apps.
6. Turn on VoiceOver or TalkBack and confirm Arabic is read with an Arabic voice, which depends on the lang attribute.
7. Ask a native speaker who hasn't seen the project to use it for ten minutes and note what feels foreign.

If you are planning a bilingual build, our software development team can help you scope it.

Sources

• Google Search Central: Managing multi-regional and multilingual sites
• Google Search Central: Tell Google about localized versions of your page
• W3C: Structural markup and right-to-left text in HTML
• W3C: Arabic and Persian layout requirements
• MDN: CSS logical properties and values
• Apple Human Interface Guidelines: Right to left