A useful RSS feed gives readers another way to follow an independent publication. Keeping that route dependable takes more than finding a feed URL once: the entries need to represent the articles you actually publish, and the subscription path needs a repeatable check.
Use this RSS feed checklist for publishers during a release or after a CMS change. It focuses on RSS 2.0 feed maintenance. The broader content distribution plan explains how to assign RSS and other channels a place in your publishing workflow.
Start with the public feed address
Find the feed through the publication's own navigation or subscription instructions. Record the exact public URL and open it while signed out. Check whether it returns a feed, a sign-in page, an error, or an unexpected destination.
A browser may display an XML document tree rather than a designed article page. That presentation alone does not establish a problem. Inspect what the document contains before reporting a failure.
For a concrete example of an entry point, the Congrid blog links to its RSS feed. Use your publication's actual feed address in the checks below; do not assume that every CMS uses the same path.
Confirm the format and basic structure
The RSS 2.0 specification defines an XML document with an rss root whose version is 2.0, containing a channel. The required channel fields are title, link, and description. An item must have at least a title or a description.
Keep the format requirement separate from your editorial checklist. For a feed that introduces articles on your website, review whether readers can recognize the publication, understand each entry, and follow a useful article link. A structurally acceptable entry may still offer a poor reading experience.
The W3C Feed Validator documentation distinguishes validation errors and warnings and also links specifications for other feed formats. Confirm the format you are inspecting before applying an RSS 2.0 rule to a different kind of feed.
Compare a small sample with the live articles
Select a newly published article, an older article, and an article that received an editorial correction if one is available. This is a practical review sample, not a claim that three entries can establish the condition of an entire archive.
For each entry, compare:
- Headline: Does it clearly identify the intended article?
- Destination: Does the link open the published article rather than a preview, login page, or unrelated resource?
- Summary or content: Does the entry accurately describe what a reader will find?
- Presentation: Are characters, paragraphs, and any included images understandable in the reader you test?
Keep the feed response and the article page in the same review note. If a headline differs, identify whether the feed is stale or the difference is an intentional editorial choice. Avoid changing several fields at once before understanding the mismatch.
Review identifiers and dates deliberately
An item's guid identifies that item. Under the RSS specification, isPermaLink defaults to true; with false, the identifier need not be a URL. Check how your CMS generates this value rather than assuming that every identifier is the article link.
The RSS Best Practices Profile recommends a GUID for every item and explains how it helps an aggregator recognize previously received content. As a maintenance check, compare an edited article's identifier with its earlier recorded value. Repeatedly assigning a new identity to the same article is worth investigating when subscribers see duplicates.
When dates are present, check their syntax and meaning. The profile describes RSS date-time formatting and recommends four-digit years. Compare the reported publication time and timezone with your editorial record; distinguish an article's publication date from the feed's build information.
A correction to an existing article should follow your publication's update policy. Record the intended behavior before treating an old article appearing again as either a success or a defect.
Validate the feed, then test the reading path
Run the public address through a feed validator and keep its specific findings. Use the W3C documentation to interpret the reported error or warning. After a correction, validate the same public address again and record which finding changed.
Then use a feed reader you already support or use. Add the feed through the normal subscription flow, inspect a sample entry, and follow its article link. Record the reader and observation time so another editor can reproduce the check.
Validation and reader testing provide different evidence. A validator result does not establish that a particular application has refreshed its copy. Compare the current public feed with what the reader shows before diagnosing a delay.
| Observed symptom | Next check |
|---|---|
| The feed URL opens a login or error page | Confirm the public address and its deployed response |
| A validator reports a parsing problem | Preserve the exact message and inspect the affected output |
| An article link reaches the wrong page | Compare the feed entry with the intended published URL |
| An edited article appears as a duplicate | Compare its identifier before and after the edit |
| The public feed is current but a reader looks stale | Record the reader's refresh state and compare the same entry |
Keep feed maintenance in the release record
Assign an owner and retain the feed URL, observation time, sampled article URLs, identifier checks, validator findings, reader result, and next action. Repeat the relevant checks after changes to feed generation, article URLs, publication settings, or the site template.
RSS upkeep and Congrid publisher participation have their own requirements. The current publisher guide describes domain registration and maintaining a matching homepage member badge. Publishing a feed does not replace that workflow. Use the guides overview for the current participation instructions.
Treat a working feed as a maintained distribution route. Reader visits, organic search performance, and protocol rewards need separate evidence. Finish each feed review with the observed issue, the action taken, and the result of the check that originally failed.