How to Create an RSS Feed for Your Website

Most advice about RSS assumes you already have a feed and just want to display it somewhere. This guide is about the other half of the problem: producing the feed in the first place, either because your site does not generate one or because the source you care about never published one.

A feed is worth creating for a plain reason. It is the one format that lets your content leave your website without you doing anything: into readers, into other people's pages, into automation tools, into anything that knows how to fetch a URL on a schedule.

It is also unusually durable. A feed has no owner, no API key, no rate limit and no terms of service that can change next quarter. That is why it has outlasted most of the platforms that were supposed to replace it, and why the work of setting one up is done once rather than maintained forever.

The whole job breaks into four steps: check whether you already have a feed, produce one if you do not, validate it, then tell people and software where it is. Most of the difficulty sits in the second step, and which route you take there depends almost entirely on whether you control the site that publishes the content.

What Is Actually Inside a Feed File

Before choosing how to build one, it helps to know what you are building. A feed is a single XML file with a channel describing the publication, then a repeating list of items describing each piece of content.

The channel needs three things: a title, a link back to the site, and a description. Each item needs a title, a link, and enough of a description to be worth showing. Two more elements do most of the practical work:

• A publication date on every item. This is how a reader knows what is new and in what order to show it. It is also the element most often malformed.
• A unique identifier per item (guid in RSS). This is how software tells a genuinely new item from one it has already shown. Reuse an identifier and the item is ignored; change identifiers on republish and every reader announces the same article twice.

The full element list lives in the RSS 2.0 specification, which is short and worth skimming once. Everything beyond those elements is optional, and most feeds are better for keeping it that way.

First, Check Whether You Already Have One

A surprising number of people build a feed for a site that has been publishing one all along. Before doing any work, try these in order:

1. Add /feed, /rss, /feed.xml or /atom.xml to your domain. If a wall of XML appears, that is your feed.
2. View the page source of your homepage and search for application/rss+xml. Platforms declare their feed with a <link> tag in the head, and the URL is in that tag.
3. Paste your homepage URL into a feed reader. Most readers run this discovery for you and will report the feed if one exists.

WordPress, Ghost, Blogger, Squarespace and most blogging tools generate a feed by default. If you find one, your job changes from creating a feed to tidying it, which is the last section of this guide.

Four Ways to Create a Feed

These are ordered by effort, not preference. The right one depends on what you are starting from.

Method 1: A Feed Generator Service

A generator crawls a page you point it at, works out which parts are repeating content, and publishes a feed URL you can hand to anything. No code, no plugin, no access to the site required, which is the key point: this is the only method that works on a site you do not control.

It suits two situations especially well. The first is a site of your own on a platform that stubbornly refuses to produce a feed. The second is following a source that never published one, such as a news section, a changelog, or a listings page you want to monitor.

The trade-off is fragility. A generator infers structure from the page's HTML, so a redesign can break the feed. Check it after any significant change to the source page.

Method 2: A Plugin or Built-In Setting

If your platform has a feed feature and it is simply switched off or misconfigured, this is the cheapest fix available. On WordPress the feed exists unless something disabled it; on other platforms it is often a toggle in a syndication or sharing settings panel.

This method is also how you get control over what the feed contains without writing XML. Most plugins let you choose full content against summaries, how many items to include, and which categories to exclude, which covers the decisions that actually matter.

Method 3: Generate the XML From Your Own Data

If your content already lives in a database, a CMS or even a folder of markdown files, you can render a feed from it the same way you render a page. Every modern framework has a route or template for this, and the logic is short: take the most recent items, map each to the required elements, output XML with the correct content type.

Two rules keep a hand-built feed out of trouble. Escape your content properly, since an unescaped ampersand or a stray tag makes the whole file unparseable rather than degrading gracefully. And derive the identifier from something permanent such as a post ID, never from the title, which will change.

Method 4: Write the File by Hand

Occasionally justified: a feed of a handful of items that changes rarely, such as a small podcast, a release list, or an announcements channel. You write the XML once, upload it, and edit it when something changes.

It stops being justified the moment updates become frequent, because a hand-edited feed is one typo away from being invalid, and the failure is silent. If you find yourself editing it weekly, move to method 2 or 3.

