21/06/2026
A client emailed me at 6 am this month with one line: “We lost 1,200 pages overnight, and Google won’t tell us why.”
They weren’t exaggerating. A “site:” check showed that roughly 1,200 URLs indexed in May were simply gone in June. No manual action. No security warning. No message in Search Console. Just pages quietly dropping out of the index.
They are not alone. Through June, Glenn Gabe and a steady stream of community reports have documented Google slowly deindexing pages across a huge range of sites. It’s happening at the same time as the aftermath of the May core update, and Google has offered no public explanation. So the panic is understandable. The reaction usually isn’t.
When this lands, most site owners do one of two things. They rewrite everything, or they freeze. Both are expensive. Over the past few weeks, I’ve run the same diagnostic on four client sites hit by this, and it has saved every one of them from burning a quarter on the wrong fix. Here’s the exact order I work through.
Start with the data, not the dread
Before touching a single page, I pull the numbers. The mistake I see most is people reacting to a feeling instead of a count.
I open Search Console and go to the Pages report under Indexing. That report tells you which pages are indexed, which aren’t, and the reason Google assigned. For the 6 am client, the most common reason for missing URLs was “Crawled, currently not indexed.” That single label changes the whole investigation. It means Google saw the page and chose not to keep it, which points to quality or duplication, not a technical block.
Then I export the last 16 months of the Performance report and compare indexed-page counts week over week. In that case, the drop wasn’t actually overnight. It had been bleeding about 80 pages a week since the core update finished rolling out. The “overnight” story was just the day they noticed.
If you take one thing from this section, get the reason label and the timeline before you form a theory. A site losing pages to “Crawled, currently not indexed” needs a completely different response than one losing pages to “Server error 5xx.”
Check what your server is actually returning
The second step costs nothing and catches the most embarrassing causes. I crawl the affected URLs with Screaming Frog and look at the response codes Google is really getting.
On one e-commerce site that “mysteriously” lost 400 product pages, the answer took nine minutes. Those URLs were returning a 200 status to browsers but a 503 to the crawler during a specific window each night, when their backup job spiked server load. Googlebot kept hitting the site mid-backup, reading 503 after 503, and started dropping the pages it couldn’t reliably reach.
Here is what I checked in this pass:
Status codes for the deindexed URLs, tested as Googlebot, not just as a browser
Whether the pages carry an accidental noindex tag or a noindex in the HTTP header
Whether robots.txt started blocking a path after a recent deploy
Whether canonical tags point the deindexed pages at a different URL
Three of the four sites I looked at this month had at least one of these problems hiding underneath the scarier “Google is deindexing us” headline. Rule out the boring causes before you accept the dramatic one.
Render the page the way Google does
If the status codes are clean, I move to rendering. A page can return a perfect 200 and still be effectively empty to Google if the main content loads only via JavaScript that the renderer never completes.
I use the URL Inspection tool’s live test and look at the rendered HTML, not the raw source. On a JavaScript-heavy site that lost its blog section, the raw HTML looked full. The rendered version showed an empty content container because a third-party script had begun failing and blocking rendering. Google was indexing a shell with a headline and no body. Thin pages get dropped, and to Google, these pages had become thin overnight.
The fix there was that there wasn’t content at all. It was a single broken script reference. They restored the section in eight days once we found it. If you skip rendering and jump straight to rewriting content, you’ll spend weeks producing words for a problem that lives in your build pipeline.
Judge the content honestly against the core update
Only after the technical checks come back clean do I look at content quality, and here I’m blunt with clients. The May core update reset how Google weighs helpfulness. Pages that survived for years on thin, templated, or near-duplicate content are exactly the ones getting dropped now.
For the original 1,200-page site, after filtering out technical false alarms, about 300 pages were genuinely thin. They were location pages built from a single template, with the city name swapped in. Forty near-identical sentences, no unique information, no reason for any of them to exist separately. Google deindexing them wasn’t a glitch. It was the system working.
We didn’t rewrite all 300. We consolidated them into 40 genuinely useful regional pages, each with real local detail, and redirected the rest. Within three weeks, 31 of those 40 were reindexed and ranked better than the originals ever did. Consolidation beat replacement because it concentrated value rather than spreading it thin again.
One more thing I tell every client at this stage: deindexing is not always a punishment. Sometimes Google is doing you a favor by clearing out pages that were quietly dragging your whole site’s perceived quality down. On that same site, the 300 thin pages had been diluting the authority of the 40 that mattered. Once we removed the dead weight, the pages we kept started performing better than they had in a year. So before you fight to get every lost page back, ask a harder question: did that page deserve to be indexed in the first place? On two of the four sites I worked on, the honest answer for a chunk of the missing URLs was no, and leaving them gone was the right call.
What to do next
If your pages are dropping out of the index right now, work in this order and resist the urge to skip ahead:
Pull the Search Console Pages report and read the exact reason label for the missing URLs, then chart the indexed page count over the last 16 months to see whether this is a sudden break or a slow bleed.
Crawl the affected URLs as Googlebot in Screaming Frog and confirm the status codes, noindex tags, robots.txt rules, and canonicals are all doing what you think they are.
Run a live render test on a sample of the lost pages and confirm Google sees the actual content, not an empty JavaScript shell.
Do those three before you write a single new word. In four out of four sites I worked on this month, the real cause was found in the first three steps, and the content rewrite was either unnecessary or far smaller than the panic suggested.
The deindexing wave is real, and Google’s silence makes it worse. But “mysterious” usually just means “not yet diagnosed.” Run the checks in order, and the mystery tends to disappear faster than the pages did.
If your site is losing pages right now and you’ve run these checks but still can’t find the cause, send me the Search Console reason label and a sample URL. I’ll tell you which of these four buckets it falls into.
