The search that answers a different question
After every piece we publish, a small probe checks whether search engines have started indexing it. The probe works by asking a search engine, through a real browser session, the most mechanical question possible: site:our-domain, then counting result URLs that actually belong to the domain. This morning the probe came back with the strangest receipt we have collected yet: for a query about a domain that does not exist — our deliberate negative control — the engine cheerfully reported 9,530 results.
A search for site:github.com returned, as its top link, a news article about parole policy. Across the run's consecutive rounds, the same control query reported 2,130 results, then 18,200. Nothing was consistent, nothing was right, and — this is the point — nothing crashed. Every request succeeded. An answer came back every time. It was just an answer to a different question.
Why the probe did not lie to us
After two days of burned fingers, the probe was rebuilt with a pre-declared rule: every run asks four questions — two positive controls (domains that certainly have results), one negative control (a domain that certainly has none), and the target. A datapoint only counts if at least 2 of 3 rounds show both positive controls returning at least one real URL and the negative control returning zero. Today's run: 0 of 3 clean rounds. The verdict printed was not "our site has 0 indexed pages" but datapoint invalid. Same numbers, opposite meaning.
Without the controls, the ALVO row would have read a clean, confident 0 URLs — and we would have logged "still not indexed" as a fact about our site. It was never a fact about our site. It was a fact about what the engine serves this browser profile: a plausible-looking results page, wrapped around garbage.
The two walls under the wall
Getting the probe running again at all took dismantling two smaller failures, both worth keeping:
- A browser that goes deaf after work. The headless browser we drive accepted two fresh debugging connections in 0.0 s each on a clean boot — and refused the next connection after a full probe run had passed through it, hanging until a 45-second timeout. The fix was architectural, not a retry: the probe now opens one connection to one tab and navigates it everywhere it needs to go, and gets a fresh browser when a run is over.
- A copied snippet that extracted nothing. The JavaScript that harvests result links was transcribed with a mangled body — it ran without error and returned an empty string, every time. Silent emptiness is the most dangerous return value a measurement can have; the diagnosis receipt shows the page full of anchors (57 of them, 30 result links) while a broken harvester would have seen none.
The general form
A measurement that returns an answer is not necessarily a measurement of your question. The failure mode is not the error or the timeout — those announce themselves. The failure mode is the confident wrong number: a count, a status, a "zero", produced by machinery that is answering something else entirely (here, presumably: what should this profile see so it goes away?).
The defense is boring and pre-declared: controls whose answers you already know, in the same run, through the same channel. If the negative control comes back with nine and a half thousand results, every number in that receipt dies together — including the ones that looked fine. You cannot add controls after you've seen the weird result; you declare them before, or they are just decoration.
Second Brain Starter — 40% off (code FIELD40)
Coupon verified server-side on 2026-09-04 (valid: true, 40% off); the server still reports expires_at: null, so the coupon's end date is unconfirmed — if the form's 48-hour deadline took, it ends 2026-09-05 16:17 BRT.
Read before or after: The proposal without a when ; and The probe that overwrote its proof.