RSS identity reference

RSS feed identity

A feed is a continuing publication. Its URL is only the current retrieval location. Model both so migrations and mirrors do not create duplicates.

Four identity layers

A durable system separates the logical publication, its current canonical feed URL, every observed alias, and the identifiers of entries within the feed. These layers change at different speeds. The publication can continue for years while domains, paths, formats, and hosting providers change around it.

Core rule: never make a mutable locator the only primary key for a continuing feed.

Publication ID

Assign an opaque, immutable identifier when a feed enters the system. It can be local to an application or expressed as a registry URI. Do not encode the current domain, title, or format inside the primary key.

Canonical URL

Store one preferred HTTPS retrieval location. A canonical URL can change after a verified migration without changing the publication ID.

Aliases

Retain HTTP variants, legacy host URLs, redirected routes, and intentional mirrors with relationship types and observation dates. Aliases are evidence, not clutter.

Item IDs

RSS GUIDs, Atom IDs, and JSON Feed IDs identify individual entries. They support continuity evidence, but they do not replace the feed-level identity.

Minimum data model

feed_id             immutable registry or application key
canonical_url       preferred current retrieval URL
aliases[]           historic and alternate URLs with provenance
format              rss2, atom, jsonfeed, or unknown
site_urls[]         associated HTML publications
metadata_snapshots  titles, descriptions, language, artwork
item_id_samples[]   rolling evidence from stable entry identifiers
events[]            move, merge, split, claim, validation, retirement

Store timestamps and provenance for every observation. A field parsed from a feed is not the same as a value asserted by a verified publisher. An inferred canonical URL is not the same as one established by a permanent redirect and a declared self link.

Evidence for identity matches

Strong evidence includes a direct permanent redirect, a stable publisher-assigned feed ID, verified domain control, and substantial overlap of item IDs. Medium evidence includes matching self links and consistent site relationships. Titles, descriptions, and artwork are weak signals because they are easy to copy and change.

Keep match decisions explainable and reversible. A resolver should return the signals behind a conclusion rather than an unexplained confidence percentage.

Migrations, merges, and splits

A move creates an event: the old URL was observed, the redirect was verified, the new URL became canonical, and the old URL remained an alias. A merge preserves both source records and the evidence. A split creates new feed IDs and records their relationship to the original publication.

Never overwrite history to make the database look tidy. Historic URLs are how operators explain long-lived subscriptions and recover from broken redirects.

Implementation checklist

Create opaque feed IDs that are never recycled.
Keep canonical URL and aliases in separate fields.
Store redirect chains and item-ID samples as evidence.
Use event records for every identity change.
Require review for ambiguous merges.
Preserve source values during RSS, Atom, and JSON Feed conversions.

Continue with What Is an RSS Feed ID? for a detailed operational walkthrough, or review the registry blueprint for public API considerations.