Schema Markup for Podcast Pages

Google killed the podcast player in Search when it shut down Google Podcasts, then killed the FAQ rich result on May 7, 2026, so the two visible rewards for marking up an episode page are both gone. We edit and publish every episode for a book of 50+ B2B companies and we still ship the markup on every page. Below, the 5 schema types an episode page needs, the JSON-LD you can copy, and why the reader you are writing it for stopped being a search results page.

What Is Podcast Schema Markup, and What Does It Do Now?

The reason this article exists is that almost every guide on the subject was written for a payoff that does not exist anymore. The pitch used to be simple. Mark up the episode, get a player in the search results, collect the click. Google Podcasts shut down on April 2, 2024 and moved its listeners to YouTube Music, and the search surface it fed went with it.

Then the second payoff went. Google stopped showing FAQ rich results on May 7, 2026, removed the reporting for them in June, and cut API support in August. The guidance was that the markup causes no problems if you leave it in place, it simply produces no visible result in Search. Read plainly, that is Google saying the code is fine and the reward is gone.

So the honest question is why anyone should still do this. The answer is that the markup was never really for the SERP feature. It was for machine comprehension, and the number of machines reading pages for comprehension went up sharply at the exact moment the visible rewards went away.

Podcast schema markup

Structured data, almost always JSON-LD, that declares what a podcast page is using the schema.org vocabulary. PodcastSeries describes the show. PodcastEpisode describes one episode and links back to the series. Supporting types cover the audio or video file, the guest, and the breadcrumb path. It is a description of the page written for machines, placed in the head, and never shown to a human reader.

The schema.org types themselves are alive and in active development. The PodcastEpisode type is still listed in the pending area of the vocabulary, which is schema.org's way of saying implementation feedback is still shaping it. Nothing about it was retired. What was retired was one search feature that happened to consume it.

That distinction matters because it changes what you write the markup for. If the goal is a player in the results page, the work is dead. If the goal is that a system assembling an answer about supply chain software can tell that your page is a 47 minute interview with a named operations director at a named company, the work just got more valuable, because that is now where a growing share of the research happens.

Why Ship It If Google Removed the Rich Result?

Because the pool of pages that get pulled into answers is wider than the pool of pages that rank, and legibility is how you get into it.

Ahrefs studied 863,000 keyword SERPs and 4 million AI Overview URLs and found that only 38% of pages cited in AI Overviews also rank in the top 10 for the same query. Roughly 31% ranked between positions 11 and 100, and another 31% did not rank in the top 100 at all. A third of what gets cited is coming from pages that are nowhere near the top of the results page.

Take those first 2 numbers seriously and the ranking game and the citation game have partly come apart. A page can get pulled into an answer on the strength of the passage rather than the authority of the domain. An episode page carrying a cleaned transcript of a named expert answering direct questions is close to the ideal shape of that passage, and the markup is what tells a crawler that is what it is looking at rather than a blog post with an audio file glued on.

The third number is why it matters commercially. Gartner's research on the B2B buying journey puts the time a buying group spends with any single vendor at roughly 5% of total buying time. The other 95% is research you are not present for, conducted through whatever evidence about you exists in public. Structured data is not the evidence. It is the label on the evidence, and unlabeled evidence gets skipped.

There is a second, quieter argument. Schema is one of the few things in this field that is deterministic. Copy changes are a guess, ranking is a guess, and whether a given engine cites you next month is a guess. Whether your episode page validates as a PodcastEpisode tied to a PodcastSeries is a fact you can check in 30 seconds. We took the same position on an llms.txt file for B2B companies, which is cheap, deterministic, and mostly unclaimed.

If you are new to the split between the old game and the new one, GEO vs SEO differences explained is the starting point, and why AI answers cite some companies and not others covers how the selection actually happens.

What Schema Types Does an Episode Page Need?

Five, and a sixth that is optional but usually worth it.

