How to Build a Bilingual Arabic English Website for a UAE Business: RTL, hreflang and Arabic Fonts

One Language Per Page, One URL Per Language

The usual shortcut is one page with English and Arabic side by side, or a toggle that swaps the text with JavaScript on the same URL. Both work against you in search.

Google's guide to managing multilingual sites is clear on three points:

• Language is read from visible text. Google says it uses the visible content to work out a page's language and doesn't use the lang attribute or the URL for that. It recommends one language for content and navigation on each page and specifically advises against side-by-side translations.
• Each language needs its own URL. Google recommends separate URLs over cookies or browser settings. Googlebot usually crawls from the USA and sends no Accept-Language header, so a page that picks its language on the fly will most likely only ever be crawled in English.
• Don't redirect people by guessed language. Link to the other version and let the visitor choose. In the UAE, a guess based on IP or browser settings is wrong often enough to annoy people.

Choosing a URL Structure for a Bilingual Arabic English Website

Google's documentation lists four options and their trade-offs. Here is how they play out for a typical UAE business:

URL structures for Arabic and English versions, based on Google's multi-regional guidance

Structure	Example	When it fits
Subfolder	example.com/ar/	Most small and mid-size businesses. One host, one SSL certificate, one analytics property. Google lists it as easy to set up and low maintenance.
Subdomain	ar.example.com	When the Arabic site runs on a different platform or server. More setup, same rules.
Country domain	example.ae	When the whole business is UAE-only. Google treats a ccTLD such as .ae as a strong country signal, which helps locally and limits you elsewhere.
URL parameter	example.com/?lang=ar	Avoid. Google marks this option as not recommended.

For a hand-coded or WordPress site, the subfolder wins on effort. Google allows Arabic words in URLs, but an Arabic slug becomes a long string of %D8 codes when pasted into WhatsApp or email, so Latin slugs under /ar/ are the safer default.

hreflang for ar-AE and en-AE

hreflang tells Google which pages are translations of each other, so an Arabic searcher in Dubai gets the Arabic page and not the English one. Google's localized versions guide says the HTML, HTTP header and sitemap methods are equivalent, so pick one. On a static site the <head> is simplest. Both pages carry the identical set:

<!-- In the <head> of BOTH /services.html and /ar/services.html -->
<link rel="alternate" hreflang="en-AE" href="https://www.example.com/services.html">
<link rel="alternate" hreflang="ar-AE" href="https://www.example.com/ar/services.html">
<link rel="alternate" hreflang="x-default" href="https://www.example.com/services.html">

<!-- Each page's canonical points to ITSELF, never to the other language -->
<link rel="canonical" href="https://www.example.com/ar/services.html">

The rules that break most implementations come straight from Google's page:

• Every version lists itself and every other version. If the English page points to the Arabic one but not back, Google ignores the pair.
• URLs must be absolute, with https://. A relative /ar/services.html doesn't count.
• The first code is always a language. ar-AE means Arabic for users in the UAE. A bare AE is invalid, because Google won't work out the language from a country code.
• x-default is the fallback for visitors whose language doesn't match either version. On a UAE site that is usually the English page.

Don't add ar-SA or ar-QA tags pointing at the same UAE pages in the hope of extra traffic. That isn't a regional version, just the same page with a different label.

hreflang only connects the versions. The Arabic page still has to be in Arabic top to bottom, navigation, footer and alt text included.

RTL Website Design: Getting the Mirror Right

The W3C's article on right-to-left text in HTML gives the short version: put dir="rtl" on the <html> element, set lang="ar" as well, and never use CSS to set the base direction. The language tag does not set direction on its own, so you need both.

<!DOCTYPE html>
<html lang="ar" dir="rtl">
<head>
  <meta charset="utf-8">
  <title>&#x200F;خدمات تصميم المواقع | Example</title>
  ...

The ‏ is an invisible right-to-left mark. The W3C suggests it for Arabic titles that start with a Latin brand name, which browsers can otherwise show in the wrong order.

With dir="rtl" set, alignment, table columns and form fields flip on their own. Your CSS only flips if it uses logical properties; a hard-coded margin-left stays put. A pattern that works:

