Podcast Audit: Dead Episodes & Feeds That Look Fresh

A podcast directory records a feed URL once and points listeners at it forever. Nobody goes back to ask whether that feed still answers, whether its episodes still play, or whether the show has published anything since.

This checks. Give it Apple Podcasts show ids, a chart, or a random sample of the directory, and it reports what the feed actually delivers today against what the listing implies.

Pay per event: $0.00005 per run plus $0.002 per feed checked (in effect since 4 August 2026). No key, no login, and nothing is downloaded that a podcast app would not fetch.

What it looks for

Episode audio that is gone. The enclosure URL is still in the feed, the episode is still listed, and the file answers 404. Measured across 588 episodes: 0.5%.

Shows that only look active. <lastBuildDate> is written by the hosting platform, not by the publisher, so a show that stopped three years ago keeps a build date from this morning. 14.2% of a 300-show sample carried a build date more than a year ahead of their newest episode. Anything reading that field — which is most things — calls those shows active.

Feeds that died or moved. A feed URL that answers 404, that has moved to another host, or that declares a new home in <itunes:new-feed-url> the directory never picked up. Episodes published to the new address never reach the old subscribers.

Owner addresses that cannot receive. The <itunes:owner> email is where Apple Podcasts and Spotify send ownership verification. This reports whether that domain is registered at all, and whether it is shaped to receive mail. In a 300-show sample not one was unregistered, which is the honest answer: this is rare, and it is reported because when it is true it matters, not because it is common.

The show's own website, followed to wherever it ends up.

What makes this different

Fourteen podcast actors on the Store were read before this one was written. Every one of them extracts: episodes, metadata, host contacts, transcripts, chart positions. One of them extracts audio URLs.

None of them checks whether any of it still works.

Inputs

Give it shows in whatever form you have them — 1200361736 or https://podcasts.apple.com/us/podcast/the-daily/id1200361736. Or a chart name (top) to survey what is currently being listened to. Or a sample size, to draw shows at random from the sitemaps Apple advertises and measure a slice of the directory itself.

episodesFromEachEnd picks episodes from both ends of the feed. The newest is what a listener presses first. The oldest is where rot appears years earlier — a back catalogue quietly stops playing long before the current episode does.

Severities, and what each one cost to set

Every threshold came from measuring 300 shows drawn from Apple's own sitemaps in August 2026. A symptom that appears on a fifth of healthy shows is not a warning.

Finding	Severity	Why there
feed_dead	critical	0.7% of shows. The directory is sending new subscribers to nothing.
feed_domain_unregistered	critical	Whoever registers the name decides what every current subscriber receives next.
owner_domain_unregistered	critical	Ownership verification mail goes to an address anyone could arrange to receive.
episode_audio_dead	high	0.5% of 588 episodes. Rare enough to mean something.
feed_unreachable, owner_mail_undeliverable (no DNS)	high	The name is still held, so it is not open to anyone — but nothing arrives.
dormant_years (5+)	medium	5.8% of shows.
new_feed_url_ignored, block_requested_but_listed	medium	The publisher said something and the directory did not act on it.
dormant_years (2+), looks_fresh_but_dormant, feed_moved_host	low	18.6%, 14.2% and 1.7%. Common enough to be context.
feed_blocked, episode_audio_blocked	low	A server refusing us is not a dead link.
episode_audio_undetermined	low	Reported so the run's own blind spots are visible.

Three things are measured and never reported as faults, because measuring showed how ordinary they are: 14.6% of shows publish no owner address, 30.5% use a free mail provider, and 98.6% have a website — so its absence says nothing.

What it will not do

It does not pretend to be a listener. Most large podcasts serve audio through a per-listener redirect service that stitches in advertising, and those services answer an automated request with 404 Missing redirect URL. That is not a dead episode. Six of the nine shows with apparently-dead audio in the first 300-show sample were on one such platform, and every one of them was publishing that week. They are reported as episode_audio_undetermined with the host's own words quoted, and the report says plainly that whether the audio is there could not be established.

It does not run keyword searches. itunes.apple.com/robots.txt names /search*. Apple's public chart feeds and the sitemaps podcasts.apple.com/robots.txt advertises cover the same need, so those are read instead.

It does not touch a mail server. The owner address is checked against DNS only — is this domain registered, does it resolve, does it publish a mail exchanger. Whether a particular mailbox exists cannot be asked without bothering a stranger's server.

It does not download audio. HEAD answers whether the file is there. A host that refuses HEAD is asked for a single byte.

It does not guess at registration. .io, .co, .jp and others publish no RDAP service, so no registry can be asked. Those come back unknown, never "free" — the most damaging thing this Actor could get wrong is telling you a domain is available when it is not.

It does not tell you why. Apple returns the same empty answer for a show that was removed and one that never existed. A feed that 404s may be a migration in progress. The finding says what was observed.

Output

One row per show, with the directory record, what the feed said, the episode probes, and the findings.

Three key-value records alongside it:

• SUMMARY — counts by severity and by finding, the query, the method, and the base rates the severities were set from
• ACTION_LIST — findings ranked, worst first
• CUSTODY_REPORT — the domain and owner-address questions on their own, with an explicit note about what unknown means

Notes on accuracy

The redirect chain behind a podcast enclosure is longer than it looks: pdst.fm → clrtpod.com → pscrb.fm → prefix-v4.pscrb.fm → dts.podtrac.com → the host → the CDN → the file. Seven hops, for an episode published this week and playing fine. This Actor follows twelve. An earlier version stopped at five and called 7.8% of healthy episodes broken — which is how that number is known.

A connection failure is retried once before it is reported. One bad second on this end is not evidence about someone else's episode.