RSS GUIDs Explained: Stable Item IDs Without Duplicate Entries

The smallest identity decision in an RSS feed has one of the largest operational effects. Every item needs a value that lets readers recognize it the next time the feed is fetched. When that value changes unexpectedly, an old post can appear new again, a podcast episode can download twice, and analytics can split one item into several records. In RSS 2.0, the usual tool for this job is the guid element.

GUID stands for globally unique identifier, but the practical requirement is more specific: the value should be unique within the publication and stable for the life of the item. It does not need to be a UUID. It can be a URL, a tag URI, a database-backed token, or another opaque string. What matters is that the publisher understands the chosen semantics and does not casually regenerate the value.

What the guid element actually says

An RSS item may contain a guid. The specification describes it as a string that uniquely identifies the item. It also defines an optional isPermaLink attribute. When that attribute is omitted, its default value is true, which means the GUID is expected to be a URL that can be opened in a browser. When it is false, the value is an opaque identifier and consumers should not assume it is a clickable location.

This default surprises many feed generators. They emit an internal value such as post-1842 without setting isPermaLink="false". A tolerant reader may still handle it, but the feed is making a claim it cannot honor. The precise definitions are available in the RSS 2.0 specification, and generators should follow them rather than copying a sample without understanding the attribute.

URL GUIDs can work, but only under a stability contract

Using the public article URL as the GUID is attractive because it is readable and already unique. It works well when URLs are permanent. A site with immutable post paths can safely publish the same address in both link and guid. If the visible URL later redirects to a new canonical page, keeping the old GUID is usually better than replacing it. The GUID represents the item’s established identity, while the link can point to the current location.

Problems begin when a CMS rebuilds URLs from titles, dates, categories, or language settings. A headline edit can change the slug. A category move can change the path. If the feed generator blindly copies the current URL into the GUID, each editorial change becomes an identity change. Readers that have already stored the old value may present the edited item as a duplicate.

Opaque GUIDs separate identity from presentation

An opaque GUID avoids dependence on a public route. A typical value might be urn:uuid:..., a tag URI, or a namespaced database key such as example.org:post:1842. The item’s public URL can then change independently. The feed must set isPermaLink="false", and the publisher must guarantee that the token is never reused for another item.

<item>
  <title>A corrected headline</title>
  <link>https://example.org/new-path/corrected-headline/</link>
  <guid isPermaLink="false">urn:uuid:8d9f4c7a-3c12-4a72-9a31-81d4d8a1f662</guid>
  <pubDate>Wed, 29 May 2024 14:30:00 GMT</pubDate>
</item>

The token does not have to resolve on the web. Its job is comparison, not navigation. Readers should store it exactly as published. Publishers should avoid case folding, trimming meaningful characters, or applying URL normalization to opaque values.

Generate once, then store the result

The most reliable workflow assigns an item ID when the content record is created and stores it in the database. Feed rendering reads that field; it does not recalculate it from the current title, body, timestamp, or URL. This also makes staging and production behavior predictable because identity is attached to the content rather than to a particular rendering environment.

Content hashes are usually a poor primary GUID. A correction changes the hash even though the item is still the same publication event. Timestamps are also risky because imports and timezone conversions can alter them. Random values are fine only if generated once. A random UUID created on every feed request is catastrophic: every refresh tells readers that every item is new.

Edits should update content, not identity

Publishers frequently correct spelling, replace artwork, update summaries, or add a disclosure. Those edits should keep the same GUID. A consumer can use the stable ID to locate its stored item and update the visible fields. Changing the GUID turns an update into an insertion.

There are cases where a new GUID is appropriate. If an old item is withdrawn and a substantially different item is published as a separate editorial event, it should have a new identity. If a podcast releases a corrected audio file for the same episode, most publishers keep the episode GUID and change the enclosure metadata, but the exact behavior should be tested with the directories and apps that matter to the show.

Migrations require a GUID preservation plan

Moving from one CMS or podcast host to another is where GUID failures become visible. The new platform may generate identifiers from its own database, even though the imported posts already have established GUIDs. Before switching, export the old feed, map each item to the new record, and verify that the new output preserves the original values character for character.

A migration test should compare more than the latest item. Sample old, middle, and recent entries, including items with unusual characters or prior URL changes. Check the GUID value, the isPermaLink attribute, publication dates, and enclosure URLs. Then fetch the feed through the old URL after the redirect to confirm that clients still see a continuous item history.

How readers should handle imperfect feeds

A reader cannot assume every feed has a GUID or that every GUID is well designed. A robust parser uses the GUID when present, but keeps fallback signals such as the item link, normalized enclosure URL, title, and publication time. Fallback matching should be conservative because two legitimate items can share a title or publication date.

Readers should also scope GUIDs to a feed identity. The string 42 can legitimately appear in unrelated feeds. A useful database key is therefore a pair: stable feed ID plus item GUID. When feeds are merged after a verified migration, the application can preserve the old scope as an alias rather than rewriting every historic row.

Frequent GUID mistakes

• Regenerating IDs on every build. Static site pipelines sometimes create new UUIDs whenever the feed is compiled.
• Using mutable slugs. A title change silently produces a different identifier.
• Omitting isPermaLink="false". Opaque values are published as though they were browser URLs.
• Reusing IDs. Deleted database records are replaced and their numeric keys become attached to unrelated posts.
• Changing IDs during migration. A new host imports content but discards the original identity field.
• Normalizing opaque strings. A consumer lowercases or decodes values that should be compared exactly.

A durable implementation pattern

For a new system, create an immutable feed_item_id column, assign a UUID or another collision-resistant token at creation, and publish it as an opaque GUID. Keep the public URL in a separate field. Add a database constraint that prevents reuse. During imports, accept an existing GUID and preserve it unless a collision is proven to represent a different item.

For an existing feed, do not “clean up” GUIDs merely to adopt a more elegant format. Stability is more valuable than appearance. Document the current scheme, add tests that snapshot representative values, and make the feed build fail if a known item’s GUID changes unexpectedly. The validation checklist includes identity checks that can be placed in continuous integration.

Conclusion

RSS GUIDs are simple strings with a demanding promise: the same item should keep the same value. They are not required to be UUIDs, not required to be public URLs, and not safe to regenerate from mutable content. The best GUID is one the publisher can preserve through edits, redesigns, hosting changes, and imports.

Once identity is stored independently from presentation, the rest becomes straightforward. Links can move, titles can improve, and content can be corrected while readers continue to recognize one continuing item. That stability is the foundation of duplicate-free syndication.