Moving Your Podcast? Keep the Old Feed Pointing to the New One

Imagine an independent producer moving a weekly interview show to a new podcast host. The new dashboard shows all forty episodes. The cover looks right, and the latest interview plays on the producer’s phone. But that phone is following the new feed, added for testing. A listener who subscribed two years ago may still be relying on the old address. The move is only finished when that listener has a route to the new feed.

Think of a podcast move as two jobs: transfer the publication and preserve the route people already use to reach it. A successful import is evidence for the first job. For the second, you need to test from the old address and from a subscription that existed before the move. You can prepare those checks while you still have access to both hosts.

Check the imported archive before redirecting anyone

Save a copy of the old feed and take an inventory of the episodes you expect to keep. The RSS 2.0 specification distinguishes an item’s identifier, called a GUID, from its enclosure, which points to the media file. The enclosure address can change when audio moves to a new host. In a migration, the old and new feed should still identify the same episode with the same GUID. Compare the values themselves rather than relying on matching titles.

Check the oldest episode, a recent one and anything unusual: a trailer, a bonus release or an episode whose audio you replaced. Compare the full set of expected episodes as well. An imported feed that contains only the latest releases can look fine in a quick preview while leaving part of the public archive behind. If a host limits how many entries appear in its feed, ask how to expose the back catalogue before switching.

Play several imported episodes, including a late section of an older one. Check whether the new feed still points to media on the old host. If it does, find out what happens to those files when the old account closes. Treat the links in your own website embeds or show notes as a separate check. A working redirect for the feed address does not automatically repair every link that points directly to an audio file.

If you also need to replace a recording, consider doing it as a separate change. That way, if a listener reports a duplicate or a broken download, you have fewer causes to investigate. Our guide to correcting podcast audio without changing the episode’s identity covers the replacement itself.

Keep the old address working through the handover

Check with the old host before cancelling anything. Ask whether it can send a permanent redirect from your old feed URL to the new one, how long that redirect remains available and what happens if you close the account. Ask the new host how it preserves episode IDs and which parts of the migration it handles. Get clear answers while the old feed is still live, when you can choose a different route if necessary.

For a self-hosted move, Apple Podcasts’ feed migration guidance calls for an HTTP 301 redirect at the old feed address and an itunes:new-feed-url tag in the new feed pointing to the new URL. Apple recommends maintaining the redirect and tag for at least four weeks. That is Apple’s guidance for this route. Check what your own hosts and other distribution services require, and keep the redirect longer where you can if older links or less active subscribers still matter.

Apple also describes an option to update the feed URL through Podcasts Connect, depending on the state of the original feed. If you cannot redirect the old address, check the recovery options for the directories you use and communicate the change through channels you control. Updating a directory listing does not establish that every app following the old URL directly has moved.

Test from the listener’s side

Set up a test subscription to the old feed before changing it, ideally in an app your audience already uses. After the change, check the old URL, the new feed and that existing subscription separately. Opening the new address and seeing the right artwork is useful; it does not tell you what the old subscription received.

• Follow the old address. Verify that it redirects to the exact new feed and that the destination serves the feed rather than a login page or an ordinary show page.
• Check the existing subscription. After its normal refresh, look for a missing archive or unexpected duplicates. Avoid unsubscribing and re-adding it during this check.
• Check the next real episode. Publish once, at the new host, then verify that the episode reaches an existing subscription and can play. Check your main directory listings separately.
• Record the handover. Save both addresses, the switch date, the redirect commitment and the person to contact if an older episode stops playing.

Allow time for refreshes before interpreting the results. If one service is slow, check its status or guidance before changing settings again. If a listener reports a problem, ask which app they use, which episode is affected and whether they were already following the show. That helps you distinguish an old subscription that has not moved from an archive or playback fault at the new host.

The best evidence of a successful move is ordinary listening: a person who followed the show before the switch receives the next episode, and can still play one from the archive. Make those two checks part of the move before you let the old host go.

Sources

• Apple Podcasts for Creators, Change the RSS feed URL, platform guidance.
• RSS Advisory Board, RSS 2.0 specification, version 2.0.11, 30 March 2009.