Schema Markup·4 min read

Podcast Structured Data Explained: Episodes and Series

Every podcast already publishes machine-readable data, it just publishes it to the wrong audience for search. Your RSS feed feeds Apple and Spotify; your website pages feed Google, and those pages are usually bare. This is podcast structured data explained for show owners: PodcastSeries and PodcastEpisode markup that describes your show and its installments on the pages that actually rank, with a worked example and the mistakes that make the effort pointless.

Open the tool All insights

Podcast structured data explained: schema on top of RSS

Why show websites stay invisible.

The typical podcast site is built fast: a homepage with a player, an episode page per installment, show notes pasted in. Traffic comes from the directories, and search contributes almost nothing, because to a crawler each episode page is an undifferentiated blob of text with an audio player it can't interpret.

Podcast markup changes what those pages declare. The show page states it's a PodcastSeries with a genre, a language, a publisher, and a feed. Each episode page states its number, its date, its length, and where the audio file lives. That's the raw material for search features and, more fundamentally, for Google understanding that a show exists here at all.

Episode vs series markup: PodcastSeries and PodcastEpisode

Two types, two page shapes.

The episode vs series markup split maps directly onto your site structure. PodcastSeries belongs on the show's home: name, description, cover image, genre, inLanguage, publisher as an Organization, and webFeed pointing at the RSS URL. It's the entity record for the show itself.

PodcastEpisode belongs on each episode page, carrying the episode number, datePublished, duration, author, and an associatedMedia node describing the audio file. The partOfSeries property ties every episode back to the series by name and URL, which is what lets a crawler assemble eighty scattered pages into one coherent show instead of eighty orphans.

Podcast RSS vs schema: two channels, two audiences

Not competitors, parallel outputs.

The podcast rss vs schema question confuses people because both carry the same facts. The difference is the consumer. RSS is a subscription protocol: directories poll it, ingest new episodes, and build their catalog entries from it. Search engines don't treat your feed as your website.

Schema is page-level description for crawlers. It can't get you into Apple Podcasts, and RSS can't tell Google what your episode page contains. A complete setup runs both from the same source data, and the webFeed property is the formal handshake between them, telling crawlers where the canonical feed lives.

There's a practical consequence for tooling: whatever generates your episode pages should emit the markup from the same fields that populate the feed. Duplicate data entry is how titles drift apart between the two channels, and drifting titles are how a show ends up looking like two shows.

A worked PodcastEpisode with audio and series link

Episode 41, fully declared.

For a freelancing show's pricing episode, the essential block reads: {"@type": "PodcastEpisode", "name": "Episode 41: Pricing Freelance Work", "episodeNumber": "41", "associatedMedia": {"@type": "MediaObject", "contentUrl": "https://cdn.example.com/ep41.mp3"}, "partOfSeries": {"@type": "PodcastSeries", "name": "The Solo Desk"}}.

The Podcast Schema Generator fills in what this fragment omits: a datePublished assembled from date, time, and timezone with a live ISO 8601 preview, a duration, the author and publisher nodes, and the encodingFormat inside the MediaObject, which it infers from the file extension so an .mp3 automatically carries audio/mpeg.

Tips for podcast markup that stays accurate

Automate or it rots.

Template the episode block into your CMS so every new installment ships marked up from the data you already enter, because hand-pasting JSON per episode fails by episode twelve. Keep the series name and URL in partOfSeries byte-identical across all episodes; small variations split the show into multiple weak entities.

And point contentUrl at the permanent audio file, not a redirecting tracking URL that may break or get blocked for crawlers.

Duration deserves the same discipline as dates. Publish it in ISO 8601 form, PT44M for a forty-four minute episode, and take the value from the exported file rather than the planned runtime. A crawler that finds consistent, accurate durations across an archive has one more reason to trust everything else those pages declare.

Podcast schema mistakes that undercut the effort

Seen on real show sites.

The recurring problems:

Series markup pasted onto every episode page, drowning the episode data it should complement.
No associatedMedia node, describing an episode while hiding the one thing that makes it audio.
datePublished in a local date format instead of ISO 8601 with an offset.
Episode numbers that restart per season without any season context, producing five different episode ones.
A webFeed URL pointing at an old host's feed that now redirects.

Podcast Schema Generator next to the related generators

When the format shifts.

Video-first shows published with full episodes on your site should consider the VideoObject Schema Generator for those pages, since video rich results are more mature than podcast treatments. Long written show notes that stand alone as articles can carry markup from the Article Schema Generator alongside the episode block.

And for an episode archive page listing the whole back catalog, the ItemList Schema Generator structures the list itself while individual pages keep their episode markup.

Try it now

Open Podcast Schema Generator

The tool is one click away. No sign up, no upload, no payment.

Open Podcast Schema Generator

Write a review