How podcast RSS redirects actually work

A podcast is an RSS file sitting at a URL. Apple Podcasts, Spotify, and Pocket Casts do not keep your episodes. They check that URL on their own schedule and cache whatever they find. That is the only reason moving hosts is possible at all: the feed URL is the identity of the show, and whoever generates the file, Libsyn or Buzzsprout or Transistor, is just the machine behind it.

So a migration is not moving a show. It is changing which server produces the file, then convincing every app in the world to look at the new address. Apps check when they feel like it, so the mechanism has to work with that lag rather than around it.

A proper feed redirect is an HTTP 301, the same permanent-move response the rest of the web uses. An app asks for the old URL and gets back a short answer: this lives at the new address now. Not the old XML. A pointer.

Apps that respect that update their own record of your feed and stop touching the old host entirely. This is very different from writing we have moved in your show description, which does nothing for a machine and only helps the rare human who reads descriptions.

Not every app handles 301s well. Plenty check every few days rather than every hour, so even a perfect redirect takes time to reach everyone. Apple recrawl runs days to about two weeks, and that recrawl is not your keep-alive window. Smaller apps and regional directories are slower, and a few abandoned ones will never update.

Which is why you cannot switch the old host off yet. If an app has not seen the redirect and the old feed is already gone, it gets a 404 instead of a pointer, and some apps quietly drop the show from that listener's subscriptions instead of hunting for it.

Every host's own documentation lands in roughly the same place: 60 to 90 days minimum. That covers the slow apps and gives you time to notice if the redirect was set up wrong.

Check analytics on both hosts through that window. Real download activity still hitting the old feed at day 60 means either the redirect is broken or a real chunk of your audience uses an app that has not moved. Either way, extend the overlap.

Apple Podcasts Connect identifies a show by its feed URL, not by the hosting company. Reviews, ratings, and category position stay attached to that record when you move with a proper 301, and you do not have to do anything inside Connect for a normal redirect to work. Apple crawls on its own. Log in afterward and confirm the feed URL it stores has changed, usually within a few days to about two weeks.

Still showing the old URL after two weeks? Either the redirect is wrong or Apple has not recrawled. Use the resubmit feed option in Connect to nudge it. Do not read that two-week recrawl as permission to kill the old host. The 60 to 90 days still applies.

If Spotify is only a directory for a show hosted elsewhere, your host's 301 is what updates the Spotify listing. Their crawl is usually quick, often a few days. Check the show page afterward for missing or duplicated episodes.

If the show was actually hosted on Spotify for Creators, that redirect lives in Settings under Redirect your podcast at creators.spotify.com. No generic host 301 can do that job for you. The dedicated leave guide walks the clicks.

Do not rename the show or swap the cover art in the same fortnight as a host move. Change one thing at a time, or you will not know which change caused the weirdness, and some platforms treat a title plus feed change as a bigger disruption than either alone.

Keep publishing on the normal schedule. A gap in the exact week the address is shifting reads as a dead show to both an algorithm and a person.

Use a feed validator that shows response codes, not just the rendered XML. What you want to see is a clean 301 pointing at the new URL. Not a 200 with a note about moving. Not a 302, which some apps treat as temporary and ignore.

Check it the day you flip it, then again a week later. Some hosts want you to manually activate the redirect rather than doing it the moment you stop publishing.