RSSid.com Identity Log

Designing an RSS Feed Identity API and Registry

2026-10-02T12:00:00Z

A feed identity API answers a deceptively difficult question: given a URL or identifier, which continuing publication does it represent? A useful service must do more than fetch XML. It needs a durable data model for feeds and aliases, a resolver that preserves redirect evidence, a validator, a change history, and clear confidence semantics for uncertain matches.

The registry should not become a black box that silently declares two feeds identical. Its value comes from stable identifiers and transparent provenance. Every canonical URL change, alias, merge, split, validation result, and ownership assertion should be represented as data that clients can inspect.

Define the resources before the endpoints

The primary resource is a logical feed record with an immutable feed_id. It has one current canonical URL, zero or more observed aliases, a detected format, associated site URLs, metadata snapshots, and lifecycle status. Items can be represented separately or sampled for identity evidence. Organizations, claims, and validation runs are distinct resources rather than nested text fields.

Model history explicitly. A canonical URL is valid from one time until another. An alias may be observed, redirected, publisher-declared, or disputed. A feed can be active, moved, dormant, unavailable, or retired. Avoid a single mutable record that erases earlier states.

Use opaque, immutable feed IDs

A registry ID should not contain the canonical domain, title, category, or format. Those properties can change. An opaque token such as rssid:feed:01J... or a UUID-based URI remains stable through migrations. Human-readable slugs can be secondary routes that redirect to the immutable identifier.

Do not recycle IDs after deletion or retirement. A tombstone can explain that a record was merged or withdrawn. Reuse would make cached references point to an unrelated publication.

Core read endpoints

A small read surface can cover most integration needs:

GET /v1/feeds/{feed_id}
GET /v1/resolve?url={feed_url}
GET /v1/feeds/{feed_id}/aliases
GET /v1/feeds/{feed_id}/events
GET /v1/feeds/{feed_id}/validation/latest
GET /v1/search?q={title_or_domain}

The feed response should include the canonical URL, format, site relationship, current metadata, status, timestamps, and links to aliases and events. The resolver should return both the matching feed and the evidence used: exact canonical match, known alias, redirect, declared self link, or an inferred similarity requiring review.

Resolver behavior must be bounded

A URL resolver performs network activity and therefore needs strict controls. Normalize the input conservatively, reject unsupported schemes, resolve DNS safely, prevent access to private network ranges, cap redirects, limit response size, enforce timeouts, and parse content with hardened libraries. Server-side request forgery is a primary risk.

Return the requested URL, each redirect hop, final URL, status codes, content type, detected format, and validation summary. Do not hide a redirect chain behind a single canonical string. Provenance is necessary for troubleshooting and identity decisions.

Separate observations from assertions

An observation says what the service fetched at a time. An assertion says what an actor claims, such as “this is the canonical feed” or “this organization controls this domain.” An inference says what the registry concluded from evidence. Mixing those categories turns uncertain data into apparent fact.

Each field should have provenance: source, observed time, verification method, confidence, and expiration if relevant. A title parsed from the feed is different from a title entered by a verified owner. A canonical URL inferred from redirects is different from one explicitly declared by the publisher.

Represent aliases and migrations as events

When a feed moves, create an event that links the previous URL, new URL, redirect evidence, observation time, and actor. Keep the old URL as an alias. Clients can then understand why a resolver maps both addresses to one feed ID and can reconstruct the state at an earlier date.

Merges and splits need similar events. A merge should preserve the source IDs as tombstones or aliases rather than deleting them. A split should create new IDs and state how they descend from the original. These operations should require stronger evidence than an automated content match.

Design confidence as structured evidence

A resolver can expose a result such as verified, high, possible, or unmatched, but the label must be accompanied by signals. A permanent redirect plus stable item-ID overlap is stronger than title similarity. A verified domain-control claim may be stronger than a self link fetched over a compromised route.

Clients should be able to set their own thresholds. A feed reader might automatically follow a high-confidence alias. A compliance archive might require verified publisher control. Returning the evidence lets each consumer make an appropriate decision.

Validation is a resource, not a boolean

Store validation runs with the requested URL, final URL, fetch metadata, parser version, errors, warnings, item count, identifier checks, and timestamps. “Valid” alone loses useful detail. A feed may parse but contain duplicate GUIDs or broken enclosures. Another may have a noncritical profile warning.

Expose recent results and a compact history so clients can detect regressions. Avoid fetching on every read request; use a queue, cache policy, and explicit refresh endpoint with rate limits. A stale result should include its age rather than appear current.

Write operations and ownership

Public users may propose a feed URL, but changes to canonical status, organization ownership, and merges should require authentication and review. Domain control can be verified through DNS, an HTML token, a well-known file, or an authenticated publisher workflow. No single method fits every host, so record the method and time.

Protect against hostile takeover attempts. A temporary redirect or copied feed should not allow a claimant to seize a long-established record. High-impact changes can use delayed activation, notifications to existing verified contacts, and an appeal process.

HTTP and caching semantics

Use stable resource URLs, clear status codes, ETags, and cache headers. A lookup for an unknown ID should be distinguishable from a retired ID. A merged ID can return a redirect to the surviving record or a tombstone document with the replacement link, depending on the API contract.

Resolver requests may be asynchronous when network fetching is required. A client can submit a URL, receive an operation ID, and poll or follow a callback policy. Do not hold connections indefinitely while following slow redirects and parsing large documents.

Document the contract with OpenAPI

A machine-readable API description makes schemas, parameters, errors, authentication, and examples testable. The current standard is described in the OpenAPI Specification 3.2.0. Pin the version used by the registry and publish compatibility notes when the contract changes.

Examples should include uncertain and failure cases, not only a perfect response. Document rate limits, freshness, pagination, merge redirects, validation warnings, and the difference between observed and verified fields. SDK generation is useful, but clarity of semantics matters more than generated code.

Privacy, abuse, and retention

Feeds can include personal data, private tokens, or unlisted content. The service should default to public HTTP and HTTPS sources, redact credentials from logs, avoid indexing private network targets, and provide removal or suppression processes where appropriate. Raw responses may need shorter retention than derived metadata.

Rate limits should account for both API calls and outbound fetches. Attackers can use a resolver to scan hosts or amplify traffic. Cache identical requests, respect reasonable publisher load, identify the crawler, and provide contact information.

Suggested response shape

{
  "feed_id": "rssid:feed:01J9W6T2M8Y7KQ4R3N2P1A0BCD",
  "canonical_url": "https://example.org/feed/",
  "status": "active",
  "format": "rss2",
  "aliases": 3,
  "match": {
    "level": "high",
    "signals": ["known_alias", "permanent_redirect", "item_id_overlap"]
  },
  "observed_at": "2026-10-12T17:20:00Z",
  "links": {
    "events": "/v1/feeds/rssid:feed:01J9.../events",
    "validation": "/v1/feeds/rssid:feed:01J9.../validation/latest"
  }
}

The response is concise enough for clients while preserving the reason behind the match. Detailed observations can live behind linked resources.

Implementation sequence

Create the immutable feed, alias, observation, event, and validation models.
Build a safe fetcher with redirect and network protections.
Implement exact canonical and alias resolution before similarity matching.
Add strict parsing and identity-aware validation for RSS, Atom, and JSON Feed.
Expose evidence-rich read endpoints with caching and pagination.
Add authenticated claim and review workflows for high-impact changes.
Publish the API description, version policy, limits, and abuse contact.
Introduce fingerprint and similarity systems only after provenance is solid.

Conclusion

An RSS feed identity API is a registry of relationships and evidence, not merely a URL fetcher. Its stable feed IDs allow locators to change. Alias and event records preserve history. Validation resources describe quality over time. Resolver responses explain why an observed URL maps to a publication.

Build the transparent data model first, secure the network boundary, and keep uncertain matches reversible. With those foundations, an API can support feed discovery, migration, deduplication, analytics, and archival systems without turning identity into an opaque guess.

Feed Fingerprints: Detecting Duplicate or Mirrored Syndication Sources

2026-06-09T12:00:00Z

