How to Create PodcastEpisode Schema

Podcast episode pages are the most consistently wasted asset in content marketing. A team records a genuinely good conversation with a practitioner, publishes a page containing an embed and two sentences of description, and produces something no search engine can rank and no AI engine can cite.

The waste is real because the content is good. An hour of an expert explaining how they actually solved a problem is exactly the first-hand experience Google's helpful content guidance asks for. It is just locked inside an audio file, which is opaque to every retrieval system that matters.

Two things fix it. Structured data that declares what the audio is, and a transcript that makes the substance readable. This post covers both, and the second one is where the returns are.

Why Podcast Pages Underperform

Four structural problems compound on a typical episode page.

The page has almost no text. An embed plus a short description is a couple of hundred words, and there is nothing for a search engine to assess relevance against beyond the title.

The audio is unreadable. No crawler transcribes your MP3. Whatever was said in the episode does not exist as far as retrieval is concerned.

The episodes are indistinguishable from each other. Episode 41 and episode 42 have near-identical page structures, near-identical descriptions, and differ only in a title. That is a duplicate-adjacent pattern across an entire section.

The markup is usually absent or generic. Most episode pages carry WebPage or Article at best, which tells a machine nothing about what the page contains.

The consequence is that a branded podcast with fifty excellent episodes contributes almost nothing to organic or AI visibility, while the same fifty conversations published as text would be a substantial content library.

The Series and Episode Relationship

Two types are involved and the relationship between them is the structural core.

PodcastSeries is the show. It carries the name, the description, the artwork, the host, and the feed URL. It is defined once and referenced by every episode.

PodcastEpisode is one episode. Schema.org nests it under Episode and above that CreativeWork. It carries the episode-specific detail: title, number, date, duration, guest, and the audio file.

The link is partOfSeries, pointing from the episode at the series.

The pattern that works is one canonical PodcastSeries node with an @id, defined on the podcast hub page, referenced by @id from every episode. That gives an engine a single show entity with fifty episodes attached, rather than fifty episodes each asserting a slightly different version of the same series.

Two properties that get skipped and should not. episodeNumber and seasonNumber belong in the markup as integers, not only inside the title string. A machine parsing Ep. 42 out of a headline is guessing, and where a series has seasons the number alone is ambiguous.

The Properties That Matter

The property set divides into four groups, and only one of them is commonly done well.

Identity is usually fine: name, description, datePublished, and url.

The audio itself goes in associatedMedia as an AudioObject, carrying contentUrl pointing at the file and duration in ISO 8601 format. PT47M12S for forty-seven minutes and twelve seconds. This is the part most implementations omit, which leaves the markup describing a page with no stated media.

People are where the value concentrates and where implementations are thinnest. The host goes in author or creator, and the guest goes in actor or is named in the description. If your guest is a credentialed practitioner, that is an E-E-A-T signal sitting unused. Give them a Person object with a sameAs pointing at something verifiable, and the episode inherits their authority rather than wasting it.

Subject matter goes in about and keywords. about referencing a Thing with a name is stronger than a keyword string, because it declares the episode's topic as an entity rather than a phrase.

One more property worth including: transcript, carrying the text, or a clear on-page transcript the markup describes. That leads directly into the next section.

A Complete Working Example

This is one episode with a named credentialed guest.

{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "@id": "https://example.com/podcast/42-postgres-replication#episode",
  "url": "https://example.com/podcast/42-postgres-replication",
  "name": "Running Postgres replication at 40 terabytes",
  "episodeNumber": 42,
  "seasonNumber": 3,
  "datePublished": "2026-08-19T06:00:00-04:00",
  "description": "Ravi Chandrasekaran explains how his team moved a 40 terabyte Postgres cluster to logical replication without a maintenance window, and the two failure modes they hit on the way.",
  "timeRequired": "PT47M12S",
  "partOfSeries": {
    "@type": "PodcastSeries",
    "@id": "https://example.com/podcast#series",
    "name": "The Storage Layer",
    "url": "https://example.com/podcast"
  },
  "associatedMedia": {
    "@type": "AudioObject",
    "contentUrl": "https://cdn.example.com/audio/storage-layer-042.mp3",
    "encodingFormat": "audio/mpeg",
    "duration": "PT47M12S"
  },
  "author": {
    "@type": "Person",
    "name": "Priya Raman",
    "url": "https://example.com/authors/priya-raman"
  },
  "actor": {
    "@type": "Person",
    "name": "Ravi Chandrasekaran",
    "jobTitle": "Principal Engineer",
    "worksFor": { "@type": "Organization", "name": "Larkfield Systems" },
    "sameAs": ["https://www.linkedin.com/in/ravichandrasekaran"]
  },
  "about": [
    { "@type": "Thing", "name": "PostgreSQL logical replication" },
    { "@type": "Thing", "name": "Zero downtime database migration" }
  ],
  "keywords": "postgres replication, logical replication, database migration, zero downtime"
}

