What Is a Podcast Feed Redirect (301)?
A podcast feed redirect is a 301 instruction at your old RSS feed URL that tells every app "this feed has permanently moved, use the new address." When you switch hosts, your feed URL changes, and the 301 carries your existing subscribers across to the new feed automatically, they keep getting episodes without re-subscribing or noticing.
The "301" is just the HTTP status code for "moved permanently." That word, permanently, is the whole point. A 301 tells apps to forget the old address and remember the new one. Get it right and a host migration is invisible. Get it wrong, or skip it, and you can strand a chunk of your audience on a feed that stops updating.
What is a podcast feed redirect, in one paragraph?
A podcast feed redirect is a server rule that returns an HTTP 301 ("moved permanently") at your old feed URL, forwarding any app that requests it to your new feed URL. It exists for one job: moving subscribers when you change hosts. Because apps store your feed URL and re-read it on a schedule, the redirect is the only thing that updates that stored address for them.
Your show lives in your RSS feed, a single file at a fixed web address that every directory copies from. When someone subscribes in Apple Podcasts or Spotify, the app saves that exact URL and keeps checking it for new episodes. So when the URL changes, the app is still loyally checking the old one. The redirect is the forwarding note you leave behind.
How a feed redirect works during a host move
When you move from Host A to Host B, you give your old host a single piece of information: the new feed URL from Host B. Host A then stops serving your normal feed at the old URL and instead serves a 301 that points to the new URL. Most modern hosts have a literal field for this, labeled "redirect feed," "301 redirect," or "point feed to new host."
From there it's the apps' turn, and this is the part you don't control. Apple Podcasts, Spotify, Overcast, and the rest each re-read feeds on their own schedule, sometimes within hours, sometimes over days. The next time each one checks the old URL, it gets the 301, records the new address, and from then on reads Host B. Your one official directory listing (the URL you submitted to Apple years ago) updates itself. You never re-submit anything.
There's also a tag-level version of the same idea. The RSS spec includes an new-feed-url tag is Apple's preferred extra signal. Good hosts set both.
The one thing that breaks it: the old feed has to stay alive
Here is the rule the term really teaches, and the mistake that costs people their audience: a 301 redirect only works for as long as the old feed is still answering requests. Apps don't all migrate the instant you flip the switch. Each directory caches your old URL and re-reads it on its own slow schedule, so until every app has checked in and seen the 301, some of your subscribers are still pointed at the old address.
If you cancel your old host too soon, the old URL goes dead before those apps have refreshed. Now an app requesting the old feed gets nothing, no 301, no episodes, and it simply stops updating that subscriber. They don't get an error they'll act on; their feed just quietly goes silent, and they assume you stopped publishing. You've split your audience across one feed you control and a dead URL you can't fix.
How to change podcast hosts without losing subscribers
Changing hosts without losing subscribers comes down to order: import first, redirect second, cancel last. The redirect is only one of the things that can break in transit, episode identity matters just as much. Run the move as a sequence, not a single switch, and confirm each step before the next.
- Import your full back catalog to the new host first, and check that it preserves your existing GUIDs. A GUID is the permanent ID apps use to recognize each episode. If the new host generates fresh ones, every app sees your whole archive as new, reposts all of it, and may re-notify subscribers about episodes from a year ago. A good host imports GUIDs intact; Apple's podcast requirements describe the episode GUID as the identifier that "never changes," and the Podcasting 2.0 namespace warns that changing it duplicates the episode downstream, which is exactly what a careless import does to every episode at once.
- Confirm the new feed actually plays before you redirect anything. Open it in a feed validator or a test subscription and check that the enclosure links, the tags that point to each episode's audio, resolve and play.
- Set the 301 redirect at the old host, pointing to the new feed URL. If your old host also exposes the
- Wait. Then wait longer. Leave the old host running and paying for weeks, many guides suggest a month or more, so every directory has time to re-read the old URL and catch the 301. There is no button that forces all apps to refresh at once.
- Cancel the old host only after traffic has moved. Watch your new host's stats; when downloads on the new feed match your usual numbers, the migration has landed. Then, and only then, cancel.
Why the redirect is the part to care about most
Of everything in a host move, the redirect plus your GUIDs are the two values that decide whether you keep your audience. Audio files can be re-hosted; show notes can be re-typed; artwork can be re-uploaded. Your subscriber relationship lives entirely in that one feed URL and the redirect that forwards it. Lose the redirect and there is no undo, you can't reach back into thousands of apps and re-point them by hand.
This is also why the feed is worth understanding even if you never plan to switch hosts. The same machinery that makes podcast distribution effortless, publish once, every app copies, is what makes a careless migration dangerous. The directories are working from a cached address on a slow loop, and the 301 is the only language they all speak for "I moved."
Frequently asked questions
Does a feed redirect make subscribers re-subscribe? No. That's the entire point. A correctly set 301 moves existing subscribers to the new feed silently, they keep getting episodes in the same app with no action on their part. They typically never know the show changed hosts. The redirect only matters to apps and directories, not to listeners.
How long should I keep the old podcast host running? Keep it active for at least a month after setting the redirect, and longer if you can afford it. Apps re-read feeds on their own unpredictable schedules, so the old URL has to keep answering with the 301 until every directory has caught up. Cancel only after your new host's download numbers match your normal baseline.
Is a 301 redirect different from a 302? Yes, and the difference matters. A 301 means "moved permanently" and tells apps to update their stored feed URL to the new one. A 302 means "found / temporary" and tells them to keep using the old URL. For a host move you always want the 301, a 302 leaves apps pointed at the old address indefinitely.
What happens to my download stats when I move hosts? If your GUIDs are preserved and the redirect is set correctly, your episode-level history carries over and apps treat each episode as the same one. If GUIDs change during the import, apps see the back catalog as new and stats can split or reset. Verifying GUID preservation before you redirect is what protects your numbers. The ID3 tags baked into the audio file are a separate layer the redirect doesn't touch.
Most podcasts go quiet anyway, so does the redirect matter? It matters precisely because most shows that go silent aren't lost to a migration, they podfade. Only about 16% of podcasts on Apple Podcasts are currently active, 482,930 of roughly 3 million, defined as having published in the last 90 days (The Podcast Host). A clean feed migration keeps the audience you've already earned; staying consistent enough to keep publishing is the harder, separate fight.