Short answer: An RSS 2.0 feed is an rss element containing one channel, which describes the source and contains a list of item elements. The channel requires only three elements: title, link and description. Each item needs at least a title or a description, but in practice every item should have a title, link, guid, pubDate and description. Extensions such as content:encoded, Media RSS and the Atom self link add full text, images and discovery features on top.
Most people never look inside a feed, and they do not need to. But if you build a feed, debug one, or want to know why your posts look odd in a particular reader, understanding the elements is the fastest way to the answer. RSS 2.0 is small: the whole specification fits on a few pages. This article walks through it element by element, explains which parts matter in practice, and points out the details that trip people up.
The overall structure
A minimal RSS 2.0 feed looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>Example Blog</title>
<link>https://example.com/</link>
<description>Notes on feeds and publishing</description>
<item>
<title>First post</title>
<link>https://example.com/first-post/</link>
<guid>https://example.com/first-post/</guid>
<pubDate>Mon, 24 Aug 2026 07:00:00 +0000</pubDate>
<description>A short summary of the post.</description>
</item>
</channel>
</rss>
Everything else is optional or comes from extensions. Items usually appear newest first, although the specification does not require any order; readers sort by date themselves. The XML declaration with the encoding should be the very first thing in the file, with nothing before it, not even a blank line.
Required channel elements
- title: the name of the feed, usually the site’s name. Readers display it as the source name, so make it recognisable. If you publish several feeds, include the section: “Example Blog – News”.
- link: the URL of the website the feed belongs to, usually the home page or the section page.
- description: a sentence describing the feed. Some readers show it when you subscribe or browse a directory.
These three are the only strict requirements at channel level. A feed missing any of them fails validation, even if some readers still display it.
Useful optional channel elements
| Element | Purpose | Worth including? |
|---|---|---|
| language | Language code, for example en-us | Yes, helps readers and directories |
| lastBuildDate | When the feed content last changed | Yes, if accurate |
| pubDate | Publication date of the feed content | Optional |
| image | A logo with url, title and link | Yes, shown by some readers |
| copyright | Copyright notice | Optional |
| managingEditor, webMaster | Email addresses of contacts | Rarely useful, often spam-harvested |
| category | Topic of the whole feed | Optional |
| generator | Software that produced the feed | Harmless, sometimes useful for debugging |
| ttl | Minutes the feed may be cached | Rarely respected; HTTP headers matter more |
| skipHours, skipDays | Times when readers need not check | Rarely supported |
The image element deserves a note: its title and link should match the channel’s, and the image itself should be a small logo. Many modern readers prefer the site’s favicon or other icons, so do not rely on this element for branding.
Item elements: the ones that matter
title and link
The headline and the address of the full article. The link should be the canonical URL of the page, absolute and ideally without tracking parameters, unless you deliberately add campaign tags for analytics.
guid
A unique identifier that never changes. Readers use it to decide whether they have seen an item before. If the guid is the item’s permalink, it can be written as is; if it is anything else, add isPermaLink="false". Changing guids is the most common cause of duplicate items in readers.
pubDate
The publication date in RFC 822 format, with English day and month names and a time zone, for example Mon, 24 Aug 2026 07:00:00 +0000. Wrong or missing dates lead to wrong ordering and sometimes to items being ignored as too old.
description
Either a summary or the full text, usually as escaped HTML. When the feed also has content:encoded, keep description short: readers use it for list views and previews.
Other item elements
- author: an email address of the author, optionally followed by a name in parentheses. Because it requires an email, many feeds use
dc:creatorfrom the Dublin Core namespace instead, which takes a plain name. - category: one element per category or tag. Readers and tools use these for filtering.
- enclosure: an attached media file with
url,lengthin bytes andtype. Essential for podcasts; only one per item. - comments: the URL of the comments page.
- source: the feed an item originally came from, useful in aggregated feeds.
Common extensions
RSS 2.0 allows elements from other namespaces, declared on the rss element. The ones you will meet most often:
- content:encoded (
http://purl.org/rss/1.0/modules/content/): the full HTML of the item, usually in a CDATA section. - dc:creator (Dublin Core): the author’s name.
- atom:link rel=”self” (Atom namespace): the feed’s own URL, recommended by validators, and used with
rel="hub"for WebSub. - media:content and media:thumbnail (Media RSS): images and video with sizes, widely used for thumbnails.
- itunes:* and podcast:*: podcast metadata such as artwork, categories, durations, transcripts and chapters.
- slash:comments and wfw:commentRss: comment counts and comment feeds, output by WordPress.
Every prefix must be declared once on the root element, and only once. A missing or duplicated declaration makes the XML invalid.
Details that trip people up
- Escaping. HTML in
descriptionmust be escaped or in CDATA; ampersands in titles and URLs must be written as&. - Relative URLs inside content break images and links in many readers.
- Time zones missing from dates cause items to appear hours off.
- Empty elements, such as an empty title, are worse than omitting the element.
- Encoding declared as UTF-8 but served differently garbles special characters.
- Very long feeds with hundreds of full-text items slow down every reader that fetches them.
Building a feed yourself: a practical order of work
If you generate a feed in your own code rather than relying on a content management system, a sensible order of work avoids most of the problems above:
- Use an XML library or a well-tested feed library for your language instead of printing strings. Libraries handle escaping, encoding and namespaces for you.
- Start with the core elements only: channel title, link and description, and for each item a title, link, guid, pubDate and description. Validate at this stage.
- Decide on identifiers before launch and document them. A database ID combined with your domain, or the permanent URL, both work, as long as they never change.
- Add full content with
content:encodedif you want full-text reading, keepingdescriptionas a short summary. - Add images with Media RSS, using absolute HTTPS URLs and a reasonably large size.
- Add the atom:link self element with the canonical feed URL.
- Serve it correctly: status 200, a feed content type, UTF-8, and caching headers such as ETag or Last-Modified so readers can check cheaply.
- Add autodiscovery to your pages and validate once more.
Working in this order means each step builds on a feed that already validates, so when an error appears you know exactly which change caused it. It also produces a feed that is useful from the first step, rather than a complex one that is broken until everything is finished.
Reading feeds that others publish
Knowing the elements also helps when you depend on other sites’ feeds and one looks wrong in your reader. Check the raw feed: missing guids explain duplicates, missing images explain blank thumbnails, and short descriptions explain why you see only a sentence. If a source’s feed is poor or missing, our tool, Feeds, can build a feed of its items with titles, links, images, summaries and dates, using the page’s structured data where available and the existing feed when it is usable. You check the preview before anything is created; see the home page.
Related reading
- RSS vs Atom: Which Feed Format Should Your Site Publish?
- How to Validate an RSS Feed and Fix the Most Common Errors
- How to Add Featured Images to Your WordPress RSS Feed
The bottom line
RSS 2.0 is a small, forgiving format: a channel with a title, link and description, and items that should each carry a title, link, permanent guid, correct date and a summary. Extensions add full text, authors, images and podcast data. Get the core elements right, declare namespaces once, escape and date everything properly, and your feed will read cleanly everywhere.
SSS
What elements are required in an RSS 2.0 feed?
At channel level, title, link and description are required. Each item must have at least a title or a description. In practice every item should also have a link, a guid and a pubDate so readers can display and track it correctly.
What is the difference between description and content:encoded?
Description is part of core RSS and usually holds a summary. Content:encoded comes from the content module and holds the full HTML article. Feeds that include both give readers a short preview and the full text.
Why do validators recommend an atom:link with rel=”self”?
It states the feed’s own canonical URL, which helps readers and hubs identify the feed even when it is fetched through a redirect or another address. It is also required for WebSub.
How should I write the author in RSS?
The core author element expects an email address. Many feeds use dc:creator from the Dublin Core namespace instead, which takes a plain name and avoids publishing email addresses.
Can an item have more than one enclosure?
The RSS 2.0 specification allows only one enclosure per item, and podcast apps expect exactly one. Use Media RSS elements if you need to describe several images or media files.


