Bilingual Arabic English Website: Getting RTL Right

Key takeaways

A bilingual Arabic English website is two complete sites sharing one codebase. It is not an English site with a translate button. These are the five points that decide whether it works:

• Arabic runs 20 to 30% longer than English for the same meaning. Buttons, nav labels and headlines sized for English will clip or wrap badly in Arabic.
• Mirroring for RTL (right-to-left) means flipping the direction of the whole grid, not just aligning text to the right. Arrows, chevrons and progress bars have to reverse too.
• hreflang tags alone do not fix a bilingual site. Both language versions need matching URL structures and reciprocal tags on every page. Without them, search engines index the wrong one.
• Separate, unlinked Arabic and English content models in the CMS are the main reason translations drift apart. A locked field structure with a translation status flag stops that.
• Numbers, dates, prices and phone numbers often stay left-to-right inside Arabic text. Handling that inconsistency correctly is what makes a site look native rather than translated.

What makes a bilingual Arabic English website different from an English site with a translate button

The usual founder request is short: "We just need an Arabic version." What they need is a second reading direction running through every component, template and content field on the site. That is a structural change, and it has to be designed in.

Why Google Translate widgets and browser plugins fail founders

A translate widget swaps words after the page has loaded. The layout underneath stays left-to-right. Headlines come out in Arabic but sit on the left edge. The logo and navigation stay in English order. The copy reads like a machine wrote it, because one did.

Search engines don't index widget output as a proper Arabic page, so nobody searching in Arabic finds you. Arabic-speaking visitors also notice the problem within seconds. The widget suggests you want their business but didn't think them worth the effort. For a premium brand, that costs more than having no Arabic at all.

The four things that actually change: direction, layout, typography, content structure

• Direction. The document reads right-to-left, so the browser's idea of where a line starts and ends is reversed.
• Layout. The grid mirrors. The sidebar that sat on the right moves to the left, and the logo moves to the top right.
• Typography. Arabic script needs different sizes, line heights and a typeface built for it.
• Content structure. Every page exists twice. The CMS has to keep both versions in step, and the SEO setup has to tell search engines which is which.

When we do bespoke website design and development for EN/AR clients, all four are planned in the first design pass. Retrofitting them later is where most of the cost goes.

How to mirror a layout for RTL without breaking it

Good RTL website development follows one rule: write the layout once, in terms of direction rather than physical sides, and let the browser flip it.

Setting dir="rtl" and why CSS logical properties matter more than direction alone

Set dir="rtl" and lang="ar" once on the root element of the Arabic version. Don't set them on individual components. The standard recommendation is to declare direction at the html or body level and use text-align: start instead of text-align: right, so alignment follows the language automatically.

The direction attribute only does half the job. A stylesheet full of margin-left and padding-right will still put spacing on the wrong side. CSS logical properties such as margin-inline-start and padding-inline-end respond to text direction. Physical properties do not. We write every spacing, border and position rule in logical properties from the start. With that in place, the Arabic version is mostly the same CSS reading in the other direction.

What reverses: navigation, icons, progress indicators, carousels

Anything that expresses movement or sequence flips:

• Navigation order. The first item sits on the right.
• Directional icons. "Next" arrows, breadcrumb chevrons and back buttons all point the other way.
• Progress bars and step indicators, which fill from right to left.
• Carousels and sliders. Swiping and arrow controls reverse, and slide one starts on the right.
• Form layouts. Labels, input icons and error messages mirror.
• Drawers and off-canvas menus, which open from the opposite edge.

What stays put: logos, numerals, phone numbers, embedded English brand names

Some elements should not mirror:

• Your logo, including any wordmark in Latin script.
• Icons that aren't directional, such as a search magnifier, a play button or a tick.
• Numerals. The UAE mostly uses Western digits (0 to 9), which read left-to-right even inside an Arabic sentence.
• Phone numbers, prices, dates in numeric format, card numbers and postcodes.
• English brand names or product codes inside Arabic copy.

