You fix a typo, update a broken link, or add a clarifying paragraph to a post you published three weeks ago. Ten minutes later, your auto-poster fires off a fresh round of social posts for an article your audience already saw — sometimes with a new “published” timestamp, sometimes duplicated across every connected platform. This isn’t a bug specific to one tool. It’s a predictable consequence of how RSS feeds represent time and identity, and how auto-posters use that information to decide what counts as “new.” Once you understand the mechanism, it’s usually a five-minute fix in either your CMS or your auto-posting tool’s settings.
Every RSS or Atom feed item carries, at minimum, two pieces of information an auto-posting tool can use to decide whether it has seen an item before: an identifier and a timestamp. In RSS 2.0, those are <guid> un <pubDate>. In Atom, the equivalents are <id> un <updated> (with <published> as an optional separate field). A well-built auto-poster should primarily key off the identifier — GUID or Atom ID — because that’s the field explicitly designed to be a stable, permanent handle for one specific item, regardless of what happens to its content afterward.
The trouble is that “should” and “does” diverge more often than you’d expect, on both sides of the pipeline. Some CMS platforms don’t keep the GUID stable across edits. Some auto-posting tools don’t trust the GUID alone and fall back to timestamp comparisons as a secondary or even primary signal. When either of those things happens, an edit to existing content can look, from the auto-poster’s point of view, exactly like a new item.
The RSS 2.0 specification defines <guid> as a string that “uniquely identifies the item” and explicitly notes that when the isPermaLink attribute is true (or omitted, which defaults to true), the value should be treated as a permanent, unchanging URL for that item. The intent is straightforward: once an item is assigned a GUID, that GUID never changes for the lifetime of the item, even if every other field in the feed entry — title, description, pubDate, content — gets rewritten.
This is the entire mechanism duplicate detection is built on. An auto-posting tool fetches your feed on a schedule, compares each item’s GUID against the list of GUIDs it has already posted, and skips anything it recognizes. If the GUID for a given post never changes, editing that post’s body text is invisible to the duplicate-detection logic — exactly as intended. The problem only appears when the GUID itself isn’t as permanent as the spec assumes it should be.
A handful of common patterns break GUID stability, usually without anyone intending to:
The second half of the problem is timestamp handling, and it’s arguably more common than GUID instability because it’s baked into how a lot of CMS platforms behave by default. The RSS spec is actually fairly permissive about what <pubDate> means — it’s documented as “the publication date for the content,” which in practice a lot of software interprets as “the last time this database row was saved,” not “the first time this content went live.”
That distinction matters enormously for auto-posters that use pubDate as part of their change-detection logic — either as a tiebreaker alongside GUID, or, in poorly built tools, as the primary signal. If a CMS bumps the pubDate every time a post is edited and re-saved, and the auto-poster interprets an item with a newer pubDate than what it last saw as a new or updated item worth posting, then any edit — a typo fix, a date correction, a single added sentence — reads as fresh content.
There’s a legitimate reason some auto-posters watch pubDate at all: it’s a useful signal for catching legitimately updated content that publishers genuinely want reshared, like a “best restaurants in [city]” roundup that gets refreshed annually with a new intro paragraph and updated pubDate specifically so subscribers notice it’s been refreshed. The problem isn’t that pubDate-awareness exists — it’s when a tool can’t tell the difference between that intentional refresh signal and routine maintenance edits, because the feed itself doesn’t distinguish the two cases either.
Strip away the specifics and the underlying issue is the same in almost every case: many feeds only expose one timestamp, and that timestamp gets overloaded to mean two different things depending on when you look at it. A cleanly designed feed exposes both:
Atom actually got this right at the spec level — <published> un <updated> are two distinct, well-defined elements, and <updated> is explicitly meant to change on every edit while <published> stays fixed. RSS 2.0, by contrast, only has <pubDate>, with no standard second field for modification time (some feeds add a non-standard <atom:modified> or a Dublin Core <dc:date> extension inside an otherwise RSS 2.0 feed to patch this gap, borrowing the Atom namespace for exactly this purpose). When a feed only has one date field and that field gets overwritten on every save, there’s no way for a downstream tool to distinguish “brand new post” from “post that existed for a month and had a comma fixed” without additional logic beyond just reading dates.
The table below separates the edit scenarios that legitimately can cause reposting from the ones that shouldn’t, assuming reasonably well-behaved software on both ends of the pipeline.
| Scenario | Typically triggers a repost? | Why |
|---|---|---|
| Fixing a typo or grammar error | No, if GUID and original pubDate are stable | Content-only edit; identity and publish date unchanged |
| Adding a paragraph or updating a statistic | No, if GUID and original pubDate are stable | Same as above — substantive content change is not identity change |
| Changing the post’s URL slug (GUID is URL-based) | Yes | GUID changes along with the URL, so the item looks new |
| Editing the post triggers the CMS to update pubDate to “now” | Yes, in tools that key on pubDate | Publish date now falls after the last time the feed was checked |
| Migrating to a new CMS or platform | Yes, usually for the whole archive at once | Post IDs and GUIDs are frequently regenerated during migration |
| Manually republishing/unpublishing then republishing a post | Yes | Most CMSs treat this as a new publish event and reset pubDate |
| Changing only the featured image or a tag | Usually no | Metadata-only change; GUID and pubDate typically untouched |
| Scheduled “content refresh” workflows that intentionally bump the date | Yes, by design | Publishers sometimes want this resurfaced — different intent than a typo fix |
Because so much of the auto-posting audience runs WordPress, it’s worth being precise about what WordPress actually does, since some of the folklore around this is outdated or only half-right.
WordPress’s default <guid> output is generated once, at the time a post is first published, and is based on the post’s ID (an internal, permanent database key) combined with the site URL — not the post’s slug. Critically, WordPress does not regenerate the GUID when you edit the slug or the permalink structure later; the original GUID string stays in the database untouched, even though it may now point to a URL that no longer matches the post’s current, visible address. This is actually the correct, spec-compliant behavior, even though it looks strange if you go digging through your feed XML and notice the GUID URL doesn’t match the post’s live URL — that mismatch is expected and harmless for identification purposes, because isPermaLink handling means well-behaved consumers treat it purely as an opaque identifier, not something to fetch or resolve.
Where WordPress can cause the exact problem this article is about is <pubDate>, and specifically what happens on republish. A standard content edit through the normal “Update” button does not change WordPress’s core publish date — the post’s original post_date field stays fixed, and the feed’s pubDate should reflect that original date, not the edit time. Where things go sideways:
post_date, and the feed’s pubDate moves with it.post_modified in ways that inadvertently affect feed output depending on which date field a given feed template pulls from.WordPress does separately track post_modified (last-edited timestamp) from post_date (original publish timestamp) in its database, which is exactly the “published vs. modified” separation described above — but the default WordPress RSS feed template only outputs <pubDate> from post_date, with no standard modified-date element in the base feed XML. So the data WordPress needs to prevent this problem is already sitting in the database; it’s just not surfaced by default in a way most auto-posters look at.
You don’t need to guess. A short, repeatable test tells you exactly how your site behaves:
/feed/ to your site’s URL (standard on WordPress) and locate the item, or use your CMS’s documented feed path.<atom:modified>, <dc:date>, or (in an Atom feed) a separate <updated> tag alongside <published>. If present, note whether it’s populated correctly — some plugin-generated feeds include the tag but leave it stale or identical to pubDate, which defeats its purpose.If you find that pubDate is shifting on ordinary edits, the fix belongs in your CMS or plugin settings — disable “update date on modification” style features if you don’t specifically want that SEO behavior, or check whether a caching/feed plugin is responsible. If GUIDs are shifting, check whether anything ties GUID generation to the slug, title, or category rather than a permanent internal post ID, since that’s almost always the actual cause.
The other half of the fix lives on the auto-posting side. A tool that handles this well should behave according to a few principles:
This is really the same discipline that shows up across the broader category of RSS feed troubleshooting issues — duplicate GUIDs across different items, stale caching serving outdated feed snapshots, missing ETags causing unnecessary re-fetches. Reposting edited content is a variant of the same underlying theme: the auto-poster’s job is to trust the identifier the feed provides and treat everything else as secondary evidence, not the other way around.
No. On a well-behaved CMS with a stable GUID and unchanged publish date, a typo fix through the normal edit-and-update workflow shouldn’t touch either field, and a properly built auto-poster keys off the GUID rather than the content itself — so the edit is invisible to duplicate detection.
No. WordPress generates the GUID once at first publish based on the post’s internal ID and does not regenerate it when you later change the slug or permalink structure — even though the GUID’s embedded URL may then no longer match the post’s live address, which is expected and not a problem for identification purposes.
Because correcting the date field itself (as opposed to editing the body text) changes WordPress’s post_date, which is exactly what populates <pubDate> in the feed. Any auto-poster paying attention to pubDate will see what looks like a newer publish time.
If avoiding accidental reposts matters more to you than the SEO freshness signal that feature is meant to send, yes — disable it, or scope it to major content updates only rather than every save. It’s a deliberate trade-off, not a bug in the plugin, so the right call depends on which outcome you value more for a given site.
The permalink is the post’s current, human-visible URL and can change over time. The GUID is meant to be a permanent identifier that never changes, even if it happens to be built from a URL that’s now outdated. Auto-posters should treat GUID as identity and permalink as just a link to include in the post.
Yes, if your auto-posting tool supports it — look for a setting like “repost on content update,” typically scoped per feed so it doesn’t apply globally to every post you ever edit. This is the right way to resurface a genuinely refreshed evergreen article without it happening accidentally to routine edits.
Less often, because Atom’s spec explicitly separates <published> from <updated>, giving well-built consumers a clean way to distinguish new items from edited ones. The risk is lower but not zero — it still depends on the auto-poster actually using that distinction correctly rather than treating any change to <updated> as reason to repost.
Run the manual test: record your GUID and pubDate, make a trivial content-only edit, and check whether either field changed in the raw feed XML. If neither changed and you still got a repost, the issue is on the auto-poster’s side. If either field did change, the fix starts in your CMS or plugin settings.
Reposted edits almost always trace back to one of two things: a GUID that isn’t as permanent as it should be, or a publish date that gets bumped on ordinary content edits. Both are checkable in under five minutes by looking at your raw feed XML before and after a test edit, and both are fixable — either in your CMS’s date and GUID handling, or in your auto-posting tool’s duplicate-detection settings. The goal on both ends of the pipeline is the same: treat identity and edit history as separate signals, so that fixing a typo never looks, to a machine, like publishing something new.