Why you can't link to a podcast episode

Workbench
1

The inability to reliably link to specific podcast episodes represents a fundamental failure of the podcasting ecosystem to provide what the web has had since its inception: stable, universal hyperlinks. This analysis examines why the problem exists, what solutions have been attempted, and what—if anything—could actually fix it.

This is a coordination problem compounded by platform economics that actively discourage interoperability. This is not primarily a technical problem. The technical pieces exist.

(If you’re reading on https://forum.podcaster.community/ note that there is a table-of-contents for this topic enabling you to jump to sections easily.)

Part 1: The Anatomy of the Problem

A Specific Case: The Vanishing Episode

An attempt to link to the July 2015 Seth Godin episode of The Moment with Brian Koppelman reveals multiple failure modes at once:

  1. The hosting platform page died: The Cadence13 URL shows.cadence13.com/podcast/themomentwithbriankoppelman/episodes/... no longer resolves. The show’s RSS feed is now at feeds.megaphone.fm/themomentwithbriankoppelman, suggesting a hosting migration where the old web presence was abandoned.

  2. No stable identifier followed the episode: Even if someone had the episode’s original GUID from the RSS feed, there’s no universal service that maps “this GUID” → “here’s where you can listen to it now.”

  3. Platform-specific links require choosing sides: You can find the show on Apple Podcasts, but linking there assumes your reader uses Apple’s ecosystem.

Why This Matters Beyond Convenience

Podcasts are built on RSS—the same open standard that powered the blogosphere. Yet while blog posts remain linkable (and archivable via the Wayback Machine), podcast episodes exist in a strange limbo:

  • The audio file URL may change when hosting platforms migrate
  • The episode’s web page may vanish when hosts restructure their sites
  • Platform-specific links assume a platform your reader may not use
  • Third-party aggregator links add dependencies that can themselves fail

The result: anyone writing about podcasts—journalists, bloggers, show notes authors—is forced to say “go search for it” rather than providing a direct link.

Part 2: The Current Landscape of Solutions

2.1 Universal Link Aggregators

Pod.link
Created by Nathan Gathright out of frustration that the industry wasn’t solving this problem. Pod.link works by:

  • Taking an Apple Podcasts ID or base64-encoded RSS feed URL
  • For episodes: appending /episode/<base64-GUID> or /episode/<MD5-GUID>
  • Presenting a landing page with buttons for multiple platforms

Strengths: Works today, supports episodes, no podcast-side implementation required.
Weaknesses: Another intermediary that can fail; relies on being able to construct the GUID-based URL; some platforms don’t provide APIs to verify episode availability.

Podnews Player Pages
James Cridland’s approach uses Apple Podcasts IDs to create persistent URLs like podnews.net/podcast/814550071. The system:

  • Queries Apple’s API for podcast data
  • Provides device-aware app buttons (no Apple Podcasts button on Android)
  • Includes a web player for immediate listening
  • Supports QR codes for physical-to-digital bridging

Strengths: Device-aware, includes web playback, stable URLs based on Apple IDs.
Weaknesses: Depends on Apple’s index as the primary key; episode-specific linking less prominent.

Plink
Similar to pod.link, provides show-level and episode-level smart links that route to platform-specific destinations.

2.2 Platform-Specific Deep Links

The landscape documented by Nathan Gathright’s podcast-platform-links repository:

Platform URL Scheme Episode Support
Apple Podcasts podcast://podcasts.apple.com/.../id?i=episodeId Yes, via ?i= parameter
Spotify spotify:episode:episodeId or open.spotify.com/episode/id Yes, via Spotify’s internal ID
Overcast overcast.fm/+code or overcast:// Yes, via proprietary encoding
Pocket Casts pktc://subscribe/feedURL Feed-level only
Castro castros://subscribe/feedURL Feed-level only
Podcast Addict podcastaddict://feedURL Feed-level only

The fragmentation problem: Each platform uses its own ID system. Spotify’s episode ID bears no relation to Apple’s, which bears no relation to the episode’s RSS GUID. There’s no universal “episode ID” that works everywhere.

The iOS lock-in problem: Apple claimed the pcast:// URL scheme in 2012 when they launched Apple Podcasts, preventing third-party apps from registering as handlers. Unlike default browsers and email clients, Apple has never allowed users to set a default podcast app.

2.3 The Podcasting 2.0 / podcast:guid Approach

The Podcasting 2.0 initiative added <podcast:guid> to the RSS namespace—a UUIDv5 generated from the RSS feed URL using a standard namespace (ead4c236-bf58-58c6-a2c6-a6b28d128cb6). The intent:

  • A podcast gets one GUID for life, even if the feed URL changes
  • New hosts should discover and preserve the GUID during migrations
  • Enables “fast-follow” share links: https://example.com#fastfollow-podcast:guid

Adoption statistics (per Podcasting 2.0 documentation):

  • 14 podcast apps support it
  • 23 hosting platforms implement it
  • All podcasts in Podcast Index have assigned GUIDs

However, James Cridland’s February 2025 analysis is blunt:

“The podcast:guid should be a great idea. In reality, it doesn’t work.”

Problems he identifies:

  • Dependency on Podcast Index: There shouldn’t be dependency on any service to run a GUID lookup, especially a volunteer-run one
  • Inconsistent host implementation: Some hosts issue new GUIDs on migration (defeating the purpose), accept arbitrary values, or issue the same GUID for every podcast on their platform
  • Most hosts don’t support it anyway

Note: podcast:guid is for podcasts (feeds), not individual episodes. Episode identification still relies on the standard RSS <guid> element, which has its own problems (often just the enclosure URL, which changes during migrations).

Part 3: Why Existing Solutions Fail

3.1 The Link Rot Problem

Every solution that involves a third party introduces a point of failure:

  • Hosting platform web pages: The Cadence13 example. Hosts change, restructure, or go out of business. The Megaphone RSS feed survives; the Cadence13 web presence doesn’t.

  • Aggregator services: Pod.link is one person’s side project. Podnews is James Cridland’s work. What happens if they stop maintaining them? (Cridland notes that pod.link had to switch payment processors when Plasso shut down.)

  • Platforms themselves: Google Podcasts shut down in 2024. Every podcasts.google.com link is now broken. Listeners were migrated to YouTube Music, but links weren’t redirected.

3.2 The Identification Problem

There’s no universally-adopted, universally-respected episode identifier:

Identifier Problem
RSS <guid> Often just the enclosure URL; changes when hosts migrate; not enforced to be stable
Enclosure URL Changes during host migrations; is the audio file, not metadata
Apple episode ID Proprietary to Apple; only works for shows in Apple’s index
Spotify episode ID Proprietary to Spotify; unrelated to RSS data
Overcast episode code Proprietary encoding; Overcast-specific

The RSS specification says the GUID “should never change,” but there’s no enforcement. Hosts that say they’ll “migrate your feed” often fail to preserve GUIDs, causing duplicate episode downloads for subscribers and breaking any GUID-based linking.

3.3 The Platform Economics Problem

This is the elephant in the room. Spotify, Apple, YouTube, and Amazon don’t want universal podcast links:

  • Lock-in is a feature: If listeners must search within their app, they stay in that app
  • No incentive to interoperate: Spotify gains nothing by making it easy to link people to Apple Podcasts
  • Exclusives break the model entirely: Spotify exclusives don’t exist in RSS at all

The platforms with market power have no incentive to solve this. The open podcasting ecosystem (independent apps, RSS-based players) lacks the coordination to force a solution.

3.4 The Back-Catalog Problem

Even if a perfect solution emerged tomorrow:

  • Old episodes wouldn’t magically get stable identifiers
  • Hosts that have already broken GUIDs during migrations can’t unbreak them
  • Episodes from defunct shows may not be in any current index

Part 4: What Would a Robust Solution Look Like?

4.1 The Browser Extension Approach

Concept: A browser extension that intercepts podcast links and offers to open them in the user’s preferred app.

How it could work:

  1. User installs extension, sets preferred podcast app
  2. Extension recognizes podcast URLs (Apple, Spotify, pod.link, etc.)
  3. Attempts to extract episode identifier (GUID, title, show+date)
  4. Redirects to preferred app via that app’s URL scheme

Limitations:

  • Only works in browsers, not when links are shared via messages/social apps
  • Requires the extension to understand every podcast URL format
  • Can’t work for platforms like Spotify that don’t expose RSS data
  • Doesn’t solve the “which episode is this” identification problem

4.2 The Registry/Redirect Service Approach

Concept: A canonical registry where episodes get permanent URLs that redirect to current locations.

How it could work:

  1. Service indexes episodes from RSS feeds and platform APIs
  2. Assigns permanent URLs based on stable identifiers (UUIDv5 of show+episode GUID)
  3. Maintains redirect mappings as hosting changes
  4. Optionally provides a web player fallback

This is essentially what pod.link and Podnews do, but with limitations:

  • Single point of failure (who runs the registry?)
  • Can’t index Spotify exclusives or other walled content
  • Requires ongoing maintenance as platforms change their URL structures
  • Authority problem: who decides the canonical version?

4.3 The Standards Adoption Approach

Concept: Get the ecosystem to actually implement existing standards consistently.

What would need to happen:

  1. All podcast hosts properly implement and preserve podcast:guid for shows
  2. Industry agrees on a podcast:episodeGuid that’s a proper UUID, not just the enclosure URL
  3. Major platforms (Apple, Spotify) agree to support lookup by these GUIDs
  4. Apps agree on a URL scheme (podcast://) that the OS allows users to route to their preferred app

Why this probably won’t happen:

  • Platform incentives oppose it (see 3.3)
  • Apple would need to allow default podcast app selection (they haven’t for 12+ years)
  • Requires coordination among competitors
  • Podcasting 2.0 has tried this; adoption remains inconsistent

4.4 The Pragmatic Hybrid Approach

What might actually work, given real-world constraints:

  1. For linking to episodes: Use pod.link or similar, accepting the dependency risk. Include enough metadata (show name, episode title, date) that readers can find it if the link breaks.

  2. For archival purposes: The Internet Archive’s Wayback Machine captures some podcast web pages. Archive.org’s podcast collection preserves some audio.

  3. For your own show notes: Link to your own website’s episode pages if you have them, since you control that domain. Use RSS GUIDs that are true UUIDs, not enclosure URLs.

  4. For referencing others’ work: Provide multiple links (Apple, Spotify, web) or use a smart-link service, and include enough identifying text that the episode is findable via search.

Part 5: Trade-Off Analysis

Approach Solves Deep Linking? Solves Link Rot? Depends on Third Party? Works for Back-Catalog? Adoption Barrier
Pod.link/Plink Mostly No Yes Limited Low
Podnews pages Partially No Yes Limited Low
Platform-specific links Yes No Yes (platform) Yes Low
podcast:guid standard Not for episodes Possibly Yes (Podcast Index) No High
Browser extension Partially No No Yes Medium
Canonical registry Yes Possibly Yes Potentially Very High
Multiple redundant links Partially Partially Distributed Yes Low

Part 6: Conclusions

What’s Actually Solvable

  1. Show-level linking is mostly solved by pod.link, Podnews, and similar services—with the caveat that these are dependencies.

  2. Episode-level linking works today via pod.link’s GUID-based URLs, but requires:

    • Knowing the episode’s RSS GUID
    • The GUID being stable (often not guaranteed)
    • Pod.link remaining operational

  3. Platform-specific linking works well if you’re willing to choose a platform for your readers.

What’s Probably Not Solvable

  1. True universal deep links that work like web URLs—open in the reader’s preferred app without friction—would require Apple to allow default podcast app selection and major platforms to agree on identifier standards. There’s no business incentive for this.

  2. Permanent, decay-proof links are fundamentally at odds with how podcast hosting works. Hosts go out of business. Platforms shut down. URLs change.

  3. Back-catalog stability for shows that have already been through multiple host migrations with broken GUIDs.

Honest Recommendations

For writing about podcasts today:

  • Use pod.link for episode links where possible
  • Include show name, episode title, and date in your link text so the episode is findable if the link breaks
  • Consider multiple platform links for important references
  • Accept that some friction is unavoidable

For the podcast industry:

  • The Podcasting 2.0 effort is directionally correct but needs better adoption incentives
  • A well-funded, independent registry service (like DOI for academic papers) could help, but would need sustainable funding and industry buy-in
  • Apple allowing default podcast apps would unlock URL scheme solutions

For the specific case (The Moment with Brian Koppelman, Seth Godin, July 2015):

  • The show is on Apple Podcasts: podcasts.apple.com/us/podcast/id814550071
  • The RSS feed is at: feeds.megaphone.fm/themomentwithbriankoppelman
  • Pod.link page: pod.link/814550071
  • The specific episode would need its GUID extracted from the feed to construct a pod.link episode URL

Sources

Universal Linking Services

Podcasting 2.0 and Standards

Platform-Specific Linking

RSS and Feed Standards

Platform Changes and Failures

2

This morning I was spun off on a tangent. I was writing a blog post (not yet published) about that Godin/Koppelman episode. I know full well you cannot link to episodes, so I just said the usual “go search…”

I sometimes give my blog post drafts to Claude.ai for critique. For this piece, it pointed out I should just link to the episode… cue my frustration. It’s a valid critique, and I don’t fault that Claude for not understanding the reality . . .

So we talked about it until it did understand. Then I told it to write me a prompt (because I didn’t want my writing critique to go farther afield away from being a writing critic) for a Claude-code instance…

View the actual prompt

Project: Podcast Episode Deep Linking — Problem Analysis and Solution Exploration

The Problem

There is no reliable way to link someone to a specific podcast episode such that it opens in their preferred podcast player. This is a real friction point for anyone who writes about podcasts, recommends episodes, or creates show notes that reference other people’s work.

Specific Example

I wanted to link to a specific episode of The Moment with Brian Koppelman — his July 7, 2015 conversation with Seth Godin. Here’s what I found:

  1. No universal scheme exists. There’s no podcast:// URI that would open a listener’s preferred app and navigate to this episode.

  2. Platform-specific links are fragmented. I can link to Apple Podcasts, Spotify, etc. — but that assumes the reader uses that platform, and forces a choice on them.

  3. Podcast hosting platform pages are unreliable. A web search surfaced this URL for the episode page:
    https://shows.cadence13.com/podcast/themomentwithbriankoppelman/episodes/1aee9c04-e485-481f-b4a2-aee0141a7e81

    That page no longer exists. “Safari Can’t Find the Server.” The URL was indexed when it worked; now it’s a 404. This is the current podcast host for the show.

  4. Third-party aggregator links also decay. Services that attempt to solve this problem (pod.link, Podnews, etc.) add another layer of indirection that can break when they change or shut down.

  5. The pragmatic workaround is friction. The current reality is: “Everyone knows to just whip out their favorite app and hit search.” That works, but it’s friction — and it means anyone writing about podcasts can’t actually link to what they’re recommending.

Why This Matters

Podcasts are a web-native medium built on RSS, yet they lack the basic hyperlinking capability that makes the web work. Blog posts, articles, and show notes that recommend podcast episodes are reduced to saying “go search for it” rather than linking directly. This:

  • Reduces discoverability
  • Creates friction that loses listeners
  • Makes podcast recommendations second-class citizens compared to linking a YouTube video or article
  • Frustrates podcasters who maintain good practices (like setting episode URLs in their RSS feeds) because there’s no reliable way to leverage that work

What I Want From This Project

  1. Research the current landscape. What solutions exist? (pod.link, Podnews player pages, Apple/Spotify deep links, the podcast:guid namespace in Podcasting 2.0, etc.) What are their failure modes?

  2. Analyze the RSS/namespace angle. The Podcasting 2.0 initiative added the <podcast:guid> tag for globally unique episode identification. Is this actually adopted? Could it be leveraged for deep linking?

  3. Explore what a robust solution might look like. Is this a browser extension problem? A registry/redirect service problem? A standards adoption problem? Some combination?

  4. Document the trade-offs. Any solution that relies on a third party introduces a point of failure. Any solution that relies on adoption won’t work for back catalogs. Be honest about what’s actually solvable.

  5. Produce a written analysis I can reference, share, and potentially use as the basis for a blog post or podcast discussion about this problem.

Which I then handed off. It took Claude about 10 minutes to do the work you see above. I particularly LOVE :heart: its list of sources… there’s so much great reading there.

And its analysis actually surprised me. I had assumed this was a technical problem… it’s not.

There was a time when I’d make a web site, email people (eg James Cridland), and start trying to rally people into fixing something. But those days need to be behind me, I simply cannot take on another new thing.

My hope? Someone somewhere sees this topic. Learns something about the problem and gets energized to do something about it.

I love podcasting, but this isn’t a fight I can lead.

Maybe you can? :slight_smile:

ɕ