Planning a Bilingual Arabic English Site Before Design Starts

The Arabic English website structure you choose before design starts decides how easily the site can be found, edited and grown in both languages. Four choices are expensive to reverse once pages are built: the URL pattern, how much content must exist in both languages, how the CMS stores each language, and who owns translation. Settle those first and the visual work, including right to left layout, sits on a stable base.

Visual layout and Arabic typography are a separate topic. This guide covers the structure that designers, developers and content teams all depend on.

Why bilingual structure has to come before design

An English homepage mockup looks complete, so the Arabic version is often left as a task for after launch. That is when the problems appear.

• Templates are built with English text lengths, so Arabic headings wrap badly or push buttons out of place.
• The CMS has one title field per page, so Arabic content ends up in a duplicate page with no link to its English twin.
• URLs are set without a language segment, and adding one later means redirecting every page.
• Nobody owns translation, so the Arabic side drifts out of date within months.

Each of these is cheap to decide on paper and costly to fix in a live site. The rest of this article works through them in the order they should be decided.

Decision 1: the Arabic English website structure for URLs

Search engines and users both need a stable, separate address for each language version of a page. Google's guidance on multilingual sites recommends distinct URLs per language rather than switching language with cookies or browser settings, because Googlebot generally crawls without signalling a language preference and may never see a version that only appears dynamically. Google's multi regional site documentation sets out the options.

For most UAE businesses with one brand and one market, subdirectories are the practical default. They keep one codebase, one analytics property and one set of backlinks.

Arabic URL structure: script or transliteration?

Once you have /ar/, decide what follows it. You have three choices for the slug of an Arabic page:

1. Arabic script slugs. Readable to Arabic speakers in the address bar, but they become long percent encoded strings when copied into emails, spreadsheets or some ad platforms.
2. Transliterated slugs such as /ar/khadamat/. Short and portable, but inconsistent unless someone sets spelling rules.
3. Shared English slugs such as /ar/services/. Easiest to maintain and map between languages, though less meaningful to Arabic readers.

There is no single right answer. What matters is choosing one rule, writing it into the content guide and applying it to every page, so the site does not end up with a mix of all three.

Root URL and redirects

Decide what the bare domain shows. Many sites serve English at the root and Arabic under /ar/; others put both languages in folders and use the root as a language choice page. Avoid automatically redirecting visitors to a language based on their location or browser. Google's guidance warns that this can stop both users and crawlers from reaching every version, and in the UAE a visitor's location says very little about the language they prefer to read.

Decision 2: hreflang and the language switcher

With separate URLs in place, each page needs to declare its alternates. Hreflang annotations tell search engines which pages are translations of each other. Google's localized versions documentation notes that each language version must list itself and every other version, and that links must point both ways or the annotations may be ignored. The reserved x default value covers visitors whose language does not match any version.

Plan this at template level, not page by page. If the CMS knows which English page pairs with which Arabic page, the annotations can be generated automatically and stay correct as pages are added.

Language switcher rules

• Link to the equivalent page, not the other language's homepage. Someone reading an Arabic service page who switches to English should land on the same service in English.
• Use the language name in its own script, so "العربية" and "English", rather than flags. Flags represent countries, and Arabic is used across many of them.
• Handle missing translations honestly. If a page exists only in English, either hide the switcher on that page or link to the nearest Arabic parent page with a short note.
• Place it consistently in the header on desktop and in the mobile menu, so it is easy to find on every template.

Decision 3: content parity

Content parity means deciding how closely the Arabic site should match the English one. Full parity sounds ideal but is not always realistic, and partial parity is fine if it is deliberate.

Three parity models

Whichever model you choose, write it down as a page inventory with a column for each language. This becomes the brief for writers, the checklist for QA and the source of truth when someone asks why a page has no Arabic version.

Localise, do not just translate

