Arabic SEO in the UAE: 2026 Technical Guide

Arabic SEO is the practice of making a website rank in Arabic-language search results by treating Arabic as a source language rather than a translation target. It covers Arabic keyword research, orthographic and dialect variation, hreflang and URL architecture for bilingual sites, right-to-left rendering, Arabic structured data, and measurement in Google Search Console.

That definition matters because most Arabic SEO fails at the first step. A UAE business builds an English site, runs the copy through a translation layer, drops it at /ar/, and waits. Nothing happens — not because Google struggles with Arabic, but because the Arabic version targets English search intent wearing Arabic words.

This guide is the technical version. It covers what actually changes when you optimise for Arabic, with the markup, the character sets, and the Search Console syntax included rather than described. It is written from how NxFold runs its own bilingual site — English at the root, Arabic under /ar, region-qualified en-AE / ar-AE / x-default hreflang, one canonical source of truth — so the examples are implementations we maintain, not diagrams.

What actually changes between English SEO and Arabic SEO#

Everything below expands one of those rows.

Arabic search behaviour in the UAE: three registers, not one language#

The single most consequential fact about Arabic search is that a user can express one intent in at least three written registers, and they route to different SERPs.

Modern Standard Arabic (MSA) is the formal written register. It is what news, government, and documentation use, and it dominates informational and evergreen queries.

Gulf dialect (Khaleeji) appears in conversational, local, and transactional queries — the phrasing people actually say out loud.

Arabizi is Arabic written in Latin characters with digits standing in for sounds that have no Latin equivalent. It is common in messaging and shows up in search more than most agencies account for.

The Arabizi substitutions are consistent enough to research directly:

So "7abibi", "3arabi", and "5edma" are searchable strings. If your category has an Arabizi form in common use, it is worth checking — but note that Arabizi queries usually indicate informal, early-stage intent, not purchase intent. Prioritise accordingly.

Orthographic variants: the same word, spelled several ways#

Arabic writing tolerates variation that changes the byte sequence without changing the word. Users type whichever form is fastest.

Search engines normalise a good deal of this, but you should not rely on normalisation to carry a page. The practical rule: write the canonical form in headings and body copy, and let the variants be covered by real query data from Search Console rather than by stuffing every spelling into the page. Cramming spelling variants into a paragraph produces exactly the unreadable Arabic that makes users bounce.

One more behaviour worth designing for: code-switching. UAE users routinely mix scripts inside a single query — "سيو Dubai", "SEO بالعربي", "تصميم موقع ecommerce". Brand names, technology names, and city names frequently stay in Latin script. Your Arabic content should keep those entities in Latin where that is how people write them, rather than transliterating everything on principle.

Arabic keyword research that survives a real SERP#

Keyword tools underreport Arabic volume. Sample sizes are smaller, script variants fragment the data across multiple rows, and dialect forms often do not appear at all. Treating a "0 volume" Arabic keyword as dead is one of the most expensive mistakes in this market.

A method that holds up:

1. Seed from the English page you already rank with. Take the top 20 English queries from Search Console for the equivalent page. These are proven intents in your market; you are looking for their Arabic expression, not new topics.
2. Generate the register set. For each seed, write the MSA form, the Gulf form, and the Arabizi form if one exists in common use. Do this with a native speaker or a strong Arabic model — not a dictionary.
3. Validate against the live SERP, not the tool. Search each candidate in Arabic with UAE location. Read what ranks. If the results are commercial pages, the intent is commercial regardless of what a volume field says. If they are dictionary entries and news, it is not your query.
4. Harvest autocomplete and related searches in Arabic. These are behavioural signals from real sessions and they cost nothing.
5. Mine your own Search Console for Arabic queries you already receive. Almost every bilingual UAE site is already getting Arabic impressions it has never looked at. See the measurement section below for the filter.
6. Cluster by intent, then by register. One page per intent. Do not build separate pages for MSA and dialect spellings of the same intent — that is cannibalisation with extra steps.

The output is a keyword set where each entry has an intent, a register, and a SERP observation attached. That is a defensible brief. A spreadsheet of translated English keywords is not.

URL architecture for bilingual UAE sites#

Three viable structures, and one of them is right for almost everyone.

Subfolder wins for the overwhelming majority of UAE businesses. It is what we run: English at /, Arabic at /ar/, one domain, one authority pool.

Should Arabic slugs be in Arabic script?#

Non-ASCII characters in a URL are percent-encoded on the wire (RFC 3986), so /ar/تصميم-مواقع transmits as /ar/%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%85%D9%88%D8%A7%D9%82%D8%B9. Browsers and Google display the decoded Arabic; anything that logs or shares the raw URL shows the encoded form.

