Multilingual websites
Multilingual Website Design for Gulf Businesses: A Practical Guide
How to actually build an Arabic and English website that works for a Gulf audience — not a checklist of best practices, but the structural decisions that decide whether it ranks, reads properly and converts.
3
language codes, one site
en, ar and tr — the ISO codes a Gulf-facing WordPress site typically declares in its hreflang tags
1
URL per language, always
/, /ar/ and /tr/ — each a separate, indexable address, never one page swapped by a script
RTL
is a layout system
Arabic reads right to left — navigation, forms and icons have to mirror, not just the paragraph text
4–8 wks
to add a language properly
For an existing site of moderate size, once content strategy and hreflang mapping are agreed
What is on this page
Why word-for-word translation fails
The most common mistake in Gulf-facing multilingual projects is not a technical one. It is the assumption that an Arabic version of a site is the English version with the words swapped out. Hire a translator, run the copy through them, publish the result under /ar/, and call the project done.
That approach fails for a reason that has nothing to do with grammar. Search intent is not the same across languages, even for what looks like the same product or service. An English speaker researching “web design agency Dubai” is often comparing shortlisted suppliers late in a decision. The Arabic-speaking equivalent of that search frequently sits earlier in the journey, mixed in with broader questions about cost, process and credibility that an English searcher has usually already answered elsewhere. A page translated word for word answers the English question in Arabic words. It does not answer the question the Arabic searcher actually typed.
The same problem shows up in tone, proof and structure. A direct translation carries over whichever persuasion style the source language uses — hedged, formal, packed with adjectives, whatever it happens to be — regardless of whether that style reads as trustworthy or as stiff and foreign in the target language. Idioms translate literally and land oddly. Calls to action that work well in English can read as low-value or overly casual once translated directly into Arabic business writing, where formality and evidence of scale often carry more weight than urgency.
There is also a structural failure that direct translation cannot fix: keyword research done once, in one language, and then applied to both. Arabic and English keyword volumes, competition and phrasing do not map onto each other. A term that is high-volume and competitive in English can be a wide-open opportunity in Arabic, or the reverse. Building the Arabic site as a mirror of the English sitemap — same pages, same headings, same order — throws that opportunity away before the project starts.
None of this means translation has no place. Legal text, product specifications and anything where precision matters more than persuasion often should be translated closely, and reviewed by a native speaker rather than rewritten. The judgement call is knowing which pages are which. A homepage, a services page or a landing page written to rank and convert needs web design and copywriting treated as one connected job per language, not a design phase followed by a translation phase bolted on at the end.
Translation vs transcreation
Two different jobs get sold under the same word. Knowing which one a page actually needs saves both budget and embarrassment.
| Aspect | Direct translation | Transcreation (what we build) |
|---|---|---|
| Starting point | The English page, translated sentence by sentence | The Arabic reader's own question, researched separately |
| Keyword basis | English keywords, translated afterward | Arabic keyword research, done from scratch |
| Tone | Carries over the source language's style, whether it fits or not | Matched to how the target audience actually writes and reads |
| Calls to action | A literal rendering of the English phrase | Rewritten for what motivates that audience specifically |
| Numbers, dates, currency | Often left in the source format | Localised to the audience's own conventions |
| Who should review it | A translator working from the English draft | A native copywriter, briefed on the goal, not just the words |
Direct translation is faster and cheaper, and it is the right choice for legal pages, technical specifications and anything where precision outranks persuasion. For pages meant to rank and convert — homepages, service pages, landing pages — transcreation is the difference between a site that reads as native and one that reads as translated.
WPML, Polylang and the platform question
On WordPress, the platform decision is mostly a solved problem, and it is worth resolving early because it shapes how content gets structured everywhere else. WPML and Polylang are the two multilingual plugins most Gulf-facing WordPress sites end up choosing between, and both do the same fundamental job: they let a single post or page exist as several linked translations, each with its own URL, its own SEO fields and its own entry in the language switcher.
The meaningful differences are about depth and cost, not capability at a basic level. WPML is the more complete commercial option — it handles string translation inside themes and plugins, translates taxonomy terms and menus, and integrates with page builders and WooCommerce with less manual work. Polylang has a capable free tier and a lighter footprint, which suits a smaller site with fewer moving parts, though its paid version narrows the gap considerably. Neither is universally better; the right choice depends on the size of the site, the page builder in use and the budget for ongoing licensing.
What matters more than the plugin name is the structure decided before either one is installed. Every translated piece of content needs to be explicitly linked to its original through the plugin’s own relationship system — a translation that exists as a standalone post with no link back is invisible to the language switcher, and often invisible to hreflang tags too, which quietly breaks the SEO benefit of having a second language at all. Menus, widgets and any custom fields need a language attached to them individually; assuming a plugin will handle every element of a theme automatically is a reliable source of half-translated pages weeks after launch.
Outside WordPress, the same principle holds regardless of platform: a proper multilingual setup gives every language its own URL and its own metadata, linked to its siblings through structured data a search engine can read — not a cookie, a browser-language redirect, or a client-side script that swaps text after the page has already loaded. If a platform cannot do that natively, that is a real constraint worth knowing before committing to it, not after.
Hreflang tags and why every language needs its own URL
Hreflang is the mechanism search engines use to work out that /, /ar/ and /tr/ are the same page in different languages, rather than three separate pieces of duplicate content competing against each other. Get it right and a search engine shows the Arabic version to an Arabic searcher and the English version to an English one, even when both target a similar underlying query. Get it wrong, or skip it, and the versions cannibalise each other, or the wrong language shows up in the wrong market’s results.
The rule that trips up almost every DIY multilingual project: hreflang assumes each language has its own crawlable, indexable URL. A homepage with a dropdown that swaps the visible text via JavaScript, with no change to the address bar, has nothing for hreflang to point at. There is one URL, one piece of indexed content, and a menu that changes what a visitor sees after the page has already loaded — invisible to a search engine that never runs the click. This is the single most common structural mistake behind “we translated the site and nothing changed in Arabic search,” and it needs a rebuild, not a patch.
Done properly, every language version carries a set of hreflang links in its page head — pointing to itself and to every sibling version, plus a fallback (x-default) for visitors whose browser language matches none of the versions on the site. The links have to be reciprocal: if the English page links to the Arabic version, the Arabic version has to link back, or the relationship is not confirmed and a search engine may ignore it. This is precisely where hand-coded hreflang tends to drift out of sync — a new page gets added in English, its Arabic sibling gets the tag, and nobody remembers to add the return link. A multilingual plugin generates these automatically from the same relationship data that drives the language switcher, which is the main reason to use one instead of hand-rolling the mechanism.
None of this is optional polish. Google’s own documentation on localized versions treats correct hreflang as a prerequisite for serving the right language to the right audience, not a nice-to-have. Our SEO work on multilingual sites starts by auditing exactly this — the tag pairs, the reciprocity and whether x-default is set — before touching content at all.
How a search engine reads a multilingual site
Three separate, indexable URLs, each declaring itself and linking to its siblings — this is what a search engine needs to tell three language versions apart instead of flagging them as duplicates.
If a site’s current setup cannot produce this structure — three URLs, each with its own hreflang block — no amount of translated copy will fix the underlying SEO problem.
RTL is a layout problem, not a text-direction flag
Setting a right-to-left text direction on the page (see MDN’s reference on the dir attribute) is the easy five percent of building for Arabic. It flips the reading direction of the text. It does nothing to the parts of the interface that were designed assuming left-to-right, which is most of them.
A layout built for English reads left to right and top to bottom, and every convention follows from that: the logo sits top-left because that is where the eye lands first, the primary navigation runs left to right in reading order, a “next” arrow points right, a progress bar fills left to right, a breadcrumb trail reads home-first on the left. In Arabic, all of that mirrors. The logo moves to the top-right. Navigation order reverses. A “next” arrow that still points right now points backward against the reading direction, which is a small but real source of friction a visitor feels without necessarily being able to name it.
Icons are a common casualty. An arrow, a chevron in an accordion, a “back” icon shaped like a left-pointing caret — all of these carry directional meaning that inverts in RTL. A theme that only flips text and leaves the icon set untouched produces a page that reads right to left but points left to right, which is more disorienting than a page that never bothered with Arabic at all.
Typography needs its own decision, not an inherited one. Most Latin web fonts either lack Arabic glyphs entirely or ship a mismatched Arabic weight bolted on as an afterthought, and the difference is visible immediately to a native reader — thin, cramped letterforms, wrong line height, awkward spacing between joined characters. Arabic script also needs more vertical breathing room than Latin text at the same point size; line height that looks generous in English often reads as cramped in Arabic. The right approach is to choose a typeface with a genuine, purpose-built Arabic weight and set its line height and letter spacing independently of whatever was chosen for the English version.
Numerals are a smaller but frequent stumbling block. Two numeral systems are in active use across Arabic-speaking markets: Western Arabic numerals (the same digits used in English) and Eastern Arabic-Indic numerals, and convention varies by country and even by context within one country — a price on an e-commerce site and a date in a formal document do not always follow the same rule. The safer default across the Gulf is Western Arabic numerals for prices and interface elements, since that matches what most e-commerce and government sites already use, with the decision revisited if there is a specific reason a client’s audience expects otherwise.
The practical takeaway: RTL has to be part of the design phase, not a CSS pass applied after an English layout is finished. A page designed right-to-left from the first sketch and a page flipped afterward are visibly different pieces of work, and native readers notice the second one immediately.
Mirroring the interface for Arabic
The same layout, mirrored rather than merely flipped: logo, navigation order, alignment, buttons and reading flow all move together.
This is also where a theme that is simply “translated” tends to fall short — it renders Arabic text but keeps English-oriented spacing and icon direction, producing exactly the mismatch native readers notice first.
Currency and number formatting per audience
A price is not just a number with a currency symbol attached. It is a small piece of localisation that either matches what a reader expects to see, or quietly signals that the page was not really built for them.
The Gulf is not one currency market. A price shown to a Dubai or Abu Dhabi audience reads naturally in AED. The same offer shown to Riyadh or Jeddah needs SAR, not a converted AED figure with a note in brackets. Doha expects QAR, and Kuwait City expects KWD — which also happens to be a three-decimal currency, unlike the other three, a detail that trips up number-formatting logic borrowed from a single-currency site.
Formatting conventions layer on top of the currency itself. Thousand separators and decimal points are not universal — some locales use a comma where others use a period, and reversing them silently turns a price into a different number to anyone reading quickly. Dates carry the same risk in the other direction: a purely numeric date is read in different orders by different conventions, and a multilingual site that renders the same numeric date format across every language guarantees it is ambiguous for at least one audience. Spelling the month, or using an unambiguous format, avoids the problem entirely.
Phone numbers and WhatsApp links deserve the same care as currency. A number formatted with a country code, spacing and a working click-to-chat link for one market does not automatically work for another if area codes or preferred contact conventions differ — and WhatsApp is frequently the primary contact channel across Gulf markets, not a fallback under a contact form.
None of this is difficult once it is decided. What causes problems is deciding it once, for one market, and then reusing the same formatting logic everywhere on the assumption that a currency-symbol swap is the whole job.
What actually changes per language: a working checklist
The elements that need a deliberate, per-language decision, not a global default reused everywhere.
| Element | English (root) | Arabic | Why it is not just a swap |
|---|---|---|---|
| Reading direction | Left to right | Right to left | Layout mirrors, not just the text |
| Numerals | Western Arabic (0-9) | Western Arabic, by Gulf convention | Confirm per audience; Eastern Arabic-Indic exists too |
| Currency & price format | Shown in the site's base currency | Localised per market: AED, SAR, QAR, KWD | A converted figure reads as foreign |
| Date format | Month spelled or unambiguous order | Same principle, Arabic month names | A numeric-only date is ambiguous across locales |
| Typography | Latin typeface, Latin metrics | Arabic-specific weight, adjusted line height | Bolted-on Arabic glyphs read as cramped |
| Icons & directional UI | Arrows and chevrons point with reading flow | Mirrored to point the other way | Un-mirrored icons contradict the text direction |
| Keyword basis | English keyword research | Separate Arabic keyword research | Search intent and volume differ by language |
| Trust signals & proof | Whatever reads as credible in English | Locally relevant proof, not a literal translation | Persuasion style is cultural, not just linguistic |
Where multilingual SEO actually breaks
These are common, well-documented failure modes on multilingual sites generally — not a claim about any one project — worth checking for on any site before assuming the multilingual setup is working.
| Failure mode | What it looks like in practice | The fix |
|---|---|---|
| Duplicate content across languages | Two URLs serving near-identical text because a page was "translated" by only swapping a few words, or a misconfiguration serves the same content under two language URLs | Confirm each language URL is genuinely distinct content, tagged with its own hreflang pair, not a copy with a language flag changed |
| Hreflang loops | Page A points to Page B as its Arabic version, but Page B's tag points somewhere else entirely — often an old or deleted URL — so the relationship never confirms | Audit hreflang pairs in the page source after every content change, not just at launch; a pair that is not reciprocal is as good as missing |
| Redirect chains | A URL redirects to a second URL, which redirects to a third, often left behind after a slug rename or a language-structure change | Point every redirect straight at its final destination; a chain of two or more hops wastes crawl budget and can drop hreflang signals along the way |
| Forced browser-language redirects | Every visitor is redirected to a language guessed from their browser or IP, with no way to reach the other version by URL | Detect and suggest, never force; keep every language URL directly reachable, including by crawlers that carry no preferred-language header |
| Missing or incorrect x-default | No fallback is set for a visitor whose language matches none of the site's versions, or x-default points at the wrong one | Set x-default deliberately, usually the root or English version, rather than leaving it unset |
| Thin machine-translated pages | A second language exists mainly to tick a box: short, generic, obviously translated rather than written, with none of the depth or internal linking of the original | Treat each language as a full content project, not an export job, especially for the pages meant to rank |
Adding a second language to an existing site: a realistic process
01
Discovery and content audit
Map what exists on the current site, which pages actually deserve a second language, and which languages the audience data supports. Not every page is worth translating — a thin page multiplied across languages is still a thin page.
02
Content strategy per language
Separate keyword research for each language, decided before any writing starts. Some pages need a different structure in Arabic than in English, not just different words on the same template.
03
RTL and typography
Layout, navigation and iconography mirrored for Arabic; typography chosen and set specifically for the script, not inherited from the English theme.
04
Technical hreflang setup
Each language on its own URL, reciprocal hreflang tags generated from the same relationship data as the language switcher, and an x-default fallback set deliberately.
05
QA across languages and devices
Every page checked in every language on real devices — layout, links, forms and contact flows — because a bug that only shows up in the Arabic mobile menu is still a bug.
06
Launch and monitoring
Redirects mapped and tested if URLs changed, search console properties confirmed for each language, and indexing watched for the following weeks rather than assumed.
“A language switcher is not a multilingual website. It is a button. The website is what happens after someone clicks it.”
What this looks like in practice
This is not a theoretical checklist for us. Filweb designs, builds and writes its own trilingual property platform — a real estate content site selling property to English, Arabic and Persian-speaking buyers across 148 published articles — and every decision described above is one we made, and in places got wrong before fixing, on that project ourselves. We will not re-run the numbers here; the full breakdown lives on its own case study page.
What is worth saying here is narrower: this guide reads as practical rather than theoretical because we maintain a multilingual site of our own, in three languages across two different reading directions, and deal with the hreflang, RTL and content-strategy questions above on a working codebase, not a slide deck. Examples of that and other work sit in our portfolio.
Further reading
If you are weighing up a multilingual project:
- Web design — how we approach a build from structure through to launch
- SEO services — how Arabic and English search are handled as separate work
- Our multilingual case study — a working example of everything on this page
- Published pricing — what a bilingual or trilingual build costs
- More from the blog — further reading on web design and SEO for Gulf-facing businesses
Frequently asked questions
What is the difference between translating a website and localising it?
Translation converts words from one language to another. Localisation goes further: it adjusts search intent, tone, currency, numerals and layout direction, and sometimes which pages exist at all, so the result reads as written for that audience rather than converted for them.
Do I need a separate URL for each language, or can I use a language switcher with hidden text?
A separate, indexable URL for each language, such as /, /ar/ and /tr/, is required for a search engine to treat the versions as distinct, correctly targeted pages. A switcher that swaps visible text on one URL without changing the address has nothing for hreflang to point at, and search engines generally cannot index content that only appears after a script runs client-side.
What is hreflang and why does it matter?
Hreflang is an HTML attribute that tells search engines which URL serves which language and region, and that several URLs are translations of the same page rather than duplicate or competing content. Without it, language versions can cannibalise each other in search results, or the wrong language can show up in the wrong market.
Should I use WPML, Polylang, or something else for a WordPress multilingual site?
Both are capable options and neither is universally better. WPML handles theme and plugin string translation and page-builder integration with less manual setup; Polylang has a lighter footprint and a workable free tier. The right choice depends on site size, the page builder in use and the ongoing licensing budget; the structural principles in this guide apply to either.
Is Arabic just English written right-to-left?
No. Reading direction is the most visible difference, but Arabic also needs its own typeface choice, its own line-height and spacing decisions, a mirrored interface layout, and separate keyword research. Treating it as English with the direction flipped is where most DIY multilingual sites go wrong.
Do I need to redesign my layout for Arabic, or just flip the text direction?
Layout has to mirror, not just the text. Logo placement, navigation order, icon direction, button alignment and reading flow all reverse in a genuinely right-to-left design. Setting a right-to-left attribute on the page flips paragraph text; it does nothing to the rest of the interface.
Should numbers and dates also change for an Arabic audience?
Numerals, date formats and currency all need a deliberate decision rather than defaulting to whatever the English version uses. Western Arabic numerals are the safer default across most Gulf e-commerce and government sites, but the convention should be confirmed per audience rather than assumed.
Which currency should a UAE-facing multilingual site display?
AED for a UAE audience, shown natively rather than as a converted figure from another currency. The same principle applies across the Gulf: SAR for Saudi Arabia, QAR for Qatar, KWD for Kuwait, each with its own formatting conventions, including Kuwait’s three-decimal currency.
Do I need Turkish on a Gulf-facing website?
Only if a meaningful share of the actual audience searches or reads in Turkish, such as a Gulf business with Turkish suppliers, partners or a Turkish-speaking customer base. Adding a language nobody in the audience needs dilutes the effort that should go into the languages they do use.
What causes duplicate content issues on multilingual sites?
Most often, a page that was translated by swapping only a handful of words, leaving the bulk of the content near-identical to another language version, or a technical misconfiguration that serves the same content under two different language URLs without distinguishing them through hreflang.
What is a hreflang loop and how does it happen?
It happens when Page A’s hreflang tag points to Page B as its translation, but Page B’s tag points somewhere else, often an old or deleted URL, so the relationship between the two pages never confirms. It is usually the result of a page being renamed, merged or deleted without updating its sibling’s hreflang reference.
How long does it take to add a second language to an existing website?
For a site of moderate size, four to eight weeks is typical once content strategy and hreflang mapping are agreed. Content and translation review usually set the pace more than the technical build itself.
Can I just use a browser translation widget instead of proper localisation?
A browser-based translation tool can help a visitor understand a page in a pinch, but it does not create indexable, hreflang-tagged URLs in the target language, does not adjust the layout for RTL, and does not involve separate keyword research, so it provides none of the SEO or usability benefit a genuine second language version does.
Does adding Arabic hurt my existing English SEO?
Not if it is implemented correctly, with each language on its own URL and proper hreflang linking them together. Done wrong, with duplicate content, missing hreflang or forced redirects, it can create competition between the two versions, which is a configuration problem rather than an inherent risk of going multilingual.
Building or rebuilding for the Gulf market?
If you would rather have the hreflang setup, RTL layout and Arabic content strategy handled properly from the start, see our web design service — or tell us about your site and we will look at what a second language actually needs.