Deindexed for 31 days: what it actually looks like

On 15 May 2026 the second search engine sent this site 14 clicks, which was an ordinary Friday.

On 16 May it sent 1.

On 17 May it sent 0, and then it sent 0 the next day, and the next, and every day after that for thirty-one consecutive days. In that entire month the site was shown to a human being exactly once, a single impression on 5 June, which produced no click.

Almost everything written about deindexing is written by people selling a recovery service. This is the daily data from an actual outage, including the parts that make our own first diagnosis look wrong.

The three phases

The 128 days of available data split into three unmistakable regimes.

Two things in that table matter more than the gap itself.

The transition was binary, not gradual. Traffic went 14, then 1, then 0, and stayed at 0. A ranking penalty produces a slope. This produced a cliff.

That distinction is the single most useful diagnostic act available when your traffic disappears, because the two have different causes and different fixes:

• A slope means demotion. Your pages are in the index and ranking worse. This is a content, relevance or authority problem.
• A cliff means deindexing. Your pages are not in the index at all. This is a crawl, coverage, verification or infrastructure problem, and almost none of the advice written for the first case applies.

The recovery was not a recovery. Look at the CTR column. Before: 46.56%. After: 10.68%. Impressions per day went the other way: 59 to 150. The site did not come back to where it was. It came back somewhere else, and that turns out to be the most interesting part.

What it was not

Our first hypothesis was thin content. It is the natural one: a site with sixty near-identical tool pages generated from a template is exactly the profile quality systems are built to catch.

Here is the evidence against it. The method matters more than the conclusion, so it is worth walking through in order.

1. Nothing had changed. git log for May 2026 contains zero commits. The last deploy before the collapse was 28 April, eighteen days earlier. The site was byte-identical for the fortnight and a half leading into the blackout and for its entire duration. Whatever happened on 16 May, the site did not do it.

2. The other engine disagreed completely, at the same moment, about the same pages. May 2026 was Google's best month in the project's history: 7,115 clicks, up 61% month over month, on 177,473 impressions.

This is close to decisive. Thin content is a property of the pages. If the pages were the problem, the stricter and more sophisticated of the two systems would not have picked that exact month to have a record.

3. It was cured by a reindex request, and nothing else. No content was rewritten, no templates consolidated, no reconsideration appealed. The URLs were resubmitted through the engine's own console and coverage returned.

This is the most diagnostic fact available, and it points one way: a quality judgment is not reversed by asking to be recrawled. If a page has been demoted for being thin, resubmitting gets you crawled again and demoted again. Coverage that returns the moment you ask for it means the pages were never disqualified. They were simply absent, and nobody had told anyone.

4. It returned with broader coverage than it left with. If a system had judged the pages thin, the plausible recovery is fewer pages ranking. What happened was two and a half times the daily impressions. That is the signature of a fuller index, not a forgiving one.

The honest conclusion is that this was an index-side or property-side fault at the engine, not a judgment on the content. But the conclusion is not the lesson. The lesson is that we cannot prove it, and neither will you. There was no notification, no console message, no status change and no explanation on either side of the event. A month of a real traffic channel vanished and reappeared, and the entire diagnosis above is inference from surrounding evidence.

That is the normal condition. Build for it.

The outage was as long as it took to try the cheapest thing

The fix took minutes. It was available on day one and on every one of the thirty-one days in between.

Nobody tells you a channel has gone. There is no email, no alert, no status change you happen to notice. A fifth of the site's traffic stopped existing on a Sunday in May and nobody went looking for the reason until the middle of June, because Google was simultaneously having its best month ever and the blended total went up.

That is the part worth stealing:

A single traffic number will conceal the complete death of any channel under about a third of your volume. Which is every channel you have except the biggest one.

Two operational rules follow.

Review each channel separately, on a schedule. Not the total. Once a week, look at each source on its own, and specifically look for zeros rather than declines. A decline draws the eye; a zero next to a bigger number does not.

When a channel cliffs, escalate cheapest-first, stopping the moment one works:

1. Read the engine's own console: coverage, verification, manual actions, crawl errors. Minutes. This is where the answer usually is, and it is the step people skip because it does not feel like doing something.

2. Resubmit the sitemap and request reindexing. Minutes. This is what fixed it here.

3. Check the boring infrastructure: robots.txt, DNS, certificate, whether a deploy changed a header. An hour.

4. Only then consider the content. Weeks.

The trap that was one decision away

Suppose we had reacted in May the way founders actually react. Rewrite the thin pages, consolidate the templates, add a thousand words of unique copy to each of sixty pages. Two weeks of work. Then push it live and resubmit the URLs, because of course you resubmit after a big change. Everyone does.

Coverage returns within days.

We would have concluded the rewrite fixed it. We would have published that, with a genuinely convincing before-and-after graph, and we would have been completely wrong, because the resubmission at the end was doing all the work, and it would have worked on its own, in May, in ten minutes.

When you bundle a cheap intervention with an expensive one, the cheap one usually did it, and the expensive one takes the credit, enters your playbook, and charges you again every time you reach for it.

