Taking content down means acting on its list of copies, not the original

Say you take a product down from your online store. You hit "Unpublish" in the admin screen, open the product page, and see a 404. Done?

Usually not. That product's name and photo still live in several places. The link preview image that appears when you paste the link into a messenger, the sitemap you submitted to search engines, the content delivery network's (CDN) cache, and the build cache that the next deploy will reuse. There is one original but many copies, and the "Unpublish" button usually knows about the original alone.

It's the same when you ask an agent to "build a way to take posts down." The agent makes the original page return 404, checks it, and reports the job done. That's not wrong. It's just that nobody counted the copies.

The principle — taking something down means acting on the list of copies, not the original

Before you build a feature that hides or deletes content, first write down every place that content gets copied to. Then make the take-down button clear that list item by item, and check against the whole list too.

Copies survive in two forms.

One: derivatives baked separately. A post page and that post's preview image live at different addresses. When you tell the framework "rebuild this page," it rebakes only that page's address and leaves the image address derived from the same post untouched. This actually happened. Taking a post down turned its body into a 404, but the preview image address, with the post's title and cover image baked in, stayed public. Neither a person nor an agent noticed; the security review that runs on every commit caught it. The fix was simple — the take-down button now rebakes the three addresses belonging to a post (the body and two kinds of preview image) by name.

Two: caches that don't know all their inputs. A build tool's cache usually decides "same as last time" by looking at the code. But if a page is built by reading the database at build time, the build output depends on both the code and the data. A cache keyed on code alone doesn't notice when the data changes. When we ran a production build as a test, the database held a single post, yet the build cache brought back the output from back when there were 46. In other words, a post taken down in the admin screen could have reappeared at the next deploy. We closed this one by turning the cache off. Putting the data's state into the cache key was another option, but deciding what counts as "the same data" cost more than the time the cache saved.

In both cases the original had been taken down properly. The problem was that checking the original was where it ended.

Building the list of copies — five questions

Before you build a hide or delete feature, ask these about the content.

1. What other addresses are generated from it? Preview images, thumbnails, RSS and sitemaps, search JSON, print pages.
2. Where is it shown in a list? The front page, category pages, "previous / next post," recommendation slots.
3. Who bakes it ahead of time? Static generation, incremental regeneration, the CDN, browser cache headers.
4. What does that cache look at to call things "the same"? If it only looks at code, don't cache output that depends on data.
5. What has already left the building? Search engine indexes, previews that messengers have already fetched. These we can't delete — so for something like a preview image, make its address switch to a generic image after take-down, and it disappears the next time it's fetched.

Instructions to give your agent

You can put this principle straight into an agent's working instructions.

When building or changing a feature that hides or deletes content:
- Before building, write down that content's list of copies
  (derived addresses · lists · sitemaps · prebaked pages · caches).
- The take-down action invalidates the whole list. Don't stop at deleting the original.
- Check each address on the list in a build identical to production.
  Don't report done on "the original is a 404" alone.
- If the build reads a database or other external data,
  don't trust that build output to a code-keyed cache.
- Check restoring (republishing) against the same list.

The last line matters more than it looks. Fix only take-down, and you open the opposite hole: republish, and only the preview stays a generic image. After the fix, we measured both in a production build: take down → generic preview card and a 404 body; restore → the original image and a 200 body.

Checklist

• Is the taken-down post's body address a 404?
• Do that post's preview and thumbnail addresses no longer show its content?
• Has it dropped out of lists, the sitemap, and RSS?
• Does a clean build with the cache cleared match a build that used the cache?
• Does republishing bring all of the above back?

"Deleted" isn't the state of one original; it's the state of the whole list of copies. Without the list, you have no grounds to say whether it's deleted or not.