Arabic and English text displayed on screen representing bilingual website development

Dubai / UAE

Bilingual Arabic and English Website Development: The Complete Guide

Stackzeno Team · July 14, 2026 · 12 min read

TL;DR

A bilingual Arabic-English website is not just translation — it's a complete UX reversal, a dual SEO strategy, and a separate content pipeline. Here's the technical and strategic guide to doing it right.

Thinking about building a website?

Get a Quote →

TL;DR:

Bilingual Arabic-English website development is a full rebuild — RTL layouts, mirrored UX, separate SEO strategy, and native-quality Arabic content are all non-negotiable.

Google Translate content destroys your Arabic SEO and damages user trust — the UAE and KSA markets will notice immediately.

hreflang tags, dir="rtl", Arabic-first typography, and dual keyword research are the four technical foundations that decide whether the site succeeds.

Bilingual Arabic Sites Are Not a Translation Project

Most businesses in the UAE and KSA treat Arabic localization as an afterthought — a translation layer bolted onto an English-first design. That approach fails consistently.

Bilingual Arabic-English website development is not a translation project. It is two separate websites sharing a codebase. The layout mirrors horizontally. The typography requires different font rendering. The SEO strategy targets completely different search behaviors. The content must be written — not translated — by native Arabic speakers who understand your industry.

Dubai and Riyadh represent two of the most competitive digital markets in the Arab world. Arabic-speaking users in these markets have high expectations. They will judge your brand's credibility within seconds of switching to the Arabic version of your site. A poor Arabic UX doesn't just underperform — it actively destroys trust with a market that represents more than 400 million speakers globally.

This guide covers everything your development team needs to build a bilingual site that actually serves both audiences.

Thinking about building a website? See how we work →

What Makes Bilingual Arabic-English Sites Technically Complex?

The technical complexity of Arabic web development is genuinely different from European bilingual sites. Here's why.

RTL Layout. Arabic reads right to left. This is not a CSS text alignment change — it's a full layout reversal. Navigation menus move to the right. Sidebars flip sides. Cards reverse their content flow. Flex and grid directions invert. The dir="rtl" attribute on the <html> element triggers automatic RTL handling in modern browsers, but many layout components break when tested and require individual fixes.

CSS Logical Properties. The modern approach uses CSS logical properties (margin-inline-start instead of margin-left, padding-inline-end instead of padding-right) so the same CSS works correctly in both LTR and RTL contexts. Legacy codebases using physical properties (left, right, margin-left) require systematic refactoring.

Font Rendering. Arabic fonts render differently from Latin fonts. Size relationships change — a 16px Arabic body font appears smaller than a 16px Latin font. Line heights need adjustment. Arabic ligatures (connected letter forms) must render correctly or the text becomes illegible. Do not assume your Latin-selected font size scales apply to Arabic.

Number Formatting. Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) and Western Arabic numerals (0123456789) are both used in Arabic content, but conventions vary by market. UAE content typically uses Western numerals. KSA content sometimes mixes both. Decide explicitly — inconsistency looks unprofessional.

lang Attribute. Each language block needs the correct lang attribute: lang="ar" for Arabic, lang="en" for English. This affects screen readers, browser spell-check, hyphenation, and search engine language detection. It's not optional.

How to Implement Arabic/English i18n in Next.js

Next.js has native internationalization routing that handles Arabic-English sites cleanly — but there are decisions to make upfront.

Locale routing options:

/en/about and /ar/about — subpath routing (recommended for SEO)
en.example.com and ar.example.com — subdomain routing
example.com and example.ae — separate domains (strongest geo-signal, highest maintenance overhead)

Subpath routing is the default recommendation for most UAE and KSA businesses. It keeps SEO equity on one domain and simplifies deployment.

Using next-intl. The next-intl library is the leading i18n solution for Next.js. It handles message formatting, locale detection, RTL/LTR switching, and works with the App Router's server components model. Key implementation steps:

Define supported locales: ['en', 'ar'] with ar as the RTL locale
Create message JSON files per locale — never auto-generate these with machine translation
Set dir attribute dynamically: <html dir={locale === 'ar' ? 'rtl' : 'ltr'} lang={locale}>
Configure the middleware to detect locale from Accept-Language headers and handle redirects
Use the useTranslations hook in components to access locale-aware strings