1. PodcastEpisode. The type of the page itself. Carries the episode name, the description, the publish date, the duration, and the canonical URL. This is the one that says the page is an episode rather than an article.
2. PodcastSeries, through partOfSeries. Every episode points back at the show. This is the property that builds a series out of a pile of unrelated pages, and it is the most commonly skipped one on shows that publish episodes as blog posts.
3. AudioObject or VideoObject, through associatedMedia. Points at the actual media file with its content URL and encoding format. If you publish the episode as video, use VideoObject and follow the video documentation, because video is the one podcast surface where Google still ships a visible result.
4. Person, for the guest. Name, job title, the organization they work for, and a sameAs link to their LinkedIn or company page. This is the property that turns a transcript into a documented statement by a specific real expert.
5. BreadcrumbList. Home, then the show, then the episode. Cheap, and it tells a crawler that the episode sits inside a structured section of the site rather than floating loose.
6. FAQPage, optional. When the episode answers 3 or 4 named questions outright, put those questions and the guest's answers in FAQPage markup. It produces nothing visible in Search anymore. It is still the cleanest question and answer pair a machine can be handed.

Notice what is not on that list. There is no property for how good the episode was, no property for download count, and nothing that rewards a bigger show over a smaller one. Structured data is descriptive, not competitive, which is why a 12 episode B2B show can be marked up better than a chart topper and be more legible for it. That is the same reason audience size does not gate podcast lead generation the way people assume.

One property deserves its own note. transcript is available on MediaObject, and if you are publishing the transcript on the page anyway, pointing at it from the media object costs nothing. The case for publishing transcripts at all is in podcast transcripts as AI search fuel, and what to cut out of them is in turning episodes into answer content.

What Does the Markup Actually Look Like?

Here is a complete episode page block. Names are placeholders. Everything else is the real shape.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "url": "https://yoursite.com/podcast/episode-14",
  "name": "Rebuilding a Domestic Supply Chain in 90 Days",
  "description": "Same sentence that appears as the summary on the page.",
  "datePublished": "2026-08-14",
  "duration": "PT47M",
  "episodeNumber": 14,
  "inLanguage": "en-US",
  "partOfSeries": {
    "@type": "PodcastSeries",
    "name": "The Fabrication Floor",
    "url": "https://yoursite.com/podcast"
  },
  "associatedMedia": {
    "@type": "AudioObject",
    "contentUrl": "https://yoursite.com/audio/episode-14.mp3",
    "encodingFormat": "audio/mpeg",
    "transcript": "https://yoursite.com/podcast/episode-14#transcript"
  },
  "actor": {
    "@type": "Person",
    "name": "Dana Whitfield",
    "jobTitle": "VP of Operations",
    "worksFor": {
      "@type": "Organization",
      "name": "Northwind Fabrication"
    },
    "sameAs": "https://www.linkedin.com/in/example"
  },
  "author": {
    "@type": "Person",
    "name": "Your Host Name"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Your Company",
    "url": "https://yoursite.com"
  }
}
</script>

A few notes on the fields people get wrong.

duration uses ISO 8601, so 47 minutes is PT47M and an hour and 12 minutes is PT1H12M. Not 47, not "47:00". Validators are strict about this and it is the single most common format error we see on episode pages.

partOfSeries is the one to get right if you only get one right. An episode with no series link is an orphan, and a show whose 40 episodes are all orphans has published 40 pages that do not know about each other. Point every episode at the same series URL, and put a matching PodcastSeries block on the show page itself.

actor is where the guest goes. PodcastEpisode inherits from Episode, so actor is available and it is the right slot for a person appearing in the episode. Use author for the host. If a purist objects that actor implies performance, the alternative is contributor, and either is better than leaving the guest unmarked, which is what most shows do.

The last rule is the one that outranks all the others. Everything in the markup has to match what a human can see on the page. If the JSON says the episode runs 47 minutes and the visible player says 31, you have not helped a machine understand your page, you have taught it that your markup is unreliable. Keep the name, the date, the duration, and the description identical to the visible copy, every time.

Series Page vs Episode Page: What Goes Where?

Two different pages with two different jobs, and collapsing them is how shows end up with 40 pages competing against each other.

The bottom right cell is the argument for building this as a template rather than doing it by hand. An episode page is written once and then sits there working for years, which makes 10 minutes of setup per episode one of the better returns available in this whole channel. The tech stack for podcast lead generation covers where this fits alongside the hosting, the editor, and the CRM.

