Killing a content cluster on evidence
A question-page cluster built on a sound theory, then deindexed by Google. When to stop a reasonable bet, what counts as a verdict, and what to keep.
Earlier this year I built a cluster of question pages on motomotar.com, my eval-gated content site for Indian car buyers. The theory was sound. Search results are full of low-competition “People also ask” questions, and a young domain that answers them well should earn topical authority it can pass, through internal links, to the price pages that matter. Google deindexed the cluster wholesale.
The hard decisions in product are rarely about bad bets. Bad bets announce themselves. The decision this essay helps a PM make is when to stop a bet that was reasonable going in, and how to tell a verdict from a slow week. It covers the signal you should write down before launch, how long to wait, what to keep from a program you kill, and the same logic applied to a product I recommended against funding at a newsroom.
The theory names its own test
A good bet comes with a mechanism, and the mechanism tells you what to watch. The question-page theory ran in a chain: the pages get indexed, they rank for their questions, and the authority they build flows to the price pages they link to. Each link in that chain can be observed. The first one, indexation of the cluster itself, is also the cheapest to read and the earliest to move.
So the signal was settled by the theory before the first page went live. If the pages don’t stay in the index, nothing downstream can happen. I read it from a local mirror of Search Console that records URL-inspection results over time, which matters, because a time series shows a page leaving the index and a snapshot doesn’t.
If you’re launching a bet like this, write three things down at launch: the signal, the comparison group, and the window. The signal comes from the mechanism. The comparison group is something on the same product that you expect to behave differently. The window is how long you’ll wait before the signal counts.
How long to wait
On a young domain everything indexes slowly, and that sets the floor for the window. In August only 49 of motomotar’s 618 on-road price pages were earning any impressions. By October, 89 of them were indexed, about 14%. Against that background, a cluster that indexes slowly has told you nothing yet. The whole site indexes slowly.
The window has to be long enough that the site-wide crawl rate stops being an explanation. That means months on a site like this, and the question-page verdict came over months. Waiting that long is uncomfortable when you can generate a new page in minutes. It’s still cheaper than killing a bet that would have worked, or scaling one that was already dead.
A verdict needs a comparison
Single pages flicker. A page drops out of the index and comes back, impressions move for a week and stop, and none of that is a verdict. A verdict is a pattern across a whole group, set beside a comparison group on the same site, over the same window, doing the opposite.
That is what the question pages gave me. The cluster was deindexed as a whole. Over the same months, all nine state road-tax rule pages indexed, at positions 6 to 12. Same domain, same crawl budget, same author, same months. The variable left was the page itself. A road-tax rule page carries a hard data payload that a buyer can use. A page answering a question that’s answered everywhere else carries nothing a crawler hasn’t seen.
I’d already learned to trust comparisons like that. A controlled request-indexing test on motomotar had indexed 16 of 20 treated pages while a 10-page holdout stayed at zero. A holdout turns “it seemed to help” into a measured difference, and a natural comparison group does the same for a kill.
So I stopped adding to the cluster. The evidence system surfaced the pattern, and the call to stop was mine. That’s the same split I used when I noindexed about 139 orphaned news posts: the data made the case, and a named person made the decision.
Keep the method from a killed program
The question pages weren’t the only thing I closed. Through late summer, new content went through a strict program, the keyword ladder. Candidate terms passed a series of vetting gates, launched one cluster at a time, and waited weeks for a ranking verdict before the next cluster could start. The road-tax pages that indexed came out of it.
By October the ladder had done its job. It had shown which pages earn a crawl, and a one-cluster-at-a-time gate was the wrong shape for scaling that finding. I closed it on 18 October 2026, kept its verification steps and dropped its selection gates.
A program is a bundle. Some of its parts exist to find the answer, and some exist to protect quality once you have it. When the answer is in, the finding parts are done. The protecting parts usually aren’t, and throwing them out with the program is how a good kill turns into a quality regression.
The same logic, with a cost model
At Asianet News I built a working AI debate platform with real-time avatars, as a submission for a Google grant bid. The bet was reasonable, because the grant would have paid for it. The grant didn’t land, and the team considered funding it ourselves.
That changed the question. With outside funding gone, the product had to cover its own costs, and real-time avatar rendering and voice sync are expensive to run. I quantified those compute economics and recommended against self-funding. It never served real users.
The structure matches the question pages. Each bet rested on one condition: outside funding for the debate platform, and low-competition questions earning authority for the cluster. When the condition failed, I re-ran the case with a number. A cost model is a kill criterion you can write before launch: if each session costs more than this, and nobody else is paying, we stop.
What this means if you’re the PM
- Write the signal, the comparison group and the window at launch. Derive the signal from the bet’s mechanism, so the theory tells you what to watch.
- Set the window against the product’s slowest background process. If the whole site indexes slowly, a slow cluster has told you nothing yet.
- Treat a pattern across a group, set against a comparison group, as the verdict. Single pages and single weeks are noise.
- Kill the program and keep the protections. Separate the parts that found the answer from the parts that guard quality.
- Name who makes the call. Evidence systems should surface the pattern. A person who owns the outcome should stop the bet.
The indexation figures come from motomotar’s Search Console mirror; the debate platform is from my time as Senior PM at Asianet News. More in the motomotar case study.