The trade-off is real: Arabic-script slugs are more readable in the SERP and keyword-relevant, but they are fragile in analytics exports, in email, in CMS fields, and in any tool that mishandles encoding. Our position, and what we implement: keep slugs locale-agnostic and ASCII, and carry the language in the path prefix. One slug, two locales, zero encoding surprises — and the Arabic relevance signal lives where it counts, in the title, headings, and body.

Whichever you choose, choose once. Mixed slug strategies across a site are a migration you will pay for later.

Hreflang, done properly#

This is the section every competing guide names and almost none implements. Here is the full, correct block for a two-locale UAE site, rendered in the <head> of both pages:

<link rel="alternate" hreflang="en-AE" href="https://www.example.com/services/seo" />
<link rel="alternate" hreflang="ar-AE" href="https://www.example.com/ar/services/seo" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/services/seo" />
<link rel="canonical" href="https://www.example.com/services/seo" />

Four rules that decide whether it works:

1. Self-reference. Each page lists itself among its own alternates. The English page includes the en-AE tag pointing at itself. Omitting this is the most common failure.
2. Return tags. If A points to B, B must point back to A. Unidirectional hreflang is ignored.
3. Canonical must agree. A page's canonical points to itself, never to the other locale. A canonical pointing across locales tells Google the Arabic page is a duplicate of the English one and removes it from the index. This single error kills more Arabic pages than any content problem.
4. Absolute URLs, consistent host. Match the protocol, the www choice, and the trailing-slash convention exactly. https://www.example.com/ar/x and https://example.com/ar/x/ are different URLs to a validator.

ar or ar-AE?#

Use ar-AE when you are targeting UAE Arabic speakers specifically and your content reflects UAE context — currency, regulation, delivery, local terminology. Use bare ar when the page serves Arabic speakers across markets equally. You may also ship both, with ar as the fallback and ar-AE for the region-specific page, but only if the pages genuinely differ. Two hreflang entries pointing at one URL is noise.

We use region-qualified en-AE / ar-AE with x-default resolving to English, because the site's commercial context is explicitly UAE.

The failures worth auditing for#

• Hreflang on a page that is noindex — the annotation is discarded
• Hreflang in the sitemap and in the <head> disagreeing
• A locale in the set that returns a 404 or redirects (very common when a "planned" market page does not exist yet)
• Language codes invented rather than BCP 47 (ar-UAE is not valid; ar-AE is)
• Hreflang generated per page by hand, drifting over time

The structural fix is to derive alternates from one function rather than authoring them per page. On nxfold.com every page's alternates come from a single builder fed by one siteUrl constant, which is also the origin used for the sitemap — so a canonical can never disagree with its own sitemap entry. Making the correct thing automatic is worth more than any audit.

RTL is not dir="rtl"#

Setting the attribute is the first ten percent.

<html lang="ar" dir="rtl">

The rest:

Use CSS logical properties. margin-inline-start instead of margin-left, padding-inline-end, border-inline-start, inset-inline-start. These flip automatically with direction. A stylesheet built on physical properties requires a parallel RTL stylesheet, which then drifts.

Handle bidirectional text. Arabic paragraphs containing Latin strings — brand names, URLs, version numbers, "Next.js" — are bidirectional. The Unicode bidi algorithm mostly gets this right, but punctuation adjacent to a Latin run frequently lands on the wrong side. Where it matters, isolate the run with a bdi element or unicode-bidi: isolate.

Mirror the right things, not everything. Directional icons (arrows, chevrons, progress indicators) mirror. Logos, media playback controls, and clock faces do not. Blanket transform: scaleX(-1) on an icon set produces backwards logos.

Test Arabic typography as a first-class case. Arabic glyphs need more vertical space; line-height tuned for Latin clips descenders and diacritics. Arabic text also has no uppercase, so any design leaning on text-transform: uppercase for hierarchy loses that hierarchy entirely in Arabic and needs weight or size to carry it instead.

Watch layout shift. Arabic web fonts are large. A font swap that reflows an RTL layout is a CLS problem, and Google's threshold is CLS below 0.1 (alongside LCP under 2.5s and INP under 200ms). Subset your Arabic font, serve WOFF2, and use font-display: swap deliberately. Our Core Web Vitals guide for UAE businesses covers the measurement side.

For the design and UX half of this — layout, navigation, form patterns — see our Arabic website design and RTL guide.

Structured data in Arabic#