RTL CSS strategy. Structure your global stylesheet to apply dir-based overrides cleanly. Avoid duplicating stylesheets. Use CSS logical properties everywhere possible and add targeted RTL overrides for components that require them.

The most expensive bilingual site mistake is building the Arabic version as an afterthought. It always costs more to retrofit than to build correctly from the start.

Talk to Stackzeno about bilingual development →

hreflang Implementation for Bilingual Arabic-English SEO

hreflang is the HTML attribute that tells Google which version of your page to serve in which language and region. Getting it wrong means your Arabic and English pages compete with each other in search results — or the wrong language ranks for the wrong market.

The correct hreflang setup for a UAE bilingual site:

<link rel="alternate" hreflang="en" href="https://example.com/en/services" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/services" />
<link rel="alternate" hreflang="ar-AE" href="https://example.com/ar/services" />
<link rel="alternate" hreflang="ar-SA" href="https://example.com/ar/services" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services" />

Key rules:

Every page must reference every alternate version, including itself
The hreflang value must match the lang attribute on the page
Use region-specific tags (ar-AE for UAE, ar-SA for KSA) when your content is regionally differentiated
Implement in both <head> tags and your XML sitemap — Search Console checks both
Canonical tags must point to the language-specific URL, not across languages

Google's hreflang documentation is the authoritative reference. Read it before implementation.

Separate Keyword Research for Arabic vs. English SEO

Arabic and English audiences do not search the same way. This is the most overlooked aspect of bilingual Arabic-English website development.

Translating your English keyword list into Arabic and targeting those terms directly is a strategy that fails. Here's why:

Search behavior differs. An English-speaking Dubai resident searching for a web design agency types "web design Dubai." An Arabic-speaking UAE resident may type "تصميم مواقع دبي" or "شركة تصميم مواقع في الإمارات" — and those are different queries with different search volumes, different SERP competitors, and different intent signals.

Keyword tools have Arabic coverage. Google Keyword Planner, Ahrefs, and Semrush all support Arabic keyword research. Use them. Pull data specifically for ar-AE (UAE) and ar-SA (KSA) if both markets matter to you.

The Arabic web is less saturated. In many B2B niches, Arabic-language SEO competition is significantly lower than English. A business that invests in quality Arabic content and technical SEO can reach page 1 in Arabic search faster than the equivalent English campaign would take. This is an underexploited advantage.

Volume context. StatCounter data shows Arabic is the primary web language for over 200 million users in the MENA region. A bilingual site without a serious Arabic SEO strategy is leaving a significant audience unserved.

Treat Arabic SEO as a separate campaign with its own keyword research, content calendar, and performance tracking — not an extension of your English strategy.

Why Google Translate Destroys Your Arabic UX and SEO

This is the most common mistake in bilingual site development, and it costs businesses in Dubai and Riyadh credibility they never recover.

Google Translate produces grammatically approximate Arabic that sounds like a non-native speaker wrote it. Arabic is a morphologically rich language — word roots expand into dozens of forms, and context determines meaning in ways that machine translation still handles poorly. Technical content, marketing copy, and service descriptions are particularly vulnerable to mistranslation.

The consequences are specific:

UX damage. Arabic-speaking users in the UAE and KSA have high language standards. A page of awkward, stilted Arabic communicates that your business doesn't value them enough to invest in real localization. Trust is lost in seconds.

SEO damage. Google evaluates content quality. Machine-translated pages are identified as low-quality and rank poorly. They also fail to target the actual search terms Arabic users use — they match the machine translation of English queries, not the native Arabic queries your audience actually types.

Legal risk. For regulated industries (finance, healthcare, legal services) in the UAE, inaccurate Arabic translation can create compliance issues. The standard in Dubai's professional services market assumes human-quality translation.

The right process: native Arabic copywriters who understand your industry write the Arabic content from a brief, not a translation of the English. Budget for this from the start — it's not optional.

According to Stackzeno, the Arabic content quality gap is the single biggest differentiator between bilingual sites that succeed in the UAE market and those that look like they were built for a checkbox.

Arabic Typography Best Practices

Font selection for Arabic web content is not interchangeable with Latin font selection. The wrong font makes Arabic text hard to read and looks unprofessional to native readers.

Recommended Arabic typefaces for web:

