Arabic SEO and localization in the UAE: what actually changes

Adding Arabic to a UAE website changes six things Google can verify: the hreflang cluster, the declared direction of the document, the font loading path, the URL and canonical structure, the vocabulary register your keywords sit in, and the internal links flowing into /ar/. Translation is the part agencies sell. Those six items decide whether the Arabic pages get indexed at all, and whether they get served to people in the Emirates rather than to Arabic speakers in Manchester.

Arabic SEO in the UAE is the technical and editorial work of making an Arabic version of a site retrievable for Arabic queries inside the Emirates: region-specific hreflang, a correctly declared RTL document, keyword sets built around orthographic variants rather than single spellings, and enough internal authority for the Arabic section to rank without leaning on the English one.

Two notes on numbers first. Globalization Partners has put the share of UAE users who prefer searching in Arabic at 65 to 70 percent, and regional reports place Middle East mobile traffic somewhere in the high eighties to mid nineties percent of sessions. Both are directional, both come from someone else's dataset, and neither replaces your own Search Console. You will also read that Arabic keywords carry three to five times less competition than English ones. We have not found a source behind that multiplier and we are not going to repeat it. The narrower claim we can defend sits further down, in the keyword research section.

Arabic SEO hreflang basics: ar, ar-AE, and the codes Google actually reads

Use ar-AE when the page is written for people in the UAE. Use ar when the same Arabic page is meant to serve Arabic speakers anywhere.

ar is a language code with no regional preference. Google will happily serve that page to Arabic-language searchers in Riyadh, Cairo, London and Dubai alike. ar-AE adds the ISO 3166-1 alpha-2 code for the Emirates, which asks Google to prefer that URL for Arabic searchers located in the UAE. If your prices are in dirhams, your delivery is domestic and your service area is Dubai, plain ar leaves the regional signal on the table.

Value	What Google reads	Use it when
ar	Arabic, no country preference	one Arabic page serves the whole region
ar-AE	Arabic, users in the UAE	pricing, stock, delivery or service area is UAE-specific
en-AE	English, users in the UAE	the English page is UAE-targeted, not global
ae	Avestan	never
ar-UAE	invalid, ignored	never
x-default	fallback for unmatched users	one URL per cluster, usually the selector or global English page

The fourth row is not a joke. ae is a valid ISO 639-1 language code and it belongs to Avestan, the liturgical language of Zoroastrianism. A tag written as hreflang="ae" parses cleanly, passes most validators, and targets an audience of nobody. The same class of mistake produces en-UK, where the correct region code for the United Kingdom is GB and uk on its own is Ukrainian.

Four cluster rules cause most of the real damage:

1. Every URL in the set lists every other URL, including itself. A missing self-reference is the single most common error we find.
2. Return links have to be bidirectional. If /ar/ points at /en/ and /en/ does not point back, Google drops the pair.
3. URLs must be absolute, canonical and indexable. Point hreflang at a URL that 301s, canonicalizes elsewhere or carries noindex, and the pair dies quietly.
4. Pick one delivery method. Head tags, XML sitemap, or HTTP header. Two sources that disagree is worse than one source that is slightly wrong.

Here is a failure worth memorizing, because it costs nothing to create and produces no visible error. A site declared its Arabic alternates in the page head as https://example.ae/ar/services with no trailing slash. The server actually resolved /ar/services/ with a slash and 301'd the other version. The return links now originated from URLs Google had already canonicalized elsewhere, so the whole cluster was ignored. Search Console no longer has a dedicated international targeting report, so nothing in the interface flagged it. The symptom was English pages appearing for Arabic queries for four months.

The second self-contradiction is geo-IP redirection. A site declares ar-AE and en-AE correctly, then runs a script that force-redirects every UAE IP to /ar/. Googlebot crawls predominantly from US addresses, so it never sees the Arabic experience your users see, and any crawl from a regional address gets bounced off the English URLs. Your markup says one thing, your server does another. Offer the language switch, do not impose it.

If you want that cluster checked before launch rather than after, it is the first item in every Arabic SEO and technical SEO audit we run on a bilingual site.

