What Are Podcast Show Notes? The Two-Job Explainer

Podcast show notes are the written text that describes an episode, a summary, the topics covered, guest names, timestamps, and links. They're what a listener reads to decide whether to press play, and what a search engine reads to understand the episode. Same words, two audiences, two jobs.

That double duty is the part most explainers miss, and it's why the show notes inside your podcast app can look different from the version on your website. One copy lives in your RSS feed and gets squeezed into a small app description field; the other lives on a web page where length and formatting don't cost you anything. The rest of this page is about that split, what goes in each version, why they differ, and which one your listeners actually see.

What are podcast show notes, in one paragraph?

Podcast show notes are the episode's description in text: a few sentences on what it's about, often plus guest bios, links mentioned, sponsor mentions, and chapter timestamps. Your podcast host stores them in the episode's feed entry, in plain text in the field and, for richer formatting, in a content:encoded field, so every app can display them. The same text, usually expanded, also lives on the episode's web page, where it can be indexed by Google.

The simplest way to think about them: show notes are the back cover of a book. Short enough to read in the store, specific enough to tell you whether this is your kind of thing. The blurb on the back is the app version. The full author's-note-and-reviews page online is the website version. Same book, two lengths, two places people meet it.

The two jobs show notes do

Get this distinction right and everything else about show notes makes sense. Most advice treats them as one thing. They are two, and the two jobs reward different writing.

Job one: human reference, shown in the app. Inside Apple Podcasts, Spotify, Overcast, and the rest, the description is a small panel. People skim it in seconds to answer one question, is this episode worth my next 40 minutes? The first sentence does almost all the work, because most apps truncate the rest behind a "more" tap. This version should front-load the hook and the guest's name. Links here are often not even tappable, depending on the app, so don't bury anything important inside one.

Job two: search-indexable text, crawled on your site. Your episode's web page is a normal HTML page, and Google reads it like any article. This is where keywords, a real transcript, named topics, and tappable links earn their keep. Audio is invisible to a search engine; the show notes page is the only part of your episode it can actually read. So the web version can be long, structured with headings, and written to match how people search. (The full playbook for that lives in show notes that actually rank.)

The mistake is writing one block of text and pasting it both places. The app wants a tight blurb; the website wants depth. Write the blurb first, then expand it for the page, not the other way around.

Why the feed version and the site version can differ

The feed version and the website version of your show notes can differ because they live in two different systems with different limits, and that's normal, not a bug. The RSS field is built to be portable across dozens of apps, each of which renders a different amount of it and strips different HTML tags. Your website has no such limits, so the page version is usually longer and richer.

Here's the mechanism. When you publish, your podcast host writes your notes into the episode's in the RSS feed, as plain text in and, where supported, as formatted HTML in content:encoded. Apps read those fields, not your website: HTML-capable apps use content:encoded and ignore , while text-only apps do the reverse, which is why the same notes render so differently across players (Podnews tested 40+ apps and found Pocket Casts, Overcast, and Castro handled them best). So whatever an app shows comes from the feed, not from the prettier page you built. Many hosts also generate a basic episode web page from the same field, but plenty of shows maintain a separate, fuller page on their own site or a CMS. When those two sources drift apart, the app shows one thing and Google indexes another. Neither is wrong; they're answering to different readers.

So which one do listeners actually see? In a podcast app, always the feed version, because apps only read the feed. Someone who finds you through Google search lands on the website version first. Practically, that means your one tight opening sentence has to work in the app, while the depth and keywords go on the page. Write for both deliberately.

What goes inside good show notes

A useful set of show notes usually carries six things, in roughly this order. None of them are mandatory, but each earns its space.

1. A one-sentence hook. What this episode is and why it matters, front-loaded, because the app cuts off the rest.
2. A short summary. Two or three sentences expanding the hook, naming the guest and the core topic.
3. Timestamps / chapters. Where each segment starts. Useful to listeners and increasingly read by apps that support chapters.
4. Links mentioned. Books, tools, the guest's site, tappable on your page, listed plainly in the feed.
5. Guest bio and handles. Who they are and where to follow them.
6. A clear next step. Subscribe, join the list, or watch a clip, one call, not five.

Keep the feed description tight and put the long material, full transcript, deep links, extra context, on the web page. That respects both readers without making either work harder than they should.

How show notes relate to the rest of the feed

Show notes are one field among several that travel inside each episode's feed entry, and it helps to see where they sit. The description is the human-readable text. The enclosure tag is the link to the actual audio file. The GUID is the episode's permanent ID. And the metadata embedded inside the audio file, the title and artist your car stereo reads, are ID3 tags, a separate layer from the feed entirely.

That separation matters in practice. You can rewrite your show notes anytime and apps will pick up the change on their next read, because notes live in the feed, not in the audio file. But fixing a wrong title shown in someone's car may mean editing the ID3 tags, not the notes. Knowing which layer holds which text saves a lot of "why won't this update?" frustration.

Frequently asked questions

Do show notes affect podcast SEO? Yes, but only the website version. Search engines can't read audio, so the text on your episode page is the part Google indexes and ranks. The feed description helps inside apps but isn't a ranking page on its own. Put your keywords, topics, and a transcript on the web page, and keep the app blurb short and human.

How long should show notes be? The feed version: one strong sentence plus a short paragraph, since apps truncate the rest. The website version: as long as the episode warrants, a paragraph for a quick chat, several hundred words plus a transcript for a deep interview. Length isn't the goal; matching the reader is.

Are show notes the same as a transcript? No. Show notes are a written summary and reference; a transcript is the full word-for-word text of the episode. Many shows put the summary at the top of the web page and the transcript below it. The summary sells the episode; the transcript makes the whole thing searchable.

Who writes the show notes? Usually the host or producer, often from the episode's outline. A growing number of shows draft them from the transcript automatically, then edit for the hook and the links. Whoever writes them, the first sentence deserves the most attention, it's the one most listeners ever see.

Where do apps pull show notes from? From your episode's entry in the RSS feed, the content:encoded field for apps that render HTML, the plain-text for those that don't. Apps never read your website. So if your app description looks wrong, fix it in your host's episode editor, not on your separate web page.