A Google developer doc has been 404 for five days. Here is the receipt.
Since 20 September 2026, an official Google developer documentation page — the Web Search Service API overview — has returned 404. No redirect, no replacement, no announcement we can find. Our Policy Radar, which watches 36 first-party sources every day, has recorded the failure each day since it began, with dated timestamps and reproducible SHA-256 hashes. This post is the running log of an empty page. We do not know why the page is gone; we will date the return when it happens.
The fact, in a table
| Date (2026) | Check | Result |
|---|---|---|
| 20 Sep, 22:15 IST | Daily sweep | Page begins returning HTTP 404 (previously live; last content change 16 Sep) |
| 21 Sep, evening | Daily sweep | Still 404 |
| 22 Sep, 22:15 IST | Daily sweep | Still 404 — flagged publicly as unverified (HTTP 404) |
| 23 Sep, 22:31 IST | Daily sweep | Still 404 |
| 24 Sep, 09:22 IST | Manual spot-check (curl + browser UA) | Still 404 — confirmed in person before publishing |
Every sweep row is reproducible: the hash prefixes are published on the Policy Radar; the method is below.
What the page was
https://developers.google.com/web-search-service/overview — the overview doc for Google's Web Search Service API family, inside the official developers.google.com documentation tree. Not a blog post, not a marketing page. A doc that other software is built against.
What we know — and what we do not
We know: the page returned content until at least 16 September; it returns 404 now, from multiple networks and user-agents; the 404 is served by Google's own servers (an intentional response, not a network fault); and we have found no redirect, no note, and no press coverage of the removal.
Why this matters if you are not Google
Documentation is load-bearing. Dashboards, plugins, citations and integrations are built against pages exactly like this one. When such a page can vanish for days without a trace, "we monitor our vendors' announcements" is not diligence — because announcements do not happen. Watching the sources themselves, daily, is the only version that works. That is the discipline we run on ourselves before we ever recommend it to a client.
How the detection works (method, public)
Thirty-six first-party sources — search engines, AI labs, crawler registries, open specs — are fetched daily. HTML is tag-stripped, JSON is key-sorted, whitespace normalised, and the result SHA-256 hashed. A hash change logs changed; a fetch failure logs unverified — a failed fetch is never reported as "unchanged". A human reads the diff before we interpret anything. On the morning this post was written we independently re-derived one published hash prefix and got the identical 12 characters, which is the point: verify before you trust — including us.
Live ledger: Policy Radar · raw JSON: engine-watch · event log: Engine Changelog
Questions this post keeps getting
Which Google page is missing?
developers.google.com/web-search-service/overview — the Web Search Service API overview, an official doc in the developers.google.com tree.
Could this just be your tools failing?
The 404 is served by Google's own servers — an intentional response, not a fetch error on our side. Verified with curl and browsers from more than one network, plus manual checks on the morning of 24 September.
How do I verify the timeline myself?
Public ledger: policy-radar.php carries the daily table with hash prefixes anyone can re-derive (sort keys, SHA-256); engine-changelog.php lists the dated events.
Running log
- 2026-09-24 (day 5): Post published. Page still 404 at 09:22 IST manual check.
- New entries are appended here, dated — including the day the page returns, if it does. A fixed page and a vanished page are both news; the log records both.