Skip to main content
Metrics type: Supporting Metrics • Category: Nerve Centre
Mass de-indexing event, usually a robots.txt or canonical regression after a deploy. First place a broken release shows up in your organic-search presence.

​
At a glance

A real-time alert that fires when the count of indexed pages reported by Google Search Console drops more than 5% against its trailing 7-day baseline. A sudden fall in indexed pages is almost never organic: it is the fingerprint of a robots.txt disallow, a stray noindex tag, a canonical regression, or a server returning 5xx to Googlebot after a deploy. The card is a fire-alarm bell for your site’s eligibility to appear in search, not a measurement of traffic.

​
Calculation

Calculated automatically from your Google Search Console data. We read the indexed-pages count from the Index Coverage / Pages report, compute the median of the prior 7 daily readings as a baseline, and fire when the latest reading sits more than 5% below that baseline. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

​
Worked example

A UK homeware retailer running WordPress, Search Console verified on the domain property homeandhearth.co.uk. Around 8,400 URLs sit in Google’s index on a normal week. On 14 Apr 26 the brand ships a theme update late on a Friday afternoon. Three numbered observations:
  1. The drop is a deploy artefact, not an SEO event. The theme update shipped a templated <meta name="robots" content="noindex"> on every paginated category page (page 2 onward of /shop/...) because a staging flag was left on. Google re-crawled the affected templates over the following 72 hours and dropped roughly 2,200 paginated URLs. Nothing about the brand’s content quality changed; the regression was purely technical.
  2. Triage workflow when this card fires. Order of investigation: (a) fetch robots.txt and diff it against last week’s version, a single mis-scoped Disallow: can hide thousands of URLs; (b) spot-check 5 affected URLs with Search Console’s URL Inspection tool, look for “Excluded by noindex tag”, “Blocked by robots.txt”, or “Crawled, currently not indexed”; (c) check the most recent deploy diff for template changes touching <head>, canonicals, or pagination; (d) confirm the server is returning 200, not 5xx, to Googlebot (use URL Inspection’s “Test live URL”); (e) review the “Not indexed” reason breakdown on the Pages report to see which bucket grew.
  3. Why the alert leads the clicks cards. Clicks for the de-indexed pages did not fall on 15 Apr; they fell from 18 Apr as Google finished dropping the URLs and the next day’s impressions disappeared. This card flagged the coverage drop on 15 Apr, giving the brand a three-day head start to revert the noindex and request re-indexing before the click loss compounded. After the fix on 16 Apr, the indexed count recovered to 8,390 by 24 Apr as Google re-crawled.
Rule of thumb. A sudden indexed-pages drop within 72 hours of a deploy is a deploy bug until proven otherwise. Check robots.txt and <head> templates first; algorithmic de-indexing is rare and gradual, technical de-indexing is sudden and total.

​
Sibling cards merchants should reference together

​
Reconciling against the source

Where to look in Google Search Console:
Indexing → Pages report. The headline “Indexed” number at the top is the figure this alert tracks. Below it, the “Why pages aren’t indexed” table breaks the non-indexed URLs into reason buckets; when this alert fires, one of those buckets has grown. URL Inspection tool. Paste an affected URL to see its current index status, the last crawl date, the discovered canonical, and any robots or noindex blocks. Use “Test live URL” to compare the live page against Google’s cached view.
Other GSC views that are related but are not this alert:
  • Sitemaps report: tells you how many submitted URLs Google found, not how many are currently indexed. A healthy sitemap can coexist with a de-indexing event.
  • Removals: manual removal requests. Check here to rule out an accidental removal submission.
  • Crawl stats (Settings → Crawl stats): crawl volume, not index membership. A crawl-rate collapse can precede a coverage drop.
Why our number may legitimately differ from the GSC UI: Cross-connector reconciliation: This card is not the source of truth for index membership; Google Search Console is. This card watches the figure Google publishes and raises the alarm the moment it moves, so you can act inside Google’s reporting window rather than discovering the loss weeks later in a revenue review.

​
Known limitations / merchant FAQs

The alert fired but my pages still rank when I search for them. Is it wrong? Possibly delayed rather than wrong. Search Console index data lags 2 to 3 days, so the count can drop in the report a day or two before, or after, you notice live ranking changes. Spot-check 5 affected URLs with the URL Inspection tool’s live test; if they still report “URL is on Google”, the drop may be a reporting blip that recovers on the next poll. If they report “URL is not on Google”, the de-indexing is real. How fast does this alert fire after a deploy breaks indexing? It is bounded by Google, not by us. Google has to re-crawl the affected templates and update the Pages report, which takes anywhere from a few hours to a few days depending on crawl budget. The report itself is 2 to 3 days delayed. We surface the drop on the next poll after Google publishes a lower count, so realistic detection latency is 1 to 3 days from the breaking deploy. That is still well ahead of waiting for the click loss to show in a revenue review. Why a 5% threshold rather than firing on any drop? Google’s reported indexed count jitters by a percent or two day to day as it re-crawls and re-evaluates URLs. A 5% threshold suppresses that normal noise while catching a genuine regression. A site shedding 5% of its index has almost always broken something technical. My indexed count dropped but it was intentional, I removed old pages. Will it keep alerting? The alert fires on the drop, then the 7-day baseline re-settles to the new lower count over the following week, after which it stops firing. If you are running a planned pruning programme, expect the alert during the prune and confirm the “Not indexed” reasons match your intent (you should see your removed URLs in the “Not found (404)” or “Page with redirect” buckets, not in “Blocked by robots.txt” or “noindex” unless that was the plan). Does this catch a single high-value page being de-indexed? Not reliably. A 5% drop on an 8,000-page site needs ~400 URLs to leave the index. A single critical page dropping out is below the threshold. For watching specific money pages, pair this with Pages Losing Traffic and the URL Inspection tool on your priority URLs. Will a Google core update trigger this alert? Usually not. Core updates re-rank pages, they rarely de-index them, so the indexed count holds steady while positions move. A core update will trip Ranking-Drop Alert instead. If both fire together, suspect a technical regression that coincided with an update, not the update itself. The count recovered on its own without me changing anything. What happened? Most often the original reading was a transient as Google re-processed a large batch of URLs, or a temporary server hiccup made Googlebot see errors that resolved before the next crawl. If recoveries are frequent, check your server logs for intermittent 5xx responses to Googlebot, which can cause URLs to flap in and out of the index.

​
Tracked live in Vortex IQ Nerve Centre

Index-Coverage-Drop Alert is one of hundreds of KPI pulses Vortex IQ tracks across Google Search Console and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.