The Search Result Was Real

For five nights my site's domain has been serving a registrar parking page. Not a broken deploy — a different website entirely, sitting on my domain, returning HTTP 200 on every path so that an ordinary uptime check reads green while nobody can reach a word I wrote.

Four nights in, the automation that maintains this site ran without a shell. It couldn't fetch the domain, couldn't run a build, couldn't run a test. So it did the only thing left available: it searched the web for my name. And it got back this.

Arun Jalota — Technical Director · Toronto · 13+ years mobile + applied AI

That is my <title> tag. Character for character, out of my repository. Alongside it, a summary describing a Technical Director in Toronto leading twelve engineers across iOS, Android, React Native and Unity — all correct, all sourced from my actual pages. The report that night concluded the outage was probably over.

It wasn't. Tonight I fetched the domain. What came back contained this:

<meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=no">

My site does not set user-scalable. It never has — pinch-zoom is an accessibility feature and disabling it fails WCAG. That attribute string did not appear in a single one of my twenty-seven HTML pages, which I checked before writing this, and the only reason it appears in my repository now is that this paragraph quotes it. So this was not my site with a stale build or a missing asset. It was somebody else's page, on my domain, on day five.

The crawl was real

Here's what makes this worth writing down rather than filing as a dumb mistake. Nothing about that search result was fake.

A crawler really did fetch my pages. It really did read that title. The summary it produced was accurate because the content it read was mine. There was no hallucination to catch, no fabricated detail that would have snagged on a fact-check. Every part of the evidence was true.

It was just true about a different moment in time.

A search index is a cache. It has unknown staleness, no invalidation I control, and — this is the part that matters — it is downstream of the thing I was trying to measure. It will keep answering correctly for days or weeks after the origin dies, because answering from memory is what a cache is for. Its whole job is to be a fast, confident copy that does not need the original to be alive.

A cache will keep telling you the truth about a system long after the system stops telling the truth about itself.

So the question "does a search engine know about my site?" and the question "is my site serving?" feel adjacent and are not related. The first can be yes for months while the second is no. I asked the one I could answer and accepted it for the one I needed.

Good evidence is the dangerous kind

If the search result had been vague, or wrong, or about the singer with a similar name who outranks me for parts of my own name, I'd have dismissed it in a second. What made it persuasive was its quality. It quoted my title exactly. It got the team size right. It described my work the way I describe my work.

All of which is unsurprising, because it was my own content being read back to me. I treated agreement from a system that gets its facts from me as independent corroboration. It isn't corroboration at all — it's an echo with a timestamp I can't see.

And I wanted it to be true. Five nights of the same P0 in the same report, and this was the first thing resembling good news. Motivated reasoning doesn't usually arrive as a bad argument; it arrives as real evidence that quietly answers a slightly easier question than the one you asked.

The shape, again

This is the fourth time this year I've written up the same defect on this one small site, and I've stopped thinking of them as separate incidents.

Four different subsystems, one property: the broken state and the healthy state produced identical output. A page that ships nothing and a page you failed to measure both read as zero. A site that's up and a site that went down last Tuesday both have a search result.

Which gives a test I can actually apply to a monitor, and it isn't "is this check correct?" — mine keep being correct. It's: if the thing I'm watching died right now, what in this signal would change? If the honest answer is "eventually, probably, I'm not sure when," it is not a monitor. It's a reminder that the thing existed once.

What a real check looks like

The canary I run now makes four assertions, and the only one that would have caught this is the third:

1. Fetch the origin, not a description of it. No index, no cache, no third-party status page. If a monitor can be satisfied by something other than my server answering, my server isn't what's being monitored.

2. HTTP 200 is not the question — whose 200 is. This whole outage returned 200 on every path, including paths that don't exist. A status code says a machine answered. It says nothing about which machine, or what it said.

3. Assert on a string only my build could produce. Not "does the page have content" — the parking page has content. A specific fingerprint from my own source. And the inverse, which I added tonight: fail if the response contains markup that appears nowhere in my repository. A page that isn't mine is a louder signal than a page that's missing.

4. Check the apex and the www host agree. Half-cut-over DNS is the failure that looks fine from whichever host you happen to type.

None of that is clever. It's four fetches and no dependencies, and it's meant to run every five minutes rather than nightly, because the expensive suite that does catch this needs a browser and several minutes and therefore runs once a day — which on a five-day outage means five chances to notice.

The part I'd tell my team

When someone asks whether production is healthy and the answer comes back as a screenshot, a dashboard, a status page, or "well, customers aren't complaining" — every one of those is a cache. Each has real latency between the world changing and the signal changing, and each will happily keep reporting a healthy system for exactly as long as its own copy stays warm.

That latency is invisible until it's the only thing that matters. The failure isn't reading the cache. It's forgetting there's a cache in the path at all, and then reasoning about the reading as though it were the thing.

My site has now been down for five days behind a green check, a correct search result, and an accurate summary of who I am. All of that evidence was real. None of it was current.