The show page row about webFeed is worth calling out. PodcastSeries has a webFeed property that takes your RSS URL, and it is the join between the page a crawler reads and the feed a player reads. Fill it in. It costs one line and it is the only thing on the page that connects the 2 worlds.

What Are the Most Common Podcast Schema Mistakes?

Six, and 5 of them are silent, which is what makes them expensive.

• Marking the episode page as an Article. The most common failure by a distance, because most shows publish episodes through a blog template and inherit whatever the template emits. A crawler then reads a 6,000 word transcript page as a very long blog post with no series, no guest, and no media. Nothing errors. It just never gets understood as an episode.
• No partOfSeries link. Covered above and worth repeating because it is the difference between a show and a pile of pages.
• The guest left unmarked. The guest is the reason the page has any authority at all. Leaving them as plain text in the body throws away the strongest signal on the page, and it takes 5 lines to fix.
• Markup that contradicts the visible page. A description in the JSON that was written for search and a different description on the page. Pick one and use it in both places. Google's structured data policies treat markup that does not reflect the visible content as a violation, not a stylistic preference.
• Transcript locked in a PDF or a player widget. The markup can point at a transcript that no crawler can read, which is worse than pointing at nothing because it looks done. Publish the transcript as HTML on the page.
• Shipping schema and calling it a strategy. The one that costs the most. Structured data is a label. If the page underneath is a 200 word summary of a conversation nobody would repeat, the label is accurate and useless.

That last point deserves the emphasis. Markup does not make weak content get cited. It makes strong content legible, which means the sequence is always content first, structure second. A founder who spends a week on JSON-LD while the guest list sits empty has picked the comfortable task over the useful one, and we listed the rest of those in common podcast acquisition failure modes.

How Do You Validate It Without Guessing?

Two tools, and they answer different questions, which almost nobody separates.

1. The Schema Markup Validator. Checks the vocabulary itself. Is this valid schema.org, are the types real, are the properties allowed on those types, is the JSON well formed. This is the correct tool for podcast markup because it does not care whether Google currently ships a feature for it.
2. The Rich Results Test. Checks eligibility for features Google ships right now. Since podcast results and FAQ results are both gone, this tool will report nothing useful for an episode page, and that is a correct result rather than a failure. Use it for VideoObject and for BreadcrumbList, which still produce visible results.
3. Read the rendered output once. If the page builds its JSON-LD from a template, view source on a live episode and read the block with your own eyes. Template variables that failed to resolve are the most common production bug and both validators will happily accept a description field containing a literal placeholder.
4. Spot check quarterly, not daily. Once the template is right, the markup does not drift on its own. It drifts when someone changes the theme. Put a check in whenever the site template changes and otherwise leave it alone.

Measurement is a separate problem and a harder one. There is no report that tells you a machine understood your episode page correctly. What you can do is ask the engines your buyers use the 10 questions your episodes answer, once a month, and record whether your show, your host, or your guests come back in the answer. Crude, cheap, and more honest than most dashboards, and we laid the method out in how to track AI search visibility. What to expect from the traffic side is in LLM citation vs SEO traffic.

What Does the RSS Feed Handle That Schema Does Not?

Everything to do with players, which is a completely separate pipe from everything to do with crawlers.

Your schema markup does not put your show in Apple Podcasts. The RSS feed does. Your RSS feed does not help a crawler understand the episode page on your own site. The schema does. Shows get this wrong in both directions, usually by assuming that submitting the feed to directories was the end of the technical work.

Podcasting 2.0 transcript tag

An RSS element, written as podcast:transcript, that points at a transcript file in SRT, VTT, JSON, or TXT format for a given episode. It lives in the Podcasting 2.0 namespace and requires a namespace declaration in the channel header. Apple Podcasts and Spotify both ingest transcripts through it. It is the feed side equivalent of publishing your transcript, and it is separate from anything in your schema markup.

The transcript story is the clearest example of the split. Apple introduced transcripts for Apple Podcasts in March 2024, and creators can supply their own through the feed rather than relying on the automatic version, which is documented in Apple's transcript support page. The tag itself is specified at podcastnamespace.org and Spotify reads the same open standard.

