Feed Archives for a Personal Website - Preserve History Without Pretending Pagination Is Complete
A personal website may publish hundreds of posts while its feed exposes only the latest twenty. That is often enough for regular subscribers, but it leaves an awkward question: if a reader arrives late or misses several updates, does the feed provide a defined path to the older entries, or does it merely show a moving window?
Adding ?page=2 looks like an obvious answer. Yet pagination alone does not say whether page two will contain the same entries tomorrow, whether a client can reconstruct the site's history, or whether an absent entry should be treated as deleted. RFC 5005, Feed Paging and Archiving, separates these concerns by defining complete, paged, and archived feeds. The distinctions are old, but the publishing question remains useful: what promise does each feed document make about the larger collection?
A feed document is not necessarily the whole feed
RFC 5005 distinguishes a feed document from a logical feed. A document is one Atom file, or a similar syndication document, retrieved from one URL. The logical feed is the complete set of entries associated with it. One document may represent all of that set, a temporary slice, or a stable portion of an archive.
This is similar to a library catalogue displayed one screen at a time. A screen is a representation of the catalogue, not automatically the catalogue itself. Before following page links, software needs to know whether those screens are shifting search results or durable shelves.
Atom itself allows a feed document to contain some or all associated entries, but it leaves reconstruction details outside its scope. RFC 5005 adds vocabulary for that missing relationship. It does not require every blog to publish its whole history, and it does not turn a normal recent-post feed into an error.
Three models make different promises
Complete feeds: this document is the set
A complete feed explicitly says that one document contains every entry in the logical feed. It uses the empty fh:complete element from the feed-history namespace. If an entry is absent, a consumer should not consider it part of that logical feed.
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>Example Reading List</title>
<fh:complete />
<!-- every entry in this logical feed -->
</feed>This can fit a bounded collection such as a current reading list. It is usually less attractive for a blog whose history grows indefinitely. More importantly, the marker is an assertion about completeness, not a decorative extension. A publisher should not add it to a twenty-entry window merely because that document is valid Atom.
Paged feeds: navigation without a stable history
A paged feed splits entries across linked documents using relations such as first, last, previous, and next. According to RFC 5005, at least one of these relations must be present on a paged feed document, with as many applicable relations as practical.
The important caveat is that page contents are not guaranteed to remain stable. Suppose page one contains posts 101 through 110 and page two contains 91 through 100. A new post inserted while a client is walking the pages can shift the boundary. The client might see one entry twice and miss another. RFC 5005 therefore calls paged feeds lossy and says clients should not present them as coherent or complete.
That does not make pagination useless. It is appropriate when a client wants an arbitrary nearby slice and exact reconstruction is not the goal. The mistake is calling a moving list an archive merely because users can keep clicking “next.”
Archived feeds: stable pieces connected to the present
An archived feed is designed so its documents can be combined to reconstruct the logical feed accurately. It has one subscription document containing the newest added or changed entries and one or more archive documents containing older entries.
The subscription document points backward with prev-archive. Archive documents can continue that chain, point forward with next-archive, and identify the live subscription document with current. The IANA Link Relations registry still records these relations and their RFC 5005 definitions.
What a small Atom archive can look like
The following fragments are illustrative, not a claim about current feed-reader support. The live subscription document exposes recent entries and points to the newest completed archive:
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Notes</title>
<link rel="self" href="https://example.com/feed.atom" />
<link rel="prev-archive"
href="https://example.com/feed/archive/2026-10.atom" />
<id>https://example.com/feed.atom</id>
<updated>2026-11-08T00:00:00Z</updated>
<!-- newest entries -->
</feed>A completed October archive identifies itself as an archive, points to the current subscription document, and optionally links to adjacent completed archives:
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>Example Notes - October 2026 Archive</title>
<link rel="self"
href="https://example.com/feed/archive/2026-10.atom" />
<link rel="current" href="https://example.com/feed.atom" />
<link rel="prev-archive"
href="https://example.com/feed/archive/2026-09.atom" />
<fh:archive />
<id>https://example.com/feed/archive/2026-10.atom</id>
<updated>2026-10-31T23:59:59Z</updated>
<!-- stable archived entries -->
</feed>RFC 5005 says a subscription or archive document must include prev-archive unless no earlier archive is available. An archive should include next-archive when a later completed archive exists, should identify the subscription document with current, and should include fh:archive. Those different words matter: the specification does not give every field the same requirement strength.
Archive stability is the central contract
RFC 5005 says the entries at a particular archive URL and the URL itself should not change over time. That stability lets a consumer remember that it has already processed an archive instead of repeatedly downloading and reconciling it.
A date-based path can make this organization understandable, but the date does not create stability by itself. A CMS that rebuilds old monthly files with different boundaries after every edit still violates the expectation. The practical design question is where the archive boundary is recorded. A durable archive needs a stored membership rule or another deterministic mechanism that will not silently move entries between documents.
This also explains why an archive under construction should not be linked as though it were complete. In RFC 5005's example, the newest finished archive has no next-archive link to the current month. The live subscription document carries recent changes until an archive can be treated as stable.
Corrections complicate immutability
“Stable” does not mean factual errors should be preserved forever. The RFC recognizes a tradeoff: some clients may not revisit an archive they have already processed. When a correction must reach consumers, the publisher should consider placing the revised entry in the subscription document as well as, or instead of only, editing the old archive.
That behavior depends on durable entry identity. For Atom archives, entries with the same atom:id are duplicates. A consumer should retain the one with the most recent atom:updated; if timestamps do not resolve the choice, the entry from the more recently updated feed document takes precedence under RFC 5005's guidance.
This does not make every correction reliably visible in every client. It defines a reconstruction model for conforming consumers. A publisher still cannot infer current software support from the age or status of the standard, so any product-specific promise needs real interoperability testing.
A consumer must distrust the chain
An archive chain is input from the network, not a trusted linked list. A document can point in a loop, lead to an unavailable archive, or produce an effectively endless sequence of requests. RFC 5005 warns about excessive requests and resource consumption. A careful consumer needs limits on documents, bytes, time, redirects, and already-seen URLs.
If an archive is missing, the consumer may be unable to reconstruct the logical feed. The specification says clients should tell users when reconstruction is incomplete. Silently showing a partial history as complete would erase the exact distinction the archive model was designed to express.
Normal feed hygiene still applies. Atom documents must remain well-formed, their entry IDs must be stable, and timestamps must retain their intended meaning. The W3C's Introduction to Atom is a useful structural checklist, while RFC 4287 remains the authoritative format specification.
When a recent-entry feed is enough
RFC 5005 is not a requirement for operating a respectable blog. A normal feed with recent entries is often the better choice when readers only need updates, the HTML archive already supports browsing, and no known consumer needs machine-reconstructable feed history.
An archived feed becomes more defensible when missing old entries has a real cost, stable archive files can be maintained, and at least one target consumer is known to follow the relations correctly. A paged feed fits exploration where shifting boundaries are acceptable. A complete feed fits a genuinely bounded set. Choosing among them should start with semantics, not with whichever URL pattern is easiest to generate.
Before adding archive links, a publisher can ask:
- Is the goal nearby navigation or reliable reconstruction?
- Can each completed archive URL and its membership remain stable?
- Will important corrections return to the subscription document with the same entry ID?
- Can broken links and incomplete history be detected rather than hidden?
- Has the intended reader or downstream tool actually been tested?
Conclusion
A feed split across several URLs is not automatically an archive. Paged feeds offer navigation through changing slices; archived feeds promise stable pieces that can be assembled; complete feeds declare that one document is the whole logical set. Each model answers a different question.
For a small personal website, the simplest recent-entry feed may remain entirely sufficient. If durable machine-readable history becomes a requirement, RFC 5005 provides more than extra links: it provides a vocabulary for stating what those links mean. The hard part is not emitting prev-archive. It is keeping the stability and correction promises behind it.