How Podcast RSS Feeds Actually Work

What Is a Podcast RSS Feed? How It Works in 2026

Last updated: September 2026

An RSS feed is a single text file that lists your show and every episode in a format apps can read. Your podcast host builds it and keeps it online. Apple Podcasts, Spotify, and the rest read that one file to find new episodes. It is also the piece you own. Get the feed into the right places once, keep control of it, and distribution largely takes care of itself.

What is an RSS feed, really?

Strip away the mystery, and it is an XML file, plain text with tags. At the top it holds your show details: title, description, artwork URL, category, language, author. Below that, one block per episode with the audio file link, a title, a publish date, and the show notes.

What a podcast RSS feed looks like inside

<rss version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <channel>
    <title>Your Show Name</title>
    <description>What the show is about</description>
    <language>en-us</language>
    <itunes:image href="https://example.com/artwork.jpg"/>
    <itunes:category text="Technology"/>
    <itunes:explicit>false</itunes:explicit>

    <item>
      <title>Episode 12: The One About Feeds</title>
      <enclosure url="https://example.com/episode-12.mp3" length="28311552" type="audio/mpeg"/>
      <guid isPermaLink="false">ep-12-unique-id</guid>
      <pubDate>Tue, 28 Jul 2026 09:00:00 -0500</pubDate>
      <itunes:duration>1847</itunes:duration>
    </item>

  </channel>
</rss>

Two halves, and that is the whole document. Everything inside channel but above the first item describes the show. Each item is one episode. Add an episode and your host writes a new item block at the top. That is the entire mechanic behind “publish once, appears everywhere.”

Which tags actually matter?

Four of them do real work. The rest is metadata that makes your listing look right.

enclosure is the audio file. It carries the URL, the file size in bytes, and the MIME type. If an episode has no enclosure it is not an episode, it is a blog post that happens to be sitting in a podcast feed, and it will not play anywhere.

guid is the permanent ID an app uses to tell one episode from another. Not the title, not the URL. If a host or a bad import changes it, every app reads the same audio as something brand new, which is exactly how a listener ends up with your back catalog twice. Leave it alone forever. The long version is what a GUID is in a podcast feed.

itunes:image is your cover art, and Apple is strict about it. Square, between 1400 by 1400 and 3000 by 3000 pixels, PNG or JPEG, no transparency and no alpha channel. Apple prefers 3000 by 3000, so shoot for that and you are covered everywhere. Get it wrong and the show is rejected before a human ever sees it.

itunes:category decides where you get filed. Apple accepts a fixed list, so a category you invent is a category that does not apply.

The rest, language, pubDate, itunes:duration, itunes:explicit, shape how your show is displayed and filtered rather than whether it works.

Why does a feed break?

Almost always one of four things, and none of them require you to open the XML.

An episode has no playable enclosure, usually because an upload failed partway. Artwork does not meet Apple’s spec. A required show-level field like category or language is empty. Or a GUID changed underneath you during a host migration and every app re-downloaded your catalog.

That last one is the expensive mistake, and it is a migration problem rather than a feed-writing problem. A host that imports properly preserves the original GUIDs. One that does not will hand your subscribers fifty notifications in an afternoon. The two cases people actually hit are walked through in podcast feed rejected by Apple and podcast not showing in Apple Podcasts or Spotify.

Transistor distribution checklist showing each directory and the feed status beside it

You never edit any of this by hand, and you should be suspicious of any workflow that asks you to. The whole job of a podcast host is writing valid XML so you never think about it. What you actually control is upstream: fill in every show-level field before you submit anywhere, use artwork that meets the spec, and pick a host that preserves GUIDs on import. Get those three right and the file underneath takes care of itself.

When you “have a podcast,” what you technically own is this feed.

Everything a listening app knows about your show, it learned by reading these tags. The artwork you see in Apple Podcasts, the episode order, the little description under each title, all of it is pulled straight from the feed your host generates.

Apple layers extra tags on top through its own namespace, the itunes: ones, which is why you set an episode as “explicit” or mark a season number, and it shows up correctly across apps. You almost never edit the raw file. Your host writes it for you every time you hit publish.

That is the file itself. Below is where it lives in a host’s dashboard, in this case Transistor, which hands you the feed URL behind a copy button rather than the raw XML.

Transistor dashboard showing the Your RSS Feed panel with the feed URL and a copy button.

How do apps read your feed?

They poll it. That is the unglamorous truth. Each app, on its own schedule, sends a request to your feed URL, reads the file top to bottom, and looks for episodes it has not seen. Find a new one, and it pulls the audio and shows it to subscribers.

You do this handshake once. At launch, you submit your feed URL to Apple Podcasts Connect and Spotify for Creators, plus any other directory you care about. They validate the feed, add your show to their catalog, and start polling. From then on, you never log back into those apps to publish. The step-by-step for all three, Apple, Spotify, and YouTube, is in how to submit your podcast. You upload to your host, the feed updates, and the apps notice on their next check. Sometimes that is minutes, sometimes a few hours, depending on how often each app polls.

This is also why a podcast reaches everywhere from one action. You are not uploading to twelve apps. You are updating one feed twelve apps happen to watch.

Where do you find your podcast’s RSS feed URL?

Inside your host, on a settings or distribution screen, behind a copy button. It is never in Apple Podcasts or Spotify, because those apps only ever read the feed your host publishes. The exact screen on Buzzsprout, Transistor, Captivate, and Spotify for Creators, with a screenshot of each, is in where to find your podcast RSS feed URL.

Two habits save you real pain. Know where that address lives before you need it. And understand that it is portable, which is the whole reason you are never trapped with one host. When you switch, you import your episodes to the new host and set a redirect on the old feed so apps quietly follow the move, subscribers and download history intact. Break that redirect and your numbers reset.

One more thing worth guarding: whoever controls the feed controls the show. If a producer or agency set up your host under their account, the feed is theirs, not yours. Own the host account in your own name from day one.

FAQ

Do I have to create the RSS feed myself? No. Your podcast host builds and updates it automatically every time you publish. You copy the finished feed URL and submit it to the apps once.

Can I move my RSS feed to a new host? Yes. You import your back catalog to the new host and set a 301 redirect from the old feed. Done right, apps and listeners follow with no interruption.

What happens if my RSS feed goes down? Apps that poll it during the outage see no new episodes, and a long outage can drop your show from a directory. This is one reason to use a real host rather than serving a feed yourself.

Is a podcast RSS feed the same as my website? No. The feed is a machine-readable file apps consume. Your website is a page people visit. Some hosts give you both, but they are different things, which we unpack in podcast hosting vs a website.


Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *