Transcribe a podcast episode for SEO blog repurposing

Publishing the raw transcript doesn't rank

The intuition is obvious: an hour of audio becomes 9,000 words of text, Google indexes the page, the episode ranks. Reality is different.

Google's helpful-content framing over the last several years has specifically targeted the category of pages that are long, indexable, and not actually written for a reader — which raw transcripts fit exactly. The pages that rank are the ones that answer a searcher's question with structure a reader can scan: headings that map to sub-questions, paragraphs short enough to skim, and concrete takeaways near the top.

A raw transcript is none of that. It's a conversational artifact — false starts, side topics, two people clarifying each other — rendered as prose. Readers bounce within seconds, and bounce metrics are one of the signals the ranking system reads.

What transcript format to actually request

When you transcribe an episode, ask the tool for these three exports. Most hosted services give you all of them from one pass:

• DOCX or TXT — the writing copy. Paragraph breaks, speaker labels, no filler markup. This is what you open next to your editor.
• SRT (with word-level timestamps) — the Shorts captions file. Word-level timing is important because caption-level SRT doesn't know when a phrase starts; you'll spend more time re-aligning than writing captions manually.
• JSON — the machine-readable version with per-word timestamps and speaker IDs. Feed this to a search index or an LLM that finds quotable moments.

Whipscribe exports all three from one transcription. Paste the podcast URL (or upload the MP3), wait for it to finish, download whichever format the next step needs.

The three-rewrite workflow

This is the pipeline we'd recommend to a podcaster who wants one blog post per episode. It takes about 90 minutes of writing work on top of whatever you already invest in editing the audio.

Rewrite 1: The blog post

Open the DOCX transcript. Scan it with the structure question in mind: what specific question did this episode answer? Write that question down. The answer, broken into 4-6 sub-questions, becomes the H2 structure of the blog post.

Now write the post. Not a summary — an original take that uses the conversation as evidence. Good signals you're doing this right:

• Most paragraphs are your words, not the guest's.
• Specific quotes are block-quoted and attributed to the guest.
• You added context the episode didn't have — why the question matters, what a reader does next.
• A reader who never listened to the episode gets real value from the post.

Target length: 1,200 to 2,000 words for a 60-minute episode. The goal isn't length, it's completeness of the answer to the central question.

Rewrite 2: The show notes

Show notes are a different product. They live on the episode page (Apple Podcasts, Spotify, your site) and they're written for listeners who are deciding whether to play the episode.

The structure we'd use:

• A two-sentence summary — what's in the episode, why it's worth an hour.
• A timestamped outline — 5-8 chapter markers with topics. Use the timestamps from the transcript.
• Links for anything mentioned — books, tools, people. Listeners chase these.
• One link to the blog post from rewrite 1, for people who'd rather read.

Show notes are short. A full page of show notes is too long. 250-400 words is the sweet spot.

Rewrite 3: The Shorts (if you ship video)

Shorts are the highest-leverage output per unit of time, and the hardest to do well. Open the SRT file and the audio together. Scan for segments of 30-60 seconds where the guest says something with a clear, complete takeaway — not a setup that goes somewhere, but a full thought that stands on its own.

Realistic yield: three to five usable Shorts per hour of audio. Most conversations don't generate more. Forcing the quota produces Shorts nobody watches.

On the "AI rewrote my transcript into a blog post" temptation

Every transcription tool on the market right now advertises some version of "we'll turn the transcript into a blog post for you." A few of these outputs are decent first drafts. Most are indistinguishable from the thousands of other machine-rewritten blog posts Google is actively demoting.

The difference between a ranking post and a demoted one, on the same underlying transcript, is the human who added structure, context, and a point of view. You do not need a better transcription tool to skip that step; you need to do the step.

Use an LLM for the sub-tasks where it helps — extracting a first-pass outline from the transcript, generating candidate headlines, suggesting pull-quotes — and do the actual writing yourself. This is a 90-minute edit per episode, not a zero-effort loop. The posts that rank were written; the posts that don't were generated.

The SEO-specific details that matter

A few details that routinely move the needle when you're publishing the post:

• Title. The episode's title is usually not the post's title. The episode title is for listeners browsing your feed. The post title is for a search query. Rewrite it.
• Meta description. Write this as a two-sentence answer to the searcher's question, not as a tease. The snippet is a click-through factor.
• Structured data. An Article JSON-LD block plus a FAQPage block if the post answers discrete questions. Both are supported by Google's rich-result guidance and both give the post more surface area in results.
• Internal links. Every post links to 2-3 older posts on adjacent topics and to the episode page. This compounds over months — older posts gain link-equity from every new one.
• Embedded player. Include the episode's audio near the top of the post. It's a session-length signal and it keeps listeners who came for the audio.

What about the transcript page itself?

A reasonable objection: if the blog post is the ranking artifact, why publish the raw transcript at all?

Two cases where we'd still publish it, at a dedicated URL:

• Accessibility. A text version of the episode is a real benefit for hearing-impaired audiences and for anyone who reads faster than they listen. Linked from the show notes, marked with a rel="nofollow" if you're worried about duplicate-content signals.
• Long-tail search. Specific phrases inside a transcript sometimes match niche search queries the blog post doesn't cover. Publishing the transcript catches these tail queries even when the transcript page itself never ranks for a head term.

Both cases are real, but they're second-order benefits. The primary SEO artifact is still the written blog post.

Frequently asked