How to compare old and new podcast RSS feeds without breaking episode identity

Changing podcast hosts looks deceptively simple: import the show, inspect a few titles, set the redirect, and close the old account. The risky part is that a feed can look correct to a person while presenting a different set of episode identities to listening apps.

You can avoid most of that uncertainty with a small, repeatable comparison. The important idea is to test the migration twice:

1. compare the old and new feeds before setting the redirect; and
2. verify the redirect path before closing the old host.

This guide shows how to do both. It works with ordinary public RSS feeds and does not require host credentials.

1. Start with episode identity, not presentation

A title is editable. An audio file can move to a new CDN. Artwork and descriptions often change during a migration. None of those fields is a reliable primary key for deciding whether two RSS items represent the same published episode.

For podcast migrations, compare items by their <guid> values. Apple describes the GUID as the unique identifier for an episode and tells creators to preserve it even when metadata such as the title or enclosure URL changes. Apple also warns that changed GUIDs can lead to duplicate episodes or abnormal analytics after a move.

Build two maps:

oldByGuid[guid] = old episode
newByGuid[guid] = new episode

Then answer four deterministic questions:

• Does every old episode have a non-empty GUID?
• Does every new episode have a non-empty GUID?
• Is each GUID unique within its feed?
• Does every old GUID occur in the new feed?

Treat a missing old GUID or a duplicate GUID as a blocker. Do not explain it away because the titles match. A title match can support a manual investigation, but it cannot prove that a listening app will preserve episode identity.

If a legacy feed truly has no GUIDs, follow the directory and hosting-provider instructions for that specific show. Some systems may fall back to the enclosure URL, but changing hosts commonly changes that URL too. Do not silently invent replacement GUIDs during the comparison.

2. Separate migration blockers from review items

A useful report should not turn every difference into a red alarm. During a host change, some drift is expected:

• the enclosure hostname may change;
• artwork may be re-encoded or moved;
• descriptions may be normalized;
• feed-level metadata may be reformatted; and
• the new host may add provider-specific namespace elements.

Keep two classes of findings.

Block the redirect when an old episode identity is absent, a GUID is empty or duplicated, the destination feed cannot be parsed, or required recent audio is unreachable.

Review before redirecting when titles, descriptions, artwork, episode numbering, or enclosure URLs differ. Review findings may be intentional, but they should be visible instead of being buried beneath a single pass/fail label.

This separation makes the report useful to a host's support team. “Episode abc-123 is absent from the destination feed” is actionable. “The feeds are different” is not.

3. Check coverage in both directions

The most important set difference is:

missingFromNew = old GUIDs - new GUIDs

Those are previously published identities that did not survive the import.

Also calculate:

newOnly = new GUIDs - old GUIDs

New-only episodes are not automatically failures. They may be trailers or episodes published after the import began. Report them so the operator can explain the difference.

Compare the feed-level title, description, and artwork, plus episode and season numbers when the show uses them. Apple specifically advises creators to verify metadata, audio, and numbering during a host change. Keep these comparisons visible, but do not rank cosmetic drift above missing identities.

4. Probe recent audio without downloading the catalog

An enclosure URL in XML is only a claim that a media object exists. Test a bounded sample of recent episodes from the destination feed.

For each sampled enclosure:

1. request the URL with a short timeout;
2. follow redirects deliberately;
3. reject malformed or unsafe destinations;
4. confirm the final response is successful; and
5. record the path and status without downloading the full audio file.

A bounded sample is a preflight, not a full catalog guarantee. Say exactly how many URLs you tested. For example: “6/6 most recent enclosure URLs responded inside the probe boundary.” Do not convert that into “all audio works.”

The boundary matters operationally too. Fetching hundreds of large media files would be slow, expensive, and needlessly heavy on third-party infrastructure. A recent sample catches common import and CDN mistakes while keeping the check predictable.

5. Record the preflight before changing the route

Save a timestamped receipt before setting the old feed's redirect. At minimum, include:

• old and new source URLs;
• final URL reached for each source;
• comparison timestamp;
• episode count in each feed;
• preserved, missing, duplicate, empty, and new-only GUID findings;
• feed-level metadata differences;
• sampled enclosure results; and
• explicit test boundaries.

JSON works well because it can be archived, diffed, and attached to a support ticket. The receipt should not contain host credentials, listener data, or private-feed tokens. If either URL is private or secret-bearing, stop and use the host's approved workflow instead.

6. Verify the redirect as a separate second pass

After the destination feed passes preflight and the old host has installed the redirect, request the old feed URL again. Do not inspect only the final URL. Record every hop.

For a migration check, the chain should:

• contain at least one redirect;
• use permanent redirect statuses such as 301 or 308 for every hop;
• terminate at the intended new feed URL; and
• return a valid destination feed.

A chain like 301 → 302 → 200 reaches the destination but is not fully permanent. Report the temporary hop instead of collapsing the chain into “redirect works.” Also stop on loops, missing Location headers, excessive hops, or a destination other than the intended new feed.

Apple's host-migration guidance specifically describes a 301 redirect from the old RSS URL to the new one. Some hosts may also add <itunes:new-feed-url>, but you should still observe the actual HTTP route that clients receive.

Run the feed comparison again through the redirected old URL. Only then consider closing the old hosting account, subject to that provider's retention and migration instructions.

A compact manual checklist

Before redirecting:

• [ ] Both public feeds load and parse.
• [ ] Every old and new episode has a unique, non-empty GUID.
• [ ] Every old GUID exists in the new feed.
• [ ] New-only episodes are understood.
• [ ] Titles, descriptions, artwork, and episode numbering were reviewed.
• [ ] A declared recent enclosure sample is reachable.
• [ ] A timestamped receipt was saved.

After redirecting, before closing the old host:

• [ ] The old feed returns at least one redirect.
• [ ] Every redirect hop is permanent.
• [ ] The chain ends at the intended new feed.
• [ ] The destination still parses and preserves the expected GUIDs.
• [ ] The second receipt was saved with the first.

What this check does not prove

This comparison cannot guarantee when every podcast directory or listener app will refresh its cached data. It does not change the host, configure the redirect, certify a provider, or measure audience behavior. It is a bounded technical preflight that gives you concrete feed differences and a recoverable record before you remove the old route.

Sources

• Apple Podcasts for Creators: How to change hosting providers
• Apple Podcasts for Creators: Technical updates for hosting providers

Disclosure: I built Podcast Move Receipt by Arelvia Studio to automate this bounded comparison for two public feeds. It is a USD 39 one-time workspace; the checklist above works without it.