A feed fingerprint is a compact representation used to compare syndication sources. It can help a crawler recognize that an HTTP and HTTPS URL expose the same feed, detect a copied or mirrored publication, group aliases after a migration, and avoid processing identical documents repeatedly. The difficult part is deciding what the fingerprint is meant to prove.

A hash of the raw response proves only that two byte sequences are identical. Feeds that mean the same thing can differ in whitespace, namespace prefixes, element order, generated timestamps, tracking parameters, or archive depth. Conversely, two feeds can have the same recent items while representing different category or language editions. Useful fingerprinting therefore combines several measurements and keeps the evidence explainable.

Begin with the question the fingerprint answers

There is no universal feed fingerprint. A transport cache wants to know whether the fetched bytes changed. A validator may want to know whether the parsed structure changed. A registry wants to know whether two URLs represent the same continuing publication. A plagiarism monitor may want to detect substantial content overlap. Each objective requires different inputs and different tolerance for false matches.

Name the fingerprint by purpose: content_bytes_sha256, normalized_document_hash, item_identity_signature, or publication_match_score. Calling every value “the fingerprint” hides assumptions and makes later migrations risky.

Raw byte hashes are exact and limited

A cryptographic hash of the response body is cheap, deterministic, and useful for caching. If the bytes are identical, the bodies are identical. If the hash changes, however, the logical feed may still be the same. A generator can reorder attributes, change indentation, rotate namespace prefixes, or refresh a build timestamp without changing any meaningful item.

Store the byte hash alongside response headers, retrieval URL, time, and content length. It supports conditional processing and forensic comparison, but it should not be the sole key for publication identity.

Canonicalization reduces syntactic noise

XML canonicalization creates a normalized representation intended to remove certain serialization differences. The goals and processing rules are defined by standards such as W3C Canonical XML 1.1. Applying an established canonicalization method is safer than inventing ad hoc rules for attribute ordering and namespace handling.

Canonical XML still represents the whole document. A changed publication date, added item, or updated description produces a different result, as it should for document-change detection. It does not by itself answer whether two changing documents belong to the same publication.

Semantic normalization should be narrow and documented

A semantic fingerprint can parse the feed and select fields that matter for the intended comparison. For example, a publication signature might include the canonicalized feed URL, site URL, normalized title, and a sorted sample of stable item IDs. A document signature might include all parsed elements after removing known volatile fields.

Every removed field is a tradeoff. Ignoring build timestamps can reduce noise. Ignoring all dates can collapse distinct editions. Removing tracking parameters from item links can help, but stripping every query parameter may merge resources whose queries are meaningful. Rules should be versioned so a future algorithm change does not silently reinterpret old hashes.

Item identity overlap is a strong continuity signal

When two feeds share a large set of stable GUIDs, Atom IDs, or JSON Feed IDs, they are likely related. Compare a window across time rather than only the newest entries. A migration may expose the same archive at a new URL. A category feed may share a few recent items with the main feed but diverge across a larger sample.

Calculate both the count and proportion of overlap. Ten shared IDs out of ten is different from ten shared IDs out of one thousand. Preserve which IDs matched and whether their associated titles, links, and dates are consistent. This evidence is more useful than an unexplained score.

URLs need normalization without erasing identity

Normalize scheme and host case, remove default ports, and resolve obvious dot segments. Be cautious with trailing slashes, percent encoding, query parameters, and path case because server semantics differ. For observed feed URLs, record the original request, redirect chain, and final response URL instead of replacing everything with one aggressively normalized string.

A verified permanent redirect is stronger evidence than two URLs that merely normalize to similar text. Redirect provenance should be kept as its own signal in a publication match.

A layered fingerprint record

{
  "algorithm_version": "rssid-fp-1",
  "retrieval_url": "https://example.org/feed/",
  "byte_sha256": "...",
  "canonical_xml_sha256": "...",
  "channel_signature": "...",
  "item_id_minhash": ["..."],
  "sample_size": 40,
  "observed_at": "2026-06-09T18:00:00Z"
}

This record separates exact document equality from structural and historical similarity. A resolver can use the fields independently. For example, identical byte hashes allow a fast cache hit, while item overlap and redirect evidence support a proposed identity merge.

Do not hash secrets or unstable personalized output

Private feeds may contain access tokens in URLs or personalized content in items. Storing raw URLs, bodies, or unsalted hashes can expose sensitive information or allow dictionary attacks against predictable tokens. Apply data minimization: redact credentials, restrict access, and document retention.

A feed that varies by authentication context should not be assumed to have one public fingerprint. Include the retrieval scope or account identity in internal cache keys, and never use a private observation as public proof of ownership.

Mirrors, aliases, and copies are different relationships

An alias is another URL for the same logical feed, often connected by redirect or publisher declaration. A mirror intentionally serves equivalent content from a separate location. A copy may reproduce content without authority. High item overlap can occur in all three cases, so a fingerprint cannot establish permission or ownership.

Store relationship types separately. Evidence such as reciprocal links, DNS control, verified publisher statements, and signed administrative actions can support an alias or mirror claim. Content similarity alone should be labeled as similarity.

Scoring publication matches

A registry can combine signals into a match score: permanent redirect, identical publisher-declared feed ID, matching self links, item-ID overlap, site URL agreement, title similarity, and host ownership. Strong signals should dominate weak text similarity. Conflicting signals should reduce confidence or trigger manual review.

A score must remain explainable. Return the individual observations and algorithm version, not only “92 percent match.” Operators need to know whether the result came from a redirect, item history, or a common generic title such as “News.”

Plan for collisions and false positives

Cryptographic hash collisions are not the practical concern in most feed systems; semantic collisions are. Two feeds can intentionally syndicate the same press releases. A network can publish localized feeds with identical GUIDs but different language content. A site can clone an archive during a split and then diverge.

Never automatically delete or merge source records based on one fingerprint. Create a reversible relationship, preserve both URLs and observations, and promote one canonical record only when evidence meets a documented threshold.

Operational uses

Fetch optimization: skip expensive parsing when the byte hash is unchanged.
Change alerts: detect unexpected structural changes despite a stable URL.
Migration discovery: connect a new URL to an old feed through redirects and item overlap.
Duplicate review: rank likely aliases or mirrors for operator inspection.
Integrity history: retain signatures for incident investigation and rollback.
Format comparison: match equivalent RSS, Atom, and JSON Feed outputs through mapped item IDs.

A safe implementation sequence

Store the raw response hash and retrieval metadata.
Parse strictly and record the detected feed format.
Apply a standards-based canonicalization where appropriate.
Compute versioned semantic signatures from narrowly defined fields.
Measure stable item-ID overlap across a meaningful time window.
Combine fingerprints with redirect and publisher-control evidence.
Keep match decisions reversible and auditable.

Conclusion

Feed fingerprints are most valuable when they remain plural. One hash can describe bytes, another normalized structure, and another item history. Together with URL provenance and publisher evidence, they help systems detect aliases, mirrors, and duplicates without pretending that content similarity proves identity.

Define the question first, version the algorithm, preserve the inputs, and expose the reasons behind every match. That approach turns fingerprinting from a brittle shortcut into a dependable component of feed discovery and registry infrastructure.

Podcast Feed IDs: Identity, Redirects, and Directory Migration

2026-02-18T12:00:00Z

A podcast feed carries several kinds of identity at once. The feed URL locates the show’s RSS document. Channel metadata describes the show. Each episode has a GUID. Each enclosure URL locates a media file. Podcast directories also maintain their own catalog records. A hosting migration succeeds only when those layers continue to refer to the same show and episodes.

Moving a podcast is therefore not just exporting XML and changing a link. A careless switch can create a duplicate show, make archived episodes appear new, break downloads, or leave followers polling an abandoned address. A safe plan preserves episode GUIDs, establishes one canonical feed URL, redirects the old URL, and verifies directory behavior over time.

Separate show identity from the feed URL

Many podcast systems use the current feed URL as the practical key for a show. That is understandable because the URL is what directories fetch. It is still a locator, and locators change. Publishers and platforms benefit from an internal immutable show ID that remains stable while the canonical feed URL and hosting provider evolve.