The difficult cases are mixed runs, such as a phone number at the end of an Arabic sentence or "AED 1,250" in a price line. Without bidirectional isolation (the bdi element, or unicode-bidi: isolate in CSS), the browser can move the plus sign or currency code to the wrong end. We test every template with real Arabic strings that contain numbers, not placeholder text. Placeholder text never contains the phone number that breaks the layout.

Arabic typography: sizing, line height and font choice

Arabic website design fails most visibly in the type. The layout can mirror perfectly and the page will still look translated if the text is cramped, too small or set in a fallback font.

Why Arabic needs a taller line height than Latin script

Arabic letters join, stack diacritics above and below the baseline, and have long descenders. At English line heights they collide. One widely used guideline is roughly 1.6 to 1.8 times the font size for Arabic body text, compared with 1.4 to 1.5 for English, plus a larger base size because Arabic glyphs read smaller at the same point size. Other guidance sets the floor at 1.5 and suggests 0.5 to 1px of letter-spacing at small sizes. Use that carefully: letter-spacing can break joined script if it is overdone.

Keep this controlled. The Dubai Design System limits line length to around 80 characters and warns against changing line height in ways that break vertical rhythm. We set Arabic type values as their own tokens in the design system, so the two languages are tuned separately without one-off overrides in individual components.

Choosing a typeface that has a genuine Arabic weight, not a system fallback

If your brand font has no Arabic glyphs, the browser falls back to whatever the device has. The result is a different weight, a different feel, and often a different font on every visitor's phone. Choose a family designed with a proper Arabic companion, and check the whole weight range before you commit. A family with a regular Arabic weight but no bold leaves every headline in the wrong weight.

Sizing buttons and headlines for text that runs 20 to 30% longer

Arabic is typically 20 to 30% longer than the English it replaces. A button sized to fit "Book a call" will clip its Arabic equivalent. Design components to grow with their content: minimum widths rather than fixed ones, padding that scales, and headline sizes tested against the longest real Arabic string. We design the Arabic states in Figma alongside the English ones, not after sign-off.

hreflang and URL structure for EN/AR SEO

This is the section to forward to your developer. EN/AR bilingual site SEO comes down to three questions: can search engines find both versions, do they know the two are equivalents, and do they show each one to the right person?

Reciprocal hreflang tags: what they do and what they don't fix

An hreflang tag tells search engines that the page has an equivalent in another language, and where to find it. Every English page points to its Arabic twin, and every Arabic page points back. Each page also references itself, and an x-default tag names the fallback.

hreflang does not make a thin or machine-translated page rank. It does not fix duplicate content either. Each version also needs its own canonical URL. If the Arabic page canonicalises to the English one, you have told Google to ignore the Arabic page, and the hreflang tags become meaningless.

Subdirectory versus subdomain for the Arabic version

We use /en/ and /ar/ path prefixes on almost every build. As one GCC-focused guide puts it, prefixes are "crawlable, shareable, cacheable, and trivially segmentable in analytics." In Next.js, locale routing handles this natively.

Common hreflang mistakes we see on EN/AR sites

• Return tags missing on the Arabic side, so the pair is never confirmed.
• Invalid codes. "ae" is a country, not a language. Use ar or ar-AE.
• hreflang pointing at URLs that redirect or return a 404.
• A language switcher that sends every visitor to the Arabic homepage instead of the equivalent page.
• Arabic meta titles and descriptions left in English, or translated word for word. Both languages need their own keyword targeting, metadata and image alt text.
• Arabic pages missing from the XML sitemap.

How to stop Arabic and English content drifting apart in the CMS

Most agencies hand over a bilingual site that is in sync on launch day. Six months later, the English pricing page has three new tiers and the Arabic one still shows the old two. The cause is almost always the content model, not the translator.

Why separate Arabic and English page trees go out of sync

