How to build an Arabic website: RTL, fonts, SEO and content
Building an Arabic or bilingual website properly: right-to-left layout, Arabic fonts, URL structure, hreflang, number formatting and translation.
By Sohail Hussain29 October 20267 min read
An Arabic website is built properly when the layout is designed for right-to-left reading rather than mirrored at the end, the Arabic typeface is chosen with the same care as the Latin one, each language lives at its own URL with hreflang tags linking the versions, and the Arabic content is written or reviewed by a native speaker. Miss any of those and the site reads as an English site with Arabic text pushed into it, which is how most bilingual business sites in the Gulf still look.
This guide covers the six parts in order: direction and layout, typography, URL structure, search setup, content details such as numbers and dates, and the workflow that keeps both languages in step. It is the process behind our Arabic and multilingual websites service, and it applies whether the site is built on Next.js, WordPress or anything else.
How do you make a layout work right to left?
Start with two attributes on the document. The lang attribute tells browsers, screen readers and search engines the language; the dir attribute sets the base direction for the whole page.
<html lang="ar" dir="rtl">
The W3C's note on structural markup and right-to-left text explains why dir belongs in the HTML and not in CSS: the browser's bidirectional algorithm needs it before any style loads, and it must survive when styles fail.
With dir="rtl" set, text, tables and lists flip on their own. Layout does not, unless the CSS was written with logical properties. margin-left stays on the left; margin-inline-start moves to the right in an RTL page. The rule for a bilingual build is simple: never use left or right in CSS for anything that should mirror. Use inline-start and inline-end, text-align: start, and flex or grid, which mirror automatically.
Things that should mirror: navigation order, breadcrumbs, back and forward arrows, progress indicators, sliders, the position of icons next to labels, form label alignment and the reading order of cards. Things that should not: logos, phone numbers, email addresses, media controls, and images that show a real-world direction such as a map. RTL web design: the rules that matter goes through each with examples.
The practical consequence is that a site built from the start with logical properties supports Arabic almost for free, and a site built with left and right values needs its stylesheets reworked before Arabic can be added. That is the audit question when a client asks to add Arabic to an existing site; see adding a second language to an existing site.
Which Arabic fonts should you use?
Arabic typography is the part most often done badly, because the English designer chose a Latin typeface and someone later picked whatever Arabic font was available. Arabic letters join, change shape by position, and sit on a different baseline rhythm; a font that matches the Latin face in weight, x-height feel and tone has to be chosen deliberately.
As of October 2026, the families we return to most are the Google-hosted open ones, because they are free to use commercially, well hinted and cover the Arabic script fully:
| Font | Character | Pairs well with |
|---|---|---|
| IBM Plex Sans Arabic | Clean, corporate, even weights | IBM Plex Sans, Inter |
| Noto Sans Arabic or Noto Naskh Arabic | Neutral, complete coverage, reliable | Noto Sans, most Latin sans faces |
| Cairo | Modern, geometric, friendly | Montserrat, Poppins |
| Tajawal | Light, rounded, popular in the Gulf | Rubik, Nunito |
| Amiri | Traditional naskh, good for long reading | Serif faces such as Source Serif |
Set the Arabic body size slightly larger than the Latin size, usually by 5 to 15 percent, because Arabic glyphs read smaller at the same nominal size. Increase line height too. Load only the Arabic subset for Arabic pages. Best Arabic web fonts covers pairing in detail, and Arabic typography mistakes lists what we see most on business sites: stretched letterforms, wrong fonts for headings, and Arabic text set in a Latin fallback because the font failed to load.
One technical check worth doing: paste any Arabic copy you receive into the Unicode character inspector. Text copied from PDFs or old systems often contains presentation-form characters, stray directional marks or tatweel characters that render correctly in one browser and break in another. Clean text uses the standard Arabic block only.
How should the URLs be structured?
Each language needs its own URL. Switching language with a cookie or a JavaScript toggle at the same URL means search engines see one version and visitors cannot share a link to the other.
| Structure | Example | When to use |
|---|---|---|
| Subfolder | example.com/ar/services | Almost always. One domain, one authority, simplest hosting |
| Subdomain | ar.example.com | When the Arabic site is run separately, on different infrastructure |
| Separate domain | example.sa | A separate business in a separate country with its own marketing |
| Query parameter | example.com/services?lang=ar | Never for a public site |
We default to subfolders. The full argument is in subdomain vs subfolder vs ccTLD. Translate the slugs as well as the pages: /ar/خدماتنا or at least /ar/services, not /ar/page-2. Arabic slugs are valid and search engines handle them; they are harder to type and share, so many Gulf sites keep English slugs under /ar/. Both work.
Put the language switcher in the header on every page, and make it link to the same page in the other language, not to the other homepage. Language switcher design covers the patterns.
What does Arabic SEO need beyond translation?
Three things, all mechanical.
Hreflang tags, so Google shows the Arabic page to Arabic searchers and the English page to English searchers rather than treating them as duplicates. Every page lists every language version of itself, including itself, plus an x-default:
<link rel="alternate" hreflang="en" href="https://example.com/services" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/services" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services" />
The hreflang generator produces these for a set of URLs, and hreflang explained covers the regional variants (ar-AE, ar-SA) and when they are worth using. Google's own reference is the page on localized versions.
Translated metadata. Title, description and Open Graph text in Arabic, written for Arabic search terms rather than translated word for word from the English. People search differently in Arabic, with more variation in spelling and word order; Arabic SEO explains the differences.
A sitemap per language, or one sitemap with both sets of URLs. Either is fine; what matters is that every Arabic URL is listed.
What details does Arabic content need?
The page direction is the start. The content inside has its own rules.
Numbers. Arabic-script sites in the Gulf mostly use Western Arabic digits (0 to 9), while some audiences expect Eastern Arabic digits (٠ to ٩). Pick one per site and apply it everywhere, including prices and dates. Phone numbers always stay left to right. Numbers, dates and currency in Arabic interfaces has the formatting details and the Intl settings that produce them.
Mixed-direction text. An English product name or email address inside an Arabic sentence needs isolation so punctuation does not jump. Use the bdi element or unicode-bidi: isolate around embedded Latin text.
Forms. Labels, placeholders, validation messages, confirmation emails and the thank-you page all need translation. Forms are where half-finished bilingual sites show themselves.
Dates. The Gregorian calendar is standard for business in the UAE; Saudi Arabia uses both Gregorian and Hijri in official contexts. Ask the client which the site should show.
How do you keep two languages in sync?
Languages drift. A new page is added in English in March; the Arabic version is "coming". By September there are nine untranslated pages and the Arabic site looks abandoned.
The fix is process, not tools. Every content change creates a translation task before it is published, and the CMS shows which pages are missing a language. In WordPress, the translation plugins do this with varying grace; WPML vs Polylang vs TranslatePress compares them. In Next.js with a headless CMS, documents are modelled per language and the editor shows the gaps; building a multilingual Next.js site is the technical guide.
On translation itself: use a professional translator or a native-speaking member of the client's team, and have someone other than the translator review it. Machine translation is a reasonable first draft for internal review and a poor final copy; machine vs human translation sets out where each is acceptable.
If the site is for the UAE market specifically, there are expectations about which language leads, how addresses are written and what the footer must contain; bilingual websites in the UAE covers them. The build order we recommend for a new bilingual site is English and Arabic designed together from the first wireframe, launched together, and maintained by one process. Adding Arabic later is possible, and always costs more than building it in.
Was this guide useful?