A registry can associate one show ID with the current URL, legacy URLs, directory IDs, and verified ownership signals. The old URLs should not be deleted after migration. They explain existing subscriptions and allow duplicate catalog entries to be reconciled.

Episode GUIDs are the continuity anchor

Podcast apps commonly rely on the RSS item GUID to recognize an episode. The new host must reproduce every established GUID exactly. If a platform imports titles and audio but creates new GUIDs, subscribers may see the entire archive as unplayed new content or download episodes again.

Export the old feed before changing anything. Build a table containing each episode title, publication date, GUID, enclosure URL, and duration. After import, compare the new feed programmatically and manually. Differences in whitespace or case can matter when values are treated as opaque strings.

Enclosure URLs can change without changing episode identity

An enclosure URL identifies where the audio or video file can be fetched. Hosting migrations often move media to a new CDN. That does not require a new episode GUID. Keep the GUID stable, update the enclosure URL and related metadata, and verify that the file is complete and served with the expected media type.

Some analytics systems place redirect layers in front of media. Test the final response, byte-range support, TLS, and playback from several apps. Avoid expiring signed URLs in public podcast feeds; a listener may request an episode months after publication.

Use a permanent redirect from the old feed

The old RSS URL should redirect directly to the new canonical feed URL. Apple’s current publisher documentation recommends a 301 redirect for host changes and describes how directories can be updated; review Apple Podcasts guidance for changing hosting providers as part of the migration plan.

The redirect must remain available after the old hosting account is closed. Confirm that the provider keeps it active, or retain control of the old domain and route. A temporary redirect or an HTML notice does not provide the same continuity. Avoid long chains through multiple historic hosts.

Understand the new-feed-url signal

The podcast namespace includes itunes:new-feed-url, which can signal a new address to compatible clients. It is a supplemental migration hint, not a substitute for an HTTP redirect. Not every client handles the element identically, and some may fetch the old URL before seeing it.

When used, the value should be the exact canonical destination and should be coordinated with the redirect. Do not point it to an intermediate tracking URL. Keep the old feed available long enough for clients to observe the change.

Directory records do not all update the same way

Major podcast directories may follow redirects automatically, offer a dashboard setting, or require a separate verification process. Build an inventory of every directory and service that matters to the show. Record its catalog ID, current feed URL, account owner, and migration status.

Do not submit the new feed as a brand-new show unless the directory specifically requires it. A fresh submission can create a duplicate listing with split reviews, followers, and analytics. Update the existing record and monitor it until the displayed episodes and artwork match the canonical feed.

Preserve channel metadata during the switch

Keep the show title, author, description, language, explicit-content setting, categories, artwork, and owner information consistent during the initial migration. Changing branding at the same time makes it harder to determine whether a directory has followed the move or created a separate record.

After continuity is confirmed, editorial updates can be made normally. The same principle applies to archive depth: if the old feed exposed 200 episodes and the new feed exposes only 20, some clients may treat missing episodes as unavailable. Understand the new host’s limits before switching.

A staged migration plan

Export the old RSS feed and retain a dated copy.
Inventory channel metadata, episode GUIDs, publication dates, and enclosures.
Import the show into the new host without changing established GUIDs.
Validate and privately test the new feed in multiple podcast apps.
Configure a permanent redirect from the old feed URL to the new URL.
Add a compatible new-feed-url signal if the workflow supports it.
Update existing directory records rather than submitting duplicates.
Monitor old and new URLs, directory pages, logs, and episode downloads.

Keep rollback notes, but recognize that permanent redirects can be cached. The destination should be production-ready before the old URL begins redirecting.

Verify from a listener’s perspective

Subscribe to the old feed URL in a clean test app before migration, then perform the switch and refresh. The show should retain its history, play state, and episode ordering. Add the new URL separately in another test and confirm that it exposes the same GUID set rather than a parallel archive.

Play recent and older episodes from different networks. Check artwork and descriptions. Inspect whether newly published episodes arrive once. These tests catch issues that a feed validator cannot, such as inaccessible media, directory lag, or client-specific duplicate behavior.

Monitor identity after launch

Keep requesting the old feed URL without following redirects and alert if it stops returning the expected permanent status. Request the new feed and compare a sample of historic GUIDs. Watch for duplicate directory listings and changes in crawler behavior. Server logs can show which services still use the old URL.

Do not interpret continued old-URL traffic as a reason to remove the redirect. It proves the redirect is still necessary. Some clients may never rewrite the stored subscription and will depend on the alias indefinitely.

Common podcast migration failures

New host generates fresh GUIDs for imported episodes.
Old feed is deleted instead of permanently redirected.
Redirect ends when the former hosting account is canceled.
Enclosure URLs use expiring signatures or return the wrong media type.
Publisher submits a new directory listing and creates a duplicate show.
Artwork, title, and archive depth change simultaneously with the host.
Only the newest episodes are tested before launch.
Legacy domains are allowed to expire.

Building a durable show identity record

An internal record can include an immutable show ID, canonical feed URL, prior feed URLs, directory catalog IDs, ownership verification, channel metadata snapshots, and a rolling set of episode GUIDs. Each migration becomes an event with a date, source, destination, and evidence.

This record helps a publisher recover from a broken redirect and helps a registry distinguish a legitimate move from a copied feed. It also supports analytics continuity when download hosts and tracking redirects change.

Conclusion

Podcast identity is distributed across the show record, feed URL, episode GUIDs, enclosure URLs, and directory catalogs. A successful migration preserves the stable parts and deliberately updates the locators. Episode GUIDs remain unchanged, the old feed redirects permanently, and directory records continue rather than restart.

Plan the move as an identity operation, not a file transfer. With a verified export, staged testing, durable redirects, and post-launch monitoring, listeners experience one uninterrupted show even as the infrastructure behind it changes.

JSON Feed IDs: Stable Identifiers in Version 1.1

2025-11-06T12:00:00Z

JSON Feed expresses syndication in a data model familiar to web and application developers. Its item object has one field that is both required and easy to mishandle: id. The value is a string that uniquely identifies the item over time. It may look like a URL, a UUID, a database key, or a namespaced token, but it should remain stable even when the item’s visible URL or content changes.

Because JSON makes serialization straightforward, teams sometimes generate feeds directly from API responses without defining an identity contract. The result can be IDs tied to array positions, current slugs, or transient database replicas. A reliable feed uses the same discipline as a durable public API: immutable keys, explicit URLs, predictable dates, and migration tests.

The id field is required

Every JSON Feed item must have an id string. The format does not require a specific syntax. A publisher can use the item URL, a UUID, a tag URI, or another value it controls. The key requirements are uniqueness within the feed and stability for as long as the item is represented.

The complete field definitions and publisher guidance are in the JSON Feed 1.1 specification. Reading the specification matters because familiar-looking fields have distinct roles. The ID identifies the item, url provides the page associated with it, and external_url can point to a resource elsewhere that the item discusses.

Do not use array position or fetch order

JSON arrays are ordered, but an item’s index is not an identity. A new item inserted at the front changes every subsequent position. Pagination, filtering, and archive trimming also change positions. Values such as item-0 or a hash of the current array index will create duplicates whenever the feed is rebuilt.

Order should be communicated through dates and the sequence of items in the current representation. Identity needs a value attached to the content record itself. If the publishing system already has an immutable primary key, it can be wrapped in a globally unique namespace and stored as the feed ID.

URL IDs work when URLs are permanent

Using the item’s canonical URL as both id and url is valid when the publisher can preserve that URL. It produces readable data and makes debugging easy. The danger is a router that rebuilds paths from mutable titles, categories, or dates. When a slug changes, a generated ID changes, and readers interpret the same article as a new item.

A publisher can keep the original URL-shaped ID after the page moves. The url field can change to the new canonical page while the ID remains the established identifier. The old URL may redirect, but the ID does not need to resolve; it needs to stay unique and stable.

Opaque IDs offer clean separation

