Is Your Podcast Feed Ready for Every Player?

A podcast feed is, underneath everything else, a standard RSS 2.0 XML document. The RSS Advisory Board's specification requires exactly three elements on the channel itself -- title, link, and description -- everything else layered on top is either optional in the base spec or added through a namespace like Apple's itunes: tags. Each episode is an item, and the piece that actually makes it a podcast rather than a blog feed is the enclosure element, which needs three attributes: url (where the audio file lives), length (its size in bytes), and type (its MIME type, such as audio/mpeg). Get any of those three wrong and podcast apps can fail to find, size, or play the episode at all, even if the rest of the feed looks fine.

Apple Podcasts layers its own requirements on top of bare RSS 2.0. Feeds need an itunes:category, an itunes:author, and other iTunes-namespace tags, plus a valid channel-level artwork reference. Apple is also strict about formatting details that are easy to get wrong in an automated export: dates must follow the RFC 2822 format (day of week, day, month, year, then 24-hour time with a time zone offset), filenames and URLs should stick to plain ASCII characters, and XML tags are case-sensitive, so a category written as "kids & family" instead of "Kids & Family" can fail validation. Every episode also needs a GUID -- a globally unique identifier that must never change once it is published, since apps use it to track what a listener has already heard.

The errors that break feeds most often are small and mechanical rather than dramatic. A missing or duplicated GUID makes apps think an old episode is new again, or a new episode is one you have already played. An enclosure with a length of 0 or a placeholder value confuses download progress and file-size displays. Dates that do not conform to RFC 2822 -- a common byproduct of some CMS and hosting-platform exports -- can cause an episode to sort incorrectly or vanish from a "recent episodes" view entirely. Ampersands written as a bare & instead of the XML entity & are one of the most common ways an entire feed becomes invalid XML rather than just one bad episode, since an unescaped character breaks the parser at the point it appears and everything after it can fail to load.

Validation matters because no two podcast apps and directories parse a feed with exactly the same tolerance for errors. Apple's own submission pipeline will reject a feed outright for missing required tags, while some third-party apps parse more forgivingly and just silently drop a malformed episode or fall back to a blank title. That inconsistency is exactly why a feed can look fine in one directory and be broken in another -- the show "works" where a listener already found it, but new listeners on a different app or platform run into missing artwork, garbled titles, or episodes that never appear at all. Catching these problems before publishing an episode is far less costly than fielding listener reports of a broken feed after the fact.

A practical validation routine starts with a general-purpose tool like the W3C Feed Validation Service to catch outright XML errors, then checks the feed against Apple and Spotify's specific requirements, since a feed can be technically valid RSS 2.0 and still fail platform-specific rules. It is also worth re-validating after any hosting migration, CMS update, or feed-redirect change, since these are the most common moments a previously clean feed picks up an encoding bug or a broken enclosure URL. Once the RSS 2.0 core and platform requirements pass cleanly, Podcasting 2.0 tags -- transcript, chapters, funding, and person credits, all championed by the open-podcasting Podcast Standards Project -- are worth adding on top, since they are additive and do not put an otherwise valid feed at risk.