How to automate podcast show notes: what they are actually for

Generated show notes usually take the form of a summary: here is what this episode covered, in three paragraphs. That is the one thing show notes are not for, because the people reading them have either not listened yet — in which case a summary removes the reason to — or have listened, in which case they want something specific they remember hearing.

Show notes are navigation and reference. Understanding that changes what belongs in them, and it changes which parts of producing them can be automated.

What we'll cover

• Who reads show notes
• What belongs in them
• Chapters, which do most of the work
• Building it with CodeWords
• The links are the reference
• What generated notes get wrong
• Writing the description that sells the episode
• What else the episode can become
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Who reads show notes

Somebody deciding whether to listen, who wants to know what it covers and who is on it — not what was concluded.

Somebody who listened last week and is trying to find the book, the tool or the name that was mentioned.

Somebody mid-episode who wants to skip to the part they came for.

Search engines, for whom this is the only text that exists about the episode.

Somebody who will never listen but wants the references, which is a larger group than most podcasters expect.

Not a reader wanting the episode's content in written form, which is what a summary serves and what the transcript is already there for.

What belongs in them

The guest, with their real title and affiliation, and how to find them.

Chapters with timestamps, which is the highest-value element and the one most often missing.

Every link mentioned, which is the reference use and the thing listeners most often come back for.

Two or three specific things discussed, as concrete claims rather than topic labels — "why they stopped doing X" rather than "hiring practices".

Anything the guest said they would share, which is a promise the episode made on your behalf.

Not a summary of the conclusions, which removes the reason to listen for the undecided reader and tells the returning one nothing they wanted.

Chapters, which do most of the work

Break by subject change, not by fixed interval, since an interval-based chapter list is noise.

Name them concretely. "The hiring mistake that cost them a year" is navigation; "Hiring" is a label.

Aim for a handful, not twenty, since a long chapter list is as unnavigable as none.

Use real timestamps, checked, because one wrong timestamp makes the reader distrust all of them.

Support the player's own chapter format where it exists, so the navigation works inside the app rather than only on your page.

Generated chapter detection is decent at finding boundaries and poor at naming them, which makes this a good place for a human minute and an automated draft.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the audio, the transcript, the publishing platform and your distribution can meet in one pipeline.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what to extract from the transcript, what needs a person, and where the notes are published.
3. Authorize the connections — the transcript source, the hosting platform, and the website.
4. Describe the exceptions: an unrecognised name, a link that cannot be resolved, an episode with an unusual format.
5. Run it over a few past episodes and compare against the notes you wrote by hand.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The links are the reference

Every book, tool, paper, company and person mentioned, which is genuinely tedious to compile and entirely mechanical.

Resolve them properly. A guest saying a book title is not a link, and finding the right edition is the work.

Flag the ones you could not resolve rather than guessing, since a wrong link is worse than a missing one.

Include the guest's own links, which is both useful and the thing guests check.

Keep them working. Links rot, and an episode page from two years ago full of dead references reflects on you rather than on them.

Affiliate links need disclosure, individually and visibly, in most markets.

What generated notes get wrong

Names and companies, inherited from the transcript, which are the errors most visible to the guest.

False precision. A hedge in conversation becomes a flat claim in a summary, which misrepresents somebody who was being careful.

Attribution. A point made by the host presented as the guest's, or the reverse, which is the error guests actually complain about.

Manufactured structure. A rambling conversation summarised into three tidy themes suggests an organisation the episode did not have.

The generic opening. "In this fascinating conversation" identifies the notes as generated to any reader in the first five words.

Losing what was interesting. The memorable moment is frequently an aside, and summarisation removes asides by design.

Writing the description that sells the episode

The first line is the whole thing in most podcast apps, which truncate aggressively.

Lead with the specific, not the topic — a claim, a number, a surprising position.

Name the guest and why they would know, in one clause.

Do not give away the answer, which is the failure mode of a summary used as a description.

Keep it short and put the detail below, since the description and the notes are different fields with different jobs.

This is the part to write yourself, or at minimum to edit properly, because it is the sentence that decides whether anybody presses play.

What else the episode can become

