A request to close a site after its operating period involved more than removing a menu link. Another address could show the same material, and someone who already knew a document or image address could request it without visiting the homepage. I reread the historical conversation and the retained retirement-response code to identify where serving stops. I did not close or reopen a customer site while preparing this article.
Visitors may know more than the preferred address
The historical request pointed to a deployment address and asked for its linked addresses to stop exposing the site too. I read that as a request to define a serving boundary, rather than to edit one screen. A custom domain, an original deployment address and a separately shared document address must first be distinguished by where they lead. Similar human-facing names are not enough to establish that they are the same service.
The earlier domain-connection article discusses DNS, project association and the page actually reached. Retirement follows that connection inventory in the opposite direction and asks which entrances remain. Seeing a closure notice through one entrance cannot fill in the response for another. I keep customer addresses private here and describe the two kinds of response boundary retained in the actual source.
Separate the router decision from the origin-address response
The custom-host router has an explicit closed flag for one entry. When a request for that entry reaches the closed branch, it creates a 410 response before reading the original site. That branch precedes generating SEO files or fetching the upstream content. It establishes a boundary against allowing a retired request to continue through the ordinary successful-page path.
A separate local retirement folder retains its own _worker.js. Its handler also returns a retirement response without reading the original assets. That is why I inspect the custom-host router and direct deployment handler separately. Either source file alone cannot prove that every current alias and platform route is connected. This review did not query remote route registrations or current customer deployments.
Include direct image and stylesheet requests in the questions
Replacing the homepage with a closure notice while continuing to serve original files leaves saved image addresses and deep document URLs as separate reading paths. The retained retirement handler is shaped to produce the same retirement response, rather than selecting normal assets by request path. I distinguish that source intent from actual deployment coverage and include requests beyond the homepage in the review questions.
The code combines status 410 with no-store and noindex, nofollow and noarchive headers. What the server returns for this request and the indexing or archiving instructions attached to it have different roles. Adding headers cannot establish that previously downloaded copies, old caches or search results have all disappeared. A retirement response and cleanup of past exposure are separate completion questions.
Retire one target without taking neighboring targets with it
The shared router contains several active destinations besides the retired entry. Blocking the whole shared address or changing its default destination cannot substitute for retiring one target. The selected source keeps host-specific settings alongside normal path routing. The intended shutdown scope and the intended preservation scope need separate names so their effects can be assessed.
The existing test file contains a closed-host homepage assertion for 410 and separate assertions about other routes. I read that file but did not execute the original tests or customer program in this run. One homepage assertion does not establish coverage for all methods and assets. Some older expected destinations also differ from the current configuration, so I did not borrow historical test success as current evidence.
Keep addresses and request kinds together in the review sheet
For another project, each known entrance can be paired with a homepage, direct document, image, stylesheet or script, and discovery file. Read requests, separate methods such as HEAD, and addresses containing query parameters can be split according to the required scope. This is a framework for a future actual review, not a new response matrix measured against this customer's server.
Expected outcomes should separately state the retirement status, whether original body or asset bytes remain accessible, and whether unaffected neighboring targets still work. An unlisted alias has not been automatically discovered and verified. Responsibility for an up-to-date connection inventory differs from responsibility for testing each request. Keeping both explicit prevents a small check count from becoming a claim of complete retirement.
Retirement and preservation are not the same deletion command
The historical completion message says that the project and prior deployment history were retained. I did not reopen that remote history to verify it now, and I changed no customer files or operating state. Stopping public service and preserving material for later review are separate decisions. Having material from which recovery might be possible is not permission to publish it again.
The same distinction applies to a maker article. Rather than reveal customer copy, addresses or contact details again, I describe the request boundary that was made. Retained source, retained retirement handlers and a currently retired service at every address are facts requiring their own evidence. This article records a review of the historical request and selected retained source, not a new operational shutdown.
Where the existing publication-state module can be reused
An already published module excludes withdrawn entries from catalogs and related links and checks publication state again for direct body requests. I extracted the current CMS version 3 code and ran nine checks with a synthetic store. They covered withdrawn-body denial, a changed state on the next read, removal of private fields and detached returned arrays. I reused that implementation to explain the shared boundary principle.
The module is not a host router or a static-asset gate and does not generate a 410 response. Its checks are not tests of whole-site retirement. Instead of adding another package, I connected the exact scope of the existing publication-state code. Asking separately whether an entry is absent from navigation and whether a direct request still serves it helps a reader define the retirement scope more clearly.