How to Do SEO for a Podcast
On this page
- What Google can read, and what it can’t
- Two search systems, two sets of rules
- Decide which episodes deserve a full page
- Build the page from the transcript, not as the transcript
- Titles and URLs: two audiences, two strings
- Where your links should point
- Structured data: accurate labels, not a search feature
- A workable setup for an existing show
- Frequently asked questions
- Related posts:
Google’s list of file types it can index covers text documents, images and video, and has no audio category. For web search, what ranks is the page around each episode: its title, its written summary and anything you build from the transcript. A show whose episodes live only as audio in a feed and a host’s player page gives Google very little to work with.
What Google can read, and what it can’t
Google publishes the file types it can index. The text list runs from HTML and PDF to Word, Excel and EPUB files. The media section lists image formats and video formats; it has no audio category, and MP3 is not on it. Whatever is said in an episode, the MP3 itself is not something Google lists as indexable. The words that can reach a searcher are the words on the episode page.
That changes what “podcast SEO” means for web search. You are not ranking a show. You are ranking a set of web pages that happen to carry an audio player, and each page competes with articles, videos and forum threads on the same terms they do. An episode with a clever title, an embedded player and two lines of description has next to nothing a search query can match.
Where the page lives matters as much as what is on it. A page generated by a hosting platform can sit on the platform’s domain, use the platform’s template and offer little editing. An episode page on your own site is the one you can structure, expand and send links to.
Two search systems, two sets of rules
A podcast can be found through two unrelated search systems, among other routes:
- Podcast apps such as Apple Podcasts and Spotify run their own search and their own charts, under rules each platform sets. For a show delivered by RSS feed, Apple’s podcast RSS feed requirements call for required tags, at least one episode and artwork. In practice, the titles and descriptions listeners see in an app listing are the ones written in the feed.
- Google web search ranks web pages. It sees your episode pages, not your feed’s standing in any app.
The two call for different writing. In an app, the episode title competes for a tap among other episodes in a list. In Google, the page title competes for a click among pages answering a question. Writing one title for both risks losing on one of them, because a title written to win a tap from a subscriber is not written to name the topic the way a stranger searches for it.
The Google side has also narrowed. Google Podcasts no longer exists as a destination; podcasts.google.com now forwards to YouTube Music. There is no Google-owned podcast app to submit to or plan around. For Google web search, the episode page on your own site is the surface you control.
Decide which episodes deserve a full page
Not every episode earns article-grade treatment, and trying to give it to every one spends the hours the strongest episodes need. Sort the archive with one question: would someone search for what this episode covers without already knowing the show exists?
- Topic episodes pass. An episode on how to negotiate a commercial lease, or on a change in a tax rule, answers a question people type into Google. It deserves a full page.
- Personality episodes may not. A long conversation with a founder about their career has no query behind it unless the guest is already someone people search for by name. A clear summary and good show notes serve the existing audience; a long article may not find new listeners from search.
Apply the same filter before paying for transcription. A transcript can earn search traffic when the episode covers a subject with search demand. For a wide-ranging interview, the words it adds match little that anyone searches for.
Build the page from the transcript, not as the transcript
A verbatim transcript is long without being organized. Spoken conversation is full of false starts, tangents, crosstalk and references the speakers understood and a reader won’t. Posted as a wall of text, it is hard to skim and says little about what the episode is for. The transcript is input, not output.
For an episode that passed the triage, read the transcript as research notes and rebuild the useful parts:
- Lead with the answer. If the core takeaway arrives forty minutes into the recording, state it near the top of the page and expand from there.
- Use headings for the questions the episode answered. A reader skimming the page, and Google reading it, can both see which sub-questions it covers.
- Add the context the conversation assumed. Two experts may mention a concept in passing that a reader needs defined, or cite a number without its source. The page fills those gaps.
- Keep the player on the page, but not as the whole page. The text has to work for someone who never presses play.
Episodes that wander across several subjects need a decision. Either pick the subject with the clearest search demand and build the page around it, or give each subject its own page that shares the same audio. Splitting works when each subject has its own audience of searchers. One page aimed at three unrelated questions is harder to make the best answer to any of them.
A full transcript can still sit on the page below the article for readers who want it, and for accessibility. The article carries the search work; the transcript is the complete record.
Titles and URLs: two audiences, two strings
The title in your feed and the title of the web page do different jobs, so they should not always be the same text.
- Feed title: it lives in podcast apps, where listeners scroll a list of episodes from shows they already follow. It can be conversational, carry the episode number or lead with the guest.
- Page title: it lives in Google’s results, competing with pages from sites that have never heard of the show. It should name the topic plainly, in the words someone would search.
“Episode 127: The One About Pricing” can do its job in an app and fail on the web. “How SaaS Companies Set Usage-Based Pricing” does the web job. If your site generates episode pages automatically from the feed, check whether it lets you set a page title separate from the feed title, since that setting decides which text Google sees.
The same reasoning applies to the URL. A slug that names the topic, such as /usage-based-pricing-saas, tells a reader scanning results what the page is about. A slug built from an episode number tells them nothing.
Where your links should point
Guest appearances, newsletter mentions and social posts can all generate links. Point them at the episode page on your own site, not at the show’s listing in a podcast app. A link to an app listing sends people into an environment you don’t control. A link to your own page sends them to a page you can rank and improve, and that page can still offer every listening app from one place.
Structured data: accurate labels, not a search feature
Schema.org defines a PodcastSeries type for a show, which it describes as an episodic series of digital audio or video files, with a webFeed property for the feed URL, and a PodcastEpisode type for “a single episode of a podcast series.” Marking up the episodes you have built out tells systems that read the markup what it is: a podcast episode, part of a named series, with an associated audio file.
Set expectations accordingly. Google’s gallery of structured data features in Search, last updated in June 2026, does not list a podcast feature. The markup describes the page accurately; it does not produce a special podcast result in Google Search. Add it to the episodes you have built into proper pages. Adding it across an archive of thin, player-only pages labels those pages without improving them.
A workable setup for an existing show
For a show with a back catalog, a practical order is:
- Create an episode page template on your own site with a separate page title field, a summary block at the top and room for a full article.
- Run the archive through the triage question and list the topic episodes.
- Build full pages for those episodes from their transcripts, starting with subjects that have the clearest search demand.
- Give every other episode an accurate summary and show notes on its page, and stop there.
- Change where guest appearances and promotions link, from app listings to your own episode pages.
- For new episodes, decide at planning time whether the topic will get a full page, and write the page title for search while the feed title stays written for the app.
Frequently asked questions
Can Google index the audio of my podcast?
Google’s list of indexable file types covers text formats, images and video, with no audio category. What Google can work with is the text on the episode page, so that text is what needs to answer the searcher’s question.
Should I publish a full transcript on every episode page?
Transcribe the episodes whose topic people search for, and turn those transcripts into structured articles. For conversational episodes with no clear search topic, a good summary and show notes are enough.
Does podcast schema get my show a special result in Google?
Google’s structured data gallery lists no podcast feature. Schema.org’s PodcastSeries and PodcastEpisode types describe the page accurately, which is reason enough to use them on your built-out episodes, but they do not create a podcast result.
Should I optimize for Google Podcasts?
No. Google Podcasts is gone; its address now forwards to YouTube Music. Put the effort into episode pages on your own site and into your listings in the podcast apps your audience uses.