Most UAE search strategies are built in English and then translated. It is an understandable shortcut and it quietly throws away half the market, because Arabic and English are not two renderings of the same search. They are two different sets of queries, with different wording, different intent and, very often, a different set of competitors ranking against you.
The same product, two different questions
Start with how people actually type. An English query in the UAE tends to look the way English queries look anywhere: short, keyword-shaped, often naming a place. Arabic queries behave differently. Arabic is a richer morphological language, so one idea can be written several ways depending on prefixes, suffixes and whether the writer uses formal Modern Standard Arabic or something closer to Gulf dialect. A single English keyword can correspond to half a dozen legitimate Arabic variants, none of which is a translation of the others.
Then there is the question of which language people reach for at all. It is not a clean split by nationality. Plenty of Arabic speakers search in English for technical, professional and product terms because that is the language the industry uses, and then switch to Arabic for anything involving family, home, health or money. The same person will use both within a day, depending on what they are asking.
This is why a translated keyword list underperforms. It carries across the English framing of the question rather than the question an Arabic speaker would have asked, and it misses the variants entirely.
Research Arabic separately, not afterwards
Treat Arabic as its own research project with its own seed terms. In practice that means:
- Start from Arabic sources. Arabic-language competitors, forums, and the questions that appear in Arabic autocomplete and related searches. Not from your English list run through a tool.
- Collect the variants. For each concept, gather the forms people actually write, including the definite article where it is used and the common spellings with and without diacritics. Group them, then decide which form the page targets.
- Check the SERP, not just the volume. An Arabic term with respectable volume may return results that answer a different intent entirely. The only reliable way to know is to look at what currently ranks.
- Expect a different competitive set. Regional publishers, aggregators and government portals often occupy Arabic results where international brands dominate the English ones. Your realistic target position is not the same in both languages.
Two keyword maps, two sets of priorities. They will overlap, but the overlap is smaller than most teams assume before they do the work.
Two languages, two pages, told properly
Once you have two keyword sets, you need two sets of pages, and the site has to tell a search engine how they relate.
The standard mechanism is hreflang. Each page declares its own language and region and points at its counterpart, and the counterpart points back. Done correctly it tells Google that these are alternates of one another rather than competing duplicates, and lets it serve whichever matches the searcher.
Three things go wrong with it more often than anything else:
- The return tag is missing. If the English page points at the Arabic one but not the other way round, the pairing is ignored. Both sides have to declare it.
- The alternate does not exist. Announcing a page that returns a 404 is worse than announcing nothing. If a section exists in one language only, say so by having the page reference only itself.
- The region is wrong.
arandar-AEare different declarations. Decide whether you are targeting Arabic speakers generally or Arabic speakers in the UAE, and be consistent across the site.
Choose a URL structure and stay with it. A subfolder per language is the easiest to manage, keeps all the authority on one domain, and is the easiest to get right. Whatever you pick, the rule is that a language version has a stable address of its own. Swapping content at the same URL based on a browser setting is the one approach that reliably prevents either version from ranking.
Translated is not the same as written
The content itself is where most bilingual sites lose. Translated copy reads as translated, and readers notice immediately. It also tends to carry English sentence structure, English idiom and, most damagingly for search, English keyword framing — so the page is optimised for a query nobody typed.
The alternative is not necessarily writing everything twice from scratch. It is deciding, per page, which of three things you are doing:
- Transliteration for things that should not change: brand names, product names, legal entity names.
- Translation for content where the facts are the point and the phrasing is not: specifications, process steps, terms.
- Original writing for anything where the search intent differs, which is most commercial and editorial content.
Brief the Arabic writer with the Arabic keyword research, not the English article. The output will be a different piece, and it should be.
The technical details that actually bite
Arabic is written right to left, which affects more than text alignment. Set dir="rtl" and lang="ar" at the document level rather than patching it in CSS, so assistive technology and search engines both read the page correctly. Mirror the layout, not just the text: navigation, breadcrumbs, progress indicators and anything with directional meaning should flip. Numbers, Latin-script brand names and code snippets stay left to right inside an RTL paragraph, which is correct and will look wrong to anyone unfamiliar with it.
Watch the font. Many Latin webfonts have no Arabic coverage, so the browser silently substitutes a system fallback and the Arabic side of the site ends up looking unconsidered next to the English. Pick a typeface with a proper Arabic companion and test it on real content, not a line of sample text.
And check the slugs. Arabic URLs are valid and work, but they are encoded when copied, so they appear as long strings of percent signs in analytics, in emails and in anything that logs a link. Many teams use transliterated Latin slugs on Arabic pages for that reason. Either is defensible; what matters is deciding once rather than ending up with both.
Measure them apart
If you report English and Arabic together you will not see either clearly. One language improving while the other declines looks like a flat month. Split the reporting from the start: separate position tracking per language, and a segment in your analytics for each.
Expect them to move at different speeds. The Arabic side of a site is usually newer, has fewer links pointing at it and less internal support, so it takes longer to establish. That is a reason to be patient with it, not a reason to conclude it does not work.
Where to begin
If you are starting from an English-only site, do not translate everything. Pick the commercial pages that matter most, do proper Arabic research for those, and write them as originals. Get the hreflang pairing right across that set, measure it separately, and expand once you can see it working.
A small number of Arabic pages that were genuinely written for Arabic search will do more than a full site that was run through translation. The second approach produces a lot of pages and very little visibility.