/* Works in both directions without a separate RTL stylesheet */
.card {
  border-inline-start: 4px solid #0891d4;  /* left in English, right in Arabic */
  padding-inline-start: 1rem;
  margin-block-end: 1rem;
  text-align: start;                       /* never text-align: left */
}
.nav .cta { margin-inline-start: auto; }    /* pushes the button to the far end */

/* Directional icons need an explicit flip */
[dir="rtl"] .icon-next,
[dir="rtl"] .icon-back { transform: scaleX(-1); }

We rendered this exact CSS in Chrome on an Arabic test page before publishing: the border, padding and button all moved to the mirrored side, and the "next" arrow pointed left, the way an Arabic reader expects.

Phone numbers, prices and English words inside Arabic text

This is where Arabic pages look broken to native readers without the developer noticing, because the browser reorders spaces and plus signs around Arabic text. On our test page, a UAE number written plainly inside an Arabic sentence, +971 4 000 0000, displayed as "0000 000 4 971+". The same number with dir="ltr" on its link displayed correctly. The fixes, all from the W3C's guidance:

<!-- Known left-to-right content: say so -->
<a href="tel:+97140000000" dir="ltr">+971 4 000 0000</a>

<!-- Text from a database or CMS where direction is unknown -->
<bdi>AED 1,250</bdi>

<!-- Form fields -->
<input type="tel" name="phone" dir="ltr" autocomplete="tel">
<input type="email" name="email" dir="ltr" autocomplete="email">
<textarea name="message" dir="auto" dirname="message.dir"></textarea>

dir="auto" picks the direction from the first strong character a visitor types, useful because UAE customers often write English on the Arabic page. dirname sends that direction with the form, so your inbox or CRM shows the message the right way round.

Arabic Web Fonts That Hold Up on a Phone

Arabic is cursive. Letters join and change shape depending on their position in a word, so a Latin font with a system fallback gives you mismatched shapes and spacing. Pick an Arabic family on purpose. These are all free on Google Fonts:

Arabic font families on Google Fonts and where they suit

Family	Style	Good for
Noto Naskh Arabic	Naskh, the traditional book style	Long-form text, legal pages, clinics and law firms
Noto Kufi Arabic	Kufi, geometric	Headings and short UI labels
IBM Plex Sans Arabic	Modern sans	Corporate and tech sites already using IBM Plex in English
Cairo	Modern sans with matching Latin	Sites that want one family for both languages
Tajawal	Light, rounded sans	Retail, hospitality and lifestyle brands

Typography rules worth applying on every Arabic page:

• Size up. Arabic looks smaller than Latin text at the same pixel size, and its dots and marks need vertical room. A good starting point is 1.125rem body text with a line height near 1.8, checked on a real phone.
• No letter-spacing. Tracking that looks elegant on an English heading can pull joined Arabic letters apart. Reset it with :lang(ar) { letter-spacing: 0; }.
• No fake italics or uppercase. Most Arabic web fonts have no italic, so the browser slants the glyphs artificially, and Arabic has no capitals. Use weight or colour for emphasis instead.
• Load only what you use. Arabic font files are bigger than Latin ones, so two weights are usually enough, with font-display: swap so text isn't invisible while they load. Our speed optimization guide covers the rest.

Numbers, Dates and the New Dirham Sign

Arabic text can use Western digits (0-9) or Arabic-Indic digits (٠-٩). Both are correct. What matters is choosing one and using it everywhere, including in prices generated by JavaScript or a store plugin. If your code formats numbers, pin the numbering system rather than trusting the default, because defaults can differ between browsers and runtime versions. We ran this in Node.js 20 with ICU 76:

const price = 1250;
new Intl.NumberFormat('ar-AE-u-nu-latn', { style: 'currency', currency: 'AED' }).format(price);
// "‏1,250.00 د.إ.‏"   (Western digits)
new Intl.NumberFormat('ar-AE-u-nu-arab', { style: 'currency', currency: 'AED' }).format(price);
// "‏١٬٢٥٠٫٠٠ د.إ.‏"   (Arabic-Indic digits)
new Intl.NumberFormat('en-AE', { style: 'currency', currency: 'AED' }).format(price);
// "AED 1,250.00"

