An RSS feed looks intimidating as raw XML, but it’s built from a small handful of tags that each do one specific job. Once you know what <channel>, <item>, <guid>, and <pubDate> actually mean, reading — or troubleshooting — a feed directly stops being guesswork.
Everything in a feed lives inside a single <channel> element, which holds information about the feed as a whole rather than any individual post: a <title> (the site or feed’s name), a <link> (the site’s homepage), and a <description>. Think of it as the feed’s header — it appears once, at the top, before any actual content starts.
Inside <channel>, every individual post gets its own <item> element, each with its own <title>, <link>, and <description> (or full content). A feed with 15 recent posts simply has 15 <item> blocks stacked inside the one <channel>. This is the part every automation tool and reader actually loops over to find what’s new.
Every <item> should carry a <guid> — a globally unique identifier, usually just the post’s permalink. This is what automation tools actually use to track “have I already posted this one” rather than relying on titles or dates, which can technically repeat. If a feed generator ever reuses the same GUID for two different posts (a bug, not expected behavior), tools that key off it can skip content that should have posted, or in rarer cases, mishandle what counts as new.
<pubDate> records when an item was published, and RSS specifically expects it in RFC 822 date format (for example, Tue, 15 Sep 2026 09:30:00 GMT) rather than a plain ISO date. Tools sorting items by recency, or automation platforms deciding what’s “new since last check,” rely on this field parsing correctly — a malformed or missing <pubDate> is a common, easy-to-miss cause of items appearing out of order or not being recognized as new at all.
Podcast feeds add one more tag most blog feeds don’t need: <enclosure>, which attaches a media file’s URL, type, and size directly to an <item>. This single tag is the entire mechanism podcast apps use to find and download episode audio — there’s no separate podcast-specific protocol; it’s the same RSS format with one extra tag doing the work.
Almost never — WordPress, Ghost, Squarespace, and virtually every other CMS generates valid <channel>/<item> structure automatically. Knowing the tags mainly helps when troubleshooting why something isn’t posting correctly.
Most tools fall back to using the <link> as an identifier instead, which works fine as long as that URL stays stable — the risk appears only if the URL later changes, which can make a tool see an old post as “new” again.
It’s by far the most common in practice, though Atom is a related-but-differently-structured alternative some platforms use instead; the concepts (a channel-level wrapper, per-item entries, unique identifiers, publish dates) carry over even though the exact tag names differ.
An RSS feed’s XML boils down to one wrapper (<channel>) holding a list of entries (<item>), each identified uniquely (<guid>) and timestamped (<pubDate>), with podcasts adding one extra tag (<enclosure>) for media files. That’s the entire structure most automation and troubleshooting ever touches.
