Moving a podcast is not the same as moving its audio files. Your show’s RSS feed is the public address that podcast apps and directories use to find new episodes. If that address breaks during a host change, existing subscribers may stop receiving updates. If the same show appears under two feed addresses, listeners may see duplicate episodes or follow the wrong version.

The safest process is straightforward: export and map first, publish on the new host second, redirect the old feed third, then validate and monitor before closing the old service. Keep the old host available until the migration passes your checks.

This guide does not recommend a hosting product. It is a migration plan you can use with any host that supports feed imports, exports and redirects.

What actually moves during a podcast host migration?

A podcast migration usually involves four connected pieces:

  1. The show identity: title, author, description, artwork, language, categories and ownership details.
  2. Episode metadata: titles, descriptions, publication dates, audio URLs, episode numbers, seasons, episode types and identifiers.
  3. The RSS feed: the permanent public feed address used by podcast apps and directories.
  4. Distribution and audience state: existing subscriptions, directory listings, analytics history and any linked website or player.

The audio files should move to the new host, but your subscriber subscriptions usually do not “move” as database records inside your control. Instead, listeners and directories need a reliable signal that the feed has permanently relocated. A permanent HTTP 301 redirect from the old RSS URL to the new one provides that signal.

Apple’s current guidance says that self-hosted feeds should return an HTTP 301 response for the old feed and include a new-location tag in the new feed. It also advises maintaining the redirect and new-location tag for at least four weeks. The exact redirect process for a third-party host may instead be handled through that host’s support team.

Treat these as operational safeguards, not a promise that every app or directory will update at the same speed. Some services refresh automatically; others may need manual review or a fresh submission.

Podcast RSS feed migration checklist

1. Decide what success means before moving

Write down the state you expect to preserve. A useful pre-migration record includes:

  • the current public RSS URL;
  • the destination RSS URL, once it exists;
  • your current episode count;
  • the latest episode title and publication date;
  • the five most recent audio URLs;
  • each episode GUID;
  • show artwork and key metadata;
  • directory and app listings you know about;
  • current download and subscriber figures;
  • any dynamic ads, private feeds, membership content or paid subscriptions;
  • links from your website, social profiles, email newsletter and show notes.

This inventory becomes your comparison baseline. Without it, it is easy to mistake a display or reporting difference for a missing episode.

Also write a simple acceptance test. For example:

When the migration is complete, every existing episode should be available from the new feed, new episodes should be published only through the new host, the old feed should return a permanent redirect, and the feed should pass validation without errors.

Add any requirements specific to your show. A private feed, a season-based structure or a show with advertising may need extra checks.

2. Export a complete backup

Before importing anything, obtain the most complete export the old host offers. Look for:

  • RSS XML;
  • episode audio files;
  • episode artwork and show artwork;
  • episode titles, descriptions and show notes;
  • publication dates;
  • episode GUIDs;
  • explicit and implicit episode numbers and seasons;
  • transcripts or chapter data, if available;
  • advertising or monetization records;
  • analytics exports;
  • subscriber or email-list information, where available.

Keep at least one untouched copy. If the migration exposes an import problem, you may need to rebuild an episode entry manually.

Do not assume every export contains everything. A simple RSS file may not preserve password-protected episodes, private-feed settings, ad markers, website configuration or analytics history. Test what actually exists rather than inferring from the export button.

3. Map the old feed to the new one

Open the old and new RSS feeds side by side. Create a field map before publishing the migrated catalogue.

What to map What to verify
Show title and author Exact spelling, credited author name and consistent capitalization
Description and categories Categories still represent the show and available fields were imported
Artwork Correct image, acceptable dimensions and consistent artwork across episodes
Episode titles and notes Text, links, formatting and episode-specific images survived the move
Publication dates Dates and ordering remain correct rather than changing on import
Episode GUIDs Existing episodes retain their original GUIDs
Audio URLs Files are public, playable and linked to the correct episode metadata
Episode numbers and seasons Numeric values and hierarchy are intact
Episode type Full, trailer, bonus or other supported types are classified correctly
Transcripts and chapters Tagged media or supporting files are present where the new host supports them
Enclosure details File type, byte length and MIME type correspond to the hosted audio

Episode GUIDs deserve special attention. Apple states that changing a GUID can cause duplicate episodes, distort analytics or affect a show’s status. If the new host generates a new GUID for an imported episode, correct the mapping before the episode is distributed. If an episode has no GUID, the enclosure URL may serve that identifying role, so do not alter it without understanding the consequence.

Do not change a title, artwork file or episode URL simply because the new host offers a different layout. Make the necessary corrections first, then normalize the feed in a later controlled pass.

4. Import into the new host without publishing

Use the new host’s import workflow if available, but keep publication under your control wherever possible. Importing as drafts makes it easier to inspect metadata and test access before the feed becomes the authoritative source.

Check the import in this order:

  1. The show-level information.
  2. The newest episode.
  3. The oldest episode.
  4. A normal episode with notes and artwork.
  5. A season-based or numbered episode, if applicable.
  6. A private, trailer, bonus or paid episode, if applicable.
  7. Audio playback on mobile and desktop.

