Every subscribe button hands your reader a URL that returns XML. What arrives in that file — and what the publisher chose to leave out of it — decides whether you get whole articles, three-line teasers, or a headline and nothing else. It takes about a minute to check before you commit.
Open the site's feed URL directly in a browser tab, or fetch it: curl -sL https://example.com/feed.xml | head -60. Compare what comes back with the annotated entry on this page. Every clickable element name below is explained further down.
One entry is one item in your reader. A feed document holds many.
A feed file has two layers. The outer <feed> describes the publication — its title, its own identifier, when it last changed. Inside it sit repeated <entry> blocks, one per article, and those are what land in your reader as separate items.
The specification is strict about what an entry must carry. Each one is required to have exactly one identifier, exactly one title and exactly one updated timestamp. Everything else is optional, and the optional parts are where publishers differ most.
If a field is optional, some publisher somewhere has omitted it — and your reader has to cope. That is the source of nearly every "why does this feed look wrong in my app" complaint.
Required. Also the field most often padded with the site name.
Titles are required, so they are always present, and that makes them the one field you can rely on when you skim. The complication is that a title can be sent as plain text, as escaped HTML, or as embedded markup, and the entry says which by carrying a type attribute.
When a title arrives with entities in it and the type says plain text, the entities are literal characters, not markup. Get that wrong and readers display & where an ampersand belongs. If you see that in your reader, the mismatch is in the feed, not the app.
Required, permanent, and the cause of most duplicate items.
The identifier is what your reader uses to decide whether an entry is one it has already shown you. It is meant to be permanent and universally unique, and it is not meant to change when the article is edited, moved or re-titled.
Publishers break this in two directions, and each has a distinct symptom:
You cannot fix either from your side. You can recognise them, which saves you from concluding that your reader is broken.
Required. Marks the last significant change, not the first appearance.
This timestamp records the most recent modification the publisher considered significant — and the specification deliberately leaves "significant" to the publisher. A typo fix need not move it. A rewritten section usually does.
That single sentence explains a behaviour people find maddening: an article from three weeks ago jumping to the top of the list. It was edited, the publisher judged the edit significant, and readers that sort by this field promptly resurfaced it.
If items keep reordering, look at whether your reader sorts on this field or on the one below. Many let you choose, and the two produce visibly different timelines for any site that revises its work.
Optional. At most one per entry.
This marks an instant early in the entry's life — in practice, first publication. It is the field that matches what a reader intuitively means by "when did this come out", and it is optional, which is exactly the problem.
A feed that omits it leaves your reader with only the modification timestamp to sort by. Those are the feeds where the chronology quietly stops matching the site's own archive page. Before you subscribe to something you intend to read historically, check that this element is present.
The rel attribute changes what the link means entirely.
Links inside a feed are typed. When the rel attribute is absent, the link means alternate — but four other values are defined, and readers treat them very differently.
| rel value | What the target is | Typical use |
|---|---|---|
alternate | Another version of this same thing | The article page you click through to |
self | The feed document itself | How a reader learns the feed's own address |
related | Something connected, but not the same | A topic page or companion piece |
enclosure | A large attached file | Audio in a podcast feed |
via | Where the information came from | Crediting an original source |
An entry may only carry one alternate link per combination of media type and language — that is what stops a reader having to guess which of three links is the article. Podcast apps look specifically for the enclosure relation, which is why a feed can look complete in a text reader and produce no playable episode in a podcast app.
The enclosure link is where a length hint belongs. When an app shows a download size before you tap, that number came from the feed, and it is advisory — the real size is whatever the server reports when the file actually transfers.
This is the single check worth doing before you subscribe.
Two elements can carry the words. <content> holds the article. <summary> holds a short description of it. A feed that sends only summaries is asking you to click through for everything, and you cannot tell from the subscribe button which kind you are getting.
There is one place the specification forces a summary to exist: when the content is not inline text your reader can display — because it is a remote reference or a non-text media type — a summary becomes required. That rule exists so a reader always has something to show, even for an entry whose payload it cannot render.
<content> element with the whole article inside it means full text.<summary>, or a content element pointing elsewhere with a src attribute, means teaser.Publishers change this. A feed that was full text last year can quietly become a teaser after a redesign, and nothing in your reader announces it. Re-checking the sources you rely on once in a while costs a minute each.