So a complete setup publishes the transcript 3 times, in 3 formats, for 3 readers. As HTML on the episode page for crawlers. As a VTT or JSON file referenced from the feed for players. And pointed at from the media object in your schema so the connection is explicit. That sounds redundant until you notice that no single one of those reaches all 3 audiences.

Directories deserve the same clear eye. They do a real job and it is not distribution for a B2B show, which we worked through in why you should publish on Apple and Spotify anyway. Publish there because a buyer checking whether your show is real will look, then spend your effort on the pages you own. The full picture of what a show does to your search surface is in what a podcast does for your search footprint.

Where Does This Argument Stop Working?

Four places, and the version of this article written by a schema plugin vendor names none of them.

The first is when the show does not produce enough episodes. All of this is a multiplier on a supply of recorded conversations. A perfect markup template applied to 4 episodes a year is 40 minutes of work and no outcome. The bottleneck on nearly every show we see is not the technical layer, it is that nobody is booking guests at a steady rate, which is an outbound problem before it is a content problem.

The second is when the invites never land. A guest list is a spreadsheet until email reaches an inbox, and if the invites go to spam then none of this ever starts. That layer is its own discipline. Start with podcast invite email deliverability, then setting up sending domains, warming a new domain, SPF, DKIM and DMARC, what email deliverability actually is, and how to stay out of the spam folder. If the wrong people are being invited in the first place, the fix is further upstream in how to define your ICP.

The third is when the page has nothing on it. Schema describes content. An episode page with a player, 3 sentences of summary, and no transcript gives a crawler an accurate description of a page with nothing to lift. Publishing the transcript is the step that makes the markup worth writing, and it is the step most shows skip.

The fourth is when someone expects a measurable result inside a quarter. This is infrastructure. It raises the odds that your pages get classified correctly and it does not produce a graph that goes up next month. If you want a lever you can see move, the honest answer is that the recorded conversations themselves are the lever and this is the residue. Getting cited by ChatGPT and Perplexity and AI Overviews for B2B cover the engine specific mechanics, and how to rank in AI search is the overview if you are starting cold.

One caution on the research in this piece. The AI search field is roughly 2 years old, most published numbers come from vendors with a product to sell, and studies disagree with each other regularly. The Ahrefs study discloses its sample and is worth reading directly. Use the rest for direction, then grade yourself on your own 90 days, which is the only dataset that contains your buyers.

Reverse Outbound Engine

An outbound method where, instead of cold selling your ideal buyers, you invite them onto your podcast as a guest. The invite reads as recognition rather than a sales approach, so it earns replies at rates a direct pitch never reaches. You spend about 45 minutes hearing how the guest built and grows their business, which builds real trust. Any fit for working together is a separate, later conversation. The markup and the transcript are the residue, not the point.

If the whole model is new, what is a podcast acquisition system is the plain description, how to start a B2B podcast for lead generation is the build order, and podcast lead generation benchmarks sets the ranges to expect. The attribution wiring that connects a recording to a closed deal is in podcast attribution and B2B podcast ROI explained.

The Practitioner Takeaway

Google removed both visible rewards for marking up a podcast page and the correct response is to keep doing it anyway, because the reward was never the point. A player in the results page was a nice side effect of a machine understanding your page. The understanding is what carried the value, and there are more machines reading for understanding now than there were when the player existed.

Build the template once. PodcastEpisode on the episode page, PodcastSeries on the show page, the 2 joined by partOfSeries and webFeed, the media object filled in with a real content URL, the guest marked as a named Person with a link to their profile, and every visible field on the page matching every field in the JSON. Validate the vocabulary, read the rendered output once with your own eyes, and then leave it alone until someone changes the theme.

Then go back to the thing all of it is downstream of, which is how many decision makers sit down to record with you next month. As an acquisition-first B2B podcast agency, we commit to 30 recorded conversations with your ideal buyers in 90 days or your money back, and the guarantee is written on conversations rather than on pages because conversations are the input. The markup is how the record of those conversations stays readable to whatever reads the web next.