Podcast show notes: where they earn search traffic and where they don't

Apple Podcasts search reads three fields. Apple says so itself, on its support page explaining how search works: the show name, the channel name, and the episode title. Podcast show notes are not on that list. The description you write after every recording does nothing for the search box inside the Apple Podcasts app, and once you accept that, the twenty minutes you spend on it every week gets a lot easier to aim.

Show notes still earn traffic. They earn it somewhere else, under rules set by a different set of companies, and the two jobs they do pull in opposite directions. One is winning the tap from a listener who is already looking at your episode in a podcast app. The other is bringing a stranger in from Google who has never heard of your show. Most podcasters write one block of text and hope it covers both. It does not.

The index that stops at the title

Apple's page on search names three inputs: metadata, popularity, and listener behavior. Metadata means the names and titles, nothing more. Popularity means followers and plays. Behavior means what people do with the results they get. Apple's advice to creators is to make sure the "channel name, show titles, and episode titles are specific and unique," and to avoid generic names, titles that collide with existing shows, emoji, and repeated episode titles.

Two things follow. The first is that your episode title is carrying the entire weight of in-app discovery, so an episode called "Episode 147" is invisible to Apple Podcasts search in a way no amount of description writing can fix. The second is that ratings and reviews do not appear in Apple's list of ranking factors at all. They matter for the decision a human makes on your show page, which is a real thing worth chasing reviews for, but they are not a search lever.

Apple also tells creators that engagement compounds: "The more listeners engage with your new shows and episodes, the higher they will rank for relevant search terms." That makes launch-week promotion a search investment rather than a vanity exercise, which is the argument for front-loading the channels that bring listeners in rather than spreading effort evenly across a quarter.

Ninety characters before anyone scrolls

Spotify publishes its own editorial guidance on episode descriptions, written by the copywriters who do it for the company's in-house studios. Paige Ransbury, a copywriter for Spotify's Parcast Studios, tells creators to cut the filler opening, the "On today's episode of [podcast], our host [name] talks about" construction, in order to "make those first 90 characters really count." Jared Silverman, a copywriter at Spotify, goes further and advises creators to "limit your podcast descriptions to two or three sentences."

Spotify's team is explicit that the goal is not summary. Their advice is to avoid spoiling the episode, avoid repeating what the title already said, and include specifics: names, places, timely topics, guests. Write four or five sentences, then cut.

That is sound advice for the text that ships inside your RSS feed, and it is terrible advice for a page you want ranking on Google. Ninety characters of intrigue will not rank for anything. The resolution is not a compromise between the two. It is two separate pieces of writing, which is what the next section is about.

The copy that lives on an address you own

The feed description is a conversion asset. The episode page on your own domain is the search asset. They can share material, but they are not the same document, and the podcast apps are not where the search traffic is.

Worth knowing about the plumbing: the itunes:summary tag that a generation of podcast tutorials told you to fill is, according to the podcast de facto standard documentation, "no longer used by Apple Podcasts, but other indexers and apps still use this." The plain description tag is what carries through. If your host gives you two boxes, the second one is doing less than you think.

An episode page you control has no 4,000-character ceiling, no restricted tag list, and no host deciding how your formatting renders. It can carry a full transcript, a proper heading structure, and internal links to your back catalogue. That is the surface Google indexes, and it is the whole basis of podcast SEO as a practice. The mechanics of getting those pages crawled and surfaced are covered in our walkthrough on getting a podcast into Google results, and the limits of the transcript-as-SEO shortcut are covered in what a transcript does and does not do. The short version of that second piece: a raw transcript dumped on a page answers no question anybody typed.

Four thousand characters, minus the markup

The working limit for a feed description is 4,000 characters. It is not an Apple rule written anywhere public so much as an industry convention, and the host RSS.com describes it that way, calling it "an industry standard that ensures compatibility with all major platforms, including Apple Podcasts and Spotify."

The part that catches people out is that the markup counts. RSS.com's own documentation spells out the arithmetic: a paragraph tag adds 7 characters, bold formatting adds 17, and hyperlinks "increase the character count significantly" once the tag and the URL are both counted. A show notes block with a dozen links and a timestamp list can burn several hundred characters on code the listener never sees.

