When Google drops pages: reading index volatility without panicking

Every site loses indexed pages. Most of the time it is noise. Occasionally it is the first signal of something that will cost you real traffic — and the hard part is that both look identical on day one: the URL was indexed yesterday, today it is not.

Making that call well requires separating four very different causes.

1. Your change

You shipped something. A redirect map with a hole, a template change that noindexed a section, a canonical flip, a render regression that empties the page for the crawler. This is the best possible cause, because it is yours: revert or fix, and the index follows within days.

The signature: the drop cluster in time with a deploy. If your monitoring only shows the index, you will blame Google for your own release. Keep a deploy log next to your coverage history.

2. Quality re-evaluation

Google continuously re-scores pages. A page that lost its internal links after a menu redesign, a page whose content is now duplicated by a newer one, a section that accumulated thin entries over a year — the re-evaluation lands weeks after the actual cause.

The signature: the drop is permanent across several crawls and affects pages that share a weakness. One-off URLs come back; a class of URLs does not.

3. Google-side volatility

Index composition shifts. Canonicalization choices get revisited, dedup decisions get re-tuned, and during confirmed indexing events large numbers of pages — including healthy ones — fall out, often to return days later.

The signature: the drop is broad, not clustered on your weak spots, and it reverses. This is why "wait one more crawl" is genuinely good advice — after you have ruled out cause 1.

4. Rendering and serving flukes

The crawler got an error page, a timeout, or a degraded render on its last visit. The page is fine; the last crawl was not. Next crawl fixes it.

The signature: isolated URLs, mixed verdicts (some moved to "crawled, not indexed", some to "server error"), quick self-recovery.

What to actually do

In order:

1. Check your deploy log first. Correlate the drop timestamps with releases. If a release matches, stop reading forums and start reading diffs.
2. Count the cluster. Five URLs is noise. Five hundred URLs sharing a template is a cause 2 signal. Everything equally, regardless of quality, points to cause 3.
3. Look at transitions, not snapshots. A URL that dropped and recovered twice is flake (cause 4). A URL that dropped and stayed is a decision (cause 2). You cannot see this in any report that only shows today's state — you need the history per URL.
4. Only then change things. Every reactive sitewide change made during cause-3 volatility costs you more than the volatility did.

The part that is unacceptable

Volatility is normal. Not noticing for six weeks is not. The expensive scenario is not the drop — it is the drop of a money page during cause 2 that nobody noticed until the traffic chart caught up a month later.

That is the gap indexsubmit exists to close: every monitored URL's verdict is recorded daily, transitions trigger alerts (an indexed page dropping, or starting to 404), and the 30-day trend distinguishes "Google shuffled things" from "our template broke" before you have to.

If you have ever found a dead money page by accident, set up alerts — the next time it happens, you will be the first to know.