A podcast feed connects an editorial schedule to the media files listeners actually play. The XML describes the show and its episodes; the audio is delivered from the addresses referenced by the feed. A reliable publishing workflow therefore checks two things together: the accuracy of the episode record and the availability of the corresponding media.
That connection becomes especially important when a show changes hosting providers. Moving a feed is a continuity project involving existing episode identities, media addresses, directory records, and subscribers. The podcast feed overview introduces the components. This checklist follows an episode from preparation through publication, then extends the same discipline to a host migration.
Keep a durable record for every episode
Create an episode record before uploading its final media. Include an immutable identifier, title, description, publication time, media filename, and canonical episode page. Keep show-level information such as the publication name, artwork, language, and description in a separate record. This makes it easier to change a show description without accidentally rewriting the identity of every episode.
Use titles that remain understandable outside your own website. A listener may encounter an episode in a search result, queue, or shared link with little surrounding context. Explain the central topic in the title and use the description to add the guest, question, or outcome. If your show uses seasons or episode numbers, keep those values consistent in your editorial records.
Retain original source material and the final published media file. An editable recording project, an export, and a publicly served file are distinct assets. Name them so a future maintainer can tell which one was published. A migration is much easier when the team can locate an authoritative copy of each episode without comparing several similarly named downloads.
Validate the directory's actual requirements
For public submissions through RSS, Apple Podcasts' feed requirements specify RSS 2.0, a publicly reachable feed, stable episode GUIDs, and an enclosure with its URL, length, and type. Apple also calls for hosting that supports HTTP HEAD and byte-range requests. These are useful concrete checks when evaluating the output of a hosting provider.
Directory-specific requirements sit alongside general XML correctness. Confirm required tags and supported media or artwork specifications for each destination you intend to use. Record those requirements in the publishing checklist, with a review owner. A feed can parse as XML while still lacking information that a particular distribution platform needs.
Check spelling and capitalization in controlled values such as categories. Keep an example of a known valid episode record so editors can compare unusual cases against it. Avoid copying a random feed simply because it appears in a podcast app; another publisher's output may depend on history, exceptions, or software behavior that does not apply to your show.
Check the finished media before publishing
Listen to the final exported file, including the beginning, transitions, and ending. Confirm that it is the intended cut and that the episode description matches the recording. Check any promised supplemental resources on the episode page. Feed validation cannot identify an accidental draft recording or a missing closing segment.
Generate the enclosure's byte length from the actual published file, and set the media type according to its format. Duration and file size describe different things. A file replaced after metadata generation may have a different size, so make the finished asset part of the same release record as the feed item.
Test the media address from outside the publishing account. Confirm that it returns the media rather than a sign-in page, an expiring preview, or a storage management screen. Test seeking within playback and inspect the hosting behavior required by your destinations. Keep episode media available after it leaves your promotional homepage; subscribers may discover the recording much later.
Publish in a deliberate sequence
- Finalize the episode record and approve the recording.
- Upload the finished media and any required artwork.
- Confirm that the public media and episode page are reachable.
- Generate or update the feed with the approved episode entry.
- Validate the public feed and inspect the episode in representative players.
This sequence reduces the chance of announcing an episode before its file exists at the published address. Where your host automates the process, understand which checks it performs and which remain editorial responsibilities. Automation is most useful when the team can still explain the order of publication and identify a failed step.
Keep a brief release record with the episode identifier, intended publication time, media location, and final check result. If a listener reports a problem, this record gives the maintainer a starting point. It also helps distinguish a publishing mistake from a delayed refresh in a consuming application.
Review the listener's experience
Subscribe to your own feed in more than one representative player. Check the show artwork, episode title, description, release ordering, and playback destination. Follow links in the description and verify that they remain meaningful on a small screen. Read the description without the episode page nearby to see whether it stands on its own.
Inspect at least one older episode during routine review. A new release can work while an older storage location has become unavailable. Choose a small rotating sample from the archive, including episodes with older artwork or unusually large files. This makes archive maintenance manageable without assuming that recent success proves the entire catalog is healthy.
When correcting metadata, preserve the episode's identity. Maintain a clear distinction between a revision to an existing episode and an intentionally new publication. A short correction note in the description can help listeners understand a substantive change without forcing the publishing system to represent the recording as a different episode.
Prepare a migration inventory
Before changing hosts, export the existing feed and create an inventory of episode GUIDs, titles, dates, enclosure addresses, and media sizes. Record the current feed address and the directory records associated with it. Confirm which account or provider controls redirects from the old address. Those details determine what you can preserve during the move.
Import into the new host without immediately retiring the old service. Compare the imported catalog against your inventory. Look for missing older episodes, changed GUIDs, altered publication dates, truncated descriptions, and unexpected artwork substitutions. The feed hosting guide helps organize questions about URL control, media delivery, and ongoing access.
Check the new feed and media using their public addresses before directing subscribers to them. Keep the comparison specific: episode count alone is insufficient if the identifiers have changed. Review a few detailed records as well as a complete machine-readable comparison of the identifiers when your tools support it.
Move the address while preserving identity
Apple's published migration procedure calls for an HTTP 301 redirect from the old feed address and an itunes:new-feed-url tag in the new feed pointing to its new location. It says to maintain the redirect and tag for at least four weeks. Follow the applicable provider and directory procedures carefully, and preserve every existing episode GUID through the move.
Keeping the old redirect available longer can provide a useful continuity margin when you control the address. Decide that retention period before canceling the old hosting arrangement. An address printed on an old website or saved in a rarely opened player can still matter. Document who owns the domain and who can change the redirect later.
After the move, test the old address, the new address, and a selection of episode files. Confirm that the old feed resolves to the intended new feed without an unnecessary chain of intermediate destinations. Review directory status and listener-facing displays. Differences in analytics between providers deserve investigation, but they are not a substitute for testing actual subscription and playback behavior.
Make continuity part of the next release
The first episode published after migration is an important confirmation. Watch whether it appears through an existing subscription and whether playback uses the intended media location. Keep the migration inventory until the team has verified ordinary publishing on the new setup and resolved any discrepancies.
A dependable podcast feed grows from careful records, accurate metadata, and deliberate media delivery. Use the feed operations checklist to maintain those habits between releases. Preserving the publishing trail makes both everyday corrections and larger hosting changes easier to understand, test, and carry through.