Show notes are one output of an episode. The same material supports several others, and the automation that assembles them is largely the same pipeline with different extraction.

Clips, chosen by a person and cut automatically, since selecting the moment is judgement and the cutting is not.

Quote cards for the two or three things worth quoting, with the speaker attributed correctly — which is the part to check rather than trust.

A written piece built from a section that stands alone, edited properly rather than published as transcript prose.

An email to subscribers with the one thing from this episode worth their attention, which is a different selection from the description.

Answers to questions the episode addresses that people have asked elsewhere, which is distribution rather than repurposing.

Do not automate the selection. Which moment is worth a clip is the whole skill, and a system that picks by volume or by keyword density picks badly and consistently.

Making it survive

Handle a missing transcript by holding rather than publishing empty notes.

Validate every link before publishing, and again periodically afterwards.

Keep the notes versioned, so a correction can be applied and tracked.

Publish to one canonical page and syndicate from it, rather than maintaining several copies that diverge.

Report the outcome: episodes processed, links resolved and unresolved, and anything held for review.

Limits worth knowing about

Platform limits differ on description length and formatting, and several strip links entirely.

Chapter support varies by player, so your own page may be the only place the navigation works.

Transcript errors propagate into the notes, which is why the glossary belongs upstream.

Timestamps break if the audio is re-edited after the notes are generated, which happens more than you would think.

Notes cannot rescue an episode. If the conversation did not go anywhere, no amount of structure in the notes will suggest otherwise for long.

What to build first

The link list. Extract every book, tool, company, paper and person mentioned, resolve them, and flag anything that could not be resolved. It is the most tedious part of producing show notes, it is entirely mechanical, and it is the element listeners most reliably come back for.

Two habits make the difference. Write the first line of the description yourself, since it is the sentence that decides whether anybody listens and it is the one generated text identifies itself in immediately. And name chapters concretely rather than by topic, because "the hiring mistake that cost them a year" is navigation and "hiring" is a label that helps nobody find anything.

Frequently asked questions

What are show notes actually for?

Navigation and reference. Somebody deciding whether to listen, somebody trying to find a link they heard last week, somebody skipping to a section, and search engines — for whom this is the only text about the episode.

Should show notes summarise the episode?

No. A summary removes the reason to listen for an undecided reader and tells a returning one nothing they came for. The transcript already serves anyone who wants the content in writing.

What is the highest-value element?

Chapters with real timestamps, named concretely. "The hiring mistake that cost them a year" is navigation; "Hiring" is a label. A handful, broken by subject change rather than by interval.

What can be automated cleanly?

The link list — every book, tool, company, paper and person mentioned, resolved and checked. It is tedious, mechanical, and the element listeners most reliably return for.

What do generated show notes consistently get wrong?

Names and companies inherited from the transcript, hedged statements flattened into flat claims, attribution between host and guest, manufactured structure, and generic openings that identify the notes as generated in five words.

What should I always write myself?

The first line of the description. Most podcast apps truncate aggressively, so it is the sentence that decides whether anybody presses play.

Why do timestamps matter so much?

Because one wrong timestamp makes a reader distrust all of them, and the chapter list is then worthless. They also break silently if the audio is re-edited after the notes were generated.

Do affiliate links in show notes need disclosure?

In most markets yes, individually and visibly rather than in a general footer. Links also rot, so an old episode page full of dead references is worth a periodic check.

What else can be produced from one episode?

Clips, quote cards, a written piece from a section that stands alone, and a subscriber email — all from the same pipeline. Select the moments yourself; the cutting and assembly are mechanical and the selection is the whole skill.

Can clip selection be automated?

Not well. Systems that pick by volume or keyword density pick badly and consistently, because what makes a moment worth clipping is rarely visible in either signal.

Why publish show notes to one canonical page?

Because syndicated copies diverge. A correction applied to one and not the others leaves several versions in circulation, and the one people find is rarely the one you fixed.

Can good show notes rescue a weak episode?

No. Structure in the notes can suggest an organisation the conversation did not have, but only briefly — and it costs you the trust of anyone who listens on the strength of it.

Related reading

• Automating podcast transcription
• Automating blog post distribution
• Automating newsletter curation