RTL in practice: what breaks in the layout and how it reaches Core Web Vitals

The attribute that counts is dir="rtl" on the <html> element, sitting next to lang="ar". CSS direction: rtl in a stylesheet is not equivalent.

The reason is timing and scope. dir is in the markup, so it is available the moment the parser reads it, it applies to form controls and native UI, and it sets the base direction for the Unicode bidirectional algorithm. A CSS declaration depends on the stylesheet arriving and being applied, which gives you a flash of wrongly directed text on slow connections and inconsistent behaviour in <input> and <select>. Set the attribute. Keep the CSS as reinforcement if you like.

Mixed direction is where most layouts actually break. Arabic runs right to left, but Latin brand names, URLs, model numbers, phone numbers and digits stay left to right inside the same line. The bidi algorithm handles the strong characters well. Neutral characters take their direction from whatever surrounds them, and that is where it falls apart.

Two bugs we see on almost every unaudited Arabic build. First, phone numbers: a CTA written as +971 4 123 4567 inside an RTL paragraph renders with the plus sign stranded on the wrong end, so the number reads as 971 4 123 4567+. It looks like a typo, it is actually correct bidi behaviour on an unisolated neutral character, and the fix is a <bdi> wrapper or an explicit dir="ltr" span. Second, parentheses and currency: (2026) flips to )2026( and the currency label detaches from the amount, so a price block reads as if the dirham figure belongs to the line above it. On a product page, a detached currency label costs conversions.

The layout half is simpler and more mechanical. Setting direction flips text flow, not physical CSS properties. margin-left stays on the left in RTL. padding-right stays on the right. transform: translateX(20px) moves the same way it always did. Chevrons, back arrows, carousel controls and progress bars all keep pointing the wrong way. Logical properties fix this at the source: margin-inline-start, padding-inline-end, inset-inline-start. Retrofitting them into an existing theme is a day of work. Building on them from the start costs nothing.

Now the part nobody in the top ten results mentions. Direction change moves your Core Web Vitals, and it moves them through the font.

Arabic typefaces carry contextual glyph forms. Every letter has initial, medial, final and isolated variants, plus mandatory ligatures. You can subset a Latin webfont down to a few dozen glyphs. You cannot subset an Arabic face the same way without breaking shaping. The practical result is that the Arabic font file is substantially heavier than the Latin subset it replaces. If your largest contentful paint element is the hero heading, and it usually is on a service page, font delivery gates LCP directly.

On one bilingual build the Arabic homepage's LCP sat visibly behind the English one on the identical template and the identical server response. The cause was not the backend. It was that the theme loaded the Latin font stack on /ar/ as well, so the browser downloaded a face containing zero Arabic glyphs, rendered nothing from it, fell back to the system Arabic font, and then loaded the real Arabic face on top. Two font downloads, one of them useless. Separate @font-face blocks with correct unicode-range removed the wasted request.

Cumulative layout shift has its own Arabic-specific cause. The system fallback on iOS and the system fallback on Android have very different vertical metrics from Cairo, Tajawal or IBM Plex Sans Arabic. With font-display: swap, the reflow when the webfont lands is larger than the equivalent Latin swap. size-adjust, ascent-override and descent-override on the fallback declaration bring it under control.

One more that is not a metric but wrecks the page anyway: line-height: 1.4 looks fine in Latin and clips the dots under Arabic letters and the descenders on the loops. Arabic wants roughly 1.6 to 1.8. Given that the large majority of regional traffic arrives on mobile, all of this lands on a mid-range Android first.

We handle the RTL template layer inside web development rather than treating it as a translation deliverable, because it is a build decision, not a copy decision.

Modern Standard Arabic or Gulf dialect: how to choose keywords

Write the pages in Modern Standard Arabic. Target a slice of the query set in Gulf dialect.

Modern Standard Arabic, الفصحى (al-fusha), is the written standard across the Arab world. It is what newspapers, government portals and serious brands publish in. Nobody speaks it at home. The spoken variety across the Emirates and the wider Gulf is Khaleeji, خليجي, and it differs from MSA in exactly the words people use when they are asking for something.

Three pairs that show the mechanic:

Meaning	MSA	Gulf spoken
I want	أريد (urid)	أبغى (abgha)
how much is it	كم السعر (kam as-si'r)	بكم (bikam)
best	أفضل (afdal)	أحسن (ahsan)

The register split maps onto query type. Typed queries skew toward MSA, partly out of formality and partly because Arabic keyboards make the standard spelling the path of least resistance. Voice queries skew dialect, because people speak the way they speak. By various estimates only a minority of conversational Arabic queries in the Gulf use the standard register, though we have not seen a figure we would put a decimal point on.

The working rule: body copy, headings and meta in MSA, because that is what a UAE brand audience expects to read and because it also matches the register of the government and financial sites you are competing with in a lot of verticals. Then let dialect forms appear in FAQ questions, in H3 subheads and in your internal site search synonyms, since that is where voice-shaped and conversational phrasing actually lands.

MSA is not optional in legal, financial, health and government-adjacent content. If your page sits next to a Ministry portal in the SERP and reads like a WhatsApp message, the register itself is a trust problem.

Transliterated brand names deserve a line of their own. Apple appears in Arabic search as أبل, Nike as نايك, and users search both the Latin string and the Arabic one. You do not need two pages. You need both strings present on the same page, the Latin form in the H1 or first paragraph and the Arabic transliteration nearby, so the page is retrievable either way.

Arabic keyword research: why the tools undercount and where the gaps sit

The volume figures you export for Arabic are wrong in a specific, predictable direction. They undercount, because one query exists in four or five orthographic variants and most tools count each variant as a separate row.

Four variant axes cause almost all of it. Hamza gets dropped: الإمارات becomes الامارات, إلكتروني becomes الكتروني, because the hamza needs a modifier key and a large share of typed queries simply skip it. Ta marbuta gets written as ha: شركة becomes شركه, same word, different final character, different row in your keyword tool. Alef maqsura and ya get confused: دبي occasionally typed as دبى, على typed as علي. And the definite article goes on or off: تسويق against التسويق, which changes the string but rarely the intent.

Google normalizes a good deal of this on the retrieval side, so a page spelled one way generally competes for all of them. Keyword tools mostly do not aggregate them in the volume column. So real demand for a head term is the sum of the variant set, not the number on the top row, and the term you dismissed as low volume may be three times what the export said.

The method that actually produces a usable Arabic keyword list:

1. Translate the English seed into MSA, then generate the variant set by hand across the four axes above.
2. Run autocomplete on google.ae with the interface language set to Arabic. Autocomplete reflects strings people genuinely type, misspellings included, which is precisely what the tools strip out.
3. Harvest People Also Ask in Arabic. It is the cleanest free source of question-shaped Arabic phrasing.
4. Filter your own Search Console queries by an Arabic substring. For your own site this is the only ground truth that exists, and it is free.
5. Read the SERP before you commit. If page one for an Arabic query is Egyptian and Saudi domains with no UAE presence at all, you are either looking at an opening or at a query with no local commercial intent. The layouts tell you which.

Now the narrower version of that competition claim. We cannot support a three to five times multiplier. What we will say is that on Dubai service queries, a large share of the Arabic pages ranking were translated into Arabic rather than written in it, and translated pages tend to carry English sentence order, English-length paragraphs and headings that answer nothing. Competing against that is a different job from competing against a native Arabic page, and it is usually easier. That is an observation from SERP reading, not a measurement.

If you are evaluating vendors for this work, the questions worth asking overlap heavily with the ones in our guide on how to choose an SEO agency in Dubai, with one addition: ask who writes the Arabic and whether that person has ever seen your Search Console.

The technical layer: diacritics, encoding and canonicalization

Serve UTF-8 end to end, keep the diacritics your editors typed, and canonicalize the URL variants you cannot control.

Encoding first, because it is boring and it still breaks sites. <meta charset="utf-8"> is not enough on its own if the HTTP Content-Type header disagrees with it, and MySQL's utf8 is a three-byte impostor that mangles some characters where utf8mb4 does not. The visible symptom is question marks or Latin gibberish inside Arabic meta descriptions in the SERP, which is a ranking problem and a click-through problem simultaneously.

Diacritics, الحركات (al-harakat), are the short-vowel marks written above and below the letters. Google normalizes them for matching, so a diacritized page and an undiacritized page generally compete for the same query. The problem is not Google. The problem is backends. Some CMS sanitizers, search plugins and form handlers strip combining marks on save, which silently rewrites quotations, names and any word where the vowel resolves the meaning. Undiacritized, علم can be read as عِلْم (ilm, knowledge) or عَلَم (alam, flag). A human reader resolves that from context most of the time. In a formal quotation or a legal clause, the reader who needs the mark is the one who does not get it.

Practical policy: use harakat sparingly, in headings and in genuinely ambiguous words. Do not diacritize whole pages. It reads like a primary school textbook and it inflates byte size for no retrieval benefit. Then test one thing: type a diacritized word into your CMS, save, reload, and confirm the marks survived the round trip.

URLs are a real choice with no wrong answer. Arabic slugs are valid, Google handles percent-encoded UTF-8 fine, and they read beautifully when shared in a chat. They also turn into unreadable %D8%B4%D8%B1 strings in analytics exports, spreadsheets and some email clients, which makes reporting painful. Transliterated Latin slugs under /ar/ are easier to operate. Pick one convention, apply it everywhere, and canonicalize the variants your CMS generates on its own.

One detail that costs rich results and almost never gets checked: digits. Eastern Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) are correct Arabic, but structured data is not prose. A JSON-LD price value written as ١٢٥٠ is not a parseable number, and the rich result is dropped without a friendly error. Keep Western digits in every schema field, keep dates in ISO format, set inLanguage to ar-AE, and translate the human-readable schema strings rather than copying the English block across. Deeper coverage of the crawl and rendering side sits in our breakdown of technical SEO services in Dubai.

Keeping /ar/ from cannibalizing the main site

An Arabic section cannibalizes when it has no authority of its own and the platform decides which version to show.

Subdirectory structure, example.ae/ar/, is the default for one brand serving one market. It inherits the domain's authority instead of starting from zero the way a subdomain does. That part is easy. The failure modes come later.

Translated content is not duplicate content, and Google has been consistent about that. Two things do create genuine duplication. The first is partial translation: an Arabic URL that still carries the English body copy below a translated hero, so two URLs now hold the same English text. The second is platform automation. Shopify Markets, Webflow localization and most translation apps generate locale-prefixed URLs for every page whether or not the content behind them was ever translated, and they inject their own hreflang. That auto-generated hreflang is usually generic ar, not ar-AE. If your theme also hand-writes hreflang in the head, you now have two systems making contradictory statements about the same URL, and Google resolves the conflict by ignoring both.

Authority is the other half. A /ar/ section whose only inbound link is a flag icon in the header gets crawled roughly as often as your privacy policy. The Arabic pages need Arabic navigation, Arabic breadcrumbs, Arabic blog content and body-copy internal links between Arabic pages. And the language switcher must link to the equivalent page, not to the Arabic homepage. Dumping every switch onto /ar/ destroys deep-page discovery and scrambles the hreflang pairing at the same time.

A concrete case from an audit on a UAE ecommerce site. The Arabic and English versions of the same collection page traded places in the results for one Arabic query week to week. The content was fine. The Arabic page had two internal links pointing at it. The English page had over two hundred. Google kept choosing the stronger URL and the hreflang cluster was too broken to override that choice. The fix was internal linking plus hreflang repair. Not a single word of copy changed.

For monitoring, Search Console has no language dimension, so use the Pages filter with "URL contains /ar/" and read the query set against it. The cannibalization signal is specific and easy to spot: an Arabic query returning an English URL. When you see that, check internal links and hreflang before you touch the content.

The brands we run campaigns for in Dubai retail, beauty and jewellery, Fabiana Filippi, Rayhaan and DSQ Cosmetics among them, all sit in categories where the Arabic version question comes up in the first site brief, and it usually gets treated as a translation budget line when it is actually a structure decision.

A pre-launch check that takes about an hour

Run this before the Arabic version goes live, not after the traffic fails to arrive.

1. lang="ar" and dir="rtl" present on <html>, not only in CSS.
2. hreflang values valid, self-referencing, bidirectional, absolute, pointing at canonical indexable URLs.
3. One hreflang delivery method only. Check the theme and the platform are not both emitting tags.
4. Trailing slash, protocol and www form in hreflang match exactly what the server returns.
5. No IP-based forced redirect between language versions.
6. Arabic font loaded with its own unicode-range, Latin font not loaded on Arabic pages, fallback metrics adjusted.
7. Phone numbers, prices, URLs and parentheses isolated with <bdi> and checked visually on a real phone.
8. Structured data uses Western digits, inLanguage set to ar-AE, strings translated rather than copied.
9. Arabic pages linked from Arabic pages in body copy, not only from the header switcher.
10. Diacritics survive a save and reload cycle in the CMS.

If you would rather have someone else run it, send us the English and Arabic URLs and we will come back with the specific breakages rather than a proposal. Get in touch with the two URLs and the platform you are on.

Written by Artur Gall, CEO and founder of SkyLight Marketing, Dubai.

FAQ

What is the difference between hreflang ar and ar-AE?

ar targets Arabic speakers with no country preference, so Google may serve that page to searchers in Egypt, Saudi Arabia or the UK. ar-AE combines the Arabic language code with the ISO 3166-1 code for the Emirates and asks Google to prefer that URL for Arabic searchers in the UAE. Use ar-AE when pricing, delivery or service area is UAE-specific. Note that ae on its own is the ISO 639-1 code for Avestan, not a UAE targeting signal.

Does RTL design affect Core Web Vitals?

Indirectly but measurably, mostly through fonts. Arabic typefaces carry initial, medial, final and isolated forms of every letter, so they cannot be subset as aggressively as Latin faces and the file is heavier. If the hero heading is your LCP element, font delivery gates LCP. Layout shift also runs higher because Arabic system fallback fonts have different vertical metrics from webfonts like Cairo or Tajawal, which makes the swap more visible.

Should I use MSA or Gulf dialect for a UAE audience?

Write the pages in Modern Standard Arabic and target part of the query set in Gulf dialect. MSA is the written standard your audience expects on a brand site and it is mandatory in legal, financial and government-adjacent content. Dialect forms belong in FAQ questions, subheadings and site search synonyms, because voice and conversational queries skew spoken.

How do I stop /ar/ pages cannibalizing the main domain?

Give the Arabic section real internal authority and fix the hreflang cluster. Cannibalization on bilingual sites is almost always an authority imbalance, where the Arabic page has a handful of internal links and the English equivalent has hundreds, combined with broken or contradictory hreflang. Link Arabic pages from Arabic body copy, point the language switcher at equivalent pages rather than the Arabic homepage, and make sure your platform is not injecting hreflang that contradicts your theme.

Can I use machine translation for Arabic content?

As a first draft with human editing, yes. As a publishing pipeline, no. Machine output produces grammatically valid MSA with English sentence order, it flattens the register, and it will translate your brand name unless you stop it. It also cannot make register decisions, which is the part that determines whether the page reads as credible to a UAE reader.

Why is Arabic keyword research different?

Because one query exists in several orthographic variants and keyword tools count each as a separate row. Dropped hamza, ta marbuta typed as ha, alef maqsura confused with ya, and the definite article present or absent all split a single intent across multiple lines in your export. Google normalizes much of this on retrieval, so real demand is the sum of the variant set, not the top row.

How do diacritics affect rankings?

Google normalizes harakat for matching, so a diacritized page and an undiacritized page generally compete for the same query. The risk is not ranking, it is data integrity: some CMS sanitizers and plugins strip combining marks on save, which silently changes quotations, names and any word where the vowel resolves meaning. Use diacritics sparingly, then verify they survive a save and reload cycle.

What share of UAE search is actually in Arabic?

Published estimates vary. Globalization Partners has put the share of UAE users who prefer to search in Arabic at 65 to 70 percent, and other regional reports give different figures depending on methodology and sample. Treat all of them as directional. The only number that matters for your decision is what your own Search Console shows when you filter queries by an Arabic substring.