An opaque token such as urn:uuid:... or example.org:article:1842 separates identity from routing. It also makes format conversion easier because the same token can be carried into an RSS GUID or an Atom ID with a documented mapping. The token should be created once and stored.

{
  "id": "urn:uuid:51f84fa3-6b66-4bb0-9b12-2f3d78dcd24e",
  "url": "https://example.org/guides/stable-identifiers/",
  "title": "Stable identifiers for feeds",
  "content_html": "<p>...</p>",
  "date_published": "2025-11-06T15:00:00Z",
  "date_modified": "2025-11-14T18:30:00Z"
}

Do not expose a raw database integer without a namespace if feeds from several systems can be combined. The value 1842 may be unique in one table and ambiguous everywhere else.

Dates support synchronization but do not identify

date_published describes original publication, and date_modified describes a later change. Neither should be used as the item ID. Imports, timezone corrections, and editorial updates can alter dates without creating a new item. Two items can also be published at the same instant.

Readers can use the stable ID to find an existing item and the modification date to decide whether to refresh its stored representation. Publishers should avoid setting every modification date to the build time. Doing so makes every feed request look like a full update and reduces the value of incremental synchronization.

Attachments need their own stable handling

JSON Feed attachments represent audio, video, documents, and other media associated with an item. Their URLs may move to a new CDN or storage provider. That change should not force a new item ID. Preserve the item identity and update the attachment metadata.

When an application needs attachment-level deduplication, it can store a separate media identifier or a verified checksum. Do not overload the item ID to represent a particular file version. One item can legitimately have multiple attachments or replace a broken file while remaining the same editorial item.

Feed-level identity still needs a local model

JSON Feed provides feed_url for the URL of the feed and home_page_url for the associated site. It does not define a required immutable feed ID. Applications that need to track a publication across URL changes should assign their own internal feed identifier, preserve old URLs as aliases, and treat the current feed_url as the canonical locator.

This mirrors the approach on the feed identity model: stable publication ID, canonical URL, aliases, observed metadata, and item IDs. A feed URL can move while JSON item IDs remain continuous.

Version 1.1 discovery and media type

JSON Feed 1.1 uses the more specific media type application/feed+json. An HTML page can advertise the feed with an alternate link element using that type. The feed response should return a matching content type when practical, and the JSON should be valid UTF-8.

Discovery metadata should point to the canonical feed URL. If a site also offers RSS or Atom, give each link a distinct title and media type. Equivalent formats should preserve a consistent item identity mapping so a multi-format reader does not create duplicates merely because a user switches formats.

Converting IDs between formats

A JSON Feed ID can become an RSS opaque GUID or an Atom entry ID when the value meets the target format’s syntax requirements. If it does not, place it inside a stable URI namespace instead of inventing a new random value on each conversion. Store the mapping so future exports reproduce the same result.

When importing from RSS, preserve the GUID rather than replacing it with the current link. When importing from Atom, preserve the entry ID. A conversion pipeline should be idempotent: converting the same source twice should produce the same target IDs.

Validation and testing

Parse the JSON strictly and require an ID for every item. Check that IDs are strings, nonempty, and unique within the logical feed. Compare current IDs with the previous production version. Existing content should retain its ID even when URL, title, summary, content, authors, tags, or attachments change.

Also validate that each item includes at least one appropriate content field, that URLs are absolute where required by the application, and that dates use valid ISO 8601 forms. Fetch the public feed without credentials and confirm the content type and canonical redirect behavior.

Common JSON Feed ID mistakes

Using the item’s array index as the ID.
Generating a UUID during every feed request.
Hashing the complete content, so corrections create new identities.
Using a mutable slug without preserving the original value.
Changing IDs when attachment URLs move to another CDN.
Discarding source GUIDs or Atom IDs during format conversion.
Treating the feed URL as a permanent publication ID without alias history.

A production-ready pattern

Create an immutable item identity in the publishing database. Expose it as a namespaced string in JSON Feed. Store the public page URL separately and update it when routing changes. Set publication and modification dates from content events, not deployment time. Preserve imported identifiers and document format mappings.

For the publication itself, keep an internal feed ID and a canonical feed URL. Record redirects and aliases. Add automated tests that compare IDs across builds and reject duplicates. This pattern works for a static export, a server-rendered endpoint, or an API that emits JSON Feed as one representation.

Conclusion

JSON Feed makes item identity explicit without prescribing one identifier syntax. That flexibility is valuable when paired with discipline. IDs should be immutable keys; URLs should describe current locations; dates should describe content events; attachments should describe media.

Keeping those roles separate allows a JSON Feed to survive redesigns, API refactors, CDN migrations, and conversions to other syndication formats. The result is predictable synchronization for readers and a clean identity model for publishers.

Atom IDs and RFC 4287: Choosing Permanent Feed and Entry Identifiers

2025-07-14T12:00:00Z

Atom treats identity more explicitly than RSS 2.0. Every Atom feed requires an id, and every entry requires its own id. Those values are not decorative metadata. They are permanent identifiers that allow consumers to recognize a feed and its entries even when titles, links, authors, and hosting locations change.

The requirement is simple to state and easy to undermine. A generator that derives IDs from the current URL can change identity during a migration. A static build that uses the current timestamp can create new entries on every deployment. A conversion tool can replace established RSS GUIDs with fresh Atom IDs. Good Atom publishing begins by deciding what the identifiers mean, storing them, and testing that they remain stable.

Atom id is a URI, not necessarily a web address

An Atom id contains an Internationalized Resource Identifier. It must be globally unique and should never change for the represented resource. The value can be an HTTPS URL, a URN, or a tag URI. It does not have to be dereferenceable in a browser. Its purpose is identity, while Atom link elements describe locations and relationships.

The normative rules and comparison behavior are defined in RFC 4287. Publishers should follow those rules directly because small transformations that seem harmless to a developer can change the identifier as a string. Consumers should compare IDs according to the specification rather than applying arbitrary URL cleanup.

Feed identity and entry identity are separate

The feed-level ID represents the continuing publication. Entry IDs represent individual posts, releases, alerts, or other units within it. An entry’s ID must not be copied from the feed ID, and the feed ID must not be regenerated from the newest entry. The hierarchy is conceptual, not encoded by string prefixes.

A system that stores Atom data should normally key entries by both the logical feed record and the entry ID. Global uniqueness reduces collision risk, but retaining the feed relationship preserves provenance and helps when feeds are merged, mirrored, or split. The feed ID itself can be one signal when deciding whether two observed URLs expose the same publication.

HTTPS URL IDs are readable but need permanence

A canonical HTTPS URL can serve as an Atom ID when the publisher controls it and can keep it stable. For an entry, the public article URL is a common choice. For a feed, a URI specifically reserved as the identity can be clearer than the retrieval URL. The important question is whether the URI will remain unchanged when routing, domains, or content systems change.

If an entry URL changes, the Atom link rel="alternate" can point to the new page while the original ID remains. An ID is not a command to fetch the latest representation. Treating it as a permanent name allows location to evolve without creating a new entry.

Tag URIs decouple identity from hosting

A tag URI uses a domain or email authority plus a date to establish a globally unique namespace, followed by a publisher-defined component. A value can look like tag:example.org,2025:post/1842. The domain identifies an authority at the chosen date; the URI is not expected to resolve over HTTP.

This form is useful when a publisher wants readable IDs without promising that a web route will stay online forever. The dated authority should be chosen carefully, and the local component must remain unique. Like any other identifier, the result should be stored rather than reconstructed from mutable fields.

Generate once and preserve exact values

The safest implementation adds immutable fields for the feed ID and each entry ID. Assign them when the publication or entry is created. The feed renderer reads those values without changing case, encoding, or punctuation. A database constraint or application rule prevents reuse.

<feed xmlns="http://www.w3.org/2005/Atom">
  <id>tag:example.org,2025:updates</id>
  <title>Example Updates</title>
  <updated>2025-07-14T16:00:00Z</updated>
  <link rel="self" href="https://example.org/atom.xml"/>
  <entry>
    <id>tag:example.org,2025:post/1842</id>
    <title>A stable entry</title>
    <updated>2025-07-14T15:45:00Z</updated>
    <link rel="alternate" href="https://example.org/posts/stable-entry/"/>
  </entry>