Then correct the mapping errors that the import revealed. Avoid making broad edits while troubleshooting an individual field, because that makes it harder to identify the source of the problem.

5. Validate the new RSS feed

Open the new public feed URL directly. It should return an XML feed rather than an HTML login page, a generic error or an empty shell.

Run the feed through a podcast-specific validator, such as Cast Feed Validator. A standard RSS checker can reveal malformed XML, but a podcast-oriented validator is more likely to flag podcast-specific requirements. Review every error and warning; do not treat a partly successful validation as a completed migration.

Then test these practical elements:

  • The feed loads without authentication.
  • At least one episode is present and playable.
  • The enclosure points to the actual audio file.
  • The audio file can be opened without a session-specific or expiring URL.
  • The show and episode artwork loads.
  • Dates, GUIDs, episode numbers and seasons match the old feed.
  • No duplicate episodes have been created.
  • The feed’s new-location tag points to the correct destination.

Keep the validator output with the migration record. It gives you a dated baseline for checking the feed after the redirect and after future episode publications.

6. Configure the old RSS redirect

Request a permanent HTTP 301 redirect from the old feed URL to the new feed URL. Depending on the old host, you may be able to configure this yourself or need to ask support.

A practical request contains:

Subject: Permanent RSS feed redirect request

Hello,

I am moving this podcast to a new hosting provider:

Old feed URL:
[PASTE OLD FEED URL]

New feed URL:
[PASTE NEW FEED URL]

Please configure a permanent HTTP 301 redirect from the old feed URL to the new feed URL and keep it active for at least four weeks. Please confirm when it is in place and whether there are any service-specific requirements for the redirect.

Thank you.

Do not redirect a generic website page when the old feed address itself must resolve. The request to the old RSS URL should produce a permanent redirect response. The destination must be the new feed URL, not a homepage, player page or “mirror” listing.

Apple’s guidance for self-hosted feeds also calls for a new-location tag in the new feed. If your old host handles the redirect for you, confirm whether it also supplies the required feed-side signal.

Test the redirect from a clean request rather than relying only on a browser that may have cached the response. Confirm that it returns the expected permanent status code, resolves to the exact new feed and reaches the intended XML.

7. Switch publishing to the new host

Once the new feed and redirect are validated, publish only through the new host. Do not publish the next episode from both systems, even if the imported episodes look correct. Dual publishing can create the same episode under two feeds, produce duplicate GUIDs or make the authoritative feed ambiguous.

After the first new episode is published:

  • confirm it appears in the new feed;
  • play it in a podcast app;
  • verify its GUID and enclosure URL;
  • test a fresh subscription to the new feed;
  • revisit the feed validator;
  • check that the old feed redirects to the new location;
  • update or verify the public submission URL in Apple Podcasts Connect if required for your setup.

Apple notes that a third-party host may handle the feed change through its redirect, while creators who manage their own feed may need to update Apple’s stored URL as well. Use the current Apple workflow for your account rather than assuming the old submission URL always remains the correct source of truth.

Your RSS feed is central, but it is not the only public reference to your show.

Review:

  • the show listing in major podcast directories;
  • embedded players on your website;
  • links in episode show notes;
  • social profile and newsletter links;
  • QR codes on posters, videos or printed material;
  • private or membership feeds;
  • podcast-related website pages that display the feed URL.

Where a player or directory stores the feed URL internally, confirm that it updates or can be refreshed. Do not replace every historical episode link with the new feed automatically: an old episode’s page may correctly remain a permanent episode URL, while the feed address should be treated separately.

Also update links in future show notes. Historical links can remain when they still resolve correctly, but new templates should use the current feed or episode destinations.

9. Monitor for at least four weeks

Apple recommends maintaining the redirect and feed-side new-location tag for at least four weeks. Treat four weeks as a minimum operational window rather than a universal deadline, especially if your audience or directory coverage is substantial.

During this period, monitor:

  • whether the new feed updates after each publication;
  • whether the old feed continues to redirect;
  • validation errors or new warnings;
  • missing or duplicate episodes;
  • directory appearances and stale artwork;
  • playback failures;
  • changes in downloads or unique listeners;
  • support messages from listeners;
  • ad delivery, private-feed access or paid-content behavior, if relevant.

Compare results with the pre-migration baseline, but be careful about what the numbers mean. Hosting dashboards can count downloads differently. A decrease immediately after a switch is not automatically evidence of lost subscribers; an increase is not automatically evidence of growth. The strongest continuity signal is that known subscriptions continue receiving the same episodes through the same public show identity.

10. Keep a rollback path until acceptance

Do not cancel the old host, delete the old feed or remove original audio immediately after the first successful redirect.

Your rollback plan should identify:

  • who can restore or reactivate the old feed;
  • where the exported files and metadata are stored;
  • what the old feed URL and redirect status were;
  • which episodes were published after the move;
  • how a failed publication can be corrected on the new host;
  • how long the old service must remain active.

If the new feed develops a serious validation or playback problem, you may need to correct the destination, re-point the redirect, or temporarily restore the previous feed. Do not improvise this during an outage: make sure the rollback steps are written down while both systems are still available.