Emit locale-aware JSON-LD rather than one block reused across both languages.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://www.example.com/ar/blog/post#article",
  "inLanguage": "ar-AE",
  "headline": "عنوان المقال بالعربية",
  "description": "وصف الصفحة بالعربية",
  "author": { "@type": "Organization", "name": "NxFold Technologies LLC" },
  "datePublished": "2026-08-02",
  "dateModified": "2026-08-02"
}

Three things to get right:

• inLanguage on every locale variant. It is the cheapest correctness signal available and it is almost universally omitted.
• Distinct @id per locale. Reusing one @id across two URLs merges two entities into one and confuses the graph.
• Localise the values, not just the wrapper. name, description, address, and areaServed should be in Arabic on the Arabic page. An Arabic page carrying an English LocalBusiness name is a mismatch signal.

On FAQ markup: Google restricted FAQ rich results in 2023 to well-known authoritative government and health sites, so most businesses will not see the rich result. FAQPage markup is still worth shipping — it makes your question-and-answer pairs machine-legible for AI search systems that parse structured data — but do not budget for a SERP feature you will not get. And never emit Review or AggregateRating markup for reviews you do not have.

Measuring Arabic performance in Search Console#

Most bilingual sites cannot answer "how is our Arabic doing?" because the data is not separated. Two filters fix that.

Isolate the Arabic pages. Performance → Pages → filter → URLs containing /ar/. Everything downstream — queries, countries, devices — is now Arabic-only. Compare it against the inverse filter to get a genuine EN-vs-AR split.

Isolate Arabic-script queries. Search Console query filters support RE2 regular expressions. Select Query → Custom (regex) → Matches regex:

[\x{0600}-\x{06FF}]

