§1Deletion is a request, not a state change
When a page is removed, the change feels total. The file is gone from the source, the build no longer emits it, and the URL answers with a redirect or a gone status. Every instrument under your control agrees the page is finished.
None of those instruments own the copy that matters. A search index holds its own snapshot, refreshed on its own schedule, and that snapshot is what a person actually sees. Removal at the origin is instantaneous. Removal in the index is eventual, and “eventual” is measured in days.
§2The result outlives the page
The case that taught me this: a page was removed and its URL redirected to a replacement. The origin was correct within seconds. The search result was not. For more than four days the old entry kept rendering—its previous headline, its previous summary—describing something the site had already stopped doing.
People clicked it. They arrived at a page that had never made that claim. The redirect worked perfectly and the experience was still broken, because the statement that generated the click was served by a surface the redirect never touched.
A redirect repairs the destination. It does not retract the claim. Between removal and recrawl, the loudest description of your work is one you have already decided to stop making.
§3Three surfaces keep the old truth
The cached result and any rich attributes attached to it—headline, summary, and structured details.
Sitemaps, JSON feeds, structured data, and machine-readable files that still enumerate the URL.
Caches, aggregators, and answer engines that snapshot on a schedule you cannot see.
The second one is the embarrassing one, because it is entirely yours. A deleted page that is still listed in your own sitemap or machine-readable inventory is not a stale cache; it is an active, current, self-published claim that the page exists.
§4Submit the old URL, not just the new one
The instinct after a migration is to announce the replacement: push the new URLs, ask for a crawl, watch them appear. That instinct leaves the actual problem untouched. The engine already knows about the new page eventually. What it does not know is that the old one is finished.
Removal is the notification with the shortest half-life and the least attention paid to it. Submit the removed URLs explicitly, through whichever fast-notification or removal channel the engine offers, and treat that submission as part of the deletion rather than as follow-up work.
§5“Removed” is a checklist, not a delete
ORIGIN
The URL answers with the intended status, and the
destination honours the intent that brought the visitor.
INTERNAL
No surviving page still links to it as if it were live.
SELF-PUBLISHED SURFACES
Sitemap, feeds, structured data, and machine-readable
inventories no longer enumerate it.
NOTIFICATION
The old URL is submitted for recrawl, not only the new one.
RECHECK
A dated external check confirms the old promise
stopped being served.§6Verify from outside the building
A request against your own origin proves what your server does. It proves nothing about what a person is shown. Those are different systems with different clocks, and only one of them is the one your visitor uses.
So the closing check for any removal is an external one: run the query that used to surface the page and read what comes back. Until that result changes, the old version is still the one being served—whatever your repository says. Live truth beats local assumptions, and this is the case where the gap has a reader standing in it.
The compact rule
- Removal at the origin is instant; removal in the index is eventual.
- A redirect fixes the destination, never the claim.
- Audit your own feeds first—they are the one stale surface you fully control.
- Notify engines about the removed URL, not just the replacement.
- Close the loop with an external check, not a local one.