What show notes are actually for
They are not a summary for people who already listened. They are a page a search engine and an AI answer engine can read, aimed at the question your episode answers. Audio is opaque to both. The page is the whole surface.
Most episode pages are three sentences and a link to Apple. That is a caption, written for someone who already knows the show exists. It cannot rank for anything, because it never says what the episode is about in the words anyone would use to go looking for it.
Meanwhile the hour of good conversation you recorded is invisible. Nothing that reads the web can listen to it. Whatever is not written on the page did not happen.
Write for one query per episode
The episode is about something. Name it the way a stranger would type it, not the way you would title it for regulars. One episode, one question. If you cannot say which question this episode answers, the page has nothing to rank for.
The test is simple and slightly uncomfortable. Say the episode out loud the way someone who has never heard of you would ask for it. Not the guest's name, not the clever line from minute twelve. The question they would type at eleven at night when they actually need this.
Then pick one. Episodes are wide, and the temptation is to load the page with every topic that came up, which leaves it aimed at nothing. If the conversation genuinely contains two questions, you probably recorded two episodes.
That question is usually decided before you record, not after. The episode concept you wrote on the guest prep page, back when you were deciding why this guest and why this topic, is the seed of the title. Pod Green Room keeps the concept attached to the booking, so guest tracking still has it on the day you sit down to write the page.
The structure that works
Five parts, in this order. A title written as the searcher's query, an opening paragraph that answers it, timestamped chapters as subheadings, the guest and their links, and the resources named in the episode. Everything else is optional.
- The title, written as the query. Put the question in it, in plain words. The guest's name can follow, but it should not be the whole title unless the guest is what people are searching for.
- The opening paragraph, which answers that question directly. Two or three sentences that stand on their own if someone reads nothing else on the page.
- Timestamped chapters, written as subheadings rather than a wall of times. Each one says what happens there, so the page reads as a structure instead of a log.
- The guest. Name spelled right, what they actually do, and every link you promised them while the recording was still running.
- Resources mentioned. The book, the report, the tool, the other episode. If it was named out loud, it belongs on the page.
The order is not decorative. It puts the searchable line first, the quotable answer second, and the scannable structure third, which is the order a reader and a machine both work through a page.
Answer the question in the first paragraph
Answer-first is not a style preference. It is how both a search snippet and an AI answer engine pull a quotable line out of your page. Put the answer in the opening paragraph, in plain sentences, then spend the rest of the page earning it.
The failure mode is the tease. 'In this episode, we get into what really drives...' is the default opening on most podcast pages, and it says nothing. A passage that states the thing is easy to quote. A passage that promises the thing is coming is not quotable at all.
You are reading a page built that way right now. The paragraph under the headline answers the title question before any nuance, every section opens with its own standalone answer, and the questions at the bottom are phrased the way people actually type them. It is not complicated and it is not an accident.
Timestamps, the guest, and the links you promised
Chapters do two jobs. They give a listener a way in, and they give the page real headings a machine can index. Then the guest's name spelled correctly, their title, and the links you promised in the room.
Write chapters as descriptions, not labels. 'Intro' and 'Main topic' tell nobody anything. 'Why she turned down the first offer' tells a reader where to jump and tells the page what it contains. Five to eight per hour is usually right.
The guest section is where most pages get careless, and it is the section with the most riding on it. This is the page your guest forwards to their own audience. Current title, correct spelling, a link to whatever they are promoting, and the specific link they asked you for.
Those promised links are the ones that go missing. Someone mentions a report at minute forty, you say you will include it, and three weeks later you are searching your inbox at midnight. Pod Green Room stores them on the guest record next to the follow-ups, so guest tracking has the list waiting when you open the page to write it.
The rest of that handoff, what to send a guest before and after the recording, is in the guide to booking podcast guests. The episode page is the last step of it, and the one guests actually check.
Transcripts, honestly
A raw transcript wall helps a little and reads terribly. It gives the page text and gives the reader nothing. A cleaned excerpt or structured notes beat dumping the file. If your host publishes transcripts automatically, leave them, and still write the notes.
A transcript is unstructured, repetitive, and full of the noise of speech. Anything trying to work out what the page is about has to wade through an hour of half-sentences and agreement noises to find it. Your written notes say the same thing in one paragraph.
So treat the transcript as raw material. Pull the exchange that made the episode worth publishing, quote it properly with the speaker named, and let that carry the page. One good excerpt gives readers substance, gives the guest something to share, and gives you a line for social.
Where the notes live decides whether they can rank
A page on a website you own can rank. A description inside a podcast app mostly cannot, because that page belongs to the app and is built for someone already browsing it. Publish the real notes on your site, and treat the app description as a different, shorter artifact.
| The page on your site | The description in the app | |
|---|---|---|
| Who reads it | A stranger who searched a question | Someone already browsing your feed |
| How long | Full notes, chapters, links, one excerpt | A few lines before it truncates |
| Its job | Get found, then answer | Get the play |
| What it needs | Headings, links, real written text | The hook and one link back to the page |
The site page has one thing the app description will never have, which is a permanent address you control. Apps redesign, hosting companies get bought, feeds get moved. The page you own is the one still sitting there in three years collecting search traffic.
For a cold read on what your feed currently hands a stranger, the sponsor readiness grader reads it and scores the parts people judge before pressing play, show notes included.
Fifty episodes, fifty doors
This is the part that compounds. One episode page is a small thing. Fifty episode pages, each one aimed at a real question, is fifty separate ways for a stranger to arrive at your show without ever having heard of it.
Which is the argument for doing it weekly rather than in a heroic catch-up weekend. Each page targets a different question, so they never compete with each other. They accumulate. The show gets a second life as a set of pages that answer things, and that keeps working on episodes you published two years ago.
A show note that only makes sense to someone who already listened is not a show note. It is a receipt.
Twenty minutes an episode. Put the question in the title, answer it in the first paragraph, chapter the middle, link everything you named out loud. Then publish it somewhere you own and let it sit there working while you go record the next one.