The currency sign has changed too. The Central Bank of the UAE unveiled a new dirham symbol in March 2025, and the Unicode Standard version 18.0, released in September 2026, encodes it as U+20C3 UAE DIRHAM SIGN. Being encoded doesn't mean it displays yet. Fonts and operating systems need updates first, so for now keep "AED" or د.إ as the visible text and only switch once you have checked the symbol renders in your chosen font on the phones your customers use.

Write the Arabic, Don't Just Translate It

A machine-translated Arabic page fails a native reader in the first line, and it misses how people search. Arabic searchers don't always type the literal translation of your English keyword, so do the keyword research again in Arabic and give the Arabic writer the brief, not the English page.

The parts that often get left in English:

• The <title>, meta description and image alt text
• Form labels, placeholder text, validation errors and the thank-you message
• Open Graph tags. Set og:locale to ar_AE with an og:locale:alternate of en_AE, per the Open Graph protocol, and translate the title and description. On our I-Realtor project, UAE agents shared links mainly on WhatsApp, where that preview is the first thing a customer sees.
• Structured data. Translate the text fields in your JSON-LD and set "inLanguage": "ar". Our schema markup guide has the full LocalBusiness template.

The lang attribute still matters for accessibility. Screen readers use it to pick a voice, and WCAG 2.2 success criterion 3.1.1 requires the page language to be set in code. Mark English phrases inside Arabic text with <span lang="en">; our accessibility guide has more.

Launch Checklist for a Bilingual Arabic English Website

1. Every English page has an Arabic twin at its own URL, and the language switcher links to that twin, not to the Arabic home page.
2. Both versions carry identical hreflang sets with absolute URLs, plus x-default, and each canonical points to itself.
3. <html lang="ar" dir="rtl"> on every Arabic page, and no CSS direction rule standing in for it.
4. No left or right left in layout CSS except where something truly must stay fixed.
5. Phone numbers, emails, prices and order numbers display correctly inside Arabic sentences.
6. Forms tested in Arabic on a phone, including errors and the confirmation email.
7. Arabic titles, descriptions, alt text and Open Graph tags written, not copied from English.
8. Both language URLs listed in sitemap.xml and submitted in Google Search Console.
9. GA4 reports split by the /ar/ folder, so you can see whether the Arabic pages earn their keep.

Common Bilingual Website Mistakes

• Using a translation widget as the Arabic site. Machine-translated text appears on the same URL, so Google can't index it, and native readers notice straight away.
• One-way hreflang. The Arabic pages point to English, but nobody updated the English templates. Google drops the pairing.
• Flipping everything. Mirroring the logo, a play button or a chart's time axis looks just as wrong as not mirroring the navigation.
• Leaving the Arabic site half-built. Ten translated pages linking into an English-only blog sends Arabic visitors back to English after one click. Launch fewer pages, but complete ones.

Frequently Asked Questions

Should a UAE website be in Arabic and English?

It depends on who buys from you. If government buyers, Emirati households or Arabic-speaking customers are a real part of your market, a proper Arabic version is worth it. If your customers are almost all English-speaking expats, a well-written English site with Arabic contact details can be enough for now.

Should I use a subfolder or a separate .ae domain for Arabic?

A subfolder such as /ar/ is easiest for most businesses because it shares one host, one certificate and one analytics setup. Google treats a .ae domain as a strong UAE signal, so choose it when the whole business serves only the UAE.

Which hreflang codes should a UAE site use?

Use ar-AE and en-AE when prices, contact details and services are UAE-specific, plus x-default pointing to the English page. Use plain ar and en if the same pages serve the whole Gulf.

Does Google read the lang attribute to rank Arabic pages?

No. Google says it detects language from visible content and doesn't use the lang attribute for that. Keep lang="ar" anyway, because screen readers and browsers rely on it.

Can I use one font for both Arabic and English?

Yes, if the family includes both scripts. Cairo and IBM Plex Sans Arabic have Latin characters designed to match, which keeps headings consistent when an English brand name sits inside Arabic text.