Our Work
About Us Blog Contact
← Back to blog

How to Build a Bilingual Arabic and English Website Properly

How to Build a Bilingual Arabic and English Website Properly

A proper bilingual site gives Arabic its own designed layout, its own crawlable URLs and correct hreflang annotation, rather than mirroring the English one. Mirroring breaks typography, line length and keyboard focus order. Since roughly 71 percent of Saudi search queries are in Arabic, doing this badly costs most of the market.

Why this matters more than people think

Arabic accounts for roughly 71 percent of search queries in Saudi Arabia, with English at around 24 percent. If you sell to Saudi consumers and your site is English only, you are not reaching most of your market, regardless of how good the site is.

The reverse mistake is just as costly. Plenty of businesses add an Arabic version by running the English through a translator and flipping the layout, then wonder why it produces no traffic. A badly built Arabic version can rank worse than no Arabic version at all, because it competes with your English pages instead of adding to them.

Pick a URL structure first

Everything else depends on this decision, and changing it later means a migration. There are three workable options.

  • Subdirectories, example.com/ar/. Simplest to run, keeps all authority on one domain, works with any hosting. This is the right default for almost everyone.
  • Subdomains, ar.example.com. Cleaner separation if the two sites are genuinely managed by different teams, but you split some authority.
  • Separate ccTLDs, example.sa. Strongest geo signal, most expensive to run, only worth it at real scale.

Unless you have a specific reason, use subdirectories. It is the option you are least likely to regret.

Get hreflang right, or skip it

hreflang tells Google which version of a page to show which audience. Done correctly it stops your Arabic and English pages competing. Done incorrectly it is ignored, and roughly half of Arabic-language sites get it wrong.

Three rules cover most of the failures. Every page must reference all versions including itself. Every reference must be reciprocal, so if the English page points at the Arabic one, the Arabic one must point back. And you need an x-default pointing at whichever version a user with no matching language should land on.

The most common error is annotating a language version that does not exist. If you tag a page as ar-SA and serve English content at that URL, Google treats the annotation as untrustworthy. hreflang is a promise that a translated page exists there.

RTL is a design problem, not a CSS switch

Setting dir="rtl" flips your layout. It does not make it good. Arabic text sets at a different visual density from Latin text, needs different line lengths to stay readable, and has different conventions for emphasis, since Arabic has no capital letters and italics are not idiomatic.

The things that break most often in a mirrored layout are heading line breaks, button label widths, icon direction, and keyboard focus order. That last one is a genuine accessibility failure, not a cosmetic issue, and it is the one automated checks are most likely to miss.

  • Use logical CSS properties, margin-inline-start rather than margin-left, so layout follows direction automatically.
  • Choose an Arabic typeface deliberately. Do not let the browser pick a fallback.
  • Mirror directional icons such as arrows, but never mirror logos, photographs or numerals.
  • Test keyboard navigation in Arabic. Focus order is where mirrored layouts usually fail.

Translation is the smallest part of the job

Machine translation produces Arabic that is grammatically defensible and commercially useless. It reads as foreign, which in a brand-conscious market is actively damaging.

More importantly, keyword research does not translate. The Arabic phrase people actually search for is often not the direct translation of the English one, and dialect matters: Gulf Arabic search behaviour differs from Egyptian or Levantine. Do keyword research in Arabic, natively, rather than translating an English keyword list.

A practical build order

  • Decide the URL structure before design starts.
  • Do Arabic keyword research natively, not by translating the English list.
  • Design the Arabic layout as its own pass, sharing components but not assuming symmetry.
  • Have a native speaker write or properly adapt the copy, not translate it.
  • Implement hreflang reciprocally, including x-default.
  • Test keyboard navigation and screen reader behaviour in both directions.
  • Verify in Search Console that both versions are indexed and not competing.

Frequently asked questions

Should I use /ar/ subdirectories or a subdomain for Arabic?
Subdirectories, in almost all cases. They keep authority consolidated on one domain, are simpler to host and maintain, and are the option you are least likely to need to migrate away from later. Subdomains make sense mainly when the two sites are genuinely run by separate teams.
Can I point ar-SA hreflang at my English page?
No, and doing so is worse than omitting hreflang. The annotation is a promise that a translated page exists at that URL. Pointing an Arabic tag at English content makes your annotations untrustworthy, and Google will generally ignore them.
Is machine translation good enough for Arabic?
Not for anything customer-facing. Machine translation produces Arabic that reads as foreign, which damages a brand in a market this language-conscious. It also misses the point that Arabic keyword research is not a translation of English keyword research, since the phrases people actually search differ.
Does dir="rtl" handle Arabic layout for me?
It flips the layout, which is the starting point rather than the finish. Arabic needs its own typography, line lengths and spacing decisions. The things that break in a purely mirrored layout are heading breaks, button widths, icon direction and keyboard focus order.
How much does a bilingual website cost compared to a single-language one?
Meaningfully more, because it is genuinely more work: a second design pass, native copywriting, a second set of pages, and the hreflang implementation. It is not a translation surcharge. If budget forces a choice, build one language properly rather than two badly.

Book a free call with an expert

Share your ideas with us to activate the glow!

Get in touch
Get in touch