Podcast SEO: how to get your show found in apps, Google and AI answers

“Podcast SEO” gets used for three different jobs, and advice for one is often useless for the others. A show is searched for in three places:

• Podcast apps. Apple Podcasts, Spotify and the rest match a listener’s query against the text in your RSS feed: show name, author, description, categories, episode titles. They cannot hear the audio either. If the word isn’t in the feed, the app can’t find it.
• Google and AI answers. Google ranks web pages. AI assistants cite web pages. An episode that lives only inside an app or a hosting player is, to both of them, a thin page with a play button on it. The page you own on your own domain is what they read.
• YouTube. A search engine of its own. It reads the title and description you write and the words it transcribes from the video, and it recommends on top of that.

The common thread: every surface runs on text. Podcast SEO is mostly the work of turning an hour of audio into well-structured text and putting that text where each surface reads it. The rest of this guide goes surface by surface, starting with the one most shows skip.

A show page can rank for the show’s name. It cannot rank for the hundred topics the show has covered. Each episode answers a question somebody types into Google, and only a page devoted to that episode can be the answer. That is why the episode page, not the show, is the unit of podcast SEO on the web.

A page that can rank has, in roughly this order:

• A title that says what the episode is about. The guest’s name and a plain description of the topic beat “Episode 47” every time. The HTML title and the H1 can differ slightly; both should carry the subject.
• A written summary. Two or three paragraphs in your own words: what was discussed, who the guest is, what a listener will come away with. This is the passage an AI assistant is most likely to quote.
• Show notes with timestamps and links. Chapters tell a reader (and a crawler) the structure of the conversation. Links to the people, books and tools mentioned make the page useful on its own.
• The transcript. The full text, below the summary and notes. More on how to publish it without burying the page under it in a moment.
• The player and the listen links. A page that ranks and then gives the visitor no way to play the episode has wasted the click.
• Schema. Structured data labels the page for a crawler: this is an episode of that series, here is the audio, here is the publish date. It does not replace the text; it describes it.

Google’s own SEO Starter Guide asks for the same things of any page: a unique, descriptive title, a description that reads like a sentence, headings that reflect the structure, and links the reader would actually follow. An episode page is just an article whose source happens to be audio.

Inside podcast apps, your RSS feed is the whole document. Apple publishes the feed requirements it validates against; the tags that matter for being found are the ones a human reads.

• Show name. Say what the show is, or who it is for, in the name or a short subtitle. A clever name with no subject gives the app nothing to match. Don’t pad it with a list of keywords; it reads as spam to listeners and apps alike.
• Author. The host or the organisation, written the way people would search for it.
• Description. The first sentence should let a stranger decide whether to press play. Name the topic, the audience and the format. Write it once, properly, and reuse the same wording on your website and your YouTube channel.
• Categories. Pick the one that describes the show, and a second only if it genuinely fits. The category is where you compete in the charts and in browse.
• Episode titles and descriptions. Each one is a separate match for app search. A title that names the guest and the subject does double duty in the app and on the page.

Consistency is the quiet lever here. The show name, author and description in the feed, on your site, on YouTube and on your podlink.fm page should agree word for word. Search engines and AI assistants resolve an entity by seeing the same facts in several places; four slightly different descriptions give them four weaker signals instead of one strong one.

Everything above is about describing the episode. The transcript is the episode, in the only form a crawler can read. A one-hour conversation runs to several thousand words, and every name, product, question and aside in it is a phrase someone might search for. Without the transcript, your page says what the episode is about. With it, the page contains what the episode said.

Why text, specifically

Search engines index words. AI assistants answer from passages. An audio file is neither. A hosting platform’s player page usually carries the description and a play button, so it is indexed as a very short page; the transcript is what turns it into a long one.

How to publish it without a wall of text

• Lead with the summary and show notes. The transcript goes last, under its own heading, so a reader who wants the short version gets it first.
• Collapse it, don't hide it. An expandable section is fine as long as the text is in the page's HTML; a transcript loaded only when someone clicks may never be read by a crawler.
• Break it into speaker turns and chapters. Paragraph breaks and timestamps make it skimmable and tell a crawler where the topics change.
• Clean it once. Fix names and product spellings; those are exactly the terms people search for. Leave the conversation as it was said.
• Don't paste the whole transcript into the feed description. The apps want a description; the page wants the transcript.

