Indexed Pages Dropped in Search Console: What We Lost

By Ugur Saritepe · September 7, 2026

Your indexed page count in Search Console fell and you do not know what you lost. Ours did the same: 560 indexed pages on 28 August, 524 nine days later. We diffed impressions, inspected 436 URLs, and found nothing broken. Here is the method, what the 36 turned out to be, and how to tell cleanup from real loss.

You cannot look up the history, so diff around it

The first dead end is the obvious question. I asked the assistant connected to our Search Console data:

Can you see indexed history from gsc ?

No. Google does not expose the Page indexing report's history through any API, so no tool can pull the "indexed pages over time" chart; it exists only in the Search Console UI, where you can export it as a CSV. Two more traps while we looked: the sitemap endpoint's "indexed" field read 0 for both of our sitemaps, a known quirk of domain properties rather than a real signal, and URL Inspection returns only today's state, with no history. The usable proxy is search analytics by date, which goes back 16 months: the first day a page records an impression is a reliable lower bound on when it entered the index, and the day its impressions stop is a lead on when it left.

The diff that named the losses

I gave the assistant the two numbers I had, and the worry as I typed it: "So we have 560 indexed page in 28 Aug, now 524 I dont know what we lost". The method it ran is the part worth copying:

pages with impressions 1 Jan - 27 Aug, diffed against 28 Aug - 3 Sep
URL Inspection on all 436 candidates; HTTP checks on the quiet ones

4 legacy redirects reclassified "Page with redirect" (recrawled 28-31 Aug)
10 thin /game pages pruned to "Crawled, currently not indexed" (no recrawl)
~22 remaining: never earned an impression, invisible to every API
every URL with 2026 impressions: still 200 or a deliberate redirect

The whole check took 15 minutes. The unnamed remainder is real, though: the diff can only see pages that earned at least one impression, so roughly 22 of the 36 are almost certainly thin pages that never showed in a search result. The exact list exists in one place only, the "Why pages aren't indexed" trend in the Search Console UI, where the reason whose count rose is the bucket. We have not opened that trend view yet; the 14 named losses above came from the API side alone.

Both buckets were Google catching up, not Google leaving

The four redirects were URLs we had retired in June and July. Google indexes the target of a permanent redirect and treats the source as an alternate name, per its redirects documentation, but that reclassification waits for a recrawl. Ours took one to two months to arrive, and when it did, four pages left the count in four days. That is a bookkeeping correction, delayed until Google felt like visiting.

The ten pruned pages are the more interesting bucket. They are long-tail game detail pages, each last crawled in April, each earning 1 to 3 impressions in August and none since. Google moved them to "Crawled, currently not indexed" without fetching them again: a quality call made from what it already had, not a response to anything we changed. If you recognize that state from the other direction, a new page stuck waiting, that is a different problem with a different fix, and we wrote up the six weeks Google stopped indexing our new pages separately.

The count is a net, and it moves both ways

The same window that lost 36 pages gained some: five list pages moved into the index between 29 August and 6 September, and two more advanced from unknown to discovered. The inspection also found the next drop before it happens: eight retired or redirected slugs are still counted as indexed only because Google has not recrawled them, two untouched since June. The count will dip by roughly that many again, and it will mean nothing.

One structural note from the wider pull: of 276 game pages that appeared in search this year, only 150 are in our sitemap. The rest got indexed off internal links, and they are exactly the pool Google trims from; an earlier pass had already shown that adding more internal links does not reverse these prunes. We have not changed the sitemap in response, and the unsitemapped game pages remain the pool Google trims from.

When a falling count is a real problem

The count is the wrong thing to watch; the pages that earn your clicks are the right thing. Run the check in that order:

1. Inspect your earners, not your total.Take the pages that get your clicks and run URL Inspection on each. Good output: "URL is on Google" with a recent crawl date. Bad output: a state change on a page you did not touch, which is where the investigation actually starts. Google's own traffic-drops debugging guide (updated December 2025) draws the same line: site-wide questions go to the Page indexing report, page groups to URL Inspection on samples.

2. Match the drop's speed to its cause. A cliff on the chart points at something site-wide: a robots.txt block, a noindex header shipped in a deploy, a hosting change. A slow slide like ours points at recrawl-paced reclassification, because page-level changes only register as Google revisits each page. Ours took months to show up.

3. HTTP-check what changed state. Run curl -I against each reclassified URL. A 200 with the content you expect, or a redirect you shipped on purpose, is cleanup. A 404 you did not intend, a 500, or a redirect you cannot explain is a real loss, and the fix is on your side. All 14 of our named pages passed this; if yours do not, start there. A page that was never indexed at all is a different diagnosis again; see URL is unknown to Google.

Run the same check on your site

The whole verification is three asks if your data is connected to an assistant, the way the rest of my routine runs. 1."Which of my pages had impressions before date X but none after?" That is the diff, and it works in any tool that can query Search Console. 2. "Check the index state of each of those URLs." That is URL Inspection per page. 3."HTTP-check the ones that changed state." Sort the results into reclassified-on-purpose, pruned-and-thin, and actually-broken; only the last bucket is work. The other assistant-side workflows follow the same pattern. If you want the site-level basics checked first, the free triage report runs eight checks from a URL alone, no account needed.

FAQ

Why did my indexed pages drop in Search Console?

The most common causes are Google reclassifying pages it recrawled, such as redirected URLs moving to the Page with redirect state, and Google pruning thin pages it decided not to serve, which show as crawled, currently not indexed. Broken pages, an accidental noindex, or blocked crawling also lower the count, but check for reclassification first: on our site, all 36 lost pages traced to cleanup, and none needed a fix.

Is it bad if my indexed page count decreases?

Not by itself. The count is a net figure that moves in both directions, and Google routinely trims pages it has decided not to serve. It is bad when the pages that earn your clicks leave the index. Check those specific URLs with the URL Inspection tool. If they still show as indexed and still return 200, a falling total is Google narrowing to what it will actually serve, not a problem to fix.

How do I find which pages Google removed from the index?

There is no API that lists them. The Page indexing report in the Search Console UI shows the trend per reason, and that is the only place the exact bucket is visible. The workable API-side method: pull every page that had impressions before the drop, compare against impressions after it, run URL Inspection on each page that went quiet, and HTTP-check the ones that changed state. That named 14 of our 36.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works