Podcasting’s Missing Link

Podcasting is an internet-born medium that never really grew up on the web. Most episodes have a canonical URL, but nobody sends listeners there. Everyone understands that the browser isn’t where podcasts happen. Your podcast app is. That fact has shaped everything about how podcasts grow and get discovered. As Nathan Baschez put it:

With text-based websites, RSS was/is an optional step at the bottom of the funnel. You’d visit a link (via search engines, email, etc) and read an article, and if you get really into it, you might add that site to your RSS reader (if you even used one). But with podcasts, RSS is the whole thing. Podcast apps are more analogous to “web browsers for audio” than text-based RSS readers, because they are the beginning and end of pretty much all podcast discovery and consumption.

Browsers for audio

If podcast apps are browsers, feeds are sites, and episodes are articles, then podcasting has been running on a web that never faced the evolutionary pressures of the actual web. Search engines, social feeds, and algorithmic recommendation forced websites to constantly adapt or die. YouTubers have lived through this acutely. They’ve shifted from long-form to short-form and back, chased algorithm changes, pivoted formats to stay visible. Their livelihoods rise and fall with the platform’s whims.

The discovery gap

Podcasting content hasn’t blown in those same winds. Most podcast apps don’t have algorithmic feeds, so creators were insulated from the boom-and-bust cycles that define life on YouTube. A podcaster’s audience subscribes directly via RSS. No algorithm decides whether to surface the latest episode. That stability is real, but it came with a cost: podcasting never had to build the discovery infrastructure that the web developed under competitive pressure.

Which brings us to the actual problem: podcast apps lack basic tools to help shows find new listeners. Think about the simplest case, one show recommending another. The best a host can do today is say “find it wherever you get your podcasts” and hope the listener follows through. That’s a leaky funnel. The listener has to remember the name, open their app, search for it, find the right show, and hit subscribe. Every step is a chance to lose them.

Other federated ecosystems don’t work like this. Tap a Mastodon link inside a Mastodon app and it opens natively. You don’t get bounced to a browser showing a webpage with a list of ActivityPub apps. The app understands the link. Podcast apps could do the same, but they don’t.

Apple’s head start

Apple is already partway there with a great new feature called Timed Links. Apple Podcasts has been leaning into chapters and timed metadata, and Timed Links take that further: they surface links on the Now Playing view, transcript view, and a “From This Episode” section below the show notes. When a host mentions another podcast, Apple Podcasts can detect the reference and link directly to that show. It’s the behavior you’d want from every podcast app.

The catch is that Timed Links only work within Apple’s ecosystem. The links point to Apple Podcasts pages. If a podcaster links to a show’s Spotify page or personal website, Apple’s detection doesn’t recognize it. It encourages podcasters to include Apple Podcasts links over alternatives, which isn’t ideal for listeners in other apps. It’s a closed-loop version of an idea that should be an open standard. So what would it take to build one?

Teach apps to recognize podcast links

Podcast apps need to tell podcast links apart from ordinary web links. Many RSS readers already crawl URLs looking for a <link rel="alternate" type="application/rss+xml"> tag to detect feeds behind webpages. Podcast apps could do the same thing, plus one extra check: does the discovered feed contain <enclosure> tags? If so, it’s a podcast.

The nice thing about this approach is that it works around feed generators rather than depending on them. Don’t count on every hosting platform adding some new tag. Put the intelligence in the podcast app instead. Every link in a show’s notes and chapters could be quietly crawled in the background. When one points to a page that advertises a podcast feed, the app could offer to open it natively: subscribe, preview, or play. No bouncing the listener out to a browser.

Meet podcasters where they are

None of this works if it requires podcasters to change what they’re already doing. You can’t convince everyone to adopt a new URL scheme or append special parameters. They link to what’s convenient: a Spotify URL, a Podlink page, etc., not just feed-backed homepages. It should work for individual episodes too. Every podcast reference, however it’s formatted, should be a potential in-app destination.

Use the metadata that already exists

We don’t need to invent new metadata standards for this. Schema.org already defines types for PodcastEpisode and PodcastSeries. Many hosting platforms and directories already embed this structured data in their pages. A podcast app that crawls a link and finds Schema.org podcast metadata has everything it needs to act on it: show title, episode title, audio URL, feed URL.

Schema.org metadata, RSS feed discovery, and platform URL matching give apps three overlapping ways to identify podcast content on the open web. None of them require podcasters to do anything differently.

Bare-bones show example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "PodcastSeries",
  "webFeed": "https://examplepod.com/feed.xml"
}
</script>

Bare-bones episode example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "rss:guid",
    "value": "01HZA1J3N3T9X4E6K2P5VZWB3M"
  },
  "isPartOf": {
    "@type": "PodcastSeries",
    "webFeed": "https://examplepod.com/feed.xml"
  }
}
</script>

Podcasting’s separation from the web has mostly been a good thing for creators. But it also means the ecosystem never built the connective tissue that the web takes for granted. Hyperlinks are the web’s most basic technology, and podcast apps still can’t follow them. The pieces to fix this are already out there. What’s missing is someone putting them together.