Most businesses buy SEO before checking whether search engines can read their site properly. That is the wrong order, and it is expensive, because content and links added to a site with a technical fault produce very little.
The reassuring part is that the diagnosis is free, mostly straightforward, and entirely within reach of somebody who does not write code. Google publishes how crawling, indexing and duplicate handling actually work, and Search Console shows you Google's own view of your site. You do not need a specialist to find out whether something is wrong. You may need one to fix it, but that is a much better conversation to have with a specific list in hand.
Here are ten checks, in the order worth doing them, along with a short explanation of how search actually works so that each check makes sense rather than being a step you follow on trust. Nothing here requires you to write code, and most of it is looking at things you already own.
What you need before you start
Google Search Console. Free, and requires verifying that you own the domain. If you do not have it, set it up before anything else, because roughly half of what follows depends on it. Give it a day to populate.
A browser. Several of these checks are just looking at a page.
PageSpeed Insights, optionally, if you also want the performance picture. Our guide on why websites are slow covers that side separately.
That is the whole toolkit. Paid crawling tools have their place on very large sites, but nothing here requires one, and the free tools are Google's own view rather than a third party's approximation of it.
One framing point. Technical SEO is about whether search engines can find your pages, read them, work out which version is the real one, and display them properly. It is separate from content quality and from links. You can have excellent content and still be effectively invisible, which is exactly why this is worth ruling out first.
First, what search actually does with your site
Three separate stages, and knowing which one is failing saves an enormous amount of wasted effort. Almost every problem in this article belongs to exactly one of them [5].
Crawling is a search engine requesting your pages, the way a visitor's browser would. It finds addresses from links on other sites, from links within your own site, and from your sitemap. If it cannot reach a page, nothing else can happen.
Indexing is reading the page, working out what it is about, deciding whether to store it, and choosing which address represents it when several show the same content. A page can be crawled and still not indexed, which is a distinct and very common situation.
Serving is deciding, for a particular search, which stored pages to show and in what order. This is the part everybody thinks of as SEO, and it is the last of the three.
The reason this ordering matters is that effort applied to the wrong stage does nothing. Rewriting a page that is blocked from crawling changes nothing. Building links to a page Google has chosen not to index changes nothing. Fixing a canonical on a page nobody searches for changes nothing either.
So the useful sequence for any diagnosis is: can it be reached, is it stored, and only then is it competitive. This audit works through the first two, which are the ones you can check definitively rather than argue about.
Check 1: Is Google indexing your pages at all
Open the page indexing report in Search Console. It lists how many of your pages are indexed, how many are not, and the reason for each exclusion.
If the indexed count is much lower than the number of pages you have, you have found something significant in under a minute.
Two exclusion reasons come up constantly and mean different things.
Crawled, currently not indexed means Google visited the page, read it, and decided not to include it. This is usually a content judgement, not a technical fault. Thin pages, near-duplicates of other pages on your own site, and pages that add nothing a visitor could not get elsewhere all land here. The response is to improve or remove the page, not to change a setting.
Discovered, currently not indexed means Google knows the page exists but has not visited it. On a small site this often resolves on its own. Across many pages it can indicate that they are hard to reach through internal links, or that Google is not spending much crawl effort on your site.
Note the difference in response. The first is a content problem, the second is usually a structural one. Treating them the same wastes effort.
Check 2: Duplicate addresses and which one Google picked
This is the check that finds the most real problems, and the one businesses are least likely to have done.
Google calls the process canonicalisation: selecting the representative address for a piece of content when several addresses show the same thing [1]. Because the same page can usually be reached at multiple addresses, Google picks one to index and treats the others as duplicates.
You did not create these deliberately. Google lists the routine causes [2]:
- Regional variants of the same content
- Separate mobile addresses
- Both secure and insecure versions of the site
- Site functions such as sorting, filtering and search, which add parameters to the address
- Accidental variants such as a printer-friendly version
Almost every site has some of these.
Why it matters is that signals get divided. Links and relevance that should accumulate on one address are spread across several, and Google has to choose which to show. Google states it chooses the page it considers objectively the most complete and useful for search users [2], which may not be the one you would have chosen for commercial reasons.
The signals you can send [2]:
- Redirect the versions you do not want to the one you do
- Include only the preferred address in your sitemap
- Add a canonical link element on each page pointing at the preferred address
- Prefer secure addresses over insecure ones
And here is the point that catches out almost everybody. Google is explicit that indicating a canonical preference is a hint rather than a rule [2]. The tag alone does not decide the outcome. If your sitemap lists a different address, or your redirects point elsewhere, Google may pick something else. Consistency across all the signals is what actually works.
How to check what happened. Use the URL inspection tool in Search Console on a specific page. It reports both the canonical you declared and the canonical Google selected [3]. When those differ, you have found a genuine problem, and no amount of content work will fix it.
Run this on your five most commercially important pages. It takes ten minutes, and on a site that has never been checked it finds something more often than not.
The parameter problem, if you sell things online
Worth its own note, because product sites generate duplicates faster than anything else.
Filtering and sorting typically add parameters to the address. Sort by price, filter by size, filter by colour, then combine two filters, and one product listing has quietly become dozens of distinct addresses showing overlapping content. Add a session identifier or a campaign tag and the number multiplies again.
The practical effect is that Google spends its crawling effort on near-identical variations of a page instead of on your actual products, and the signals that should build up on one listing are scattered.
What usually helps. Point the canonical on every filtered variation at the clean, unfiltered listing. Keep parameter addresses out of the sitemap entirely. Avoid linking to filtered versions from your navigation, since links are how the crawler finds them in the first place. And where a filtered view genuinely deserves to be found on its own, such as a category people actually search for by name, give it a real address and real content rather than a parameter.
The judgement call is which combinations are worth indexing at all. The honest answer for most shops is very few of them: people search for the product or the category, not for the category sorted by price ascending.
Check 3: Your sitemap
A sitemap should contain only the addresses you want indexed, in their preferred form.
Not redirected addresses. Not pages marked as not for indexing. Not the insecure versions, which Google warns against specifically [2].
Most content management systems generate a sitemap automatically, so the useful question is usually whether yours is correct rather than whether it exists. Open it, which is normally at your domain followed by the standard sitemap filename, and read a sample of the addresses. Do they match what you would want? Do they use the same form as your canonical tags?
A sitemap that contradicts your other signals weakens them rather than helping. This is the most common way a site ends up sending Google mixed instructions without anybody realising.
Do you need one? A small, well-linked site can be found without it. A sitemap earns its place when the site is large, when pages are poorly connected internally, or when the site is new with few incoming links.
Check 4: robots.txt, and the mistake that hides entire sites
Open the file at your domain followed by that filename and read it. Thirty seconds.
This file tells crawlers which parts of your site they may request. It controls crawling, not indexing, and that distinction causes an enormous amount of confusion.
Two consequences worth understanding.
A page blocked in this file can still appear in results, because Google can know it exists from links elsewhere without having read it. Blocking is not hiding.
And if you want a page out of the index, you must allow crawling and instruct no indexing on the page itself. If you block the page, the crawler never reads the instruction, so the page stays. This sounds backwards, and it is the single most common technical SEO mistake made by people trying to do the right thing.
The mistake that matters most is a blanket block left over from a staging site that shipped with the launch. Two lines, entire site invisible, nothing looks broken to a visitor. It can go unnoticed for months.
Check 5: Redirects, secure addresses and www
Type your domain four ways: with and without the secure prefix, with and without www. All four should land on the same address, and the three that are not your preferred form should redirect there.
If two different forms both load without redirecting, you have a duplicate problem at the level of the whole site, which affects every page on it.
Then check old addresses. If the site has been redesigned or migrated, do links to the old structure still lead somewhere sensible? Search Console's indexing report will show a rise in not-found errors if they do not.
Two things to avoid.
Chains. A redirect that goes through two or three hops before arriving adds delay and dilutes the signal. Point old addresses directly at the final destination.
Redirecting everything to the homepage. This is a common shortcut during a migration and it is a bad one. You lose the value of those pages, and somebody following a link to a specific article lands on a generic page and leaves. Redirect each old address to its closest equivalent. Where there genuinely is no equivalent, an honest not-found page is better than a misleading redirect.
Our guide on website redesign covers building the redirect map before a migration rather than after it.
Check 6: Titles and descriptions
In Search Console, look at pages with impressions but very low clicks. Those are pages Google is showing that nobody is choosing, which usually means the title is doing a poor job.
Also check for duplicates. Many sites have dozens of pages sharing one title because a template was never customised. To Google and to the person reading a results page, they look interchangeable.
On Google rewriting your titles, which it does: it may substitute another version when it judges that more useful for a particular search. This happens most with very long titles and keyword-stuffed ones. The practical response is to write clear, specific, reasonably short titles that describe the page honestly, giving Google less reason to override them.
Check 7: Internal links and orphan pages
An orphan page is one nothing on your site links to. Visitors cannot reach it by navigating, and search engines struggle to find it or judge its importance.
These accumulate quietly. A landing page built for a campaign, a service page created during a reorganisation, an article published and never linked from anywhere.
Quick check: compare the addresses in your sitemap against what you can actually reach by clicking through your own site. Anything in the first list and not the second is orphaned.
On how much internal linking is enough: every page worth having should be reachable from the homepage within a few clicks, and related pages should reference each other where it genuinely helps a reader. Internal links do two jobs at once, helping people find things and telling search engines what you consider important. Use the reader as the test rather than any numeric target.
Check 8: Multiple languages and countries
Skip this if you publish in one language for one market. Read it carefully if you do not, because it is where UAE businesses most often get into difficulty.
Language annotations tell search engines which version of a page to show to which audience [4]. A business running English and Arabic versions, or separate UAE and Saudi sites, is exactly the case they exist for.
The rule that gets broken most often is reciprocity. Google is explicit: if page X links to page Y, page Y must link back to page X [4]. Annotations that only go one way are frequently ignored altogether, which means the effort produces nothing.
The second common mistake is listing insecure addresses in the annotations when the site runs on secure ones [4]. Same principle as the sitemap: every signal should use the same form of the address.
On structure, one site with a language prefix in the address is usually simpler to run and easier to keep consistent than separate domains, and the annotations are more reliable when both versions share a domain. Separate domains make sense when the businesses are genuinely separate rather than translations of each other. Our guide on right-to-left design covers the design half of the same decision.
Check 9: Your mobile version is what gets indexed
Google indexes the mobile version of your site. Whatever your mobile pages contain is what is considered for search.
This matters more than it sounds, because some sites hide content on mobile for design reasons. Content that only appears on desktop may effectively not exist as far as search is concerned.
The check is simple, and nobody does it: open your own site on a phone and compare it against the desktop version, section by section. Is the main body text there? The headings? The internal links? If something is missing, that is a decision somebody made, and it may be costing more than the tidier layout is worth.
Check 10: Structured data
Markup that describes what a page is in a machine-readable way: this is an article, these are questions and answers, this is a product with this price.
It can make your result look richer in search, which affects clicks.
Worth adding where it genuinely describes your content. Not worth faking for content that is not on the page, which is against Google's guidelines and can lose you the enhanced display entirely.
How to test: Google provides a rich results test that reads a page and reports what it found and what it considers invalid. Run it on one page of each type rather than on everything. Search Console also reports errors across the whole site once it has crawled enough, which is the better ongoing check.
What is not worth your time
Worth saying explicitly, because audit reports are frequently padded with these.
Chasing a perfect score in a third-party audit tool. Those tools flag everything they can detect, weighted by what is easy to detect rather than by what matters. A site can score poorly and rank well, and the reverse.
Keyword density. Not a thing to optimise, and never has been in any form that survives contact with how modern ranking works.
Meta keywords tags. Ignored by Google for many years.
Directory submissions. Largely a relic of an earlier web, and the remaining ones worth being in are the ones customers actually use, such as business listings tied to maps, which is a local search question rather than a technical one.
If a proposal leads with any of these, ask what evidence connects them to results in the last few years. Our guide on choosing an SEO company covers the wider version of that question.
Doing it in a day
Morning, the fast checks. Indexing report. robots.txt. The four-way domain test. Sitemap sample. Titles with impressions but no clicks. Perhaps two hours, and this is where the site-wide problems surface.
Afternoon, the judgement checks. URL inspection on your five most important pages to compare declared and selected canonicals. Orphan page comparison. Mobile content comparison. Structured data on one page per type. Language annotations if relevant.
End of day, a prioritised list. Sort it by whether the item makes pages invisible or merely makes visible pages perform worse. Fix the first category first:
- A blocking robots file
- Wrong canonicals on important pages
- Broken redirects from a previous site
Those three can suppress an entire section of a site, which is a different order of problem from anything else on the list. Everything else improves pages that are already working, and that work is only worth doing once the first category is clear.
Who should own this internally
Technical SEO falls into the same gap as site speed: marketing owns the outcome, development owns the mechanism, and the checks themselves belong to neither by default.
That gap is why staging blocks survive launches and why sitemaps describe structures that no longer exist. Nobody is doing anything wrong; the task simply has no home.
The workable arrangement for most businesses is that whoever owns the website commercially also owns the monthly indexing check and the annual full pass. They do not need to be able to fix what they find. They need to be able to notice it and route it, which is a much lower bar and takes an hour a month.
The one thing that must be assigned before it is needed is a launch checklist. Any migration, redesign or platform change should have somebody responsible for confirming, on the day, that the robots file allows crawling, that redirects resolve to the right pages, that the sitemap matches the new structure, and that canonicals point at addresses that exist. Four items, in that order. Assigned in advance and checked on the day, they take twenty minutes. Discovered three months later, they cost a quarter of traffic.
Documentation is worth ten minutes too. Write down which form of your address is canonical, where the sitemap is generated, what the redirect map from the last migration was, and who has access to Search Console. That last one strands more businesses than any technical fault: the agency that set it up has left, nobody else was ever added, and the only view of Google's opinion of your site belongs to somebody who no longer works with you. Add a second owner today.
Keeping it from decaying
A full pass once or twice a year, plus a monthly glance at the indexing report to catch sudden drops. Nothing here degrades quickly on its own.
But run the relevant checks after any migration, redesign or platform change, because that is when technical problems are actually introduced. Redesigns are the single most common cause of sudden traffic loss, and almost always for one of four reasons: old addresses not redirected, the staging block left in place, a sitemap still describing the old structure, or canonicals pointing at addresses that no longer exist.
Checking those four before launch rather than after is the difference between a quiet migration and a bad quarter.
If traffic has already dropped
This audit is useful preventively, but most people arrive at it because something has gone wrong. The diagnosis is different when you are working backwards from a fall, so it is worth setting out separately.
Establish when it happened, precisely. Search Console's performance report over sixteen months will show whether the decline was a cliff on a specific day or a slow slide over months. That single distinction narrows the cause enormously.
A cliff means something on your side changed, and almost always on that day. A deployment, a migration, a plugin update, a hosting move, a certificate expiring, somebody editing the robots file. Find what happened within a day or two either side of the drop and you have almost certainly found the cause. Check the indexing report for the same period to see whether pages fell out of the index, which points at a technical fault, or whether they stayed indexed and simply stopped receiving clicks, which does not.
A slow slide is usually not technical. Competitors improved, the content aged, search behaviour shifted, or the queries themselves changed shape. Technical faults tend to produce sudden effects rather than gradual ones, so a gentle decline is a signal to look at content and competition instead of spending a week on canonicals.
Separate impressions from clicks. If impressions fell, you are being shown less often, which is a ranking or indexing question. If impressions held steady while clicks fell, you are still being shown but chosen less often, which is a titles and descriptions question, or a sign that the results page itself changed around you.
Check whether it is the whole site or one section. A drop confined to one directory points at something specific to those pages: a template change, a canonical applied wrongly across a type, a set of redirects that went to the wrong place. A site-wide drop points at something site-wide.
Working through those four questions before touching anything usually identifies the cause in an hour, and prevents the far more common approach of changing six things at once and never learning which one mattered. Our guide on how long ranking takes covers the related question of how quickly a fix should be expected to show.
When to bring in help
When the diagnosis reveals something you cannot fix within your platform. When a migration is planned and you want the redirect map checked before it happens rather than after. When traffic has dropped and you cannot find the cause.
The value of doing the audit yourself first is that you arrive with findings rather than a general request, which gets you a scoped piece of work instead of an open-ended retainer.
If you would rather have it done, a focused technical audit covering crawling, indexing, duplicates, redirects and structured data, delivered as a prioritised list of specific changes, starts from around AED 2,500 with us. Implementation is quoted separately by scope, because some findings are configuration and others are development. Final pricing depends on scope, and these are our own figures rather than a market survey.
Either way, open the indexing report today. It takes a minute, it costs nothing, and most businesses have never looked at it once. Whatever it shows you is a more useful starting point than any proposal you could commission.
References
- Google Search Central, canonicalization
- Google Search Central, how to specify a canonical page
- Google Search Central, canonicalization troubleshooting
- Google Search Central, localized versions of your pages
- Google Search Central, crawling and indexing
- Google Search Central, SEO starter guide
- SKIMBOX, why your website is slow
- SKIMBOX, website redesign in Dubai
- SKIMBOX, right-to-left website design for Arabic
- SKIMBOX, choosing an SEO company in Dubai
- SKIMBOX, how long it takes to rank on Google in the UAE
Google's documentation is updated regularly and the behaviour of its systems changes. Check the linked pages for the current position before acting on anything here that matters commercially.