This is not hypothetical. It is the ordinary way growth folklore gets manufactured. Almost every "we rewrote our pages and recovered" post you will read has an unmentioned resubmit at the end of it.

The discipline that saves you takes one line: change one thing at a time, cheapest first, and write down what you expect before you do it. Cheapest-first is not just efficiency, it is experimental design. If the ten-minute action resolves it, you never spend the two weeks and you learn what was actually wrong. Bundling costs you the fortnight and the knowledge simultaneously.

The CTR reversal is the real finding

Return to those two numbers, because they contain something we could not have got any other way.

Before: 46.56% click-through on 59 impressions a day.

A 46% CTR is not a sign of a healthy site. It is nearly impossible across a broad set of queries, and its real meaning is narrow: you are being shown almost exclusively to people who already know your name. Somebody types the brand, you are the only sensible result, half of them click. High CTR on tiny impressions means the index knows you exist and knows almost nothing about what you do.

After: 10.68% click-through on 150 impressions a day.

Read that as one statement rather than two numbers: far more exposure, converting far less well. That is what it looks like when an index stops knowing your name and starts knowing your pages, showing them for jobs, mid-page, beside competitors, to people who have never heard of you.

Before the blackout, the engine knew the brand. After it, the engine knew the product.

And now that the cause is known, the mechanism is not mysterious: the reindex request forced a fresh crawl of the whole site rather than the thin, stale coverage it had been running on. The pre-blackout state was never healthy. That 46% CTR was a symptom of an index holding little more than a homepage, and it read as success only because the one number anybody looks at was high.

Which reframes the whole episode. The most valuable thing this incident produced was a full recrawl that should have been requested in March.

Be honest about the cost, though: clicks per day fell from 27.6 to 16.0. Broader coverage at page-two positions was, in the short term, worth less than narrow coverage at position one. The argument for patience is the trajectory rather than the level, the final week in the data is the strongest in the series, 157 clicks on 1,327 impressions, with the single highest-impression day of all 128 falling on 27 July.

The second engine was worth more than we assumed

One more thing this exposed. The second engine was registered months late, and here is what it was worth once running:

In April it was contributing a fifth as much traffic as Google. Not a rounding error. Every month it was not registered was that share of traffic left on the floor for no reason other than not having filled in a form, which takes about twenty minutes and costs nothing.

It is also bigger than its own numbers, because that index is not consumed only by that engine. Several privacy-focused search products are served by it, and some assistant web-retrieval paths have historically run through it too.

Score your own concentration

The last thing this episode is good for is a calculation almost nobody performs. It takes ten minutes.

1. List every acquisition channel and its share of last month's users.

2. Against each, write what breaks if it returns zero for thirty days.

3. Against each, write what warning you would get. For search, that is nothing.

4. For anything above half your traffic, name the one thing still working on day thirty.

For this project that last answer was uncomfortable and clarifying: on day thirty of a Google blackout, what still functions is the 44% of demand that arrives as a brand query, the people who bookmarked it, and the referring domains. Every one of those is an asset built before the incident, and not one can be built during it.

A channel you did not build is not a channel you can deploy. You can only have already had it.

Questions

How do I tell deindexing apart from a ranking drop?

Look at the shape. A gradual decline over days or weeks is a demotion, your pages are still indexed and ranking worse. A drop to zero or near-zero within a day or two is deindexing. The pages are not in the index at all. Then confirm with a site: search and the coverage report in the engine's console. The two have different causes and almost no overlap in remedies.

Does deindexing on one search engine mean the other will follow?

Not necessarily, and assuming so is how people waste weeks. In this case Bing removed the site entirely while Google had its best month ever on the same pages at the same time. Checking whether the other engine agrees is one of the cheapest and most informative diagnostic steps available, and it should come before any content work.

Will requesting reindexing fix a thin-content penalty?

No, and that is exactly why it is a useful test. If pages were demoted on quality, resubmitting gets them crawled again and demoted again. If coverage returns immediately after a resubmit, the pages were absent rather than disqualified, which tells you it was an index-side fault, not a judgment on your content.

Why did our click-through rate fall after recovery?

Because coverage got broader. A very high CTR on very low impressions usually means only your brand query is indexed. When the whole site gets crawled, you start appearing for many more queries at lower average positions, so CTR falls while total exposure rises. Falling CTR alongside rising impressions is usually the sign that things are working, not breaking.

How often should I check a secondary search engine?

Weekly, and look for zeros rather than declines. This outage went unnoticed for a month because total traffic rose during it, the larger channel's growth completely masked a smaller channel's death. Any channel under about a third of your volume can disappear entirely without moving the number you look at.

How long does reindexing take after a request?

In this case coverage returned within days of the request. That speed is itself diagnostic: an index that responds quickly to a resubmit was not withholding your pages on quality grounds. If you resubmit and nothing happens for weeks, you are looking at a different and more serious problem.

Run this on your own data

• Search Console Analyzer: Drop your export, get a verdict
• SERP Audit: Paste a URL, get the fix list in priority order
• Schema Inventory: Which structured data is on which page
• Internal Link Graph: Which pages nothing points at
• OG Image Generator: And what it looks like once each platform crops it