Comparing the Four Methods

Decisions That Shape a Good Feed

Four choices determine whether people stay subscribed.

Full Content or Summaries

Full content means subscribers read the whole piece inside their reader and may never visit your site. Summaries mean they click through, which serves your analytics and your calls to action but asks something of the reader. There is no universally right answer, but be consistent: a feed that alternates feels broken. If your business case depends on people landing on your pages, summaries with a clear link are the honest compromise.

How Many Items

Ten to twenty recent items suits most publications. Too few and someone who checks weekly misses things. Too many and every fetch moves more data than it needs to, which matters because aggregators fetch repeatedly.

What to Exclude

Not everything you publish belongs in the feed. Utility pages, thin announcements and internal notes dilute it. A feed is an editorial product, and choosing what stays out is most of the editing.

Stable Identifiers and Dates

Decide once whether an edited article counts as new. If it does not, keep the identifier and the original publication date fixed when you edit. Changing either is what causes a reader to re-announce months-old articles, which is the fastest way to lose subscribers.

Who Actually Consumes a Feed

It is worth being concrete about who is on the other end, because it changes what you put in the file.

• People using feed readers. A smaller audience than in RSS's heyday, but a deliberate and high-intent one: someone who subscribes has chosen to see everything you publish, with no algorithm deciding otherwise.
• Automation tools. A feed is the standard trigger for "when something new appears, do this". Cross-post to social, notify a channel, add a row to a sheet. This is probably the most common modern use and it needs nothing from you beyond a valid feed.
• Other websites. Partners, aggregators and community sites display your headlines from your feed, which is distribution you do not have to negotiate each time.
• Email digest services. Most "turn a blog into a newsletter" tools are feed readers that send email, so a clean feed is what makes an automated digest possible.
• Podcast directories, which do not merely prefer RSS but require it, covered below.
• Monitoring, including your own. A feed of a competitor's changelog or a regulator's announcements page is a low-effort way to watch something without checking it manually.

Two consequences follow. Most consumers are software, which is why validity matters more than presentation: a human forgives a malformed date, a parser does not. And because several of those consumers are triggers for automation, a feed that updates reliably is worth more than a feed that is beautiful.

Where the Feed Lives on Common Platforms

If you are on a hosted platform, the feed is usually already there at a predictable address. These are the conventions worth trying before you build anything.

• WordPress. /feed for everything, plus a feed per category at /category/<name>/feed and per author. Category feeds are underused and are the easiest way to offer a narrower subscription without extra work.
• Ghost. /rss, generated automatically and kept in step with your tags.
• Squarespace. Each blog collection exposes a feed by appending ?format=rss to the collection URL, so a site with several blog pages has several feeds rather than one.
• Blogger. /feeds/posts/default, with an Atom feed by default and an RSS variant available through a parameter.
• Substack and most newsletter platforms. /feed, which is how newsletters end up readable in feed readers at all.
• Shopify. Blogs expose /blogs/<handle>.atom, and product collections have their own feed formats aimed at merchants rather than readers.
• Webflow and most site builders. Collection-based, configured in the CMS settings rather than at a fixed path, so check the collection's settings panel.

Two things to note. Sub-feeds by category or tag are almost always available and rarely advertised, and they are the single easiest improvement to offer a reader who wants one topic rather than everything. And a platform feed reflects that platform's idea of an item, so if your content model is unusual, the generated feed may include things you would not choose. That is the point at which method 3 starts to pay for itself.

Podcasts Are RSS With Extra Rules

Worth knowing even if you are not making a podcast, because it explains why some feeds look more complicated than the specification suggests.

Podcast distribution runs entirely on RSS. Directories do not host your audio; they read your feed and point listeners at the file it references. Everything a listener sees, the artwork, the episode description, the running order, comes out of that file.

The extra rules come from a namespace of additional elements, and two structural pieces matter most. Each episode item carries an enclosure pointing at the audio file with its type and size, which is the actual distribution mechanism. And the channel carries artwork, a category and an explicit flag, which directories require before they will accept a submission at all.