</feed>

A snapshot test can record these values for representative entries and compare them during every build. The test should be insensitive to legitimate content updates but strict about IDs.

Updated timestamps do not replace identity

Atom requires an updated value for the feed and entries. That timestamp communicates modification time; it is not an identifier. A consumer can use the ID to locate a stored entry and the updated time to decide whether the representation may have changed. Generators that put a fresh timestamp on every entry during every build create unnecessary churn even if IDs remain stable.

Set an entry’s updated time when the entry’s meaningful content changes. Set the feed’s updated time according to the most recent update represented by the feed. Keep publication time in published when it is useful and known. Clear time semantics make synchronization more efficient.

Self links connect identity to retrieval

An Atom feed should publish a link rel="self" that points to the canonical URL of the feed document. The feed ID may be the same string, but it does not have to be. Keeping the concepts separate allows a permanent identity URI and a movable retrieval URL.

Resolvers can use the self link, redirect chain, feed ID, and entry overlap as independent evidence. If an old URL redirects to a new URL and both representations carry the same feed ID, the case for one continuing publication is strong. If the IDs differ, a merger should not be automatic without further evidence.

Migrating an Atom feed

Before a hosting move, export the current feed ID and all retained entry IDs. Configure the new system to import them exactly. Validate that the self link changes to the new canonical URL while IDs remain unchanged. Deploy permanent redirects from old feed URLs and update HTML autodiscovery.

A migration is not the moment to switch from URL IDs to tag URIs. That may look like an improvement, but it tells clients that every feed and entry is new. If a new scheme is required for a separate publication, use new IDs deliberately and document the relationship instead of silently rewriting history.

Converting between RSS and Atom

A converter needs an explicit identity mapping. An RSS item GUID can often be preserved as the basis of an Atom entry ID, but only if it can be represented as an IRI and the conversion remains stable. If an RSS GUID is an opaque token that is not a valid IRI, the converter can place it inside a stable URN or tag-URI namespace. The mapping must be deterministic and recorded.

Converting back from Atom to RSS requires similar care. An Atom entry ID can become an opaque RSS GUID with isPermaLink="false". Do not replace it with the current alternate link unless the publisher intentionally wants URL-based identity. The metadata guide provides a field-by-field framework for format bridges.

Consumer behavior and normalization

Consumers should store Atom IDs as published and avoid generic URL canonicalization. Removing a trailing slash, lowercasing a path, decoding reserved characters, or substituting an HTTP URL for HTTPS can collapse distinct identifiers. The URI syntax may permit several equivalent-looking representations, but the Atom comparison rules are intentionally specific.

When an ID is missing, the document is not a conforming Atom feed or entry. A tolerant application may create a local fallback to keep processing, but it should label that value as inferred and avoid presenting it as a publisher-assigned Atom ID. Fallback matching should use several signals and remain reversible.

Common Atom ID failures

Using the current build time inside the ID.
Copying the feed URL and changing it whenever the host changes.
Using an entry title or slug without preserving the original value.
Assigning the same ID to multiple entries in a batch import.
Replacing established IDs during RSS-to-Atom conversion.
Confusing updated timestamps or self links with identity.
Applying URL normalization to opaque or tag-based IDs.

An implementation checklist

Choose a URI scheme appropriate to the publisher’s long-term control.
Assign one immutable feed ID and one immutable ID per entry.
Store IDs in content data rather than regenerating them from templates.
Publish a canonical self link separately from the permanent feed ID.
Update timestamps only when represented content changes.
Preserve IDs during imports, redirects, and format conversions.
Test uniqueness and stability in continuous integration.

Conclusion

Atom makes identity a first-class requirement. That strength pays off only when publishers treat IDs as permanent names rather than convenient copies of current URLs. Feed IDs describe the continuing publication; entry IDs describe individual resources; links describe where representations can be retrieved.

Store identifiers once, keep them exact, and let links and timestamps change for their own reasons. With that separation, Atom feeds can move between domains, systems, and formats while consumers retain a coherent history.

RSS Validation Checklist: Fixing Feed Errors Before Release

2025-03-26T12:00:00Z

Feed validation is more than receiving a green badge from an XML checker. A document can be well-formed yet still create duplicate items, expose broken enclosure URLs, publish dates that clients cannot parse, or claim one canonical URL while redirects lead somewhere else. A release checklist needs to cover syntax, semantics, identity, HTTP behavior, and real client interpretation.

The best time to validate is before publication and again after deployment. Static site generators can test the built file. Dynamic systems can test a staging endpoint. Production monitoring should then fetch the public URL from outside the hosting environment, because caches, redirects, TLS, and content negotiation can change what subscribers actually receive.

Start with XML well-formedness

RSS 2.0 is XML. Every opening tag needs a matching close, attribute values must be quoted, reserved characters must be escaped, and the document must have one root element. A single unescaped ampersand in a title or query string can prevent a strict parser from reading the entire feed.

Generate XML with a real serializer rather than string concatenation. Serializers handle escaping for text and attributes and reduce mistakes around CDATA sections. If full HTML content is placed in content:encoded, verify that the generated CDATA cannot be terminated accidentally by embedded ]]> text.

Check encoding from declaration to response

UTF-8 is the safest default. The XML declaration, actual bytes, and HTTP Content-Type header should agree. Problems appear when a template declares UTF-8 but the server converts content to another character set, or when copied text contains invalid byte sequences. Test non-ASCII names, punctuation, emoji, and right-to-left text if the publication uses them.

Do not assume a browser preview proves encoding is correct. Browsers often recover from errors that feed parsers reject. Inspect the raw response and parse the bytes with the same encoding the server declares.

Verify required channel metadata

An RSS 2.0 channel requires a title, link, and description. These values should describe the publication consistently and should not be empty placeholders. The link normally points to the associated website, not back to the feed file. Optional fields such as language, managing editor, and image should be included only when accurate and useful.

Also inspect namespace declarations. Extensions such as content, atom, media, or podcast namespaces need correctly declared URIs and correctly prefixed elements. Unused declarations are usually harmless but can indicate that a template was copied without understanding the output.

Validate item identity before visible content

Duplicate prevention depends on stable item identifiers. Compare the GUIDs in the new build with identifiers from the current production feed. Existing items should keep the same values even if titles, descriptions, or links were edited. Opaque GUIDs need isPermaLink="false"; URL GUIDs should remain valid identifiers even when the current link changes.

Make this comparison automated. Keep a fixture of representative items or query the content database for the stored identity field. A build should fail if a known item’s GUID changes without an explicit migration approval. The GUID guide explains the identity contract in more detail.

Dates must be parseable and truthful

RSS publication dates use the RFC 822 family of date formats, commonly rendered like Wed, 26 Mar 2025 14:30:00 GMT. Include a timezone. Avoid locale-specific month names, bare dates, and values that depend on the server’s local timezone. An invalid date can cause an item to disappear, sort incorrectly, or look newly published on every fetch.

Do not rewrite every item date during a rebuild. The publication date represents the item, not the build. If an extension exposes an updated time, use it only when content was actually modified. Future-dated items should be intentional and tested with the target clients.

Inspect links and enclosure responses

Every item link should resolve to the intended public page. Follow redirects and reject destinations that end on authentication pages, generic homepages, or errors. For podcasts and media feeds, each enclosure URL should return the media file with the expected content type, support reliable byte delivery, and remain stable after publication.

Do not validate only the newest enclosure. Sample older episodes because storage migrations and expired signed URLs often break archives. A feed can parse perfectly while every media request fails.

Use a standards-aware validator

Automated schema and profile checks catch issues that a generic XML parser cannot. Submit the public URL to the RSS Advisory Board validator and review warnings as well as errors. A warning may describe a compatibility risk even when the document is technically parseable.