Parity of meaning matters more than parity of words. Arabic readers may need different examples, a different order of points or a call to action that suits how they prefer to make contact, such as WhatsApp rather than a long form. Plan for Arabic pages to be written by someone who understands the audience, not only converted from the English draft.

Hypothetical example: a Dubai property developer publishes English project pages that lead with investment returns and payment plans. The Arabic audience for the same project may care more about family amenities, schools and community. Under core parity, both languages get a project page, but the Arabic page is briefed separately rather than translated line by line.

For more on what different property audiences expect, see our guides on planning a developer or broker website and the features property buyers expect.

Decision 4: CMS fields and data model

The CMS is where bilingual plans succeed or fail. Before design, confirm how the chosen platform stores languages and what your editors will see.

Questions to answer about the CMS

• Are translations linked? Each Arabic page should be connected to its English counterpart so the switcher and hreflang work automatically.
• Which fields are translatable and which are shared? Text, SEO titles, meta descriptions, image alt text and slugs need separate values. Prices, SKUs, dates, phone numbers and coordinates are usually shared.
• Do menus, footers and forms have language versions? These are often forgotten and leave English labels on Arabic pages.
• Can editors see what is missing? A simple translation status per page saves hours of manual checking.
• How are media handled? Images containing English text need Arabic alternatives, and PDFs such as brochures may need two files.

On WordPress this usually means choosing a multilingual plugin early and building custom fields with it in mind. On headless platforms, the content model needs locale support defined from the start. Retrofitting either after templates are built is where most bilingual budgets overrun.

Template allowances

Give designers clear rules from the structure stage: headings and buttons must cope with different text lengths, and digit, date and phone formats should be agreed per language.

Decision 5: translation workflow and ownership

A bilingual site needs a named owner for each language. Without one, updates go live in English and the Arabic side quietly falls behind.

A workable translation workflow

1. Source content is approved in one language first. Usually English, but some UAE organisations write in Arabic first.
2. The page is flagged for translation in the CMS or a shared tracker, with any notes on localisation.
3. A translator or bilingual writer produces the second version, using an agreed glossary for product names, legal terms and brand phrases.
4. A native speaker reviews the page in context on staging, not in a spreadsheet, to catch layout and tone issues.
5. Both versions are published together, or the page stays unpublished in both languages until ready.

Machine translation can speed up drafts, but published Arabic should always be reviewed by a fluent speaker.

Regulatory and sector considerations

Some sectors in the UAE have specific expectations about Arabic content, particularly regulated areas such as healthcare, financial services and government facing services. Requirements vary by regulator and emirate, so confirm language obligations with your regulator or legal adviser before setting the parity model. If you collect personal data through bilingual forms, make sure privacy notices and consent text are available in both languages your visitors use. Abu Dhabi projects can also differ in audience and approvals; our article on how Abu Dhabi projects differ from Dubai ones covers this.

A pre design checklist

Before any design work starts, the project should have written answers to the following:

• URL pattern chosen (subdirectory, subdomain or domain) and what the root shows
• Arabic slug rule agreed and documented
• Parity model chosen, with a page inventory listing each page and its languages
• CMS or plugin confirmed for linked translations and translatable fields
• Menus, forms, footers, emails and PDFs included in the inventory
• Language switcher behaviour defined, including pages without a translation
• Hreflang to be generated at template level
• Translation owner, reviewer and glossary in place
• Digit, date and phone formats agreed per language

Our guide to the pages a new business site needs can help you build the initial page inventory.

Plan your bilingual site with Codeeo

Codeeo plans and builds bilingual websites for UAE businesses, starting with structure before any design is drawn. Our website development and UI and UX design teams work through URL patterns, CMS fields, parity and translation workflow with you, and our WordPress developers configure multilingual setups that editors can manage. If an existing site needs restructuring, our site migration service covers redirects and language mapping.

With 200+ projects delivered across the UAE and the US and an office in Dubai where you can meet the team, we can review your plans in person. Contact Codeeo to discuss your bilingual project.