Three deliberate choices there.

The description states what the guest actually said, including that they hit two failure modes. A description that says we discuss replication conveys nothing retrievable.

The guest carries a job title, employer, and a sameAs. That is a verifiable practitioner rather than a name.

about names two specific technical subjects as entities. Broad topics like databases would match nothing in particular.

The Transcript Is the Asset

Everything above makes the page legible. The transcript is what makes it valuable, and it is the part teams skip because it feels like a chore.

Reason through what your transcript actually is. Forty-seven minutes of a practitioner talking is roughly 7,000 to 8,000 words of first-hand experience, containing specifics, numbers, mistakes, and reasoning you would never put in a written post because nobody writes that candidly. Published as text, it is one of the strongest content assets you can own.

Three concrete benefits.

Your page becomes rankable. Two hundred words becomes 8,000, on a specific topic, in the voice of somebody who did the work.

The episode becomes citable. AI engines cannot retrieve audio. They can retrieve a transcript, and a passage where a named engineer explains the exact failure mode they hit is the kind of specific, attributable content that gets quoted.

Long-tail coverage arrives for free. A conversation naturally covers dozens of sub-questions nobody would write a post about, and each one is a query somebody types.

The economics are straightforward for you. Automated transcription is cheap and accurate enough that your remaining work is a light editorial pass to fix technical terms and names. Compared with commissioning 8,000 words of expert content, it is close to free.

Our post on content chunking covers why the structure of that text matters as much as its existence.

Structuring a Transcript for Retrieval

A raw transcript dump underperforms a structured one substantially, and the difference is a couple of hours of editing.

Six things to do.

• Publish it as real HTML text on the page. Not in a tab that loads on click, not inside a player widget, not as a PDF download. Retrieval needs it in the document.
• Add headings at topic shifts. A conversation naturally moves through subjects. Marking those transitions with H2s turns one wall of text into retrievable sections.
• Attribute every speaker turn by name. Who said it is load-bearing when the value is that a credentialed practitioner said it.
• Clean the verbal noise. Remove filler and false starts. Keep the substance and the voice, since over-editing into corporate prose destroys the candour that made it worth publishing.
• Fix the technical terms. Automated transcription mangles product names, acronyms, and numbers, and a wrong figure is worse than no figure.
• Add timestamps against the headings. Useful to readers and it lets you link a specific answer.

One editorial addition worth your effort: a short summary at the top stating what the episode concluded. A reader deciding whether to invest 47 minutes wants that, and so does a retrieval system looking for the answer rather than the discussion.

Our guide to VideoObject schema covers the same transcript logic for video, where the structural problem is identical.

Validation and Common Errors

Validate with the Schema.org validator, since Google does not currently offer a podcast-specific rich result test the way it does for video.

Seven errors account for most problems.

• No associatedMedia. The markup describes an episode with no stated audio file.
• duration not in ISO 8601. It must be PT47M12S, not 47:12 and not 2832 seconds.
• Each episode restating the series. Define PodcastSeries once with an @id and reference it.
• Episode number only in the title. Put episodeNumber in the markup as an integer.
• Guest not marked up. A credentialed practitioner named in prose only wastes an authority signal.
• Transcript behind a click or in a PDF. If it is not in the rendered HTML, retrieval cannot use it.
• Generic about values. Technology matches nothing. Name the actual subject.

One check to build into a crawl: assert that every episode page contains more than a threshold word count of body text. It catches the pages where a transcript was promised and never added, which is the single biggest gap in most podcast sections.

Frequently Asked Questions

Does PodcastEpisode schema produce a rich result?

Google does not currently document a podcast-specific rich result the way it does for video. The value is retrieval and entity clarity rather than a visual treatment, which is why the transcript matters more than the markup.

Do I need PodcastSeries as well as PodcastEpisode?

Yes, and define it once. Put the canonical PodcastSeries node with an @id on your podcast hub page and reference that @id from every episode through partOfSeries. Restating the series on each episode creates competing entities.

Is a transcript really necessary?

It is the part that produces results. Audio is opaque to every retrieval system, so without a transcript an episode page is a couple of hundred words wrapped around a file nothing can read. The transcript is the content.

Should the transcript be on the episode page or its own page?

On the episode page. Splitting it creates two thin pages competing for the same topic instead of one strong one. If length is a design concern, use headings and a summary rather than a separate URL.

How do I mark up the guest?

Use actor with a full Person object carrying name, jobTitle, worksFor, and a sameAs pointing at something verifiable. A guest with real credentials transfers authority to the episode, and naming them in prose alone leaves that on the table.