Technical SEO for Dubai & UAE Businesses
Technical SEO for UAE sites: making sure Google can crawl, render and index the pages you want found, in English, Arabic and Russian, and fixing what gets in the way. We start with an audit and fix the problems in short sprints. We don't hand over a list of 300 warnings.
When technical SEO is the problem
Good content cannot rank if search engines never see it. These are the patterns that usually point to a technical cause.
- Search Console reports many pages as 'Crawled, currently not indexed' or 'Discovered, currently not indexed', and some of them are service pages.
- Traffic dropped after a redesign, a platform change or a domain move, and it has not come back.
- The site is built with React, Next.js or another JavaScript framework, and Google's cached or rendered view is missing text or links.
- Arabic or Russian pages rank in the wrong country, or Google shows the English page to Arabic searchers.
- Filters, search pages or tracking parameters have created thousands of URLs that compete with the pages you care about.
- Pages feel slow on a mid-range Android phone on mobile data, even if they look fine on office Wi-Fi.
If the site is technically sound and the issue is weak pages or missing topics, you need our broader SEO programme instead. We say so after the audit rather than selling a technical project the site doesn't need.
Crawling, indexing and rendering
- Crawl paths
- We crawl the site the way a search engine does and compare that with the XML sitemap and Search Console. Orphan pages, broken internal links, long redirect chains and important pages buried deep in the structure show up here.
- Index control
- Canonical tags, noindex rules, robots.txt and parameter handling are checked to confirm they agree with each other. A common fault is a page that is canonicalised to one URL, listed in the sitemap under another and linked internally under a third.
- Index coverage
- We group Search Console's excluded pages by reason and decide for each group whether to fix it, merge it or leave it out on purpose. Not every URL should be indexed.
- JavaScript rendering
- Google renders JavaScript, but it does so in a second step, and rendering can fail or time out. We compare the raw HTML with the rendered page. Titles, main content, internal links and structured data should be in the server response, through server-side rendering or static generation. That also helps crawlers that don't run JavaScript at all, which includes many AI crawlers.
- Log files
- On larger sites, server logs show which URLs Googlebot actually requests and how often. This is how we find crawl budget lost on filter combinations or old URLs.
Core Web Vitals, redirects and site moves
Core Web Vitals measure loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint, which replaced First Input Delay in 2024) and visual stability (Cumulative Layout Shift). Google uses field data from real Chrome users, not the lab score in a one-off test. We read the field data first, then trace each failure to its cause: an oversized hero image, render-blocking scripts, third-party chat and tracking tags, web fonts loaded late, or layout that jumps when a cookie banner appears. Arabic sites often load an extra font family, so font loading needs particular care.
Redirects decide whether years of links and rankings survive a change. On a migration or redesign we build a URL-by-URL redirect map, use permanent redirects straight to the final URL, update internal links so they don't rely on redirects, and keep the map live for as long as old URLs receive traffic or links. If you are planning a website redesign, bring us in before launch, when fixes are cheap.
Hreflang for English, Arabic and Russian, and structured data
- One URL per language
- Each language version needs its own crawlable URL, for example a /ar/ or /ru/ folder. A language switcher that swaps text with JavaScript on the same URL is invisible to search engines.
- Hreflang annotations
- Every version lists itself and all its alternates, using language codes such as en, ar and ru, and region codes only where content really differs by country. An x-default points to the fallback page. Links must be reciprocal, or search engines ignore them.
- Right-to-left checks
- Arabic pages need dir="rtl", Arabic metadata and titles, and layouts that don't break when text runs right to left. We check rendering as well as markup.
- Structured data
- Organisation, LocalBusiness, Service, BreadcrumbList and Article markup where it matches visible content. We're honest about rich results: Google now shows FAQ rich results only for a narrow set of authoritative sites and has retired HowTo results, so we add FAQ markup for clarity and don't promise it will show.
How an audit becomes fixes
Access and baseline
Search Console, analytics, the CMS or code repository, and server logs where available. We record current indexing, traffic and enquiries before we change anything.
Audit
Crawl, rendering, speed, internationalisation and structured data checks, written up as findings with evidence, affected URLs and a proposed fix for each.
Prioritisation
Findings are ranked by likely impact on important pages and by effort. Most sites have a handful of issues that matter and a long tail that doesn't.
Fix sprints
Short cycles in which we implement fixes directly, or brief your developers with tickets they can act on. Each sprint ends with a check that the fix is live and behaving.
Validation
We request reindexing where useful, then watch Search Console and logs over the following weeks, because search engines take time to recrawl.
What's included, what isn't, and what drives cost
- Included: the audit report, a prioritised fix list, implementation or developer tickets, redirect maps, hreflang and structured data templates, and a post-fix check.
- Not included: writing new content, link building, or ongoing monthly SEO. Those sit in the SEO programme or the search growth programme.
- Not included: rebuilding the site. If the platform itself is the obstacle, we will say so and scope it separately under web development.
Cost depends on the number of URLs and templates, how many languages you run, the platform, whether we implement fixes or your team does, and whether a migration is involved. We quote a fixed price for the audit and price fix sprints once we know what the audit found.
Questions buyers ask
Will fixing technical issues improve our rankings?
It removes obstacles, which often leads to more pages indexed and better visibility for pages that were held back. We don't guarantee rankings. They also depend on content, competition and links.
Can you work with our existing developers?
Yes. Many clients prefer that we write precise tickets with the affected URLs, the expected behaviour and a test, and their developers implement them. We then verify each fix.
Is our WordPress site slow because of WordPress?
Rarely by itself. Heavy themes, page builders, too many plugins and unoptimised images are the usual causes. See our WordPress development page if a rebuild is on the table.
Do we need separate Arabic and English domains?
No. Folders on one domain, such as /ar/, are usually simpler to manage and share the domain's authority. Separate country domains make sense only for genuinely separate markets.
How soon will we see changes?
Fixes go live within the sprint. Search engines then need to recrawl and reprocess the pages, which can take days for important pages and weeks or longer for large sites.
Send us your domain, the platform it runs on and what changed before any drop in traffic. We will reply with what we would check first and a fixed quote for the audit. Get a proposal.