Spotify's formatting page sets out what survives the trip. For shows hosted elsewhere, the supported tags are links, h1 and h2 headers, ordered and unordered lists with nesting, paragraphs, and line breaks. Links must be HTTPS: "We only support https links (not http)." And Spotify passes your markup along unchanged, which is both convenient and a warning: "We send your HTML formatted text exactly as it appears to all listening platforms. Most platforms support HTML formatting, but be aware that your episode descriptions might look different on different platforms."

So test. Publish one episode, open it in Apple Podcasts, Spotify, and whatever third app your audience actually uses, and look at what happened to your bullet list.

Timestamps are not a ranking signal

Timestamp lists in show notes do real work. They let somebody skip to the part they came for, they get copied into forum posts and newsletters, and on YouTube they become clickable chapter markers that break a long episode into sections a listener can jump between. None of that is a search ranking factor in any podcast app. It is a retention and sharing feature, and it is a strong one, particularly if you are running episodes long enough that a listener needs a map. If YouTube is part of your distribution, the chapter behavior is one of the better reasons to be there, and the setup is covered in putting a podcast on YouTube.

The same goes for guest links, book titles, and sponsor URLs. They exist for the human reading them. Judge them on clicks, not on rankings.

The line Apple will take a show down for

There is a temptation, once you learn that titles are what Apple indexes, to stuff them. Apple's content guidelines address this directly and the language is not soft. Metadata "must always accurately represent the corresponding content that is distributed." Creators may not "artificially increase, falsify, or otherwise manipulate a podcast's follows, listens, ratings, or reviews, or attempt to influence search using inaccurate or inappropriate terms." Shows built on "mimicking, copying, or duplicating other content or search terms are not permitted."

The remedies Apple lists are escalating and they reach the account, not just the episode. Apple may "label or remove the content from Apple Podcasts, suspend the sale of subscriptions, and/or suspend or terminate your account."

One more clause in that document is easy to miss and relevant to anyone writing sponsor-heavy notes: "the amount of editorial content in an episode should greatly exceed any advertising content, so episodes must not consist primarily of advertising or marketing." That is about the audio, but a description that reads as a sponsor block with an episode attached is not a good look next to it.

Metadata changes do propagate fast, for what it is worth. Apple says its system "will automatically detect and update it on Apple Podcasts within 24 hours," so a title you want to fix is a one-day job, not a lost cause.

A routine that fits in twenty minutes

What this adds up to is a split workflow, and it is short.

For the feed, write two or three sentences. Lead with the specific thing: the guest's name, the claim, the number, the place. Spend the first ninety characters on the reason to press play and nothing else. Then a short block below it with the links a listener will want, HTTPS only, and a timestamp list if the episode runs long. Keep the whole thing comfortably under 4,000 characters with the markup counted.

For the title, write the search query. Not a clever phrase, not a running numbering scheme, the actual words somebody would type. This is the only field Apple indexes and it is the field most shows waste.

For your own site, write the page properly: a real heading structure, the transcript, and an answer to the question the episode actually settles. That page is what competes in Google, and it is where the compounding happens, because an episode page that ranks keeps delivering listeners in month nine. The pattern behind that, and the reason a Spotify-only strategy caps out, is laid out in our piece on getting more listeners on Spotify.

Where PodAnswer comes in

The episode page is the part most podcasters never get to. It is a writing job, it takes a couple of hours per episode to do well, and it has nothing in common with making the show.

That is the job PodAnswer does. We pull the real questions your episodes answer, write them up as articles with the relevant excerpt from your own transcript quoted and timestamped, and publish them on pages that can rank, each one linking back to the episode and the show. Growth is $149 a month for four articles. Network is $349 a month for twelve, which is the volume that makes a dent if you have a back catalogue worth mining. The plans are on the pricing page, and the process, including what we need from you, is on the page for podcasters.

Write the ninety characters for the app. Let the long-form page do the searching.