Preserve a published item’s identity through ordinary updates and migrations, and distinguish the current feed from copies already retained by subscribers.
If an edited article reappears as a new subscription item, compare its identifier before changing publication dates. If a deleted article remains in a feed reader, compare that reader’s retained history with the current source feed. These symptoms concern different parts of the publishing lifecycle.
Consider a fictional gardening club that revises a seasonal guide, later moves its website, and eventually retires an outdated notice. Subscribers report a duplicate guide and a notice that will not disappear. The club needs to trace item identity and delivery history separately rather than expecting the newest feed to rewrite every previously delivered copy.
Distinguish the article, the feed item and the reader’s copy
An article URL identifies a public reading destination. A feed item represents a delivered entry. A reader may retain that entry after it is no longer among the current items offered by the publisher. Record which layer each observation concerns before diagnosing the problem.
For the gardening club, collect a non-sensitive copy of the relevant source-feed entry and the subscriber’s description of the apparent duplicate. Note the item identifier, title, link and dates that each side shows. Do not assume a screenshot of a reader is a complete representation of the current XML feed.
The WordPress feed guide covers finding the source and choosing summaries or full posts. This investigation starts after that choice: what tells a reader that a revised entry is still the same published item?
Keep ordinary revisions attached to a stable identity
The RSS 2.0 specification defines an item’s guid as an identifying string. A guid need not be a web address when its isPermaLink attribute is false. Do not automatically equate that identifier with the current display link or regenerate it every time the title changes.
For the seasonal guide, choose an editorial rule: correcting wording or updating advice revises the existing item rather than pretending it is newly published. Ask the publishing maintainer to preserve the identifier through that revision. Compare the item before and after the edit to check the rule, instead of judging identity from the headline alone.
If the club intentionally publishes a genuinely separate annual edition, make that an explicit editorial event with a separate article and identity. Do not create new identities accidentally as a side effect of changing a template, moving media or revising a summary.
Keep update time separate from item identity
The Atom format specification distinguishes an entry’s permanent id from its updated timestamp. An ordinary revision can therefore change update information while preserving the entry’s identity. These Atom rules should not be presented as a guarantee that every RSS reader refreshes items in the same way.
In the fictional case, record that the guide’s instructions changed and identify the revision that readers should see. Do not change an identifier merely to force attention in a subscription list. That can create another item rather than improving how an existing revision is communicated.
Give substantial corrections a clear public explanation on the article itself. A subscriber who opens an older retained excerpt should still find the current explanation at the maintained destination. This does not make the publisher able to overwrite the earlier excerpt in every reading application.
Compare likely lifecycle causes with their own evidence
| Proposed symptom | Evidence to compare | Useful interpretation |
|---|---|---|
| Edited guide appears twice | Old and new item identifiers | A changed identity may explain a new entry |
| Title changes but reader keeps old wording | Current source entry and reader refresh behavior | Stable identity does not promise uniform refresh |
| Older item leaves the current feed | Feed scope and retained reader history | Absence alone does not prove editorial deletion |
| Domain migration creates duplicates | Identifier continuity across the move | New links and new identities are different changes |
Use harmless sample entries for a controlled reproduction. Record the reader application and its relevant configuration rather than turning one observed behavior into a universal rule. A useful issue report states exactly which identity or content field changed, when the reader fetched it, and what the reader displayed.
These are proposed exercises. No subscription reader, live feed or subscriber history was changed or tested for this article.
Preserve continuity when the website moves
Before a domain or platform migration, include feed identifiers in the content inventory alongside article URLs. Ask whether the new generator preserves the established identity of existing entries. Compare a small set containing an old article, a recently updated article and an entry with a changed destination.
The WordPress domain-change guide covers the wider move. For feeds, a working redirect to the new article solves a navigation question; it does not by itself show that a subscriber sees one continuous item rather than two distinct entries.
If a migration has already changed identities, investigate the generating rule before repeatedly rewriting the feed. Further unplanned changes can make the history harder to interpret. Keep the original source examples so the maintainer can identify which field caused the discontinuity.
Do not treat a current feed as a remote deletion command
A publisher may offer only a recent subset of articles in a feed. An entry leaving that subset does not necessarily mean the article was withdrawn. Likewise, removing an entry from the source does not establish that a reading application removed the copy it previously retained.
RFC 6721 defines Atom tombstones for communicating deletion information. This is a distinct Atom mechanism, and its deletion information is advisory. It is not a general RSS 2.0 command that recalls already delivered text from every subscriber.
For the retired gardening notice, decide what the public article destination should say and whether a correction or retirement notice is appropriate. Do not publish confidential material on the assumption that deleting its feed entry later will retrieve all copies.
Review corrections as a publishing responsibility
Use the content audit guide to distinguish a refresh, consolidation and retirement. Explain meaningful corrections where readers can find them, and keep internal records of the identifier and destination decisions made during migration or revision.
Close the investigation when the source expresses the intended item identity and current content, while any remaining reader-history limitation is described honestly. A stable feed helps avoid accidental duplicates; it does not guarantee every application’s refresh policy or the disappearance of previously delivered copies.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RSS 2.0 specificationChecked An item guid can identify an item independently of its display link.
Limits: A finite current feed is not a deletion protocol. - RFC 4287: Atom formatChecked Atom entries have permanent identifiers and distinct update timestamps.
Limits: Atom rules do not define all RSS-reader behavior. - RFC 6721: Atom tombstonesChecked Atom tombstones can express deletion information.
Limits: They are advisory, not RSS 2.0 remote recall.