Noto Naskh Arabic — Google Fonts, excellent readability for body text, consistent rendering across devices. The default choice for most web projects.
IBM Plex Arabic — Professional, modern, works well for SaaS and tech brands. Available via Google Fonts.
Cairo — Clean geometric style, pairs well with modern Latin fonts. Popular for UI work in the UAE market.
Tajawal — Contemporary, works well for headlines and marketing copy.

Typography implementation rules:

Never use a Latin font for Arabic text — many Latin fonts either don't support Arabic at all or render with broken or missing glyphs.
Set font-size and line-height specifically for Arabic. Arabic body text typically needs 10–15% larger line height than equivalent Latin text for comfortable reading.
Test font rendering on Android — Arabic font support varies significantly across mobile devices and browsers.
Avoid mixing Arabic and Latin text in the same styled element without explicit font-family fallbacks that handle both scripts.

A clean CSS pattern:

[lang="ar"] body {
  font-family: 'Noto Naskh Arabic', 'Cairo', serif;
  line-height: 1.8;
  font-size: 1rem;
}

UX Considerations: Mirrored Navigation, Icons, and CTA Placement

RTL layout is not just about flipping text. Visual logic mirrors with it.

Navigation. In RTL layouts, the primary navigation is typically on the right. The logo moves to the right side of the header. The hamburger menu appears on the left (the visual "end" of an RTL line). If your navigation design assumes LTR conventions, it will look structurally wrong to Arabic readers.

Icons. Directional icons must be mirrored. Arrows pointing right in LTR point left in RTL. Forward/back, play/pause, and progress indicators all follow this convention. Non-directional icons (stars, hearts, abstract symbols) do not need to be mirrored. This distinction trips up many development teams.

CTA placement. In LTR design, the primary CTA is typically placed at the end of a visual flow — right side of a hero, bottom-right of a card. In RTL, the equivalent position is the left side. CTAs placed on the right in RTL feel like they're at the "start" of the flow, not the "end" — which reduces visual authority.

Form inputs. Arabic text input is RTL, but numeric fields (phone, postal code) are typically LTR. Handle this with dir="auto" on input fields or explicit direction overrides per field type.

Image selection. Images showing people, hands, or directional elements (pointing, gesturing, looking) should be selected or mirrored for RTL context. A person looking or pointing to the right in LTR should look or point to the left in RTL to maintain the visual flow toward content.

Explore Stackzeno's web development process for UAE and international clients →

FAQ

Q: How much does bilingual Arabic-English website development cost?

Bilingual development adds 40–70% to a standard website build cost due to the RTL implementation, typography work, separate content creation, and dual SEO setup. For a quality small-business bilingual site in Dubai, budget $15,000–$40,000. Cutting corners on the Arabic side consistently underperforms — the market knows the difference.

Q: Can I launch in English first and add Arabic later?

Technically yes, but retrofitting RTL onto an LTR-only codebase is expensive — often costing 50–80% of the original build to do correctly. Building bilingual-first with a toggle from day one is cheaper overall if Arabic is genuinely part of your market strategy.

Q: What's the best URL structure for a bilingual Arabic-English site?

Subpath routing (/en/ and /ar/) is the recommended default for most businesses. It keeps all SEO equity on one domain and simplifies both development and analytics. Subdomain or separate domain approaches are justified only for businesses with distinct brand identities or strong regional targeting requirements.

Q: Do I need separate Google Analytics tracking for Arabic and English?

No — one GA4 property handles both with language segmentation. Create custom dimensions for locale and segment reports by /en/ and /ar/ path prefixes. Monitor bounce rate, engagement rate, and conversion rate separately per language to identify UX issues on either version.

Q: Which Arabic dialect should I use for web content in the UAE?

Modern Standard Arabic (Fusha/MSA) is the professional standard for business web content across the Arab world and is understood universally. Gulf dialect written content is appropriate only for informal social media targeting UAE/KSA audiences specifically. For a business website in Dubai or Riyadh, MSA is the correct choice.

Ready to build something that stands out? Book Intro ↗

Ready to build something that stands out?

Get a Quote ↗

Share𝕏 Share on X in Share on LinkedIn

Newsletter

Get the founder's playbook

One short email, twice a month — web design, launch lessons, and founder teardowns. No fluff.

Keep reading

← Back to all posts