Bilingual Arabic-English Website Architecture

Many "bilingual" sites are English sites with Arabic text poured in. The menu flips, a few margins break, the font falls back to whatever the browser has, and search engines see one version or neither. Getting it right is not harder than getting it wrong, but it has to be decided at the start.

Developer detail is marked "For your developer"; the checklist is the part to hand over to whoever builds your site.

Translated versus bilingual by design

A translated site is designed and built in one language, and the second is added later. A bilingual site treats both languages as first-class from the first wireframe:

• Layouts are designed for both directions, not mirrored afterwards.
• Content is written for each audience, not converted word for word.
• Both languages are held to the same performance and accessibility standards.

This is how we build ours. This site runs in English and Arabic on Next.js with native right-to-left layout, and our FAQ describes the approach as bilingual by design, not mirrored.

URL structure

Each language version should have its own URL. Google recommends separate URLs for each language version rather than switching content by cookie or browser setting on one URL. The common structures:

Google's guide to multi-regional sites lays out the trade-offs. For a company serving Arabic and English speakers from one brand, a subdirectory per language is usually the simplest to run.

hreflang, done correctly

hreflang tells search engines which URL is the equivalent page in another language. Google's rules are strict:

1. List every version. Each version lists every version, including itself: the English page points to the Arabic one and to itself, and the Arabic page does the same. Links that are not returned are ignored.
2. Use valid codes. Language in ISO 639-1 format (en, ar), optionally with a region in ISO 3166-1 format (ar-SA, ar-EG).
3. Add an x-default. It names the page for users whose language you do not serve.
4. Pick one method. HTML link elements, HTTP headers or the XML sitemap all work; the sitemap is easiest to keep consistent on large sites.

Google also states that it does not use hreflang or the lang attribute to detect a page's language; it reads the content. So the Arabic page has to actually be in Arabic, including its title and description.

Do not redirect by browser language

It is tempting to send visitors to a language automatically.

Google advises against redirecting on perceived language, because it can stop both users and crawlers from reaching the other versions. Offer a clear language switcher instead, and let it take people to the equivalent page, not the home page.

Right-to-left is a layout, not a flip

For your developer. Set the direction in the markup. The W3C recommends putting dir="rtl" on the html element, not applying direction through CSS, so the page works even if styles fail to load.

Then build every layout with logical properties, which follow the reading direction instead of the screen:

/* Physical: breaks in Arabic */
.card { margin-left: 1rem; text-align: left; }

/* Logical: correct in both directions */
.card { margin-inline-start: 1rem; text-align: start; }

In Tailwind CSS the same idea is ms-4, pe-6 and text-start instead of ml-4, pr-6 and text-left. A codebase written this way needs almost no direction-specific overrides.

What to mirror, and what not to

• Mirror anything that shows reading order or direction: back and forward arrows, progress, breadcrumbs, sliders, the position of navigation.
• Do not mirror logos, photographs, media playback controls, charts with a time axis that your audience reads left to right, or anything that represents a physical object.

Mixed-direction text

Arabic pages are full of English: product names, code, email addresses, phone numbers. Wrap content of unknown direction, such as user names or search terms, with dir="auto" or the bdi element, as the W3C guidance describes, so punctuation and numbers land in the right place.

Typography for two scripts

• A font per script. Choose an Arabic typeface designed alongside your Latin one, or a pair that matches in weight and size. Do not rely on the browser's fallback.
• Taller line height. Arabic letterforms have taller ascenders and descenders; text set at Latin line heights looks cramped.
• No letter-spacing on Arabic. Arabic is a connected script, and tracking breaks the joins.
• No italics for emphasis. Most Arabic typefaces have no true italic; use weight or colour instead.
• Decide on digits. Arabic text can use Latin digits (0 1 2 3) or Arabic-Indic digits (٠ ١ ٢ ٣). Either is valid; choose one and apply it everywhere, including dates and prices. This site uses Latin digits in Arabic.

Forms, data and search

For your developer. These details decide whether forms, data and search work in Arabic:

• Direction per field. Email, URL and phone fields should stay left-to-right inside an Arabic form.
• Formatting by locale. Dates, numbers and currency should be formatted with the browser's Intl APIs for the visitor's language, not hand-built strings.
• Bilingual validation messages. An English error on an Arabic form is a broken form.
• Search that understands Arabic. Arabic spelling varies (different forms of alef, taa marbuta and haa). Normalise text before matching, or users will miss results they typed correctly.
• Content stored per language. Each field that a visitor reads should have an Arabic and an English value, not a translated copy generated on the fly.

Content: write it, do not convert it

Search behaviour differs between languages.

Arabic searchers often use different terms from a literal translation of the English keyword, and the same idea may be searched in Modern Standard Arabic or in a regional dialect. Research keywords in each language separately, write each version for its reader in Modern Standard Arabic, and give each page its own title and meta description. Machine translation can be a draft; it should not be what you publish.

Bilingual website checklist

• Each language has its own URL, and the switcher goes to the equivalent page.
• hreflang is reciprocal, self-referencing and includes x-default.
• lang and dir are set on the html element for each locale.
• Layouts use logical properties; no physical left and right in components.
• Direction-bearing icons mirror; logos and media do not.
• Each script has its own font, line height and no tracking on Arabic.
• Forms keep email, URL and phone fields left-to-right, with messages in both languages.
• Dates, numbers and currency use locale formatting.
• Keywords, titles and descriptions are researched and written per language.
• Both versions are tested by a native reader before launch.

Planning a bilingual site? Describe your bilingual project.

Doing this in Next.js

For your developer. In the Next.js App Router, locale routing is usually handled with a [locale] route segment and a library such as next-intl, which provides locale-aware links and message files per language.

The pieces above still apply: lang and dir on the html element per locale, hreflang alternates in metadata or the sitemap, logical properties in every component, and separate message files written per language.

Bilingual website: common questions

Subdirectory or subdomain for an Arabic version?

Both work. A subdirectory such as /ar is usually simpler to run because it keeps one domain and one deployment. Pick a subdomain or a country domain only if you have a reason, such as a separate team or a country-specific business.

Do I need hreflang with only two languages?

Yes. It helps search engines show the right version to the right searcher. With two languages the setup is small: each page lists both versions and an x-default.

Can I use machine translation for the Arabic site?

As a first draft, perhaps. Published Arabic should be written or edited by a native writer, with its own keyword research, or it will read as a translation and miss what Arabic searchers type.

Should the Arabic site use Arabic-Indic or Latin digits?

Either is correct. Choose one, apply it consistently across text, dates, prices and forms, and test it with your audience.

Planning or fixing a bilingual site

If you are planning a bilingual site or fixing one that was translated after the fact, describe your bilingual project, or look at our work to see two bilingual builds. For a site that already exists, a technical audit will tell you what can be fixed in place and what needs restructuring.