Validators are one layer, not an oracle. Some extensions are intentionally outside the validator’s knowledge, and some operational failures occur after parsing. Record the validator output with the build or release so later regressions can be compared with a known state.

Check HTTP behavior at the canonical URL

Request the feed without browser cookies. Confirm a successful status, a reasonable content type such as application/rss+xml, and a body that begins with the expected XML. Check that the canonical URL does not alternate between different responses based on user agent unless that behavior is deliberate and documented.

If legacy URLs exist, inspect each redirect without automatically following it. The status should express a permanent move, the Location header should be absolute, and the chain should end at the canonical feed. Redirect loops, downgrade to HTTP, and hops through tracking services are release blockers.

Test discovery and self-reference

Fetch representative HTML pages and confirm their autodiscovery links point to the canonical feed. If the feed publishes an Atom self link, verify it matches the final URL. A mismatch may not break parsing, but it creates uncertainty for resolvers and directories trying to distinguish a mirror from the primary source.

Visible RSS links should also work without JavaScript. The footer and subscription documentation must not reference a different path from the machine-readable metadata.

Sanitize embedded HTML responsibly

Item descriptions and full-content fields often contain HTML. Ensure tags are balanced, URLs are absolute where necessary, images have meaningful alternative text, and unsupported scripts are removed. Feed readers apply their own sanitization, so an article that depends on JavaScript, forms, or complex layout may be unusable in the reading view.

Do not place untrusted markup into CDATA and assume it is safe. CDATA only changes XML parsing; it does not make HTML secure. Publishers should sanitize content before feed serialization, and readers should sanitize again before display.

Run compatibility tests in real clients

Add the staging or preview feed to several readers with different parsing engines. Confirm the title, artwork, dates, links, full content, categories, and item order. For a podcast, test directory ingestion and actual playback. For a migration, subscribe through the old URL and verify that history remains continuous after the redirect.

Real-client tests reveal assumptions that validators cannot, such as how much HTML is shown, whether relative links are resolved, or whether a particular namespace is honored. Keep a small compatibility matrix and repeat it when the generator, host, or feed format changes.

Automate a release gate

A practical continuous-integration gate can parse the XML, assert required channel fields, count items, verify unique GUIDs, check date parsing, inspect the single canonical URL, and test a sample of internal links and enclosures. It can compare known GUIDs with the previous release and reject future publication dates unless explicitly allowed.

Network tests should have clear timeouts and distinguish a temporary dependency failure from invalid output. Store the generated feed as a build artifact so the exact bytes can be inspected when a check fails. Do not let the production server be the first environment in which the file exists.

Release checklist

XML parses strictly and matches the declared character encoding.
Channel title, link, and description are present and accurate.
Namespaces are declared correctly and used intentionally.
Every item has a stable, unique identity within the feed.
Dates include timezones and preserve established publication times.
Item links and sampled media enclosures return the expected resources.
The canonical feed URL returns the feed directly over HTTPS.
Legacy URLs redirect permanently and directly to the canonical URL.
HTML autodiscovery points to the same canonical feed.
A standards-aware validator and representative readers accept the result.

Conclusion

Validation is an operational discipline, not a one-time XML test. Syntax, identity, dates, URLs, headers, redirects, embedded HTML, and client behavior all contribute to whether a feed is dependable. A release process that checks only the newest item leaves the most important failures undiscovered.

Automate the repeatable checks, preserve evidence from each release, and test the public endpoint from the outside. That combination catches malformed output early and protects subscribers from duplicate items, broken archives, and silent feed moves.

RSS Autodiscovery: Publishing the Right Link Tag in HTML

2024-12-03T12:00:00Z

Feed autodiscovery is a small piece of HTML that removes a large amount of guesswork. A website places a link element in the document head, identifies the syndication format, and points to the feed URL. Compatible readers, browser extensions, crawlers, and developer tools can then find the feed without scraping page links or guessing common paths such as /rss.xml.

The markup is simple enough to copy in seconds, but correctness depends on details: the relationship, media type, URL, title, placement, and behavior when more than one feed exists. Autodiscovery should lead clients to the canonical feed, not to an obsolete alias, an HTML landing page, or a temporary environment.

The basic RSS link element

For RSS 2.0, place a link like the following inside the HTML head of each relevant page:

<link rel="alternate"
      type="application/rss+xml"
      title="Example Site Updates"
      href="https://example.org/feed/">

The relationship is alternate because the feed is an alternate representation of the site’s changing content. The media type tells clients how to interpret the target. The title provides a human-readable label when a page exposes several choices. The href should resolve to the feed itself and ideally use the canonical HTTPS URL.

Publishers can compare their implementation with the RSS Advisory Board autodiscovery guidance. The key point is that discovery is declared by the HTML page; a client should not have to infer the feed from a decorative RSS icon or a sentence in the footer.

Atom and JSON Feed use distinct media types

An Atom feed uses application/atom+xml. JSON Feed 1.1 uses application/feed+json. A site may publish more than one format, but each link needs its own accurate media type and descriptive title.

<link rel="alternate" type="application/rss+xml"
      title="Example Site — RSS" href="https://rssid.com/feed/">
<link rel="alternate" type="application/atom+xml"
      title="Example Site — Atom" href="https://rssid.com/atom.xml">
<link rel="alternate" type="application/feed+json"
      title="Example Site — JSON Feed" href="https://rssid.com/feed.json">

Publishing multiple formats is useful only when they represent the same content reliably. If one version is abandoned or updated on a different schedule, discovery can send users into inconsistent histories. Remove unsupported formats rather than leaving stale link elements in every page.

Absolute URLs reduce ambiguity

Relative href values are valid in HTML and often work, but absolute feed URLs are easier to inspect and less vulnerable to mistakes involving base URLs, preview hosts, or copied templates. Static site generators should derive the absolute URL from the production site configuration and fail the build if it still contains localhost, a staging hostname, or an example domain.

Whichever form is used, the resolved target should be the canonical feed URL. Do not publish an old URL merely because it redirects. New subscribers should start at the preferred location; redirects exist to preserve existing subscriptions and aliases.

Put discovery in the head, not only in visible navigation

A visible “RSS” link is useful for people, and a machine-readable link element is useful for software. They solve different problems and should coexist. The autodiscovery element belongs in the document head, where clients expect metadata. A footer anchor with type="application/rss+xml" is not an equivalent substitute.

The link should appear in the initial HTML response. Injecting it later with JavaScript excludes clients that do not execute scripts and complicates crawling. On a fully static site, there is no reason to delay it.

Decide what a page is advertising

Many sites have one sitewide feed. In that case, every public page can advertise the same canonical URL. A blog article, about page, and homepage all point to the publication feed. This consistency helps tools discover the feed from any entry point.

Sites with category, author, language, or podcast feeds need a policy. A category page can advertise the category feed first and the sitewide feed second, using clear titles. An individual article usually advertises the sitewide or section feed rather than a one-item feed. A multilingual page should not silently link to a feed in a different language unless the title makes that relationship clear.

Order and titles matter when several feeds are present

Some clients display all discovered feeds; others choose the first compatible link. Put the most appropriate feed first. Titles should distinguish scope and format, such as “Engineering Updates — RSS” and “All Company News — Atom.” Avoid repeating the site name without indicating why two links differ.

Do not publish dozens of nearly identical category feeds on every page. Excessive discovery makes automated selection unreliable and produces a poor user experience. Advertise the feeds that are directly relevant to the page and link to a separate human-readable directory for the rest.

Keep HTML canonical metadata and feed identity aligned

The page’s canonical link identifies the preferred HTML page, while feed autodiscovery identifies an alternate syndication resource. They are not interchangeable. A blog homepage might contain both:

<link rel="canonical" href="https://example.org/blog/">
<link rel="alternate" type="application/rss+xml"
      title="Example Blog RSS" href="https://example.org/feed/">

The feed should also link back to the associated website through its channel metadata, and formats that support a self relation should point to the canonical feed URL. These reciprocal signals help resolvers connect the HTML publication, the feed document, and observed aliases.

Test the entire request, not only the tag