PodLink’s episode transcripts are one click per episode from the feed you already publish, and come back as editable text you can correct and copy onto the page. The show notes (the summary, chapter timestamps, takeaways and links) are written from that transcript, which is why they describe what was said rather than what a podcast episode usually contains.

A page nobody links to is a page a crawler finds late and ranks cautiously. Episode pages are the usual victims: published, listed on an index for a week, then pushed off it by the next ten episodes.

• The hub links to every episode, not just the latest. An episodes index with real titles, paginated or grouped by season, is the minimum.
• Episodes link to each other where the topics touch. "We covered the basics of this in the episode with X" is a link a listener would click and a crawler will follow.
• Every episode page links back to the show page and the subscribe links, so a visitor who lands on episode 31 from Google knows what they've found.
• Keep the URL once you've published it. A renamed slug without a redirect throws away whatever the page has earned.

The same logic applies off-site: your podlink.fm page, your YouTube channel and your social profiles should all point at the same hub, and the hub should point at them.

YouTube is where a growing share of podcast listening happens, and its search is separate from Google’s web results. It reads what you type, the title and description, and what it hears, the auto-generated captions, so the same rule holds: say the subject in the title, describe the episode in the first lines of the description, and link to the episode page on your site.

Treat the YouTube upload and the episode page as the same episode in two places. Same title, same summary, chapters in both (YouTube turns timestamps in the description into chapter markers), and a link each way. That way a search on either surface lands somewhere that routes to the other, instead of two half-built versions competing for the same query.

If the show is audio-only, a YouTube presence is optional. If you already record video, it isn’t.

• Keyword-stuffed titles. “Marketing Podcast | Marketing Tips | Digital Marketing Show” is unreadable to a listener and, in Google’s case, listed in its spam policies. One clear subject per title.
• Duplicate descriptions. The same show description pasted into every episode gives the apps and Google a hundred identical pages. Each episode gets its own summary.
• Orphan episode pages. A page that exists but that nothing links to. See the section above; the fix is the episodes index and cross-links.
• The transcript as the description. It bloats the feed, truncates in the apps, and still leaves the page thin.
• Chasing the chart instead of the query. Charts reward new followers in a short window. Search rewards a page that answers a question for years. They are different games with different tactics.

Two numbers get conflated here, and keeping them apart is most of the job.

Downloads are not search traffic. A download is a listener’s app fetching the audio file, from any source: a subscription, a share, a chart, a search inside the app. PodLink reads downloads from OP3, the open, independently checkable measurement prefix, and shows them per episode alongside listening apps and countries. That tells you how the show is doing. It does not tell you where a listener came from.

Search traffic is measured on the website. Google Search Console, free from Google, reports the impressions, clicks and queries for every page on your domain. Filter to your episode URLs and you can see which episodes rank, for what, and whether the clicks are growing. That is the scoreboard for everything in this guide; downloads are the scoreboard for the show.

Put the two next to each other and the useful questions appear. An episode with search impressions but few clicks has a title problem. An episode with clicks but no lift in downloads has a page with no obvious play button. PodLink’s Show Report is the live, shareable view of the download side; you can also connect your analytics to Claude or another MCP-capable assistant and ask which episodes moved after a page went live.

None of this needs an agency. A show with someone on the team who will transcribe each episode, write the summary and notes, and publish a page on the site every week can do all of it: the transcript and the show notes come out of PodLink, and the page is whatever your website platform already gives you.

The part that fails is the “every week”. Episode pages work because they compound, and they compound only if each new episode gets one. PodLink’s Podcast Websites service builds the hub and the episode-page template on your own domain for $3,500 one-time, and Episode Care, $400 a month on top, means every new episode gets its page, published by us, with the titles, descriptions and schema kept current. The content kit comes from the product; the page is still built by a person. There is no automatic feed-to-website pipeline, and we won’t describe one until it exists.