What is Arabic English website design, and who needs it in Saudi Arabia?
Arabic English website design is building one site that works natively in both languages: Arabic flowing right to left with its own typography, English flowing left to right, and each language treated as a first-class version rather than a copy. The visitor should never feel they are on the “other” language's site.
In the Kingdom, most businesses that sell to the public, supply government or large companies, or recruit staff will need both. Consumers often search and read in Arabic, procurement teams and international partners frequently work in English, and staff from many countries use whichever they read best. A company that shows only one language turns one of those groups away.
A bilingual site is not automatically a good one. The common failure is an English site where the Arabic version has the words swapped but the layout still reads left to right, icons point the wrong way, numbers break in the middle of sentences, and search engines see only one language. This guide is about avoiding that.
- Consumer brands, clinics, restaurants and retailers: Arabic first, English second
- B2B suppliers and contractors: often English first for tenders, Arabic for local buyers
- Recruiters, schools and training providers: both, with forms in both
- Companies with regional HQs in Riyadh: both, often with more pages in English
Bilingual vs translated: how to judge Arabic English website design on any site
Open the Arabic version of a site and check five things: is the whole page right to left, including navigation and forms; does the URL change when you switch language; does the switcher keep you on the same page; do icons such as arrows point the right way; and do numbers and dates look deliberate. A translated site fails at least two of these.
The underlying difference is where the language lives. On a translated site, language is a layer painted over English templates. On a bilingual site, it is part of the data model: every page has fields for both languages, every template knows the direction it is rendering, and every URL belongs to one language.
This matters beyond looks. When the Arabic page is a real page with its own address and title, search engines can index it and show it to Arabic searchers, and visitors can share it. When it is a cookie-driven overlay, it often does not exist as far as Google is concerned.
How RTL works: the dir attribute and CSS logical properties
Correct RTL starts in the HTML, not the CSS. The W3C's internationalisation guidance says to add dir="rtl" to the html element whenever the overall document direction is right to left, alongside a lang attribute, and to keep direction in markup because it affects meaning, not just appearance. See the W3C article on structural markup and right-to-left text.
Then comes layout. Old RTL work meant writing a second stylesheet that swapped every left for right. Modern CSS offers logical properties: margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, inset-inline-start instead of left, and text-align: start instead of left. Written that way, a single stylesheet renders correctly in both directions, because “start” means left in English and right in Arabic.
We write all templates with logical properties from the first component, use flexbox and grid (which already follow the document direction), and keep a short list of genuine exceptions: things that must not flip, such as a phone number, a media player's progress bar, a clock or a brand logo.
- html lang='ar' dir='rtl' on Arabic pages; lang='en' dir='ltr' on English
- Logical properties for margins, padding, borders and positions
- Directional icons (arrows, chevrons) mirrored; non-directional ones left alone
- dir='auto' on fields where users may type either language
Mixed Arabic and English text: brand names, numbers and user input
Arabic pages in Saudi Arabia are full of Latin text: brand names, product codes, email addresses, URLs and prices. The browser's bidirectional algorithm places these runs automatically, but punctuation next to them often lands on the wrong side, and a phone number can appear reversed in groups.
The fixes are small and specific. Wrap embedded opposite-direction runs in their own elements with the right dir or use bdi for user-supplied names, set phone and account numbers to display left to right, and check that parentheses and full stops sit where an Arabic reader expects them. W3C also recommends dir="auto" for content whose direction is unknown in advance, such as form input or text from a database.
Forms deserve a full test pass in Arabic. Placeholder text, error messages, the position of icons inside inputs, and date pickers are all places where a half-finished RTL build shows. We test each form in both languages on an iPhone and an Android phone before launch, because that is where most Saudi visitors will fill them in.
Arabic fonts in Arabic English website design: looking right and loading fast
Choose one Arabic family and one Latin family that sit well together, load only the weights you use, and serve the Arabic font only on pages that need it. Arabic fonts carry many more glyph shapes than Latin ones, so an unplanned choice is often the largest file on the page.
Google Fonts offers several well-drawn Arabic families, including IBM Plex Sans Arabic, Noto Kufi Arabic, Noto Naskh Arabic, Tajawal and Cairo, and serves them split into character-range subsets so a browser downloads only what a page needs. We usually self-host the chosen files, preload the one weight used above the fold, and set font-display so text appears immediately in a fallback while the web font loads.
Line height and size need their own values for Arabic. Arabic script has taller ascenders and descenders and many readers find it more comfortable a little larger than the Latin text beside it. We set separate typographic scales per language in the design tokens, so headings do not clip and body text stays readable without anyone hand-tuning each page.
Kufi-style families
Geometric and modern; good for headings, navigation and brands that want a clean corporate look.
Naskh-style families
Closer to printed book text; comfortable for long Arabic paragraphs such as policies and articles.
Separate URLs and hreflang for Arabic and English pages
Give every page two addresses, one per language, and tell search engines they are equivalents. Google's guidance on multi-regional and multilingual sites recommends different URLs for each language version rather than cookies or browser settings, and advises against automatically redirecting visitors to a language based on guesses.
The usual pattern is subfolders: example.sa/ar/ and example.sa/en/, or Arabic at the root and English under /en/. Each page then carries hreflang annotations listing itself and its twin, for example ar-SA and en-SA, plus an x-default for everything else. Google's documentation stresses that each version must list itself as well as the other versions, otherwise the annotations may be ignored.
Google also says it determines a page's language from its content, not from the lang attribute or hreflang. So the Arabic page must have genuinely Arabic main content, titles and descriptions. An Arabic URL showing mostly English is treated as English, however the tags are set.
- One URL per language per page; no cookie-only switching
- hreflang on every page, pointing both ways, with x-default
- Separate title, meta description and headings per language
- Both versions listed in the XML sitemap
- Language switcher links to the equivalent page, not the home page
Arabic-Indic or Western digits, and Hijri or Gregorian dates?
Decide this per context, not once for the whole site. Many Saudi sites use Western digits (0–9) in both languages for prices, phone numbers and product codes, and some prefer Arabic-Indic digits (٠–٩) in Arabic body text. Neither is wrong; what matters is consistency within each context.
Browsers can do the conversion for you. JavaScript's Intl API supports the “arab” numbering system for Arabic-Indic digits and the “islamic-umalqura” calendar, which MDN describes as the Hijri Umm al-Qura calendar using KACST-calculated months. A locale such as ar-SA with that calendar formats a date as a Hijri date without any hand-written conversion tables.
Show Hijri dates where your audience expects them: events tied to Ramadan or Hajj season, government-related deadlines, or content aimed at an older audience. Show Gregorian where business partners and systems use it: invoices, delivery dates and international events. Many sites show both on event pages. Store dates in one standard format in the database and format them at display time, so a change of preference is a setting, not a data migration.
Who writes the Arabic copy on an Arabic English website?
You do, or a translator or copywriter you choose; we build and check how it sits in the page. The team writes English, so we are clear from the start that native Arabic copywriting is not part of our work, and we plan the project so your Arabic writer is never waiting on us.
The smoothest projects start with a copy sheet: every page, every heading, every button label and every error message, with columns for English and Arabic. Your writer fills the Arabic column while we build templates with placeholders. Once the copy lands, we import it and send you both versions on a staging link to review in the real layout, which is when awkward line breaks and overlong buttons show up.
Machine translation can help your writer draft, but it should not go live unedited. Arabic readers notice immediately, and a clumsy Arabic page does more damage to trust than a missing one. If budget is tight, launch fewer pages in excellent Arabic rather than every page in weak Arabic.
What we do with Arabic text
Import it, check it renders and wraps correctly, match headings and lengths to the layout, and flag strings that look machine-generated or truncated.
What we do not do
Write or certify Arabic copy, or judge legal wording. Your writer and, where needed, your lawyer own that.
Arabic English website design choices: layout, imagery and navigation
Design both languages at the same time, with the Arabic layout drawn first for Arabic-first audiences. Designing only in English and flipping at the end produces pages where visual weight, image crops and reading order feel wrong in Arabic.
Images with a direction need attention. A person looking or pointing to the right draws an English reader into the text; in Arabic the same image points away from it. Either choose images that work both ways or crop per language. Screenshots and diagrams with embedded text need Arabic versions.
Navigation labels are often longer in one language than the other, so menus need room to breathe. Buttons should size to their content rather than a fixed width. And the language switcher belongs in a predictable place, written in the target language (“العربية” and “English”), never as a flag, because a flag stands for a country, not a language.
Which platform suits a bilingual Arabic and English site?
For content sites, a static site generator or a lean CMS with first-class multilingual fields gives the cleanest result: each page has Arabic and English fields, templates render both, and URLs are generated per language. For editors who want WordPress, a multilingual plugin that creates separate language URLs works well with a theme built for RTL.
For stores, check the platform's Arabic support before choosing it. Hosted Saudi store platforms handle Arabic well out of the box; international platforms vary theme by theme. Custom stores built on a modern framework give full control but need the same RTL discipline as any other template.
Whatever the platform, the non-negotiables are the same: language in the data model, direction in the markup, logical CSS, per-language URLs and metadata, and a staging site where both versions can be reviewed together before anything goes live.
- Static generator or headless CMS: fastest pages, clean bilingual fields
- WordPress with a multilingual plugin: familiar editing, from US$150
- Store platform or custom store: check Arabic theme quality first, from US$750
- Portal or web app: per-user language and direction, from US$900
Arabic pages are often slower than their English twins, and the cause is nearly always fonts and images rather than the language itself. Measure both versions separately in PageSpeed Insights and Search Console's Core Web Vitals report; a site can pass in English and fail in Arabic.
The fixes: subset and self-host the Arabic font, load only the weights used, preload the one needed for the first screen, and avoid loading the Arabic font on English pages at all. Serve images in modern formats with sizes set, so the page does not jump when they arrive, which matters more in RTL where late-loading elements can shift text sideways.
Sliders, animation libraries and translation widgets are the other usual suspects. Each adds script that runs on every visit. A bilingual site built with plain templates and a little JavaScript for the menu and forms is usually fast in both languages without special tuning.
Arabic and English SEO on one site, and visibility in AI search
Treat the two languages as two keyword sets, not one set translated. Saudi searchers often type Arabic queries for local services and English ones for technical or international products, and the Arabic phrasing that people actually use is rarely a literal translation of the English term.
Each language needs its own titles, descriptions, headings and internal links, researched in that language. Your Arabic writer should see the target Arabic phrases before writing, not after. Google Search Console shows queries in both languages once the site is live, which is the best guide to what to write next.
AI search tools quote short, self-contained answers. Pages that open with a clear one-sentence answer, use question headings and state facts with their source tend to be cited more readily, in either language. Structured data for your business, services and FAQs should exist in both versions. Nobody can guarantee rankings or AI citations, but a bilingual structure is the precondition for appearing in Arabic results at all. For ongoing work see SEO services in Saudi Arabia.
Adding Arabic to an existing English website: retrofit or rebuild?
Retrofit when the existing site is modern, well structured and small enough to audit quickly; rebuild when the CSS is full of left and right values, the content lives in page builders, or the platform cannot give each language its own URL.
A retrofit follows a set order: add language fields to the content model, generate Arabic URLs, set dir and lang per page, convert the stylesheet to logical properties, add the Arabic font, fix components one by one, then add hreflang and sitemaps. Each step can be tested on staging while the English site stays live.
We start any retrofit with a short audit that estimates both routes. If converting the old theme would cost close to a new build and leave you with a weaker result, we say so. For sites already on WordPress, our WordPress website design page explains the lean rebuild route.
Arabic English website design launch checklist
Run through this list on staging with both languages open side by side, on a phone as well as a laptop. Anything unticked is a reason to wait a day rather than launch.
- Every Arabic page has lang='ar' and dir='rtl'; every English page lang='en' and dir='ltr'
- No physical left or right values left in component CSS, except the documented exceptions
- Language switcher lands on the equivalent page in the other language
- hreflang pairs and x-default present and pointing both ways
- Separate titles and descriptions per language; sitemap lists both
- Arabic font subset, preloaded and absent from English pages
- Forms, errors and emails tested in both languages
- Dates and digits consistent per context; Hijri shown where agreed
- Arabic copy approved by your writer on the real layout
- Core Web Vitals checked for both language versions
If personal data is collected through the forms, align consent wording and privacy pages in both languages; our PDPL compliance for websites page covers the technical side, with legal sign-off from your own counsel.
Working with a team in India on a bilingual Saudi website
India is 2.5 hours ahead of Saudi Arabia, so a call at 10 am in Riyadh is 12:30 pm for us, and your Sunday–Thursday week overlaps with our working days on four days. Most coordination happens on WhatsApp, with a short call at each milestone.
Because Arabic copy comes from your side, the calendar is shared: we build templates while your writer works on the copy sheet, and the project moves as fast as the slower of the two. We give you the copy sheet in the first week so nobody waits.
You own everything from the first day. The domain, whether a .sa domain registered through a licensed registrar as SaudiNIC requires or a generic one, the hosting account and the code repository are all in your business's name. Quotes are in US dollars and you pay by Wise, bank wire or PayPal against written milestones, with invoices issued from India.
Week 1
Kick-off call, sitemap in both languages, the copy sheet, and your choice of Arabic and Latin fonts from two or three options.
Week 2
Page templates on staging in both directions with placeholder copy, so you see the RTL layout on your own phone before any Arabic text arrives.
Worked example: a hypothetical Riyadh engineering consultancy going bilingual
Consider an engineering consultancy in Riyadh, invented for this example, with a twelve-page English site built years ago. Tender teams read it in English, but local clients and job applicants keep asking for Arabic, and the Arabic version produced by a plugin shows left-aligned headings and reversed phone numbers.
The audit finds hard-coded left and right values throughout the theme and no separate language URLs, so a rebuild is cheaper than a retrofit. The new site uses Arabic at /ar/ and English at /en/, one set of templates written with logical properties, a Kufi-style Arabic heading font paired with a neutral Latin sans, and hreflang across all pages.
The consultancy's own bilingual office manager fills the copy sheet, with a freelance translator checking the technical terms. Project dates on case pages show Gregorian; the careers page shows both calendars for application deadlines. Before launch, both versions are measured separately for Core Web Vitals. This is a representative scenario, not a report on a real client.