RSS identity reference
RSS feed validation
Validation should prove that a feed is parseable, continuous, reachable, and useful—not merely that its XML closes correctly.
Five validation layers
Validate the document syntax, required format semantics, identity continuity, network behavior, and client interpretation. A feed can pass one layer and fail the next.
1. Syntax
Parse XML or JSON strictly, verify UTF-8 handling, escape reserved characters, and reject truncated output.
2. Format semantics
Require channel or feed metadata, valid dates, declared namespaces, unique entry IDs, and fields appropriate to RSS, Atom, or JSON Feed.
3. Identity continuity
Compare established GUIDs and IDs with the previous production feed. Existing items should not receive new identities after a rebuild or migration.
4. Network behavior
Check the public HTTPS response, content type, redirects, cache behavior, and final canonical URL from outside the host.
5. Client behavior
Subscribe with representative readers or podcast apps and inspect ordering, artwork, full content, links, and media playback.
Identity checks
- No duplicate item IDs in the logical feed.
- Opaque RSS GUIDs declare
isPermaLink="false". - Atom feed and entry IDs are present and stable.
- JSON Feed items contain nonempty string IDs.
- URL changes do not regenerate IDs.
HTTP and discovery checks
The canonical URL should return the feed directly. Legacy URLs should redirect permanently and without loops. HTML autodiscovery and visible subscription links should resolve to the same source.
Podcast and enclosure checks
Sample new and old enclosures. Verify media type, byte delivery, range behavior where needed, and non-expiring public URLs. An XML-valid podcast with broken audio is not operationally valid.
Automated release gate
Build the feed before deployment, parse it, compare identity fixtures, validate dates and links, and store the artifact. Run network checks after deployment. Review the full validation checklist for a CI-ready sequence.