Many setups keep Arabic as a copy of the English site, with separate pages and separate entries. When someone edits the English version, nothing connects it to the Arabic version. Nobody gets told. Over time the structures diverge as well. The English page gains a testimonial block that the Arabic page never gets, and the two can no longer be compared field by field.

Locking field structure and adding a translation status flag

We model content once and localise at the field level. A page has one structure, and each text field holds an English value and an Arabic value. Editors can't add a section to one language only. On top of that, each entry carries a translation status: in sync, needs translation, in review. Editing an English field automatically marks the Arabic side as stale, and stale entries appear in a list the team can work through. Headless CMSs such as Sanity and Payload support this directly. It takes a day of modelling at the start and saves months of clean-up later.

Who owns Arabic copy: a translator, not a translation plugin

Name one person who is accountable for Arabic copy. Ideally that is a native writer who knows your market, not a plugin. The status flag tells them what changed. Their judgement decides how it should read. We can write the Arabic ourselves as part of a build, or work with your translator inside the same workflow.

When a bilingual EN/AR site is worth building now versus later

Arabic done properly costs more than English alone. Done badly, it costs more again, because it has to be rebuilt later. The real decision is whether to launch in both languages or to build English with the RTL foundations in place and add Arabic content in a second phase.

Signs you need Arabic on day one

• Your buyers search and make decisions in Arabic, as in consumer retail, government-facing services and much of the Saudi market.
• You are entering Dubai or Riyadh and local partners will judge you on the Arabic version. This belongs in your UAE market entry and go-to-market planning, not as an afterthought.
• Regulation or tender requirements ask for Arabic.
• Your sales run through WhatsApp conversations in Arabic, and the site needs to match.

Signs English-first with Arabic in phase two is the smarter call

• Your buyers are B2B decision-makers who work in English, which is common in UAE fintech and professional services.
• You don't yet have anyone to own the Arabic copy.
• The offer is still changing, and translating copy that will be rewritten in a month wastes money.

Our honest advice in that case is to build with logical CSS, a localised content model and /en/ routing from the start. Adding Arabic later is then content and QA, not a rebuild. Either route is quoted at a fixed price after a free 30-minute call, and most of our bilingual clients are outside the UAE, so it's worth reading how a remote project runs across time zones.

Frequently asked questions

Does a bilingual Arabic English website cost more to build than an English-only site?

Yes. You are paying for a second design pass, RTL testing on every template, a localised content model and the Arabic copy itself. The extra is much smaller when bilingual support is planned from the first sketch than when it is bolted on later. Our projects start at $2,000, and we quote the bilingual scope as a fixed price in writing before work begins.

Can I add Arabic to an existing English website later, or does it need to be built in from the start?

You can add it later. How painful that is depends on the code. A site built with logical CSS properties and a field-level localised CMS can take Arabic in weeks. A site built with hard-coded left and right values and single-language content often needs its templates rebuilt.

Do I need a native Arabic speaker to write the copy, or can I translate my English copy?

Use a native writer. A literal translation of English marketing copy reads stiffly and misses how your buyers search, which also hurts your Arabic SEO. Translation is a reasonable starting point for legal and product pages. Headlines, calls to action and metadata should be written for the Arabic reader.

Should the Arabic version sit on a subdomain or a subfolder of the same domain?

For most businesses, a subfolder such as /ar/. It shares the main domain's authority, runs as one site with one deploy, and keeps analytics simple. A subdomain makes sense only when the Arabic version genuinely runs on separate infrastructure or is managed by a separate team.

How do I check that numbers and phone numbers aren't breaking inside Arabic text?

Test with real content, not lorem ipsum. Put an actual UAE phone number, a price in AED and a mixed English/Arabic product name into every template and view it on a phone. If a plus sign, a currency code or a digit jumps to the wrong end of the line, the run needs bidirectional isolation before launch, not after.

If your bilingual site needs the mirror to actually hold together, book the free 30-minute call and we'll tell you what your current setup gets wrong.