A perfectly written link element is useless if the target returns HTML, requires a cookie, redirects in a loop, or has malformed XML. Fetch the exact href from a clean client. Confirm the status, content type, character encoding, and final URL. Then subscribe with more than one reader and verify that the expected title and recent items appear.

Automated tests can parse representative HTML pages, collect feed link elements, resolve each href, and require a successful response. They should also reject production pages that reference development hosts. The feed validation guide covers checks for the target document itself.

Common autodiscovery failures

Wrong media type. The link says text/xml or text/html even though it targets an RSS feed.
Wrong relationship. A template uses rel="feed", which is not the established autodiscovery pattern.
HTML target. The href opens a subscription help page instead of returning feed data.
Staging hostname. Production pages advertise a preview or localhost URL.
Dead legacy path. The discovered URL was retired without a redirect.
JavaScript insertion. The link exists only after client-side rendering.
Undifferentiated choices. Several links have the same title, leaving users unable to select the intended scope.

Security and ownership considerations

Autodiscovery is a publisher assertion, not cryptographic proof. A compromised page can advertise an attacker-controlled feed. Clients that use discovery for sensitive workflows should fetch over HTTPS, apply normal certificate validation, and retain the page URL and discovery time as provenance. A registry should distinguish “declared by this page” from “verified as controlled by this organization.”

Publishers should monitor templates for unauthorized changes and ensure content management plugins cannot replace feed links unexpectedly. When a feed moves, update the discovery element at the same time the redirect is deployed. Leaving the old value in HTML prolongs dependence on the alias and obscures whether the new address is intentional.

A concise publishing checklist

Place the link element inside the server-rendered HTML head.
Use rel="alternate" and the format’s specific media type.
Point directly to the canonical HTTPS feed URL.
Add a useful title, especially when multiple feeds are advertised.
Keep the same declaration across pages that share one sitewide feed.
Test the resolved target and final response in real readers.
Update the element during migrations while retaining redirects for old URLs.

Conclusion

RSS autodiscovery is a compact contract between a web page and feed-aware software. Correct markup removes guesswork, directs new subscribers to the canonical source, and gives registries an explicit relationship to record. Its simplicity is a reason to test it carefully, not a reason to ignore it.

A good implementation uses the right relationship and media type, lives in the HTML head, points to a working canonical URL, and clearly distinguishes multiple feeds. Paired with visible subscription links and durable redirects, it makes feed discovery reliable for both people and machines.

Canonical Feed URLs: How to Move or Rename a Feed Safely

2024-09-17T12:00:00Z

A canonical feed URL is the preferred address from which a publication expects readers and crawlers to retrieve its feed. It should be stable, use HTTPS, return the feed directly, and appear consistently in website autodiscovery, documentation, directory listings, and internal configuration. Choosing that address is easy on launch day. Preserving its meaning during a domain or hosting migration is the real work.

A feed move affects more than one HTTP request. Subscribers may have stored the old URL for years. Podcast directories may poll on their own schedules. Search crawlers may discover both locations. Analytics platforms may classify them as separate sources. A safe migration therefore treats the old URL as an enduring alias and uses explicit protocol behavior to connect it to the new canonical location.

Canonical does not mean “the only URL ever seen”

One logical feed can be observed at several addresses: an HTTP version, an HTTPS version, a vendor-hosted URL, a branded URL, and one or more redirected paths. The canonical URL is the preferred current locator, not a reason to forget the others. A feed identity record should retain each previously valid address and the evidence that relates it to the publication.

This distinction prevents duplicate records. When a crawler encounters an old URL that permanently redirects to the canonical URL, it can attach that observation to the existing feed rather than create a new feed. When a redirect later fails, the alias history still explains where the subscription originated.

Choose the destination before touching the source

The new URL should be boring and durable. Avoid version numbers, campaign names, technology names, and vendor-specific folders unless they are truly permanent. A path such as https://example.org/feed/ is usually easier to preserve than https://feeds.vendor.example/customer-8472/rss.xml. The destination must return a successful response with the correct feed body and a suitable content type.

Build and validate the new feed before redirecting the old one. Compare the publication metadata and item IDs, not just the visible titles. The new output should preserve established GUIDs or Atom IDs. If the new host cannot import them, resolve that problem first; otherwise the migration can make every archived item appear new.

Use a permanent HTTP redirect

The old feed URL should respond with a permanent redirect to the new canonical URL. HTTP defines the semantics clients use to interpret redirection, and publishers should review HTTP Semantics in RFC 9110 rather than relying on folklore. In practice, a 301 response is broadly understood for feed migrations. A 308 is also permanent but may not be handled identically by older feed software, so compatibility testing matters.

GET /old-feed.xml HTTP/1.1
Host: old.example.net

HTTP/1.1 301 Moved Permanently
Location: https://example.org/feed/
Cache-Control: public, max-age=3600

The Location value should be absolute and use the final destination, not the first hop in a chain. Redirect chains add latency and create more points of failure. If possible, make every historic feed URL redirect directly to the current canonical URL.

Keep the old domain and route under control

A redirect works only while the old host continues to answer. Letting the old domain expire can expose subscribers to takeover risk or simply strand clients that never updated their stored URL. Feed migrations should include a long-term ownership plan for old domains and vendor routes. “Long enough” is measured in years, not days, because some readers poll rarely and some directories preserve source URLs indefinitely.

When leaving a hosting provider, confirm which redirects remain after account closure. A dashboard setting may stop working when billing ends. Test from an external network after the migration, and keep an independent monitor on the old URL. A successful test performed while logged into an administrative account is not sufficient evidence that anonymous clients receive the same response.

Publish the canonical URL everywhere you control

Update the website’s link rel="alternate" feed discovery element, visible subscription links, documentation, app settings, directory profiles, and API responses. Where the feed format supports a self link, publish the canonical URL there as well. Consistency helps new clients start from the preferred location while the redirect protects existing clients.

Do not remove the old URL from historical migration records. Internally, store both the requested URL and the final URL after redirects. That pair is useful for diagnosing reports such as “the feed works in one reader but not another,” because different clients may cache redirects for different lengths of time.

Preserve item identity and ordering

A move should not be combined with an unnecessary rewrite of item IDs, publication dates, and archive depth. Changing many variables at once makes failures difficult to interpret. Preserve GUIDs exactly. Keep the same timezone interpretation for publication dates. Ensure the new host does not truncate the feed so aggressively that a client sees a completely different recent history.

If content corrections are necessary, complete the identity-preserving migration first and make editorial changes afterward. That sequence gives operators a clean baseline. It also helps readers distinguish a location change from a content update.

Test like several different clients

Start with raw HTTP checks: request the old URL without following redirects, inspect the status and Location header, then follow the redirect and inspect the final content type and body. Repeat with common user-agent strings if the host applies special routing. Verify that HEAD and GET behave sensibly, although clients should not be assumed to use HEAD before every fetch.

Next, add both old and new URLs to multiple feed readers in a test account. The resulting subscription should show the same item history. For a podcast, check major directories and at least a few playback apps. Watch server logs for continuing requests to the old URL; they demonstrate why the alias must remain available.

A staged migration sequence

Inventory every known feed URL, including HTTP, HTTPS, vendor, and legacy paths.
Choose the permanent canonical destination and configure it to return the complete feed.
Import and compare stable item identifiers across old and new output.
Validate the new feed and test it directly in representative clients.
Deploy a direct permanent redirect from each legacy URL.
Update autodiscovery, visible links, directories, and internal configuration.
Monitor both source and destination, preserving logs and migration notes.
Retain control of old domains and keep redirects operational.

This sequence leaves room for rollback before the redirect is widely cached. Once clients have accepted a permanent move, reversing it can be unpredictable, so the destination should be ready before the first production redirect.

What not to do

Do not return an HTML page that says “the feed has moved” and expect feed readers to interpret it. Do not use JavaScript navigation; feed clients are not browsers. Do not place the new feed behind authentication unless the old feed had the same access model. Do not redirect to a homepage, a generic error page, or a route that negotiates different content based on cookies.