Close the old account only after the monitoring window, listener checks and directory review are complete. If the old host requires a downgrade or cancellation process to release the redirect, confirm that the feed remains reachable before the plan or account changes.

How to confirm subscribers have continuity

Subscriber continuity is not proven by one successful import. Use several checks:

  1. Subscribe to the new feed with a test account and download a new episode.
  2. Open a previously subscribed show through an existing app and confirm that its feed source has updated or redirects successfully.
  3. Check that the latest episode appears with the correct title, artwork and publication date.
  4. Play several older episodes, including the oldest imported item.
  5. Verify that episode GUIDs match the pre-migration export.
  6. Watch for duplicate listings across apps and directories.
  7. Ask a small number of real listeners to confirm that they received the first new episode.

Your own subscription may be the least revealing test because you know which feed you requested. A listener or app that still uses the saved old URL is more useful for testing the redirect.

When should you update Apple Podcasts directly?

The answer depends on who controls the feed and how the move is implemented.

If a third-party host owns the old feed, it may be able to configure the redirect on your behalf. If you host the feed yourself, Apple’s current instructions call for an HTTP 301 redirect and a new-location tag in the new feed. You may also need to update the RSS feed URL in Apple Podcasts Connect.

Do not confuse Apple’s “Mirror URL” with a feed replacement, and do not assume that changing the stored URL alone protects subscribers outside Apple. The old public feed address still needs to redirect wherever you or the old host control it.

Common podcast migration mistakes

Publishing from both hosts

This can create duplicate episodes and confuse the relationship between the old feed and the new one. Choose one publishing source before releasing the first post-migration episode.

Replacing episode GUIDs

A GUID identifies the episode, not merely the file. Preserve it unless the source feed never had a stable identifier and you have planned the change carefully.

Confusing a website redirect with an RSS redirect

A feed request must resolve to the new feed. A branded “podcast moved” page is not a substitute for a permanent redirect response.

Closing the old account too soon

Directories and apps do not all refresh on the same schedule. Keep the old redirect and service available long enough for the migration to settle.

Ignoring private feeds and special episode types

A public feed migration may not migrate subscriber access, private links, dynamic ad insertion, member-only content or trailer/bonus rules. Test these separately.

Validating only the newest episode

The oldest imported episode, numbered episodes and special items often reveal broken links or incorrect mapping.

Treating download totals as subscriber counts

Analytics definitions and reporting periods vary. Use the figures for continuity checks, not as a precise count of people who have re-subscribed.

A copyable migration record

Use one document to coordinate the move:

Podcast:
Migration owner:
Old host:
New host:
Old RSS URL:
New RSS URL:
Migration start date:
First new episode scheduled:
Redirect owner/contact:
Redirect live date:

Backup location:
RSS XML backed up: Yes / No
Audio files backed up: Yes / No
Metadata spreadsheet backed up: Yes / No

Show metadata checked: Yes / No
Episode count before:
Episode count after:
Oldest episode checked: Yes / No
Newest episode checked: Yes / No
GUIDs preserved: Yes / No
Audio URLs checked: Yes / No
Private or paid episodes checked: Yes / No

New feed validated: Yes / No
Validation result attached: Yes / No
Old feed returns 301: Yes / No
New-location tag checked: Yes / No
Directory listings checked: Yes / No
Website and player links checked: Yes / No

Rollback owner:
Old account cancellation date:
Final acceptance date:

Frequently asked questions

How long should the old podcast feed stay active?\n

Apple’s current guidance for self-hosted feeds is to maintain the redirect and new-location tag for at least four weeks. A creator with a large or slow-refreshing catalogue may want a longer window. Keep the old service active for that period and confirm the redirect remains in place before closing anything.

Will a 301 redirect automatically resubscribe everyone?\n

No. The redirect tells software that requests the old feed where the permanent new location is. Applications may update automatically, but some may take time, refresh on their own schedule or require a manual action. Test existing subscriptions and directory listings rather than assuming every listener has already moved.

Should the old feed be deleted before closing the old host?

No. Delete or cancel the old feed too early and you lose the redirect signal. Keep it alive, confirm the permanent redirect, and close the old service only after your acceptance checks are complete.

Can you change episode titles and artwork during migration?\n

Technically possible, but it expands the scope of the move. Preserve identifiers and distribution-critical metadata first. Handle cosmetic changes only after continuity is established, unless an incorrect title or artwork must be fixed to represent the show accurately.

What should be migrated first?\n

Start with a complete backup and a metadata map. Then import, validate the new feed, establish the redirect and change the publishing source. The order matters because copying files first does not protect subscribers if the feed and publication paths remain ambiguous.

The bottom line

A safe podcast host migration is a controlled change of authority, not just a transfer of files. Preserve episode identifiers, validate the new feed, redirect the old URL with a permanent response, publish from one host only, and keep a rollback path until the audience and directory checks are complete.

If you are also preparing episode material after the move, our guides on creating podcast chapters and preparing a mid-roll ad break can help you keep publishing materials portable and consistent.

Sources