
Technical SEO is the plumbing of a website: if Google can't crawl, render or index a page, nothing else you do for that page counts. Speed comes second. Google says Core Web Vitals are used by its ranking systems, but it also says good scores do not guarantee a top position, and that it will still show the most relevant page when its experience is poor. So good technical SEO services in Dubai start with indexing, and only then chase milliseconds.
Where technical SEO services should start: crawling and indexing
Verify your site in Google Search Console and open the Page indexing report. Not every URL should be indexed, and Google says that's fine: duplicates, filtered views and pages you've marked noindex are meant to stay out. What matters is whether the pages you care about are in.
For any important page that isn't, run the URL Inspection tool to see what Googlebot received. The usual causes:
- a noindex tag left over from the staging site
- a robots.txt rule blocking a whole section
- a login, firewall or CDN setting that treats crawlers as attackers
- duplicate URLs created by filters, sorting or tracking parameters
Remember that robots.txt controls crawling, not indexing. Google can still index a blocked URL without its content, so use noindex, or a password, to keep a page out.
Sitemaps, canonicals and redirects
- Sitemaps. List only canonical, indexable URLs and submit the file in Search Console. Google uses the lastmod date only when it is consistently accurate, and it ignores the priority and changefreq fields. Our own sitemap takes its dates from content changes rather than from each build, so a redeploy doesn't make every page look new.
- Canonicals. Give each indexable page a canonical tag that points to itself. Google treats redirects and canonical tags as strong signals and sitemap inclusion as a weak one, and warns against mixed messages, such as one URL in the sitemap and another in the canonical tag.
- Redirects. Use permanent server-side redirects (301 or 308) for anything that has moved. Our site sends the www version of its address to the plain domain with a permanent 308, which is what Next.js uses. Keep chains short: web.dev names redirects from ads and shortened links as a common cause of slow server responses.
One of the costliest technical mistakes is a redesign that changes URLs without redirecting the old ones. Before any rebuild, export every URL that gets search traffic or links and map each to its new home. If your platform can't produce clean URLs, pre-rendered pages or proper redirects, the answer may be a new website build rather than another plugin.
Core Web Vitals: the numbers that matter
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | Over 0.25 |
A page passes when it meets all three at the 75th percentile of real visits, measured separately for mobile and desktop. INP replaced First Input Delay as a Core Web Vital in 2024, so an audit that still reports FID is out of date.
Keep the scores in proportion. Google says there is no single page experience signal and that trying to get a perfect score just for SEO may not be the best use of your time. The stronger reason to fix speed is commercial: a page that stalls on a phone loses enquiries before rankings come into it.
How do you improve loading speed and Google rankings in the UAE?
Work through the causes in this order, and test after each change.
Loading (LCP)
- Find the LCP element in PageSpeed Insights. On most business sites it is a hero image or a headline.
- Let the browser find it early. The image should be in the HTML, not injected by JavaScript or set as a CSS background, and it should never be lazy-loaded.
- Prioritise one image. Mark the likely LCP image with high fetch priority; web.dev notes that doing this for more than one or two images stops helping. Our guide pages load the cover image near the top this way.
- Shrink images. Serve them at the size they display, in WebP or AVIF. Google Search supports both formats, and the Next.js image component we use converts to WebP by default.
- Pre-render. web.dev favours static generation or server-side rendering over building pages in the browser. Our guides are generated at build time.
- Shorten the distance. web.dev's advice is to get servers as close to users as possible, usually through a CDN. Ask your host where the origin server is and whether the CDN has locations in or near the UAE. Check, too, that ad click parameters, which change with every visit, don't stop the CDN serving cached pages.
- Speed up the server. Aim for a time to first byte of 0.8 seconds or less.
Responsiveness (INP)
Slow INP usually comes from too much JavaScript competing for the browser's main thread: chat widgets, heatmaps and tag managers carrying every marketing pixel you have ever installed. Remove what nobody uses, delay the rest and break up long tasks. Our analytics script loads only after a visitor accepts analytics cookies, so visitors who decline never download it at all.
Stability (CLS)
Give every image and video width and height attributes, or reserve the space with CSS aspect-ratio, and reserve room for anything that loads late, such as banners and embeds. A cookie notice fixed to the bottom of the screen, as ours is, doesn't push content down.
Paid landing pages need the same discipline, because every slow page wastes ad spend. Our guide to landing pages that convert covers the rest of the checklist.
JavaScript, rendering and AI crawlers
Google renders JavaScript with a current version of Chromium, but pages wait in a rendering queue, sometimes for a few seconds and sometimes longer. Its own advice is that server-side rendering or pre-rendering is still a great idea, because it makes sites faster for users and crawlers and because not all bots can run JavaScript. That matters for AI assistants, whose crawlers we cover in our guide to AI search optimisation.
- Make links real links with an href, so crawlers can follow them.
- Return proper status codes: a 404 for a missing page, not a friendly error page with a 200 status, which Google reports as a soft 404.
- Put the canonical tag and the main content in the initial HTML, and don't change the canonical with JavaScript.
Arabic pages, hreflang and structured data
If you have English and Arabic versions, give each its own URL and connect them with hreflang. Each version must list itself and the other with full URLs, including https, ideally with an x-default as well. Google ignores the tags when two pages don't point to each other. HTML tags, HTTP headers and sitemaps work equally well, so pick one method rather than all three. Our guide to building a bilingual Arabic and English website covers the set-up, including why our own Arabic pages stay out of the index until a native speaker has reviewed them.
Structured data helps Google understand a page and can make it eligible for rich results. Organization or LocalBusiness markup for the business, BreadcrumbList for navigation and Article markup for guides are worth having, and the markup must match what is visible on the page. Two things to drop: plans built around FAQ rich results, which Google stopped showing in May 2026, and the idea that AI features need special schema, which Google says they don't.
How to measure speed properly
- Test your templates. Run PageSpeed Insights on your home page, a service page and a blog post. The top section is field data from real Chrome users over the previous 28 days; the score below it is a Lighthouse lab test.
- Know when field data is missing. If a page has too little traffic, PageSpeed Insights falls back to data for the whole site, and a small site may have none at all. Then rely on lab tests and, ideally, collect your own measurements with the web-vitals library.
- Read the Core Web Vitals report in Search Console. It groups similar URLs, so a slow template shows up as one group: fix the template once, not each page.
- Re-test after each change, and give field data time to catch up, since it covers 28 days.
Technical work is one part of SEO; our guide to SEO for small businesses in Dubai covers the rest. If you want to know which of these issues affect your site, our technical SEO team can audit it and fix them with your developer or for you.
Sources
- web.dev: Web Vitals
- web.dev: Optimize Largest Contentful Paint
- Google Search Central: Understanding page experience in Google Search results
- Google Search Central: Understand the JavaScript SEO basics
- Google Search Central: Tell Google about localized versions of your page
- PageSpeed Insights: About PageSpeed Insights
Frequently asked questions
Should my website be hosted in the UAE?
Do I need a PageSpeed Insights score of 100?
Do I still need AMP pages?
How long do speed fixes take to show in Search Console?
Found this useful? Pass it on.

