Most Saudi websites are designed in whichever language the team works in, and the other language is added near the end. That default produces the familiar result: an English site that works, and an Arabic version that is technically present but visibly second-class. The decision costs nothing at briefing stage. Made late, it costs a redesign.
The short answer: decide by audience, journey and buyer — not by your team's working language
Arabic-first means the architecture — information architecture, navigation, content design, forms and search — is designed around Arabic reading patterns first, with English engineered to the same standard. Arabic-added means an English architecture is built first and Arabic fitted in afterwards, usually as translation plus a mirrored stylesheet. Neither is automatically right. The answer follows three questions: who the primary audience is, which journeys carry the revenue, and who approves.
| Decision factor | Points to Arabic-first | Points to engineered Arabic-added |
|---|---|---|
| Primary audience | Saudi consumers or citizens working in Arabic | A mainly English-working professional audience |
| Revenue journeys | Arabic sign-up, checkout and support journeys carry the business | Arabic journeys are informational; conversion happens in English |
| Content shape | Long Arabic content, Arabic search behaviour, Arabic support | Short, stable content that translates cleanly |
| Buyer and approver | Saudi decision-makers who judge the Arabic version first | International stakeholders who approve in English |
Most rows in the first column: brief Arabic-first. Most in the second: English-first can be honest — if the Arabic version is engineered, not appended.
What "Arabic-added" actually ships: five compromises your customers can feel
When Arabic is fitted into an English architecture, the same five compromises recur. First, navigation: menus structured for short English labels overflow with longer Arabic wording, so items get renamed into something less clear. Second, content design: layouts sized for English paragraph lengths make Arabic pages look sparse in places and cramped in others. Third, forms inherit English logic — field order, name formats, address structure, error messages written for a different reader. Fourth, search is tuned for English terms while Arabic visitors search differently. Fifth, support journeys — help content, status pages, confirmations — are translated last and maintained worst, so the Arabic experience decays with every update. None of these is a translation error; each is an architecture decision made earlier, in English.
What Arabic-first changes: architecture, navigation and content design, not just direction
Arabic-first is often reduced to "RTL design", but direction is the smallest part of it. Setting dir="rtl" and mirroring a layout is a stylesheet task; the W3C and MDN documentation on bidirectional text shows how much behaviour — mixed-direction strings, numbers, embedded English terms — needs deliberate handling rather than blind flipping. What Arabic-first changes sits above that layer. Information architecture is planned in Arabic first: which sections exist, how deep they run, and what they are called. Navigation is designed for Arabic label lengths and right-to-left scanning. Content is designed, not translated: page structures and calls to action are written for Arabic, with English produced to the same standard, not treated as the original. Structure options sit in our multilingual website architecture guide.
The journeys that decide it: forms, search, checkout and support in Arabic
If the averages are unclear, audit four journeys. Forms: can an Arabic user complete your longest form without fighting field order, mixed-direction entries such as email addresses and phone numbers, or misplaced error messages? Search: does site search return useful results for the Arabic terms visitors actually type, including the product names they use? Completion: does every checkout or application step hold together in Arabic, or does the journey switch languages at the moment of commitment? Support: can an Arabic customer resolve a problem entirely in Arabic? A site that passes all four has been architected for Arabic; one that fails them has a translation, not an Arabic experience. Once the architecture is settled, execution mechanics are covered in our guide to bilingual website design in English and Arabic, and the working checks sit in the Arabic RTL website checklist.
When English-first with an engineered Arabic version is the honest right answer
Arabic-first is not a moral position, and some projects are honestly English-first. A B2B firm selling to procurement teams who work in English, where Arabic pages serve credibility rather than conversion, can build English-first — if the Arabic version is engineered to parity: same journeys, same maintenance, tested with Arabic users. A company preparing an English master site for several markets may architect once in English and localise properly per market. A short-lived campaign site may not justify a full Arabic-first architecture. What is never defensible is the unexamined middle: English-first by default, Arabic appended at the end, parity claimed but never specified or tested. The difference is not the order of the languages; it is whether the second language was engineered or merely added.
Sector answers: government-facing, consumer and B2B sites are not the same decision
Sector shifts the answer. Government-facing and semi-government suppliers should treat Arabic-first as the working assumption: the entities they sell to operate Arabic-first, and official digital-government guidance published by the Digital Government Authority sets the expectations their clients are measured against. That guidance binds government entities, not private design order — but a supplier whose Arabic site feels secondary is making a statement its buyers will notice. Consumer brands should also default to Arabic-first: purchase, support and trust signals all run in Arabic. B2B is the genuinely mixed case: industrial and technology firms often sell to English-working teams. How the two versions stay findable is a separate discipline, covered in our guide to SEO for bilingual Arabic and English websites.
The cost of deciding late: rework points in design, build and content
Deciding late does not add a translation line to the budget; it reopens finished work. In design, navigation and templates built around English must be reworked when Arabic labels and scanning order stop fitting — design time bought twice. In build, direction handling retrofitted onto components never designed for it produces a trail of one-off fixes. In content, pages approved in English must be re-edited, not just translated, when their structure does not survive the change — and approval rounds restart. None of this rework buys anything new; it pays to reach the quality the first decision would have produced: a second pass over design, build and content.
Brief it properly: what to demand in the proposal, whichever way you decide
Whichever architecture you choose, make the proposal prove it. Ask which language the information architecture and wireframes will be designed in, and in which language design reviews will happen. Require parity defined in writing: same journeys, same content depth, same maintenance commitment — not "Arabic version included". Require testing with Saudi users who are customers, not bilingual staff; staff testing certifies the team's knowledge, not the site's clarity. Ask how mixed-direction content — English product names, numbers, email and phone fields inside Arabic pages — is handled in the design system, not page by page. Settle the downstream decisions in the same brief: the Arabic voice is a separate choice, covered in our guide to MSA or Saudi dialect for a corporate website; build implications are in our overview of web development in Saudi Arabia.
Common mistakes: calling a mirrored build "bilingual"
The defining mistake is vocabulary: a mirrored build described as bilingual, as if flipping a layout were designing in two languages. Close behind: deciding the architecture by asking the team rather than the audience; approving designs only in English and seeing Arabic first at launch; testing the Arabic version with the bilingual project team; and budgeting translation as the only Arabic line item, leaving no time for Arabic design review or user testing.
FAQ
Does Arabic-first mean the English version matters less?
No. Arabic-first describes which language the architecture is designed around, not which language is allowed to be good. Parity is the standard: English is engineered to the same quality. A team that cannot resource both versions has a scoping problem, not a language-order solution.
Is RTL just a stylesheet change?
No. Mirroring is only the visible layer. W3C and MDN documentation on bidirectional text shows how much — mixed-direction strings, numbers, embedded English terms — needs deliberate handling. The larger part is above that layer: architecture, navigation, content lengths, form logic and search designed for Arabic readers from the start.
When is English-first acceptable for a Saudi company?
When the primary audience genuinely works in English — many B2B buying teams do — when Arabic journeys are informational rather than transactional, or when the site is one localisation of a wider English master. It is acceptable only if the Arabic version is engineered to parity and tested with Arabic users.
Can an existing English-first site be fixed without a rebuild?
Sometimes. If the structure is sound, navigation, templates, forms and search can be reworked for Arabic in a redesign programme. If the architecture fights Arabic at every step, fixes accumulate into redesign cost anyway. An audit of the four journeys in Arabic shows which case you are in.
Should we test the Arabic site with our own bilingual staff?
Not as the main test. Bilingual staff already know where everything lives, so they unconsciously compensate for unclear labels and awkward flows. Test with Saudi users who resemble your customers, give them real tasks in Arabic, and watch where they hesitate — that hesitation is the architecture talking.
Get the decision made before design starts (CTA)
If you are scoping a Saudi website, make this decision on paper before the first wireframe — primary audience, revenue journeys, buyer — then brief the architecture that follows. To work it through with us, start with our web design services for Saudi Arabia and bring your current site or your brief. See also how we work across the Kingdom on our Saudi Arabia page.