Avoid temporary redirects for a permanent move. They tell clients that the old URL remains authoritative and can cause repeated requests through the extra hop. Also avoid blocking the old URL in robots.txt; feed readers may not obey that file consistently, and it does not communicate the new location.

When two live URLs are intentional

Sometimes a publisher intentionally offers separate feeds for all posts, a category, a language, or a media format. Those are distinct publications even when content overlaps. Give each one a clear title, canonical URL, and identity. Do not redirect a specialized feed to a general feed unless the specialized publication is genuinely discontinued.

Mirrors are different again. A mirror may serve the same logical feed for resilience. Systems should record it as an alternate retrieval location rather than a second publication, but only when the publisher declares or verifies that relationship. Similar content alone is not enough.

Conclusion

A canonical feed URL is a promise about the preferred current location, backed by a history of aliases. Safe migrations preserve item IDs, deploy permanent HTTP redirects, update discovery metadata, and keep old routes alive. The goal is not merely to make the new URL work; it is to make every existing subscription continue working without duplicate items or lost history.

Publishers that model identity separately from location can move confidently. Readers can follow redirects while retaining the original alias, registries can merge observations without erasing provenance, and users experience one continuous feed rather than a forced resubscription.

RSS GUIDs Explained: Stable Item IDs Without Duplicate Entries

2024-05-29T12:00:00Z

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.

What Is an RSS Feed ID? A Practical Identity Model for Syndication

2024-02-12T12:00:00Z

An RSS feed is easy to locate and surprisingly hard to identify. Most software starts with a URL, downloads an XML document, and treats that address as the feed’s identity. That shortcut works until the publisher changes domains, moves to a new hosting platform, adds a redirect, exposes both RSS and Atom, or republishes the same channel through a mirror. At that point a locator and an identity are no longer the same thing.

A practical RSS feed ID is a stable value that represents the logical publication rather than one temporary network location. It gives readers, crawlers, podcast directories, analytics systems, and registries a way to say, “this is the same feed we saw before,” even when visible details have changed. The idea is not a new XML element mandated by RSS. It is an operational identity layer built from the identifiers and relationships that feeds already expose.

A locator answers where; an identity answers which

The canonical feed URL remains essential. It is the address a client requests, the value publishers place in autodiscovery markup, and often the value users copy into a reader. But a URL can change for routine reasons: HTTPS adoption, a new CMS, a host migration, a path cleanup, or a switch from a vendor subdomain to a branded domain. Treating every new URL as a new publication creates duplicate subscriptions and fragmented history.

A feed ID should survive those changes. In a local application it might be a database UUID assigned when a feed is first accepted. In a public registry it could be a URI under the registry’s own namespace. In a decentralized resolver it might be a deterministic identifier derived from verified metadata. The representation can differ, but the contract should be the same: once assigned, the ID is not recycled, edited to look nicer, or replaced merely because the feed moved.

Feed identity has several layers

Reliable systems separate the identity of the publication from the identity of the documents and entries around it. Collapsing those layers into one field makes migrations and deduplication much harder.

Publication identity represents the continuing channel, show, newsletter, or stream.
Canonical feed URL is the preferred current retrieval location for that publication.
Observed feed URL records an address at which the feed was found, including old locations and mirrors.
Item identity represents one post or episode, commonly through an RSS guid, an Atom id, or a JSON Feed id.
Source identity records the publisher, site, or account responsible for the feed when that information can be verified.

This layered model prevents an item GUID from being mistaken for a channel identifier and prevents a website homepage from being treated as the feed itself. It also allows a registry to preserve a complete history: one publication ID can point to a current canonical URL while retaining prior URLs as aliases.

What RSS itself gives you

RSS 2.0 defines a channel containing metadata and items. The channel has a required title, link, and description, while items may include GUIDs. The format does not require a permanent channel-level identifier. That omission is why implementations often lean too heavily on the retrieval URL. Publishers should understand the actual vocabulary in the RSS 2.0 specification before inventing additional assumptions about identity.

Useful signals still exist. The channel link can associate the feed with a site. Atom namespace extensions can publish a self link. Redirect history can connect an old URL to a new one. Repeated item GUIDs can provide continuity. None of those signals is perfect alone, but together they can support a high-confidence identity decision.

A practical identity record

An internal feed record should be explicit about what is asserted, what was observed, and what was inferred. A compact model might store an immutable internal ID, the current canonical URL, a set of aliases, the format, the last successful fetch time, the HTTP redirect chain, the channel title, the site URL, and a rolling sample of item IDs. It should also record provenance for every change.

{
  "feed_id": "rssid:feed:7f84c9b2",
  "canonical_url": "https://example.org/feed.xml",
  "aliases": ["http://old.example.net/rss"],
  "format": "rss2",
  "site_url": "https://example.org/",
  "identity_evidence": ["permanent_redirect", "matching_item_ids"],
  "status": "active"
}

The evidence field matters. Two feeds with similar titles are not necessarily the same. A redirect from a controlled old URL, a publisher-declared self link, and a large overlap of stable item IDs are stronger signals than matching descriptions or artwork. Systems should be able to explain why they merged two records and reverse that decision if the evidence later proves misleading.

How to assign IDs without creating lock-in

The safest assignment strategy is boring: generate an opaque identifier and never encode mutable business information inside it. Domain names, product names, category names, and dates all invite later edits. A UUID, random token, or registry URI avoids that pressure. Human-readable slugs can exist as labels, but they should not be the primary key.

Deterministic IDs can be useful when multiple systems must independently reach the same result, but they are harder than they appear. Hashing the raw XML produces a new ID whenever whitespace, ordering, dates, or content changes. Hashing the current URL makes the ID move with the locator. A deterministic scheme needs a carefully defined normalization process and a collision policy. For most publishers and applications, a stored opaque ID plus documented alias history is easier to operate.

Identity changes should be events, not edits

When a feed moves, do not overwrite the old URL and erase the story. Record an identity event: old URL observed, redirect verified, new URL adopted as canonical, and old URL retained as an alias. That event log is valuable when a client reports duplicates, a host accidentally removes a redirect, or a feed is taken over by an unrelated publisher.

The same principle applies to merges and splits. If two URLs are confirmed as the same logical feed, merge them while preserving both records and the evidence. If one feed becomes two publications, create new IDs for the new publications and document their relationship to the original. An identity system should reflect publishing history rather than force every change into a single mutable row.

Common identity mistakes

The most frequent mistake is using the title as an ID. Titles are marketing copy and may change weekly. Another is using the website link, which can point many feeds to the same homepage. Item GUIDs are also misused: a GUID identifies an item, not the channel. Finally, some systems follow redirects but discard the requested URL, losing the alias that would have explained why a user’s subscription still works.

A subtler failure is merging feeds merely because they share recent entries. Publishers sometimes expose a full feed, a category feed, and a podcast feed that temporarily contain overlapping content. Identity decisions need several independent signals, time, and a way to remain uncertain. A confidence score is useful only when the underlying evidence remains inspectable.

A publisher checklist for durable identity

Choose one canonical HTTPS feed URL and publish it consistently.
Keep item IDs stable when titles, descriptions, artwork, or URLs are corrected.
Use permanent redirects when moving the feed and keep them in place for as long as possible.
Publish autodiscovery markup from the associated website.
Retain a record of prior feed URLs, hosting changes, and migration dates.
Test the old and new locations with multiple readers before announcing a move.

For applications, the corresponding checklist is to separate IDs from URLs, preserve aliases, store redirect history, compare stable item identifiers, and make merges reversible. The detailed model on the feed identity page can be used as a starting schema.

Conclusion

An RSS feed ID is best understood as a durable operational identity for a continuing publication. It is not a prettier URL and it is not a replacement for RSS GUIDs. It sits above retrieval locations, connects aliases and migrations, and gives software a stable key for subscriptions, analytics, validation history, and discovery records.

The strongest implementations do not pretend that one XML field solves the problem. They combine an immutable internal ID with a canonical URL, alias history, item-level identifiers, and explicit evidence. That approach keeps identity stable while allowing the web around it to change.