RSS GUIDs Explained: Why Readers Show Old Posts as New

Short answer: The guid in RSS (the id in Atom) is the permanent identifier that feed readers, podcast apps and automation tools use to decide whether an item is new. If an item’s guid changes, for example after a site migration, a domain change, a switch from HTTP to HTTPS or a new feed plugin, every consumer treats it as a new item: readers show duplicates, newsletters resend old posts and podcast apps download episodes again. Choose a guid that will never change, and preserve it through every migration.

The guid is a single line in each item, invisible to anyone who reads your site in a browser. Most publishers never think about their feed’s identifiers until the day subscribers complain that twenty old posts just reappeared as new, or a social automation tool re-posted last year’s articles. The cause is almost always the same: the guids changed. Understanding how identifiers work takes five minutes and prevents one of the most embarrassing feed failures.

What the guid is for

A feed is a list of recent items that consumers fetch again and again. Each time, they need to answer one question for each item: “have I seen this before?” Comparing titles or content does not work reliably, because titles get corrected and content gets edited. So feeds carry an identifier:

• In RSS 2.0, the optional guid element.
• In Atom, the required id element.
• In JSON Feed, the required id field.

The name “globally unique” is a hint: the identifier should be unique not only within your feed but across all feeds a reader follows, which is why good identifiers include your domain or another distinctive prefix rather than a bare number such as “123”. Consumers store the identifiers they have seen. An item with a stored identifier is old; an item with an unknown identifier is new. That is the whole mechanism, and it is why stability matters so much.

What happens when a guid changes

What makes this particularly frustrating is that there is no undo. Once a reader has stored the duplicate, or a tool has posted it, correcting the feed does not remove what already happened; it only prevents further damage. The damage is limited to items currently in the feed, which is usually the last 10 to 50, but that is enough to annoy readers and, in the case of automation, to publish embarrassing duplicates in public.

Common causes of changing guids

• Site migrations to a new platform that generates identifiers differently.
• Domain changes, when guids are permalinks that include the old domain.
• HTTP to HTTPS or www to non-www switches, for the same reason.
• Permalink structure changes, such as removing dates from URLs, when guids are URLs.
• New feed plugins or templates that choose a different source for the guid.
• Database imports that assign new internal IDs to posts.
• Feeds generated from scraped pages without a stable identifier strategy.

How WordPress handles guids

WordPress stores a guid for every post in the database when it is first created, typically in the form https://example.com/?p=123, and uses it in the feed with isPermaLink="false". This guid does not change when you edit the slug, which is good design. However, it does contain the domain of the site at the time the post was created. WordPress’s own guidance is that the guid column should not be changed, even when a site moves domain, precisely because feed readers depend on it. Some migration tools and search-and-replace scripts update it anyway; configure them to skip the guid column.

When there is no guid at all

RSS 2.0 makes the guid optional, and some feeds, especially older or hand-built ones, leave it out. Consumers then have to invent an identity for each item, and each does it differently:

• Some use the item’s link. Duplicates appear when links change or carry tracking parameters that vary.
• Some combine the title and link, or hash the title and description. Every correction to the title then creates a “new” item.
• Some use the publication date as part of the key, so a changed date also creates a duplicate.

The result is unpredictable: the same feed behaves well in one reader and produces duplicates in another. Adding a guid is the fix, and it is almost always a small change in the feed template. If you consume a feed without guids and cannot change it, choose tools that let you configure how items are identified, or that remove duplicates by link and title before items reach your channels.

Duplicate guids within one feed are a related problem. Template bugs sometimes give every item the same identifier, for example the feed’s own URL. Readers then show only one item, and new posts appear to be missing. A validator flags this immediately.

Choosing a stable identifier

If you build feeds yourself, choose an identifier that will survive every foreseeable change:

1. A database or CMS entry ID combined with a fixed string, such as tag:example.com,2026:post-123 or example-blog-post-123. Never tied to URLs.
2. The canonical URL, only if you are confident URLs will never change. Simpler, but vulnerable to redesigns and domain moves.
3. A UUID generated once and stored with the item. Robust, as long as it is stored, not regenerated.

The “tag” URI scheme, defined in RFC 4151, is a neat choice for Atom ids: it includes a domain and a date that you owned at the time, and it stays valid even if you later move to another domain. Whatever you choose, if the identifier is not a working URL, mark RSS guids with isPermaLink="false".

Migrating without changing guids

• Export the current feed before migrating and keep the file. It records every current guid.
• Carry guids over into the new system, for example as a custom field, and output them in the new feed for old items.
• Use new-style identifiers only for new items. Mixing is fine; what matters is that existing items keep theirs.
• Compare old and new feeds item by item before switching DNS or redirects.
• Keep the feed URL or redirect it permanently with a 301.

Plan the migration day too: if possible, switch the feed at a quiet time, and pause automations that post from the feed until you have checked the first fetch after the switch. If the guids have already changed and subscribers have seen duplicates, restoring the old guids quickly limits further damage, although items already duplicated in readers stay duplicated.

Editing items without triggering duplicates

Normal edits are safe when the guid is stable: fixing a typo in the title, updating the content or changing the image does not create a new item. Some readers update the stored item; others keep the first version. Two edits are riskier:

• Changing the publication date to “bump” an old post can make it appear new in some readers, even with the same guid, because they sort by date.
• Deleting and recreating a post gives it a new database ID and therefore a new guid on many platforms.

Detecting guid problems before subscribers do

A validator warns if guids are missing or duplicated within a feed, but it cannot know whether they changed since yesterday. To catch changes, keep a copy of your feed and compare the guids after any significant site change. Subscribing to your own feed in a reader is a simple early-warning system: if your own reader suddenly shows twenty unread old posts, you know what happened. On the consumer side, our tool, Feeds, removes duplicates automatically when it merges sources into one feed, which softens the effect of an upstream source that changes identifiers. See the plans.

Related reading

• Anatomy of an RSS 2.0 Feed: Every Element Explained
• How to Stop Duplicate Posts in Automated Content Workflows
• How to Move a Podcast Feed Without Losing Subscribers

The bottom line

The guid is how every reader, podcast app and automation tool recognises your items. When it changes, old content comes back as new everywhere at once. Use an identifier tied to your content rather than your URLs, never rewrite stored guids during migrations, compare feeds before and after big changes, and your subscribers will never see last year’s posts again by accident.

الأسئلة الشائعة

What is a guid in RSS?

It is a globally unique identifier for an item. Feed readers and tools use it to decide whether they have already seen the item. Atom and JSON Feed use an id element for the same purpose.

Why are old posts showing up as new in my feed reader?

The items’ guids probably changed, often after a migration, domain change or new feed plugin. Readers treat items with unknown identifiers as new, even if the content is old.

Should the guid be the post URL?

It can be, but URLs change more often than people expect. An identifier based on the post’s database ID or a stored UUID is safer. Mark non-URL guids with isPermaLink=”false”.

Should I update WordPress guids when moving to a new domain?

No. WordPress guidance is to leave the guid column unchanged, because readers rely on it. Configure migration and search-and-replace tools to skip that column.

Does editing a post change its guid?

Not on most platforms. Editing the title or content keeps the same guid. Deleting and recreating a post, however, usually creates a new one, so edit existing posts rather than replacing them.