Building Arabic + English websites that actually rank in both markets
A bilingual site is not a translation — it is two search surfaces wired together. Do it wrong and you split your own authority; do it right and you rank in a market most competitors left empty.
Most businesses in this region run an English-only website and quietly cede the larger audience. The Arabic-speaking internet is not a niche: penetration across MENA sits near 70 percent — hundreds of millions of users, young and mobile-first [1] — driving an e-commerce market on track to pass 57 billion dollars by 2029 [2].
But a bilingual site is not a translation. It is two search surfaces — one English, one Arabic — that must be wired together so engines understand they are the same content in two languages, not duplicate pages competing with each other. Get the wiring wrong and you split your own authority. Get it right and you rank in a market most of your competitors have left empty.
This is the practical version: how the two surfaces connect with hreflang, why machine-translated Arabic loses, and the structural calls — URL shape, RTL, fonts — that decide whether you own both markets or neither.
The spine of a bilingual site is the hreflang annotation. Each page declares its language variants and points at its counterparts; Google's own documentation [3] is explicit that the references must be bidirectional and should include an x-default fallback. The English page points to the Arabic, the Arabic points back, and both name a default for unmatched users. Miss the return link and the engines ignore the cluster entirely — which is the single most common way bilingual sites quietly fail.
Second rule: separate, server-rendered URLs, not a client-side toggle. A real Arabic surface lives at its own crawlable path — a /ar/* subfolder with its own HTML per language. An on-page "translate" switch that swaps text in JavaScript leaves one URL with mixed-language signals and gives the Arabic index nothing to rank. Google's multi-regional guidance [4] is clear that each language version needs its own URL.
Third: do not machine-translate the Arabic. Search intent, phrasing, and the actual keywords people type in Arabic diverge from a literal translation of the English. Auto-translated copy reads as foreign, ranks for the wrong terms, and converts badly. Native Arabic content — written, not run through a translator — is what earns both the ranking and the trust.
Fourth: right-to-left layout and typography are conversion-critical even where they are not strictly ranking factors. Arabic needs RTL flow, proper Arabic web fonts (a Naskh face for display, a modern sans for body), and localised number and date formatting. A page that renders Arabic inside a Latin-tuned layout reads as broken and bounces — and bounce is a signal.
Done right, the payoff compounds: you become one of the few competitors with a clean Arabic surface, hreflang consolidates authority instead of splitting it, and you capture intent in a market growing double digits [2] that English-only rivals never see. We built felukaa.com exactly this way — a full /ar mirror, hreflang across every route, native Arabic copy and Arabic fonts — because the Arabic surface is not an afterthought to the English one; it is the second half of the same asset.
The fast, cheap path: run the English site through translation, ship an Arabic mirror, move on. It gets you a bilingual-looking site in a day. It also ranks for literal translations nobody searches, reads as machine-made, and converts poorly. Cheap to build, expensive in lost intent.
Write the Arabic surface as its own thing — native phrasing, region-specific keywords, RTL-first layout. It costs more up front and needs an Arabic writer, not a translator. It is also the only version that actually ranks and converts in Arabic search. For a market this size, that is the investment that pays.
A structural debate: /ar/* subfolder inherits the root domain's authority and is simpler to wire; ar.domain.com is cleaner to operate and host separately but starts authority closer to zero. For most operators the subfolder wins — you want both languages compounding the same domain's trust, not two domains competing for it.
Wire it with bidirectional hreflang + x-default, give each language its own crawlable URL, write the Arabic natively, and prefer the /ar subfolder so authority consolidates. That is more work than a translate-and-ship mirror — and it is the difference between a site that looks bilingual and one that actually ranks in both markets.
- 01For a brand new domain, how long until the Arabic surface ranks competitively versus the English one — and does the gap close on its own or need separate link-building?
- 02When is a subdomain (ar.domain.com) genuinely the better call over a /ar subfolder, beyond pure hosting/ops preference?
- 03How much does RTL/font polish actually move conversion versus pure ranking — is a "good enough" Arabic layout costing measurable revenue?
- 04In AI answer engines, does a clean Arabic surface get cited for Arabic-language queries the way it ranks in classic search, or is GEO still English-dominant in MENA?
- 05For dialect-heavy markets, does Modern Standard Arabic content rank and convert well enough, or is per-market dialect targeting worth the extra surface?
- [1]Statista — Online shopping behaviour in the Middle East and North Africa (penetration + demographics).
- [2]Digital Commerce 360 — MENA e-commerce market projected to reach 57.8 billion dollars by 2029.
- [3]Google Search Central — Tell Google about localized versions of your pages (hreflang).
- [4]Google Search Central — Managing multi-regional and multilingual sites.
We build bilingual sites that rank in both languages — not just translated mirrors.
Native Arabic copy, RTL-first layout, hreflang wired across every route — the way we built felukaa.com. Fifteen minutes to find the Arabic intent your English-only site is missing.
Book a free 15-min consultation