We Checked 15 UAE Websites for Arabic and English SEO. Here Is Where They Break.
Table of contents
TL;DR: We audited the English and Arabic versions of 15 well known UAE websites across banking, property, tourism, telecom, healthcare and education. Thirteen declared language alternates and two did not. Of those thirteen, three had no fallback page. And among the twelve Arabic pages we could read, only eight set right to left direction on the page itself. Most sites get the big idea right and miss the details that tell search engines which version to show to whom.
Running a business in Dubai or Abu Dhabi usually means serving two audiences from one website. One reader arrives in English and expects a global standard. Another arrives in Arabic and expects the site to feel native, not translated in an afternoon.
Search engines have to work out which page belongs to which reader. When the signals are missing or wrong, the wrong version ranks, or both versions compete with each other. We wanted to see how often that happens on sites with real budgets, so we checked.
What we tested and what we did not
On October 20, 2026, we opened the English homepage of 15 UAE websites in a real browser. For each one we read the language tags in the page code, then fetched the Arabic version it pointed to and read that page's code too.
The sample was 11 non healthcare sites (banks, property developers and portals, a hotel group, a tourism board, a telecom provider and a university) and 4 hospital groups. We dropped sites that were blocked, returned an error or froze during testing.
The limits matter, so here they are plainly:
This is a homepage check, not a full crawl. Inner pages often differ.
We read the raw HTML the server sends. Some sites set language or direction later with JavaScript, which our test would not see. Search engines do render JavaScript, but raw HTML is the safest signal.
Fifteen sites is a pilot, not a statistically robust benchmark. Use the counts to spot patterns.
We are not naming any site. These are common problems, not a shaming list.
The quick results
Check | Result |
|---|---|
English page declares hreflang alternates | 13 of 15 |
Hreflang includes an x-default fallback (of those 13) | 10 of 13 |
Arabic page carries a self referencing canonical (of 12 read) | 12 of 12 |
Arabic page has its title in Arabic script (of 12 read) | 12 of 12 |
Arabic page sets lang to Arabic (of 12 read) | 11 of 12 |
Arabic page sets right to left direction on the html element (of 12 read) | 8 of 12 |
Arabic page has a heading in Arabic script in the server HTML (of 12 read) | 7 of 12 |
English page uses an invalid language value | 1 of 15 |
One site's Arabic page could not be read by our test, so the "of 12" rows exclude it.
Hreflang: most do it, and two do not
Hreflang is the tag that tells Google your English and Arabic pages are versions of each other. Google's guide to localized versions of your pages says each version should list itself and all its alternates, and that the pages should point back to one another.
Thirteen of 15 sites had this in place. That is a good result, and it reflects how common bilingual builds are in the UAE.
The two without it both had a visible Arabic language switch, so users could find the Arabic site. Search engines, though, get less help. Without hreflang, Google has to guess which version suits which searcher, and sometimes it guesses wrong or treats the pair as duplicates.
No x-default on three sites
Ten of the thirteen sites with hreflang also added an x-default entry. Three did not.
X-default tells search engines which page to show when nobody's language or region matches. On a UAE site that is usually the English page or a language picker. Leaving it out is not an error that breaks anything, but it removes a clear instruction at no saving.
Right-to-left is where details slip
This is the most interesting finding. Every Arabic page we could read had an Arabic title and a self-referencing canonical. Those basics are in place. But the details of how an Arabic page declares itself were less consistent.
Eleven of twelve set the page language to Arabic. Only eight of twelve set dir="rtl" on the html element. The other four did not set it on the html element in the raw HTML.
That might look fine to a visitor and still be a problem. Direction is part of how browsers, screen readers and some crawlers understand the page, and the W3C's guidance on setting direction in HTML recommends declaring it in markup instead of relying on CSS alone. It also affects how mixed content, such as an English brand name inside an Arabic sentence, is displayed.
Remember our caveat: if a site sets direction with JavaScript after loading, this test would miss it. If you run a bilingual site, check your own page source and not just how it looks on screen.
Arabic headings often missing from the server HTML
Only seven of twelve Arabic pages had a heading in Arabic script in the HTML the server sends. The other five may build their headings in the browser, or may have no real heading at all on the page.
If the main heading appears only after scripts run, you depend on the search engine's rendering step to see it. That usually works, but it is slower and less reliable than plain HTML. It also matters for tools that do not run scripts, including some of the AI crawlers that now feed answers to users.
A clear Arabic H1 in the source is cheap insurance.
One site declared its language as "x-default"
One English homepage used x-default as its page language value. That is not a language. It is a valid value in hreflang, not in the lang attribute, and it looks like a template mix up.
Page language should be a real language code, such as en or ar, as explained in the W3C's note on declaring language in HTML. It is a small error, and exactly the kind that survives for years because nobody sees it on screen.
The sites that did best, and what they had in common
Without naming them, the strongest sites shared three habits:
They gave every Arabic page its own address, not a script that swaps text on the same address.
They listed English, Arabic and a fallback in hreflang, and each page referenced the others.
They set language, direction and an Arabic heading in the server HTML.
None of that needs a large budget. It needs a developer who has been told what to build, and someone to check it afterward.
Why these gaps matter more now
A few years ago, a missing hreflang tag meant a slightly worse ranking in one language. Today the same gap can mean your business is described in the wrong language, or not at all, in an AI generated answer. AI tools and search engines both lean on clear page level signals when they choose which version of a page to read and quote.
There is also a plain business reason. A patient, a home buyer or a traveler who lands on the wrong language version often leaves instead of hunting for the switch. If a UAE business is paying for traffic in both languages, each click that lands on the mismatched version is money spent twice for one visit.
The fix is rarely a rebuild. In most of the sites we checked, the missing pieces were a few lines in the page template, applied once and then inherited by every page.
What this means if you run a UAE business site
Whether you are a clinic in Dubai or a property portal in Abu Dhabi, here is the order we would work in:
Give Arabic its own URL. Every Arabic page should be reachable at its own address that search engines can crawl.
Add hreflang in both directions, with x-default. The English page lists the Arabic one and itself, and the Arabic page does the same.
Set
lang="ar"anddir="rtl"in the HTML. Do not leave direction to CSS alone.Write Arabic titles, descriptions and headings by hand. Machine translated metadata tends to read stiffly and can miss how people in the UAE actually search.
Use a self referencing canonical on each version. Do not point the Arabic page's canonical at the English one.
Test in the source, not on screen. View the page source or fetch it without scripts, and confirm the signals above are present.
If you want a second pair of eyes on a bilingual build, our team handles local SEO for doctors and healthcare content marketing for hospitals and clinics, including UAE sites that serve both languages.
Two languages, one set of signals
The pattern across 15 sites was consistent. Most had built a bilingual website, and most had done the headline work. The gaps sat in small, technical details that rarely show up on screen but tell search engines and AI tools how to treat each page.
That is good news, because those details are fast to fix. A developer and a checklist can close most of them in a day.
Open the source of your own Arabic homepage this week and check for hreflang, lang, dir and an Arabic H1.
Frequently asked questions
Do I need a separate Arabic website, or can I use one site with two languages?
One site with language folders, such as /en/ and /ar/, works well and keeps your authority in one place. What matters is that each language has its own crawlable address.
Can I just use Google Translate for the Arabic version?
It is risky. Automatic translation often produces awkward wording and can miss how local searchers phrase things. Use a native speaker to write at least the titles, headings and key service pages.
Does Arabic content rank differently from English content?
It competes in a separate, often less crowded, set of results. Keyword research in Arabic is its own task, and English keywords rarely translate word for word.
Should my Arabic canonical point to the English page?
No. Each language version should reference itself as its canonical, and use hreflang to connect the versions.
How often should I check my language tags?
After every redesign or platform change, and quarterly otherwise. Template updates are the usual way these tags break without anyone noticing.