The practical consequence: for a podcast, the feed is the product. Moving hosts means keeping the feed URL alive or using the redirect element the platforms honour, because listeners subscribed to a URL, not to you. This is the clearest illustration of the rule in the previous section, that a feed URL should be treated as permanent.

Validate Before You Publish

An invalid feed usually does not announce itself. It renders in the reader you happen to test with and fails silently in three others, so validation is not optional.

1. Run the file through the W3C Feed Validation Service. It reports parse errors, missing required elements and malformed dates.
2. Check the date format specifically. RSS expects RFC 822 style dates. This is the most common single error and it is invisible until a reader silently drops your items.
3. Confirm the content type. The file should be served as application/rss+xml or application/atom+xml. Served as plain text or HTML, some clients refuse it.
4. Subscribe to it yourself in a real reader. Then publish something and confirm it appears. This catches the class of problem no validator sees, such as a feed that is valid but frozen because it is cached too aggressively.

Tell People and Software the Feed Exists

A feed nobody can find is wasted work. Three steps cover it.

• Declare it in your HTML head with <link rel="alternate" type="application/rss+xml"> pointing at the feed URL. This is how readers, browsers and tools discover a feed automatically, and it costs one line.
• Link it somewhere visible, usually the footer or the blog index. The icon alone is enough for people who use feeds; they know what it means.
• Keep the URL stable forever. A feed URL is subscribed to once and then never revisited by a human. Move it without a redirect and those subscribers simply stop receiving you, with no error and no way for you to notice.

If the goal is to show a feed on a page rather than distribute your own, that is the other direction entirely, and our roundup of RSS feed widgets and plugins compares the display options. The same principle applies to platform feeds specifically, such as embedding an Instagram feed, where the source publishes for you and your job is presentation.

Keeping a Feed Healthy

Feeds fail quietly, which is what makes them worth checking on a schedule rather than when someone complains.

• Re-validate after any template or platform change. A theme update that alters your item markup can break a generated feed without touching a visible page.
• Watch for duplicate announcements. If subscribers see old items resurface, something is regenerating identifiers or dates.
• Check the feed is not stale. Compare the newest item in the feed against your newest published page. A gap means the feed stopped updating, and that is invisible from the website itself.
• Keep it fast. Aggregators fetch on a schedule and some back off from slow endpoints. A feed should be a cached static response, not a live database query per request.

None of this needs doing often. A check when you change platforms or templates, and a glance at the newest item every month or so, is enough to catch every common failure.

The Errors That Cause Most Broken Feeds

Nearly every broken feed fails for one of these reasons, and each one is quick to check.

• Malformed dates. The most common failure by a wide margin. RSS wants RFC 822 style dates, and a reader that cannot parse a date will often drop the item rather than guess.
• Unescaped characters in content. A bare ampersand or an unclosed tag makes the entire file unparseable, so one bad article takes the whole feed down rather than just itself.
• Identifiers that change. If the identifier is derived from the title or the URL and either changes, every subscriber sees the item announced again as new.
• Relative links. Links inside a feed are read far away from your site, so a link to /blog/post resolves against the reader's own domain and breaks. Every URL in a feed must be absolute.
• The wrong content type. Served as text/html, some clients refuse the file outright even though the XML is perfect.
• An aggressive cache. A feed cached for hours looks frozen to aggregators, and a feed cached at a CDN edge can serve a stale copy long after you publish.
• A silently moved URL. The failure with no error message anywhere: subscribers simply stop receiving you, and nothing on your side reports it.

If a feed works in one reader and not another, start with dates and content type. Those two account for most of the cases where the file looks fine to a human.

Getting Started

The short path: check whether you already have a feed, because you probably do. If you do not and you control the site, turn on your platform's feed or generate one from the content you already store. If you do not control the source, use a generator service and re-check it after any redesign.

Then validate it, declare it in your head tag, and leave the URL alone forever. Once it exists, displaying it anywhere, on your own site or someone else's, is a solved problem you can handle with an RSS feed widget.

If the feed you want belongs to one particular source rather than to your own site, the same widget reads it: our guide to embedding a Google News feed works through one named source end to end.