New independent field guide, published 17 October 2026. Examples are illustrative. The historical directory records linked below are separate source context, not current recommendations or earlier versions of this essay.
Broken links are easy to imagine as pages that return an error. A more subtle failure is a successful response containing something unrelated to the resource the directory promised. The address still opens, but its meaning has changed. Redirects, expired hosting, reorganised collections and reassigned domains can all create different maintenance problems. This guide builds a practical triage method using invented examples. It distinguishes a technical response from editorial equivalence and explains how an archive can preserve historical context without becoming a substitute for a current verification. None of the old directory destinations in this edition is represented as currently checked or endorsed.
Measure availability without overstating it
An HTTP response code describes how a server handled a request under particular conditions. It does not certify the accuracy, identity or usefulness of the returned content. A successful response can contain a generic error message, an access screen or a newly repurposed page. Conversely, a temporary failure does not establish that the resource has permanently vanished. Record the response and the request context first. The directory's editorial action comes after comparing what arrived with what the entry says a reader should expect to find at that destination.
In a fictional audit, a resource called municipal map index returns a normal page containing only a sale notice for the domain. A simple status checker might mark it healthy, but the directory entry is no longer fulfilling its purpose. Another resource might reject an automated request while remaining available through an ordinary browser. The observations need different notes. Treat a tool's inability to retrieve content as a limitation of that check unless further evidence establishes a wider outage. This distinction prevents both false reassurance and unnecessary removal based on a single incomplete test.
Follow the redirect and inspect what moved
HTTP semantics distinguish several redirect statuses with different meanings and method-handling rules. For directory maintenance, the first practical question is where the request ends and whether the intended material survives there. A move from an old document path to a new equivalent document is different from a redirect to the publisher's homepage. Both can be legitimate server configurations, but only the first directly repairs the specific reference. Preserve the chain or at least the starting and final addresses with the observation date before deciding what address to publish.
An invented archive entry might point to a nineteenth-century map viewer. If its old URL redirects to a general city portal, updating the entry to that portal while keeping the map-viewer description would be misleading. The editor can search within the known publisher's collection for an equivalent resource, but should not silently substitute a thematically related page and call it the same item. If no equivalent is established, mark the limitation or retain a historical reference. A redirect is a navigational instruction from a server, not an editorial statement that two resources are interchangeable for every purpose.
Distinguish disappearance from content drift
Link rot and content drift overlap but are useful to separate. In one case the intended resource becomes unavailable; in another the address continues returning material whose content or purpose has changed. A directory description can become stale even when the publisher remains the same. A teaching page may be rewritten for a different audience, a dataset may be replaced by a new edition or a once-public document may require an account. Record which property changed. The response should match the problem rather than treating every discrepancy as a binary broken-link flag.
A fictional statistics resource illustrates version drift. The same address once provided a fixed report and now presents a continually updated dashboard. Both concern the same subject, but they support different citations and workflows. If a directory entry promises the report's original tables, it should identify an archived or versioned copy where available, or update its description to the dashboard's current scope after review. Do not keep an old publication date attached to substantially different material merely because the URL string did not change. Identity, version and access location need their own fields when the distinction matters.
Use archives to preserve context, not to invent continuity
A capture can show what a page contained when it was saved. It does not prove uninterrupted availability before or after that moment. The Memento framework describes time-based access to resource states, making the version dimension explicit. A directory can use that idea without implementing the protocol: distinguish the original resource address from the capture address and the capture time. The historical version then becomes a clearly named destination rather than an invisible replacement for the live page. Readers know they are inspecting a saved state, not using an active service.
Captures also have limits. Scripts, images or linked downloads may be missing, and a page's visible date may refer to something other than its first publication. A screenshot of a working-looking interface is not proof that its controls still function or that every underlying file was saved. Describe the scope that was actually recovered. In this edition, old directory names and addresses are recorded with capture provenance while account, submission and external listing actions remain inactive. Preserving historical evidence does not require inviting a visitor to interact with an unverified reconstruction of the former system.
Make repair decisions reversible
A small collection can use a simple decision vocabulary: unchanged, address updated, description revised, historical-only, temporarily unresolved or removed from current recommendations. Each event should have a date and a reason. This avoids an overcomplicated score while preserving enough history to understand why an entry changed. Keep the resource identifier stable where the resource itself remains the same. When a replacement is actually a different resource, create or identify a separate record and link the relationship rather than overwriting the old identity as if nothing had happened.
For an invented collection, suppose a resource returns repeated failures over several checks and no equivalent location can be established. The editor can remove its active recommendation while preserving a historical record with the last supported description and capture links. If the resource later returns, the new review can be added as another event. This is more informative than deleting all traces on the first failure or leaving an obsolete entry looking current indefinitely. The workflow should make uncertainty visible without allowing unresolved records to masquerade as freshly verified destinations for months or years.
Review what the checker cannot judge
Automated checks are useful for finding response changes, redirect loops and obvious missing pages. They cannot by themselves decide whether a revised resource still answers the directory's intended question. Human review can focus on the changed cases and on properties the tool cannot evaluate. A clear handoff note states the observed condition and the unresolved judgement. For example, final page loads but no longer contains the promised downloadable index is more actionable than link failed. The note tells the editor which boundary needs inspection and avoids repeating the same uninformative technical check.
A maintenance report should count both completed checks and unresolved cases honestly. Ten requests attempted are not necessarily ten resources verified. The historical latest-links and top-hits records below are examples of captured ordering, not a current health report or popularity ranking. The new method is to track the whole reference: its original promise, address behaviour, returned content and version context. A link is repaired only when the reader's next step is again described accurately. Until then, a specific limitation is a better result than a green badge earned solely by a successful response code.
References & further reading
- IETF HTTP Working Group — RFC 9110: HTTP Semantics ↗
- IETF — RFC 7089: Memento time-based access to resource states ↗
From the recovered archive
- Latest-links index · captured 29 November 2010
- Top-hits index · captured 29 November 2010