A podcast RSS feed is a public XML file that describes your show and lists every episode, including a direct link to each episode’s audio file. It is the single thing you hand to Spotify, Apple Podcasts and YouTube — everything they display about your show is read out of that file.
That is the part most people miss. Directories are not a place you upload episodes to. They are readers. Your audio lives on your host, your feed describes it, and the apps subscribe to the description.
RSS is the distribution protocol of podcasting
Podcasting is one of the last genuinely open media formats, and RSS is the reason. There is no central server, no upload API you have to be approved for, and no single company that can switch off your show everywhere at once.
The mechanics are plain:
- You publish an episode. Your host stores the audio file at a URL and regenerates your RSS feed to include it.
- Apple Podcasts, Spotify, Overcast, Pocket Casts and the rest fetch that feed on their own schedule and play the audio it points at. YouTube can read the same feed, but converts each episode into a static-image video on your channel instead.
- They parse it, update their copy of your show’s metadata, and show the new episode to subscribers.
- When a listener presses play, their app requests the audio file from your host, not from the directory.
That last step is why your host — not Apple, not Spotify — is where your download numbers come from, and why an unreliable host shows up as playback failures inside apps you have no control over.
It also means one broken file breaks everything downstream at once. There is no per-directory copy to fall back on.
The anatomy of a podcast feed
A podcast feed has two levels. Channel-level elements sit once at the top and describe the show. Item-level elements repeat, once per episode.
Anatomy of a podcast RSS feed
A complete, valid feed with one episode. The numbered fields are the ones directories actually check before they will list you.
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
<channel>
<title>The Turbo Hour</title>
<link>https://theturbohour.com</link>
<description>Interviews with people who ship things.</description>
<language>en-us</language>
<itunes:author>Dana Reyes</itunes:author>
<itunes:image href="https://cdn.turbocast.io/theturbohour/cover.jpg"/>
<itunes:category text="Technology"/>
<itunes:explicit>false</itunes:explicit>
<itunes:type>episodic</itunes:type>
<itunes:owner>
<itunes:name>Dana Reyes</itunes:name>
<itunes:email>[email protected]</itunes:email>
</itunes:owner>
<item>
<title>Shipping on a Friday</title>
<description>Why Dana stopped fearing the Friday deploy.</description>
<pubDate>Tue, 21 Jul 2026 09:00:00 GMT</pubDate>
<enclosure url="https://cdn.turbocast.io/theturbohour/012.mp3"
type="audio/mpeg"
length="28311552"/>
<guid isPermaLink="false">turbohour-0012</guid>
<itunes:duration>1967</itunes:duration>
<itunes:explicit>false</itunes:explicit>
</item>
</channel>
</rss>
-
xmlns:itunes="…podcast-1.0.dtd"— The Apple Podcasts namespace declaration. Every itunes: element in the feed depends on this one attribute being present and character-for-character correct. Get it wrong and the whole file parses as an ordinary blog feed with no artwork and no category. -
<title>— The show name exactly as you want it listed. Directories match on it, so renaming later can read as a different show. Plain text only — Apple rejects titles padded with search terms. -
<description>— The show summary, and a required field. Either plain text or HTML wrapped in CDATA. A raw, unescaped angle bracket or ampersand here is the most common single reason a feed stops parsing. -
<language>— An RFC 5646 code such as en-us. It decides which regional catalogue the show is filed under; missing or invented codes are a routine rejection. -
<itunes:author>— The name shown under the show title in most apps. This is the host or the network — not the company hosting the audio. -
<itunes:image href>— Note that the artwork lives in an attribute, not in the element text. Apple wants a square JPEG or PNG between 1400×1400 and 3000×3000 pixels, served over HTTPS from a URL that does not move. -
<itunes:category text>— Must be one of Apple's published categories, spelled exactly; if the name contains an ampersand it has to be XML-escaped. A subcategory nests as a second itunes:category element inside the first. Anything Apple does not recognise is quietly dropped. -
<itunes:explicit>— Required at channel level. Use true or false. Leave it out and Apple will hold the submission rather than reject it, which is why it is such an easy one to miss. -
<itunes:type>— episodic sorts newest first and suits most shows. serial sorts oldest first, for a season meant to be started at episode one. It changes the order every listener sees. -
<itunes:owner>— A name and an email address. Apple sends the ownership-verification message to this address when you submit, and it is not displayed publicly. A stale address here stalls the listing. -
<pubDate>— An RFC 2822 date, complete with day name and time zone. Apps sort episodes on it, so a malformed date scrambles the running order and a date in the future hides the episode until it arrives. -
<enclosure url type length>— The audio, and the one element that makes this a podcast rather than a blog. All three attributes count: url must point straight at the file, type must be the real MIME type (audio/mpeg for MP3), and length is the file size in bytes. A zero or guessed length breaks the progress bar and fails most validators. -
<guid isPermaLink="false">— The episode's permanent identity. Change it and directories treat the episode as brand new and push it to every subscriber again. isPermaLink="false" tells readers the value is an opaque ID rather than a URL they should try to fetch.
Everything above is generated for you if you host with TurboCast, but it is worth being able to read it: when a directory rejects a show, the reason is almost always one of these thirteen lines.
Channel-level: what the show is
These appear once, inside <channel>, and are what a directory uses to build your show page:
<title>— the show name. This is what people search for.<description>— the show summary.<link>— your show’s website.<language>— an ISO code such asen-us.<itunes:image href="...">— the cover art URL. Not the RSS 2.0<image>element; apps read theitunes:one.<itunes:category text="...">— must be an exact match for one of Apple’s published categories.<itunes:explicit>—trueorfalse.<itunes:author>— the show’s creator.<itunes:owner>— contains<itunes:name>and<itunes:email>. Spotify, Amazon and YouTube email this address to verify you own the show. Apple dropped the requirement in 2023 and verifies through your Apple Account instead. Anyone who has your feed URL can read this address, so use a monitored role address rather than a personal inbox.<itunes:type>—episodic(newest first, the default for most shows) orserial(oldest first, for shows meant to be played in order).
The feed also has to declare the iTunes namespace at the top or every itunes: tag is silently ignored. Apple’s podcast RSS feed requirements specify the declaration exactly: xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd".
Item-level: what one episode is
Each <item> block is a single episode:
<title>— the episode title.<description>— show notes. HTML has to be escaped or wrapped in CDATA.<pubDate>— the publish date, in RFC 2822 format. Apple’s docs are blunt about this: the format is “day of week, day month year” with a 24-hour time and a timezone offset, e.g.Wed, 6 Jul 2014 13:00:00 -0700. A date like7/6/2014 1:00:00 PMis invalid.<enclosure>— the audio.<guid>— the episode’s permanent identity.<itunes:duration>— length in seconds orhh:mm:ss.<itunes:episode>and<itunes:season>— positive integers, used for serial shows and season grouping.
The enclosure carries the audio
<enclosure> is the element that makes RSS a podcast feed rather than a blog feed. It takes three attributes, and Apple requires all three:
url— the direct, publicly reachable address of the audio file.length— the file size in bytes. Not seconds. Not megabytes.type— the MIME type, almost alwaysaudio/mpegfor MP3 oraudio/mp4for AAC in an MP4 container.
Two details bite people. First, Apple ignores duplicate <enclosure> URLs — if two episodes point at the same file, only one survives. Second, your server has to answer HTTP HEAD requests and byte-range requests, because that is how apps stream and scrub without downloading the whole file. Apple lists both as hard requirements.
The GUID is the episode’s identity, and it is permanent
<guid> is a string that uniquely identifies an episode. Apps key their entire database off it. Apple’s requirements say it plainly: the GUID must never change.
Here is what happens when it does:
- You change the GUID on a published episode. Every app reads it as a brand-new episode. It gets re-downloaded, it can push back into subscriber queues, and you now have two copies of the same show in the app.
- You reuse a GUID for different audio. The app may keep serving the old file, or overwrite the old episode’s metadata with the new one’s. Either way, something the listener already has is now wrong.
- You migrate hosts and the new host regenerates GUIDs from URLs. Your entire back catalogue looks new. Subscribers get an inbox of a hundred “new” episodes.
A well-behaved host generates a GUID that has nothing to do with the file URL, precisely so that moving the audio does not change the episode’s identity.
Which itunes: tags directories actually enforce
The itunes: namespace has a few dozen tags. Only a handful will stop your submission dead.
Three are effectively mandatory at channel level:
| Tag | Why it blocks you |
|---|---|
itunes:image | No artwork, no listing. Apple’s show cover spec is a square image between 1400×1400 and 3000×3000 pixels, PNG or JPG, with no transparency. 3000×3000 is what Apple prefers. |
itunes:category | Must match Apple’s category list exactly, including case and ampersand escaping. Kids & Family validates; Kids & family does not. |
itunes:explicit | A boolean. Directories use it for parental controls, and a missing value is a common rejection. |
Strongly recommended in practice: itunes:author, plus itunes:owner with a working itunes:email, because Spotify, Amazon and YouTube send an ownership verification code to that address. If that mailbox does not receive mail you cannot complete submission on those platforms. Apple is the exception — it verifies through your Apple Account and has not required the owner tag since 2023.
Situational but worth knowing:
itunes:type— setserialonly if your show is genuinely meant to be heard from episode one.itunes:block— set toYes, this actively hides your show from Apple Podcasts. Hosts sometimes set it on a draft feed and forget to remove it.itunes:complete— marks a show as finished. Directories stop expecting new episodes.itunes:new-feed-url— the redirect signal you use when moving hosts.
Everything else is polish.
How often do directories read your feed?
Directories poll — they come to you, on their own schedule, typically every few hours. Practically:
- A new episode usually appears in most apps within a few hours, and reliably within about 24.
- Metadata edits (title, description, artwork) can lag longer than episodes, because some directories cache show-level data more aggressively.
- Apple Podcasts Connect offers a manual feed refresh (available once every 24 hours), which is the fastest way to force a re-read after you have fixed something. Other platforms generally re-poll on their own schedule.
Nothing you do “pushes” to a directory. If a change has not appeared, either the poll has not happened yet or the feed is not saying what you think it is.
Your feed URL is the most important string you own
Every app that has ever fetched your show stored one thing: the feed URL. Every subscriber’s app is checking it right now. Break it, and you do not get an error message — you get silence.
Two rules follow.
Keep the URL stable. Ideally on a domain you control, so that leaving a host does not force a URL change at all.
If it must change, redirect properly. Apple’s documented process for a feed URL change is to do both of these at once:
- Serve an HTTP 301 permanent redirect from the old feed URL to the new one.
- Put
<itunes:new-feed-url>in the new feed pointing at the new URL.
Apple recommends keeping both in place for at least four weeks so slow-polling apps and infrequent listeners have time to follow the redirect. Do one without the other, or tear the old feed down after a weekend, and you will lose the subscribers whose apps never got the memo. This is the most common way podcasts silently lose an audience, and it is completely avoidable.
Check your feed before you submit it
Almost every distribution problem is a feed problem, and almost every feed problem is visible before you submit. Run your URL through our free RSS feed validator — it checks the things directories actually reject on: reachability, valid XML, required channel tags, artwork dimensions, category validity, explicit flag, and whether every episode has a working <enclosure> with a real byte length and a stable GUID.
Once it is clean, the next step is submitting your podcast to Spotify, Apple and YouTube, or working through the full podcast distribution checklist if you are pre-launch.
If your feed is already live and a directory still is not showing it, start with the diagnostic path in podcast not showing up on Spotify or Apple?.
TurboCast generates and maintains your feed for you — GUIDs, enclosures, categories and the tags directories require — so the file underneath your podcast distribution never becomes the thing you have to debug.