That range is the Arabic Unicode block; any query containing at least one Arabic character matches. Invert it (Doesn't match regex) to see Latin-script queries hitting your Arabic pages — which is how you find code-switched and Arabizi traffic you did not know you had.

Then check Search Console → Legacy tools and reports → International Targeting for hreflang errors. "No return tags" there means exactly rule 2 above is broken.

Two habits that pay off: track Arabic and English positions separately (a page can be position 4 in English and 40 in Arabic — averaged together, it looks like 22 and tells you nothing), and check Arabic queries monthly for intents you have never targeted. That report is free keyword research from your own users.

Content quality: what machine translation costs you#

Machine translation has become genuinely good at meaning. It remains bad at three things that decide Arabic rankings.

Register. Translation output tends to land in a stiff formal register that reads as foreign to Gulf readers, or drifts inconsistently between formal and colloquial within one page.

Term choice. The translated term is frequently not the searched term. Translation optimises for accuracy; SEO needs the word your buyer actually types. These diverge constantly — and a page can be a flawless translation while targeting a phrase nobody searches.

Local specificity. The English page cites examples, regulations, and payment methods that make sense to its audience. Faithfully translated, they make an Arabic page about a market it is not addressing. Native Arabic content substitutes locally relevant equivalents instead of translating irrelevant ones.

The workable process is not "translate" and not "write twice from scratch." It is: one shared strategy and keyword map, then independent authoring per language, with each locale free to differ in structure, examples, length, and FAQ set. Our own bilingual publishing enforces this at the system level — a post cannot be published unless both language versions are genuinely complete, which makes a stub Arabic version impossible to ship by accident.

Arabic and AI search#

Arabic answer coverage in AI search engines is thinner than English, which cuts both ways: less competition for citation, and a higher bar for being parseable enough to cite. The tactics that work are the ones that work for generative engine optimisation generally, applied in Arabic:

• Lead with the entity. Arabic prose conventions favour long introductory throat-clearing; extractable content does not.
• Put a self-contained 40–60 word definition near the top, in Arabic, that reads correctly with zero surrounding context.
• Use question headings phrased the way Arabic users actually ask.
• Ship comparison tables. Tables survive extraction; prose paragraphs get paraphrased.
• Name entities precisely and consistently — including keeping technology and brand names in Latin script where that is the convention.

A note on the statistics in this market#

If you read five Arabic SEO guides, you will encounter confident figures for Arabic internet penetration, mobile share, Arabic share of web content, and conversion lift from localisation. We reviewed the pages currently ranking for this topic. Almost none of those figures carries a source, several contradict each other across pages, and some contradict themselves within a single page.

We have not repeated any of them here. Where you need a number for a business case, pull it yourself from a primary source — DataReportal, StatCounter, W3Techs, or the UAE's own statistics authorities — and cite the date. In a market where nobody sources anything, being the page that does is a durable advantage, with AI search systems as well as with buyers.

Implementation checklist#

Architecture

• Arabic on a subfolder (/ar/), not a subdomain, unless there is a real infrastructure reason
• Slug strategy chosen once and applied site-wide
• Every English page has an Arabic counterpart, or is deliberately English-only

Hreflang and canonicals

• Self-referencing hreflang on every page
• Reciprocal return tags verified
• x-default present and pointing at a real page
• Canonical self-referencing, never cross-locale
• Alternates generated from one source, not authored per page
• International Targeting report clean

Rendering

• lang="ar" dir="rtl" on the Arabic document
• CSS logical properties throughout
• Bidi isolation on mixed-script runs
• Arabic font subset, WOFF2, CLS under 0.1
• Icon mirroring audited, not blanket-applied

Content

• Keywords researched natively, validated against live SERPs
• Register chosen per page type (MSA for evergreen, dialect where conversational)
• Arabic authored, not translated
• Titles and descriptions checked for rendered width, not character count
• 100% image ALT coverage in Arabic

Structured data and measurement

• inLanguage on every locale variant
• Distinct @id per locale
• No fabricated review or rating markup
• Search Console /ar/ page filter saved
• Arabic-script query regex filter saved
• EN and AR positions tracked separately

Frequently asked questions#

Is Arabic SEO just English SEO with translated keywords?

No. Translation converts meaning between languages; SEO targets the phrasing a specific audience types. The two diverge constantly — a perfectly accurate Arabic translation of an English keyword is frequently not the term Arabic users search. Arabic SEO requires native keyword research, its own intent mapping, and its own content, sharing only the strategy with the English version.

Should I use Modern Standard Arabic or Gulf dialect?

Match the register to the query. Evergreen, informational, and technical pages perform in Modern Standard Arabic, which is what people write when searching formally. Conversational, local, and transactional queries skew toward Gulf dialect phrasing. Most sites need MSA as the default with dialect terms integrated where the research shows real usage — not one register applied everywhere.

Does Google Translate output hurt Arabic rankings?

Machine-translated content is not penalised as such, but it underperforms for structural reasons: it targets translated keywords rather than searched ones, its register reads as foreign, and it carries examples relevant to a different market. Machine translation is a viable first draft. It is not a publishable Arabic page.

Do Arabic keywords really have lower search volume?

Reported volume is lower than actual volume. Keyword tools sample less Arabic data, split the same query across spelling variants, and often miss dialect forms entirely. Validate demand by searching the term with UAE location and reading what ranks — if commercial pages rank, there is commercial demand, regardless of what the volume column says.

Should my Arabic URLs be in Arabic script?

Either works technically; non-ASCII is percent-encoded per RFC 3986 and search engines handle it. Arabic-script slugs read better in the SERP but break in analytics exports, email, and tooling that mishandles encoding. Locale-agnostic ASCII slugs under an /ar/ prefix are the lower-maintenance choice, and the Arabic relevance signal is carried by the title, headings, and body regardless.

What is the single most common technical error on Arabic pages?

A canonical tag on the Arabic page pointing to the English URL. It tells Google the Arabic page is a duplicate and removes it from the index entirely. Every Arabic page's canonical must point to itself; only hreflang links the locales.

Do I need ar or ar-AE in hreflang?

Use ar-AE when the content is UAE-specific — local regulation, currency, delivery, terminology. Use bare ar when it serves Arabic speakers across markets equally. Both are valid BCP 47; ar-UAE is not.

How do I see which Arabic queries I already rank for?

In Search Console, open Performance, add a Query filter set to Custom (regex) → Matches regex, and enter [\x{0600}-\x{06FF}]. That returns every query containing Arabic characters. Combine it with a Pages filter for /ar/ to separate Arabic-page performance from English.

Where this leaves you#

Arabic SEO in the UAE is not a harder version of English SEO. It is the same discipline applied to a language whose users spell flexibly, switch registers by context, mix scripts inside one query, and are served by a SERP where almost nobody has done the technical work properly. The competitive gap is not in content volume. It is in hreflang that validates, canonicals that do not cross locales, RTL that survives a real layout, structured data that declares its language, and measurement that separates the two languages instead of averaging them.

That gap is closeable in weeks, not quarters — and closing it usually surfaces Arabic impressions a site has been earning and ignoring.

If you want the audit version of this checklist run against your own site, our SEO and performance service covers bilingual technical SEO, Arabic keyword strategy, and native Arabic content. Request a quote and tell us your Arabic and English domains — the hreflang, canonical, and index-coverage findings usually come back within a few days, and they are the fastest thing on this page to fix.

Related reading: How to choose an SEO agency in Dubai · SEO pricing in Dubai · Web development services