Building useful websites

RSS feed not updating? Check the URL, XML, IDs and reader

First find out whether the new item reaches the public feed. Then separate a broken feed from a reader that has not fetched or displayed it.

By Coru · Published 2026-10-21 · Updated 2026-10-21

1. Fetch the exact feed address

Copy the feed URL saved in the reader. If a website address fails to subscribe, find its RSS link and try that exact feed URL. Start with one missing post: write down its title, publication time and expected link.

Use a fresh working directory: existing output files with these names will be overwritten. To save a public feed with curl, replace the example address and run: curl -q -sS --compressed --max-time 20 -L --max-redirs 5 -D feed-headers.txt -o feed-body.xml 'https://example.org/feed.xml'

This skips the curl configuration file, follows at most five redirects and stops after 20 seconds. It does not use your browser login cookies. Headers and body are saved separately; --compressed decodes a compressed body but leaves the saved response headers unchanged. Read the final response status in feed-headers.txt and inspect feed-body.xml. A successful curl exit or HTTP 200 does not prove that the body is a feed: it might be a login page or the site homepage. An .xml filename proves nothing either.

For RSS 2.0, look for rss with version="2.0", containing channel and its item elements. The W3C validator guidance recommends application/rss+xml for RSS and application/atom+xml for Atom. Check both the Content-Type header and actual body; a correct label cannot repair the wrong content.

2. Repair XML before investigating the reader

Check the public URL or saved feed in the W3C Feed Validation Service. Work from the first reported error, including its line and column. A generic XML parser checks well-formedness; a feed validator also checks feed-specific rules. Passing one is not the same as passing the other.

Our broken example is <title>A & B</title>. In ordinary XML element text, write <title>A & B</title>; the parsed title is still A & B. A URL inside XML text likewise needs its query separator escaped: https://example.org/?a=1&b=2. Pass the original, unescaped text to an XML serializer and let it escape the value once; do not pre-escape it.

Also inspect anything emitted before the XML declaration. The declaration, when present, belongs at the beginning; a stray blank line or server warning can break the document. Fix the generator and fetch the public response again.

3. Give each post one stable identity

RSS guid is optional, but the W3C validator recommends a distinct, unchanging value for each item. Keep it when correcting the same post. Give a different post a different value. The RSS specification allows readers to use this identity to decide whether an item is new; each reader may apply additional rules.

For a non-URL identifier, use an explicit form such as <guid isPermaLink="false">post-42</guid>. Without that attribute, isPermaLink defaults to true: the value is treated as a permalink, so use a real complete URL.

Compare the missing item with an older one, then compare two builds of the same item. Reusing post-42 for two posts and generating a new random ID for post-42 on every build are different defects. Changing titles, dates or all existing IDs to force a refresh can hide the cause and create duplicates.

4. Check the timestamp and its format

For RSS pubDate, use the RSS date syntax with an English day/month and an explicit zone, for example Wed, 21 Oct 2026 10:00:00 +0000. The W3C date guidance recommends a four-digit year. Atom date constructs instead use RFC 3339, for example 2026-10-21T10:00:00Z. Do not paste the Atom form into RSS pubDate.

Atom is a separate feed format: its feed element uses the namespace http://www.w3.org/2005/Atom. Identify the format before interpreting its fields.

Our conversion check shows that 12:00:00 +0200 and 10:00:00 +0000 on the same date are the same instant. Relabeling 12:00 as +0000 without converting it moves the instant two hours later. Compare the stored time with the intended publication time. RSS readers may postpone an item whose pubDate lies in the future; the specification does not require every reader to do so.

5. Separate the public file from reader polling

If the missing item is absent from the downloaded feed, investigate feed generation, deployment and delivery caches. Reloading the reader cannot retrieve an item that this response does not contain. Keep an earlier saved response so you can compare the actual item list.

If the item is present, valid and correctly identified, inspect the reader next: confirm the subscription URL, look in its all-items view, and check any displayed fetch error or last-fetch time. A service may keep its own fetched copy; reloading your browser is not proof that the service fetched the publisher again.

Feedly documents different polling intervals depending on plan and, for Basic accounts, site popularity and publishing frequency. Treat that as service-specific guidance, not a delivery deadline for every reader. Record the reader and check time, then retry through its supported refresh path or wait for its stated polling cycle before changing correct feed data.

6. Make the working feed discoverable

If the exact feed URL works but subscribing with the homepage fails, inspect the homepage HTML head. A simple RSS discovery link is: <link rel="alternate" type="application/rss+xml" href="https://example.org/feed.xml" title="Site updates">.

The RSS Advisory Board describes this link relationship and recommends a full URL. Open the href itself and check that it reaches the intended working feed. Add a visible RSS link too, so a reader can copy the address directly.

For a multilingual site, label each feed clearly and verify its actual entries. A link labeled English that serves another language is a discovery mistake even if its XML is valid. Neither this tag nor a visible link guarantees that every browser shows a subscribe button.

Six controlled examples: what changed and what it proved

We ran these small original fixtures locally on 21 October 2026. They are reproducible counterexamples, not tests of a live Feedly account or evidence of reader demand.

Wrong response: the feed endpoint returns HTTP 200 with a login page. Changing its media type to application/rss+xml still leaves an HTML body. Check content, not only status or headers.
Bare ampersand: A & B makes our XML parser reject the fixture. Serializing A & B parses successfully and recovers the original title.
Reused ID: two item elements both use post-42. Our simple set-of-IDs model counts one identity; changing the second to post-43 gives two. This illustrates a collision, not a promise about a particular reader.
Changing ID: correcting the title while keeping post-42 adds no new identity in that model. Replacing it with post-42-build-2 adds one. An edit and a new post need different treatment.
Wrong zone conversion: 12:00 +0200 equals 10:00 +0000. Merely replacing +0200 with +0000 shifts the instant by two hours.
Wrong discovery link: the homepage points to /old.xml, which returns 404, while /feed.xml returns a working feed. Correcting href repairs that path without changing the feed.

Keep a short repair record

Save the exact feed URL, fetch time, final HTTP status, response body, validator result, missing item ID and timestamp, and the reader name. Change the layer with evidence of a defect, then fetch and validate again.

Finish with the same reader and subscription you started with. A valid public feed is one result; observing the expected item in that reader is another. Our local checks cover response content, XML syntax, a simple identity model, time conversion and one discovery link. They do not establish real service polling, cache behavior, subscriber counts or successful delivery to all readers.