Why did Google deindex my pages? Three causes, and none of them is usually a penalty

Almost never a penalty. In the overwhelming majority of cases a page leaves Google's index because something mechanical told Google to drop it, and that something was usually shipped by you, your host or a plugin update three weeks before you noticed the traffic fall.

The reason it takes three weeks to notice is that nothing announces it. Search Console does not alert you when a page disappears, so the first signal is a rankings report or a quiet month. The only way to catch it early is to record which URLs were indexed and check them again later, which is why the monitoring in our Bulk Google Index Checker stores each URL's last known state and emails you when one flips from indexed to not indexed.

Why did Google remove my pages from the index?

Because one of three things happened: you told Google to drop the page, your server told Google to drop it, or Google decided on its own that it no longer belonged. Those are different events with different evidence, and the fix for one does nothing for the others.

Manual actions exist, but they are announced. Google puts them in the Manual Actions report in Search Console with a description and a reconsideration path, so if that report is empty you can stop worrying about a penalty and start looking at the three causes above.

Did you deindex the pages yourself?

This is the most common answer and the hardest to accept. The noindex rule is absolute: Google's documentation says it "will drop that page entirely from Google Search results, regardless of whether other sites link to it". One directive, applied site-wide by a staging deploy or a plugin default, removes everything.

The usual sources are boring. A staging environment's noindex shipped to production. A WordPress SEO plugin's "discourage search engines" setting flipped during a theme change. A CDN rule adding the header to a path pattern. A category template that started emitting noindex after an update. None of these announce themselves, and none show up in your own browser unless you look at the response headers.

There is also a trap that works in reverse, worth knowing because it wastes weeks of debugging. If you add noindex and then block the page in robots.txt, Google warns that "the crawler will never see the noindex rule, and the page can still appear in search results". Blocking crawling does not remove anything; it freezes whatever Google already had. Checking the live URL rather than the source template is the fastest way to settle it, which is the difference between checking a page and assuming it.

Did your server tell Google the pages were gone?

A 404 or 410 is not ambiguous to Google. Its documentation states that "the indexing pipeline removes the URL from the index if it was previously indexed". If a migration changed your URL structure and the old paths now 404 instead of redirecting, you asked for the removal in the only language crawlers read.

Server errors are slower but end the same way. Google says "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling", and that already indexed URLs "are preserved in the index, but eventually dropped". A weekend outage costs you nothing. A host that returns 503 under load every afternoon for a month costs you pages, and it looks exactly like a mysterious ranking decline. The same capacity signal that stalls new pages at Discovered, currently not indexed is what removes old ones.

Authentication changes belong here too. Putting a section behind a login, or a security plugin that starts serving 403 to unfamiliar user agents, hands Google a page it can no longer read. Both statuses appear in the Page Indexing report by name, which makes them easy to confirm once you think to look.

Did Google simply decide they were not worth keeping?

It happens, and it is the case people jump to first when it should be checked last. Google indexes what it judges worth storing, and that judgement is re-made over time rather than fixed at first crawl. A page indexed in January can be dropped in August without anything on your side changing.

Duplication is the usual mechanism, and it rarely looks like duplication from the inside. Two URLs saying nearly the same thing get consolidated, and the one Google keeps may not be the one you promoted. In the Page Indexing report this shows as "Duplicate without user-selected canonical" or "Alternate page with proper canonical tag", and the traffic did not vanish so much as move to a URL you were not watching.

The other mechanism is thinness catching up with you. Pages that scraped in at the margin get dropped when the surrounding index gets better, and they resurface as "Crawled - currently not indexed", which is Google saying it looked and declined. That status carries a specific meaning worth reading carefully, because it is the one case here where the answer really is to improve the page.

Could someone have removed them on purpose?

Check the Removals tool before assuming anything technical. Anyone with Search Console access can hide a URL from results, and on a site with agency access, a former contractor or several team members, that is not a rare scenario.

The behaviour is specific enough to identify. Google states that a successful removal request "lasts only about six months", and that using the tool alone will not remove content permanently. So a page that vanished and then reappeared roughly half a year later, with nothing on your side explaining either event, has a very likely explanation sitting in the Removals report.

How do you find out before your traffic does?

Compare today's state against a recorded one. That is the entire method, and no Search Console report does it for you: the Page Indexing report groups by status rather than by URL history, lags by days, and caps its example lists at 1,000 items. A page that silently left the index does not appear as an event anywhere, only as a smaller number in a chart you may not check weekly.

Checking per URL is what closes the gap. Store the verdict for each URL you care about, re-check on a schedule, and treat any indexed-to-not-indexed transition as an alert rather than a number to interpret later. A hundred important URLs checked daily is a rounding error against the 2,000 daily inspections Google allows per property, so the constraint is never quota, only whether anything is doing the comparison.

This is also why a total count is a poor watchdog. Losing forty pages while gaining forty leaves the headline figure flat, which is one of several reasons the indexed-page count misleads when treated as a health metric.

What should you check first?

Work outside in, cheapest evidence first. Fetch one affected URL and read the raw response: status code, X-Robots-Tag header, and any noindex in the HTML. That single check eliminates the two most common causes in under a minute.

If the response is clean, open Search Console and read three things in order — Manual Actions, the Removals report, and the Page Indexing status for the specific URL. The status names the cause in Google's own words, and the fix follows from the name rather than from guesswork.

Then give the fix time to land. Recrawling is not instant, Google offers no timeframe for it, and the gap between fixing a page and seeing it return is where most people conclude the fix failed and start changing things at random.