A podcast RSS feed is just XML, and almost any well-formed-enough XML renders fine in a browser or a lenient reader. Apple Podcasts' own feed processor, and most podcast apps' parsers, are stricter than that — and the gap between "displays fine" and "satisfies the documented spec" is where a show's episodes quietly stop showing up.
Most validation failures are a missing required element — annoying, but the fix is obvious the moment you see the finding. Two failure modes are worse, because the feed looks fine and the failure shows up somewhere else entirely, later, as a confused subscriber.
<guid>
Podcast apps use an episode's guid, not its title or its position in the feed,
to decide whether it is one a subscriber has already been shown. If a feed generator produces
the same guid for two different items — often because the guid is derived from something that
turns out not to be unique, like an episode number that got reused after a renumbering — one
of two things happens: the second item gets treated as a silent edit to the first and never
appears as new, or an app's local cache gets confused enough to resurface an old episode as
unread. Neither shows up by looking at the feed; both show up as "why did episode 40
disappear?" in a support inbox.
<pubDate> that isn't RFC 822
The RSS 2.0 spec requires pubDate in RFC 822 date-time format — something like
Wed, 02 Oct 2024 15:00:00 GMT. A format that a human (and many lenient parsers)
can read perfectly well, like an ISO 8601 date (2024-10-02) or a
locale-formatted string, is not valid RSS even though it looks like a date. A strict parser is
entitled to reject it outright, sort the episode into the wrong place in the timeline, or drop
it from the feed altogether — and because the date still looks like a date to anyone
reading the XML by eye, this is one of the easiest mistakes to ship without noticing.
Apple's documented requirements are exacting at the channel level: a title, a description (or
itunes:summary), a language code, at least one itunes:category from
Apple's own taxonomy, an itunes:explicit value in the current boolean
true/false format, and cover artwork declared via
itunes:image. Any one of these missing blocks a submission outright — see the
checker on the main page for the complete list, including the per-episode requirements
(title, enclosure, pubDate).
The most common way any of this goes unnoticed is testing by opening the feed URL in a browser and seeing that it displays. A browser's XML rendering is far more forgiving than Apple's ingestion pipeline or a strict podcast app's parser — "it looks fine" and "it satisfies the documented spec" are different claims, and the second one is what actually determines whether an episode reaches a subscriber.
Check your own feed: Podcast Feed Validator. See also: how this differs from the W3C Feed Validator.
A missing required element — most often itunes:category, itunes:explicit, or the cover-artwork itunes:image tag. Apple's feed processor requires these at the channel level for every show; a feed missing any one of them cannot be submitted at all, regardless of how good the episodes are.
Two <item> elements sharing the same <guid> value. Podcast apps use guid, not the episode's title or position in the feed, to decide whether an item is one a subscriber has already been shown. A generator that reuses a guid — often because it derives the guid from something that isn't actually unique, like an episode number that got reused after a renumbering — causes one of two failures: the second item is treated as an edit to the first and never shown as new, or (worse) the change confuses an app's local cache into re-showing an old episode as unread. Both bugs are invisible in the feed's own rendered output and only show up as a support ticket from a confused subscriber.
The RSS 2.0 spec requires pubDate in RFC 822 date-time format (e.g. "Wed, 02 Oct 2024 15:00:00 GMT"). A different but still human-readable format — an ISO 8601 date like "2024-10-02", or a locale-formatted string — is technically invalid RSS even though most humans and many lenient parsers can read it. A strict podcast-app parser is entitled to reject the date, sort the episode incorrectly, or drop it from the feed's timeline entirely, and this is a documented, recurring cause of an episode appearing in the wrong order or not appearing at all.
No. A browser (or a lenient RSS reader) tolerates almost any well-formed-enough XML and will happily display a feed that Apple's stricter, spec-conformant processor rejects outright. "It looks fine when I open the URL" and "it satisfies the documented spec" are different claims, and the gap between them is exactly what a feed validator checks.