Most podcasters think about production in two phases: record and edit. Once the audio is done, it goes to their hosting platform and that is the end of the workflow. The RSS feed is something the hosting platform handles automatically. It just works.
That is true until it is not. And when an RSS feed breaks, the failure is invisible to the host until a listener reports it -- or until they notice their downloads dropped and cannot figure out why.
RSS feed hygiene is not exciting, but it is the last piece of the publishing workflow, and it deserves the same attention as the audio file itself.
What an RSS feed actually does
Your podcast RSS feed is a structured XML file that lives at a URL. It contains metadata about your show (title, description, author, artwork, category) and a list of episodes, each with its own metadata and a link to the audio file. Every podcast directory -- Apple Podcasts, Spotify, Pocket Casts, Overcast, every other app -- reads your RSS feed to display your show and deliver new episodes to subscribers.
When something goes wrong with the feed, directories may stop pulling new episodes, may display wrong metadata, or may show errors to subscribers trying to access the show. None of these are obvious to the host from inside their hosting dashboard.
The problems that come up
Feed validation errors are the most common category. These happen when the XML structure of the feed is malformed -- usually because a field contains a character that breaks XML parsing (&, <, > outside of CDATA blocks), or because required fields are missing or misformatted. Most hosting platforms handle this automatically, but if you ever manually edit a feed or use a custom setup, these errors are easy to introduce and hard to notice.
Episode title formatting issues are frequent and underestimated. Many podcasters include their show name in episode titles ("My Show: Episode 47 - The Guest's Name"). Apple Podcasts and Spotify both recommend against this -- directories already display the show name, so the episode title should just be the episode title. Redundant show names in episode titles create UI clutter and can cause truncation on small screens. More importantly, some search algorithms deprioritize episodes where the show name crowds out the actual episode topic in the title field.
Artwork specification mismatches cause headaches with Apple Podcasts specifically. The platform requires artwork in JPEG or PNG format, square, between 1400x1400 and 3000x3000 pixels. Images that are technically close but outside the spec will sometimes pass and sometimes not, with no clear feedback. Check the exact dimensions of your show art and episode art (if you use per-episode art) before upload.
Duplicate episode GUIDs are a more obscure but serious problem. Every episode in an RSS feed has a unique identifier called a GUID. If you ever re-export your feed from a backup, import into a new hosting platform, or accidentally duplicate an episode in your hosting dashboard, you may end up with two episodes sharing the same GUID. Directories that have already indexed the original may or may not update correctly when they see a duplicate. The result is unpredictable.
The twelve-minute show notes problem
Show notes are the text content attached to each episode in the RSS feed. They display in podcast apps below the episode listing. Most podcasters either skip them entirely or write two sentences and call it done.
The reason show notes matter: they are the primary indexable text content for podcast SEO. Audio is not indexed by search engines. The episode title and description are indexed. A well-written set of show notes with timestamps, guest names, topic keywords, and resource links gives search engines something to index and gives potential listeners a reason to click on an episode they have not heard yet.
The reason most hosts skip them: they take time to write after the recording is already done, and by that point the mental energy for the episode has run out.
A workflow that actually works is to draft show notes before the edit is complete. During recording, keep a notes doc open where you jot timestamps and topic transitions as they happen. After the edit, you have a skeleton. Adding the polished intro paragraph and the final timestamps takes 12 minutes, not an hour. The time cost is the startup cost -- opening a blank document after the fact and trying to reconstruct what happened in the episode from memory.
A practical feed audit checklist
Run this check on your feed every 6 months, or whenever you migrate hosting platforms.
Validate the feed at a free XML validator or a podcast-specific validator (Cast Feed Validator is one option). Look for any parsing errors in the output.
Check that your show artwork is exactly to spec for your primary directories. Apple Podcasts is the strictest.
Confirm that your most recent five episodes appear in Apple Podcasts, Spotify, and at least one third-party directory within 24 hours of publish. If any are missing, check the feed first before assuming a platform indexing delay.
Verify that your canonical feed URL has not changed. If you migrated hosting platforms and did not set up a 301 redirect from the old feed URL, subscribers using the old URL stopped getting updates at the migration date.
Check episode titles for show-name redundancy and trim if present.
After the audio is done
The edit is the hard part. Getting the audio clean and ready to publish is the work. But the feed is the delivery mechanism. A perfect edit that never reaches listeners because of a malformed XML field is wasted effort.
The good news: feed problems, once found, are usually fast to fix. The harder part is building the habit of checking at all.
