Dominate Search – Get Your SEO & AI Visibility Audit

Google Search Console Coverage Report: How to Read It and Know What to Fix First

Isometric illustration of a team inspecting a search console coverage dashboard with checkmarks and charts
schedule
Reading Time: 5 minutes
material-symbols_bar-chart

Table of Contents

Open the Google Search Console coverage report for most Dubai business sites and the first instinct is to assume every red line is a disaster. It usually isn’t. Google folded the old three-way split of Indexed, Excluded and Error into two top-level buckets, Indexed and Not indexed, and most of what lands under Not indexed is either expected or low priority. The report still carries useful detail underneath those labels. The job is knowing which rows need a fix this week and which ones are just how a working website looks.

This matters more for UAE sites than the generic SEO guides let on. A Dubai e-commerce store with size and colour variants, a hospitality group running separate Arabic and English paths, or a law firm with a service page for every emirate all generate large numbers of near-duplicate URLs. Search Console will flag plenty of them. Most don’t need action.

What the Google Search Console coverage report shows now

Google simplified the categorisation inside what most people still call the coverage report. According to Google’s own Search Console documentation, pages that were previously marked Valid or Valid with warning now sit under Indexed, while anything that used to be Excluded or Error sits under Not indexed. The individual reasons, such as Submitted URL not found (404) or Crawled, currently not indexed, still appear when a row is opened. The colour coding and icons do more of the work than the old text labels did.

That change is worth knowing before reading a search console indexing report line by line, because a growing Not indexed count on its own tells you nothing. The reason behind each row is what decides whether to act.

Sorting real gsc coverage errors from normal exclusions

Not every row under Not indexed is a problem. Some of the most common reasons are a deliberate, correct outcome of how a site is built:

  • Alternate page with proper canonical tag: the URL is a duplicate and Google has correctly chosen another version as canonical. No action needed unless the wrong URL was chosen.
  • Excluded by noindex tag: fine for filtered product listings, internal search results, or staging-style archive pages that were never meant to rank.
  • Page with redirect: expected on any site that has cleaned up old URLs.
  • Crawled, currently not indexed and Discovered, currently not indexed: Google has seen the URL and decided, for now, not to index it. This is common on thin tag or author archive pages and rarely needs urgent action on its own.

The rows that genuinely count as gsc coverage errors, and deserve attention this week rather than this quarter, are different in kind. A server error (5xx) on any page that should be live means Googlebot hit a failure trying to crawl a working page, and a redirect error, usually a chain that loops or dead-ends, points to the same kind of basic access problem.

  • Submitted URL blocked by robots.txt or Submitted URL marked ‘noindex’ on a page that was placed in the sitemap on purpose. A page cannot be both submitted for indexing and told to stay out of the index; one of those two signals is wrong.
  • Submitted URL not found (404), a page in the sitemap that no longer exists.
  • Soft 404 on a commercial or service page, where Google has decided the content looks like an error page even though it returns a 200 status.

A fix order that matches actual risk

Work through the report in this sequence rather than top to bottom as Search Console lists it. Server errors and redirect errors come first, on any page that drives bookings, enquiries or sales, since these block Google from reading the page at all. Next comes submitted and blocked, or submitted and noindex, on pages the sitemap claims are important; check whether the sitemap entry or the noindex tag is the mistake before touching anything else.

  • Submitted URL not found (404) for pages that should still exist, usually the result of a migration, a replatform, or a developer deleting a page without a redirect.
  • Soft 404s on service or product pages, since these usually mean thin or near-empty content rather than a technical fault.
  • Duplicate without user-selected canonical, where Google has picked a different canonical than intended. Add an explicit canonical tag rather than leaving the choice to Google.
  • Crawled or Discovered, currently not indexed, in bulk. One or two of these is normal. Hundreds, concentrated on one template, usually points to thin content or a crawl-budget problem rather than something to fix row by row.

Everything else on the list can wait for a scheduled technical review rather than an emergency fix.

Reading the report by template, not by URL

Opening each flagged URL individually doesn’t scale past a few dozen pages. Filter the report by URL pattern instead, for example every URL containing /product/ or /service-area/, and check whether one template accounts for most of the Not indexed count. A spike concentrated on filtered product URLs or auto-generated location pages points to a templating decision, which gets fixed once at the template level, rather than dozens of individual pages that each need separate attention.

This is exactly the kind of pattern a technical audit is built to catch before it affects rankings on the pages generating leads and sales. See how Dominate Online’s technical SEO service audits crawl and indexation issues for Dubai businesses whose product catalogues or location pages keep tripping the same coverage flags month after month.

Once the fix order is in place, check how to catch schema errors before Google does, since broken structured data and coverage issues often show up on the same templates. A site that recently moved platforms should review the website migration SEO checklist, as unresolved 404s and redirect errors after a replatform are one of the most common causes of a sudden jump in Not indexed pages.

Frequently asked questions

Why does a page show as “Crawled, currently not indexed” even though it looks fine to me?
Google crawled the page and chose not to add it to the index, usually because the content overlaps heavily with other pages on the site or doesn’t clear the bar for the query it’s meant to rank for. It isn’t a penalty. Check whether the page offers something a similar page on the site doesn’t, rather than assuming a technical fault.

Does “Not indexed” mean Google has penalised the page?
No. Not indexed is a decision not to include the page in the index, not a punishment. A manual action or penalty shows up separately, under Security & Manual Actions in Search Console, not in the page indexing report.

How often does the page indexing report update?
Data typically refreshes within a few days of a crawl, though a full picture of a large site can lag longer. Treat the report as a rolling snapshot rather than a real-time dashboard, and recheck a fix after at least a week before concluding it hasn’t worked.

Why do product pages on an online store usually produce the highest error counts in this report?
Variant URLs, filter and sort parameters, and out-of-stock items that redirect or 404 all multiply fast on a catalogue site. A store with a few hundred live products can easily generate several thousand flagged URLs once every colour, size and filter combination is counted.

Should every “Discovered, currently not indexed” URL be resubmitted through the URL Inspection tool?
No. Resubmitting a handful of genuinely important pages is reasonable. Resubmitting hundreds of thin or low-value URLs one by one wastes time and does nothing to fix the underlying reason Google chose not to index them in the first place.

Table of Contents
schedule
Reading Time: 5 minutes
material-symbols_bar-chart