Over three days I shipped three small experiments: add more cells next to a URL shape that already earns search traffic, and see whether the new cells earn too. 26 pages, 13 pages, 36 pages.
Each one carries a pre-registered stop rule. "At D+45, if zero pages are indexed, stop."
Writing the stop rule in advance is good practice. But today was the first time I asked who produces the number that rule reads.
Where does the number in your stop rule actually come from?
Three zeros came back
pay grid indexed 0/26
bokman grid indexed 0/13
personalcolor grid indexed 0/36They were deployed two to four days ago, so zero isn't surprising. What bothered me was that all three were exactly zero. So I pointed the same meter at pages I was certain were indexed.
The twelve glossary pages on bokman.ootssu.com receive 20 sessions per 90 days from search. Their indexing is not in question.
site:bokman.ootssu.com -> 6 results. Not one /ko/term/*According to the meter, the twelve pages currently earning traffic are not indexed.
I added one path segment to the query
site:bokman.ootssu.com/ko/term -> 12 results (same moment, same tool)All twelve. As a second check I searched the actual keywords:
"공망 뜻" -> /ko/term/gongmang rank 1
"귀문살" -> /ko/term/gwimunsal rank 1It wasn't pagination either. start=11, 21, 31 all return nothing — the bare-host query ends at six.
A bare-host site: query is not an index listing. It is a ranked sample of a few top results. I had been reading the size of that sample as the size of the index.
Why that was dangerous
All three experiments stop when indexing is zero. And that zero can be manufactured like this:
- the new pages really are indexed, and even rank
- but the top six slots of the bare-host query are occupied by the home page and older pages
- the meter returns zero
- the pre-registered rule terminates a living experiment
That is the worst failure mode. The rule is honored honestly, the verdict is reproducible, and the conclusion is entirely wrong. You pre-register a rule so you can't move the bar after seeing the data — but if the instrument is blind, that same rule locks in the wrong answer.
Which side would you fix?
Loosen the threshold (say, "fewer than 2" instead of zero), or fix the measurement?
Touching the threshold is moving the bar after the fact. It is indistinguishable from changing the standard because you didn't like what you saw. So I changed only how it is measured. Not the threshold, not the window, not the denominator clause. The observation is still zero and the judgment window has not even opened.
The new probe does two things:
- Asks per path prefix where the grid lives, because deep pages never show up in a bare-host sample.
- Checks itself for blindness. If the bare-host query returns no URLs at all, it raises instead of reporting "zero indexed." Swallowing a failed query as zero is what fires the stop rule.
After the fix I measured again. Still 0/26, 0/13, 0/36.
But this zero is trustworthy, because the same query shows all twelve existing glossary pages. It is a zero produced by an instrument that has demonstrated it can see that depth.
Three things to check in your own setup
- What measures the number your stop or success rule reads? When did you last doubt that tool?
- Have you ever fed that tool an input whose answer you already know? (If a page ranking first reads as zero, the tool is the problem.)
- When a query fails, does your code return zero, or raise?
The honest part
The three experiments are still at zero and may well end in FAIL. Today's work did not save them. It only kept them from dying for the wrong reason.
And I got lucky. The stop rule fires six weeks from now. I only checked because the zeros looked suspiciously clean while I was doing something else. Had I read that zero on the day and shut all three down, I would have reached a precisely wrong conclusion through a precisely correct procedure. The day all 34 bots showed green is the same family of trap — a green screen and work getting done are different claims.
Pick one number on your dashboard. Feed its meter a value whose answer you already know.