文字起こしポッドキャストSEO

ポッドキャスト文字起こしSEO:技術的実装ガイド2026

BMMamane B. MoussaFebruary 18, 2026Updated July 2, 20262 min read

Summarize this article with:

実装チェックリスト

文字起こしページを支える書き出しファイル:ページ用のテキスト、プレイヤー用のトラック

ポッドキャストの文字起こしがSEOに効くのは、サーバーレンダリングされたHTMLであり、自分のドメイン上の単一の自己参照canonical URLに置かれ、PodcastEpisodeの構造化データを持っている場合だけです。この3つのうちどれか1つでも間違えると、何百ものエピソードを公開しても1つも順位を取れないまま終わります。このガイドは技術的な実装を扱います。文字起こしがなぜ効くのかという戦略(文字起こしのSEOメリットの記事参照)や、宣伝のやり方(文字起こしでポッドキャストを宣伝する方法参照)はここでは扱いません。

詳細に入る前の手早いチェックリスト:

文字起こしがサーバーレンダリングされたHTMLに含まれている(クライアントサイドJavaScriptで注入されていない)
エピソードごとに1つのURL。ページネーションなし、ホスティングプラットフォーム上に重複なし
自分のドメインのエピソードページを指す <link rel="canonical">
<head> 内に PodcastEpisode スキーマを含むJSON-LDブロック
音声プレイヤーが文字起こしと同じページに埋め込まれている
文字起こし全文がデフォルトでDOM内に表示されている(トグルで隠されていない)
公開後にエピソードURLをGoogle Search Consoleへ送信済み

まず文字起こしをサーバーレンダリングする

ポッドキャストSEOにおける最もよくある静かな失敗要因:ブラウザでは文字起こしが見えるのに、クロール時点ではGoogleに見えていないという状態です。

Googlebotは2段階のプロセスでコンテンツをインデックスします。 フェーズ1では生のHTMLレスポンスを即座に読み込みます。フェーズ2ではヘッドレスChromiumでページをレンダリングしますが、Google自身のドキュメントによれば、そのレンダリングは数時間、場合によっては数週間待たされることがあります。ハイドレーション後にクライアントサイドのAPI呼び出しで文字起こしを読み込んでいる場合、Googleはフェーズ1で空の殻だけをインデックスし、二度と戻ってこない可能性があります。

Next.jsを使っているなら、文字起こしページが getStaticProps か getServerSideProps を使っていることを確認してください(useEffect のフェッチではありません)。手軽な確認方法:curl でページURLを取得し、レスポンスの中に文字起こしに確実に含まれるはずの単語があるか検索します。そこになければ、Googleが最初のクロールで見るコンテンツもありません。

サーバーサイドレンダリングまたは静的生成はこの問題を恒久的に解決し、ページ読み込みも高速化します。これは追加のランキングシグナルにもなります。

エピソードごとに1ページ、ページネーションなし

長い文字起こしを目にすると、「パート1」「パート2」とページを分割したくなるものです。私の見解:やめておきましょう。ページネーションはキーワードカバレッジを断片化し、リンクエクイティを複数のURLに分散させ、しかも今ではクリーンな統合メカニズムが存在しません。

Googleは2019年に rel=next と rel=prev のサポートを廃止しました。 これらのタグはページ分割されたシーケンスを示すために使われ、Googleがシグナルを統合できるようにしていました。現在は機能しません。これらがない場合、分割された各ページは独立して競合することになります。

代わりにすべきこと:

文字起こし全文を1つのURLで公開する(例:yoursite.com/episodes/episode-name-transcript)
ナビゲーション用に上部へ固定表示(sticky)の目次を追加する
ページ内の話者やトピックへのジャンプには <a href> アンカーリンクを使う

ページの長さが心配なら:60分のエピソードは約8,000〜12,000語になり、ロングフォーム記事に匹敵します。中身のある濃いコンテンツである限り、長いページはよく順位がつきます。密度の高い文字起こしはまさにその条件を満たします。

文字起こしページのURL構造

URL構造は小さいながらも持続的なシグナルです。1つのパターンを選び、一貫して適用しましょう。

機能する2つのパターン:

パターン	例	備考
エピソードスラッグ + `/transcript`	`/episodes/ep-42-transcript`	音声ページときれいに分離できる
専用の `/transcripts/` セクション	`/transcripts/ep-42-startup-funding`	すべての文字起こしを1つのサブフォルダにまとめられる

クエリ文字列ベースのURL(?episode=42&view=transcript)は避けましょう。クロールバジェットの無駄につながり、canonicalタグの扱いも面倒になります。また、#transcript のようなアンカーフラグメントも避けてください。URLフラグメントはクローラーに無視されます。

既に /episodes/ep-42 にエピソードページがあるなら、最もシンプルなのは文字起こしを別URLではなくそのページのセクションにすることです。1ページ、1つのcanonical、音声と文字起こしのシグナルが統合されます。会議の文字起こしのワークフローがデフォルトでそうしているように、文字起こしと録音が同じ宛先ページに載る形です。

canonicalタグ:自分のコンテンツを自分のものに

文字起こしが複数の場所に存在する場合、どのURLがSEOの評価を受けるかはcanonicalタグが決めます。

canonicalが必要になる3つのシナリオ:

ポッドキャストホスト(Buzzsprout、Transistorなど)も文字起こしテキスト入りのエピソードページを公開している場合。canonicalがなければ、Googleはあなたのドメインではなく相手のドメインに評価を与えるかもしれません。
同じ文字起こしにサイト内で複数のアクセスURLがある場合(wwwあり/なし、HTTP/HTTPS、末尾スラッシュあり/なし)。
ショーノートや部分的な文字起こしをニュースレターアーカイブやMediumの投稿に配信している場合。

実装：文字起こしページの <head> に以下を追加します：

<link rel="canonical" href="https://yoursite.com/episodes/ep-42-transcript" />

これは自己参照canonicalで、送れる最強のシグナルです。CMSやフレームワークが、別の場所を指すデフォルトのcanonicalでこれを上書きしていないか必ず確認してください。

ホスティングプラットフォームについて：主要なホストの多くでは、ホスト側のエピソードページにcanonicalを設定できません。現実的な解決策は、文字起こし全文を自分のドメインだけに置き、ホストには短い抜粋(150〜200語)と「全文を読む」リンクで自分のページへ戻してもらうことです。そうすれば、より完全なテキストを持つあなたのURLがプライマリとしてGoogleに選ばれます。

JSON-LDでのPodcastEpisodeスキーマ

構造化データはランキングを直接押し上げるわけではありませんが、Googleがコンテンツをより速く理解する助けになり、リッチな検索結果表示を可能にします。Googleは2025年、構造化データによって自社システムがページコンテンツを理解しやすくなりコストも下がると認めており、AI OverviewsやAI Modeでの可視性向上にもつながると述べています。

ページの <head> で PodcastEpisode(AudioObject のサブタイプ)をJSON-LDで使いましょう。JSON-LDはGoogle推奨のフォーマットで、マークアップをHTMLから分離でき、大規模でも保守が最も容易です。

最小限の動作例：

{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "name": "How to Raise a Seed Round in 2026",
  "url": "https://yoursite.com/episodes/ep-42-transcript",
  "datePublished": "2026-06-15",
  "description": "A 45-minute conversation with a first-time founder on raising $1.2M.",
  "duration": "PT45M",
  "episodeNumber": 42,
  "partOfSeries": {
    "@type": "PodcastSeries",
    "name": "The Startup Stack",
    "url": "https://yoursite.com/podcast"
  },
  "audio": {
    "@type": "AudioObject",
    "contentUrl": "https://media.yoursite.com/ep42.mp3",
    "encodingFormat": "audio/mpeg"
  }
}

発見性にとって最も重要なプロパティは name、datePublished、duration(ISO 8601形式。45分なら PT45M)、partOfSeries、そして audio.contentUrl です。公開前にGoogleのリッチリザルトテストでマークアップを検証しましょう。

他の目的(会議、リサーチ通話など)でインタビューを文字起こしする場合も、同じスキーマパターンが使えます:音声文字起こしで文字起こしを取得し、その結果のページにスキーマを組み込みます。

隠された文字起こしの罠

人気のポッドキャスト向けウェブサイトテーマのいくつかは、文字起こし全文をアコーディオンやトグルの中に、デフォルトで折りたたんだ状態で表示します。意図はページをきれいに保つことですが、結果として順位が下がる可能性があります。

Googleの公式見解では、アコーディオンコンテンツもインデックス対象です。 John Muellerは2020年、CSSで隠されたHTMLも考慮されると確認しています。しかし実際のケーススタディでは一貫して、表示コンテンツが非表示コンテンツを上回る結果が出ています。ある公開された実験では、以前アコーディオンで折りたたまれていたコンテンツをページ読み込み時に表示するようにしたところ、オーガニックセッションが12%増加しました。

このギャップが存在するのは、GoogleがHTML内に存在するかどうかだけでなく、ユーザーからどれほど目立つ形で見えるかでコンテンツを重み付けしているためと考えられます。

安全な実装：

コンテナに display:none や visibility:hidden を使わず、文字起こしをページのDOMに表示する
UXの理由で「全文を表示」トグルを使う設計なら、デフォルトで展開状態にし、ユーザーが折りたためるようにする
初期レンダリングで隠されるCSSクラスの中に、文字起こしのコアテキストを絶対に入れない

canonicalの罠:エピソードページ対文字起こしページ

エピソードページと文字起こしページを別々のURLで運営すると、2つ目のcanonical判断が生まれます:エピソードのトピックキーワードでどちらのページを順位付けすべきか？

最も安全なアーキテクチャは両者を統合することです。 音声プレイヤーと文字起こし全文を同じURLに置きます。このアプローチは：

すべてのリンクシグナルを1つのページに集中させる
どちらのページにcanonical優先度を与えるか決める必要をなくす
主要なポッドキャスト出版社(This American Life、Radiolab)がエピソードページを構成する方法と一致する

別々に保つ場合は、文字起こしページが誤ってエピソードページを指すcanonicalを持たないよう注意してください。それがあると、Googleはエピソードページに評価を与え、事実上文字起こしページの順位を抑えてしまいます。

字幕ファイル(SRT/VTT書き出し)については、別のインデックス可能なページではなく、ダウンロード可能なリソースとしてリンクしましょう。字幕ジェネレーターでフォーマットを取得し、HTMLページとしてではなくファイルダウンロードとして提供します。素のSRTファイルをインデックスしても価値はなく、クロールバジェットを希釈するだけです。

noindexの罠を避ける

noindexタグはページをGoogleのインデックスから永久に削除します。正しく使えば有用ですが、誤って適用されると静かなトラフィックキラーになります。

文字起こしページがうっかりnoindexになってしまうシナリオ：

CMSが「下書き」や「限定公開」状態のすべてのページにnoindexを適用しており、公開時に設定を切り替えるのを忘れる
長い文字起こしの薄いコンテンツを避けるため、ページネーションの2ページ目以降に noindex を付けていると、それらのページへのリンクもクロールされなくなる(リンク先ページにnoindexがあると、Googleはそれをnofollow扱いすると判断し、連鎖することがある)
ステージングやプレビュー用URLがインデックスされ、ステージングのrobotsメタタグが本番環境に持ち込まれる

文字起こしページを公開したら、そのURLをGoogle Search ConsoleのURL検査ツールにかけ、「URL は Google に登録されています」という確認を探します。noindexシグナルが見えたら、その発生源を特定してください:ページの <head> 内のメタタグ、X-Robots-Tag HTTPヘッダー、robots.txtルールのいずれかの可能性があります。

また、ページがどこかからリンクされていることも確認してください。サイト内からの被リンクがない孤立ページは、noindexがなくても発見が遅れたり、永遠に発見されなかったりします。

発見のための内部リンク

文字起こしページにはリンクが向いている必要があります。さもないと、インデックスされていてもGoogleが見つけられないことがあります。

機能する3つのリンク配置：

エピソードの音声ページから。 音声と文字起こしが別URLの場合、音声ページからわかりやすい「文字起こしを読む」リンクを追加します。
エピソードのアーカイブ/一覧ページから。 カタログ内の各エピソードカードは、音声プレイヤーだけでなく文字起こしページにもリンクすべきです。
関連記事や過去の文字起こしから。 新しいエピソードで過去に扱ったトピックが出てきたら、文字起こし同士を相互リンクします。これによりトピカルな深みが築かれ、検索エンジンが関係性を理解しやすくなります。

内部リンクは、確立されたコンテンツから新しい文字起こしページへリンクエクイティを受け渡す方法でもあります。エピソードと同じトピックを扱う既存のブログ記事があれば、文脈に沿ったリンクを文字起こしに追加しましょう。このリンクアーキテクチャの構築について詳しくは、文字起こしによるポッドキャストSEOとポッドキャストエピソードからのブログ記事作成をご覧ください。

インデックス状況の検証

公開することとインデックスされることは同じではありません。公開後、各文字起こしページをチェックしましょう。

確認手順：

Google Search Consoleを開き、URL検査に移動して完全なURLを貼り付けます。
「URL は Google に登録されています」を探します。「URL は Google に登録されていません」と表示されたら、「インデックス登録をリクエスト」をクリックします。
Googleで site:yoursite.com/episodes/ep-42-transcript の検索を実行し、表示されることを確認します。
GSCのページインデックスレポートを定期的にチェックします。よくあるブロッキング問題がそこに表示されます：ソフト404、ユーザー指定のcanonicalのない重複、クロール済みだが未インデックス。

初回のインデックスを速くするには、文字起こしページを含むサイトマップを送信し、新しいエピソードを公開するたびにpingを送ります。文字起こしページ専用のサイトマップ(例:sitemap-transcripts.xml)にしておくと管理がきれいです。

音声文字起こし経由で音声をアップロードして文字起こしを取得しているなら、公開と送信のステップをエピソードリリースチェックリストの一部に組み込み、後回しにしないでください。

よくある質問

ポッドキャスト文字起こしページにはどんなスキーママークアップを使えばよいですか?

PodcastEpisode(AudioObjectおよびCreativeWorkのサブタイプ)をJSON-LD形式で、ページhead内のscriptタグの中に記述します。重要なプロパティ:name(エピソードタイトル)、datePublished、description、ISO 8601形式のduration(例:PT42M)、あなたのPodcastSeriesを指すpartOfSeries、contentUrlとencodingFormatを持つAudioObjectを指すaudioまたはassociatedMedia。JSON-LDはGoogle推奨のフォーマットで、マークアップを表示用HTMLから分離できます。

長い文字起こしは1ページにまとめるべきか、複数ページに分割すべきか?

エピソードごとに1ページです。Googleは2019年にrel=nextとrel=prevのサポートを廃止したため、ページネーションヒントはもうシグナルを統合しません。ヒントなしでページ分割すると、各ページはリンクエクイティの一部しか受け取らず、弱い順位しかつかない可能性があります。1つのロングフォーム文字起こしページの方がユーザーにもSEOにも有利です:1つのURL、1つのcanonical、すべてのキーワードカバレッジが1か所に。ページが非常に長い場合は、ナビゲーション用に固定表示の目次を使いましょう。

私のポッドキャストホスト(Buzzsprout、Transistorなど)も文字起こしを表示しています。重複コンテンツ問題がありますか?

可能性としては、はい。ホストが独自ドメインで文字起こしテキストを公開し、あなたのサイトも同じテキストを公開している場合、GoogleはどちらのURLをcanonicalに選ぶか分かりません。あなたのサイトの文字起こしページに自己参照canonicalタグを設定し、ホスト側でcanonical化を制御できるか確認してください。多くはできません。現実的な解決策：文字起こし全文は自分のドメインに置き、ホスティングプラットフォームには短い抜粋かショーノートと、全文ページへのリンクだけを渡すことです。

文字起こしがページ読み込み後にJavaScriptで注入されます。Googleはインデックスしますか?

GoogleはJavaScriptレンダリングされたコンテンツをインデックスできますが、2段階のプロセスを経ます:フェーズ1は生のHTMLを即座に読み込み、フェーズ2はヘッドレスChromiumでレンダリングしますが、数時間から数週間遅れることがあります。フェーズ2が完了するまで、文字起こしテキストはインデックスから見えません。サーバーレンダリング(SSR)または静的生成された文字起こしHTMLはフェーズ1でインデックスされます。Next.jsなどのフレームワークを使っているなら、文字起こしページがハイドレーション後のクライアントサイドフェッチではなく、SSRまたは静的生成を使っていることを確認してください。

文字起こし全文をトグルやアコーディオンの中に隠すとSEOに悪影響がありますか?

実際のリスクです。Googleはアコーディオンコンテンツをインデックスできると言っており、John Muellerは2020年、隠されたHTMLも考慮されると確認しました。しかし実際のテストでは一貫して、表示テキストがCSSで隠されたテキストやJSトグルのテキストを上回っています。あるケーススタディでは、以前隠されていたコンテンツを表示するようにした後、オーガニックセッションが12%増加しました。最も安全な実装：文字起こし全文をデフォルトでページのDOMに表示し、文字起こしコンテナにdisplay:noneやvisibility:hiddenを使わないこと。UXのためにトグルが必要なら、デフォルトで展開し、ユーザーが折りたためるようにします。

参考資料

Try transcription free

Convert any audio or video to clean, unwatermarked text — speaker labels, timestamps, and AI summaries included. First 10 minutes free, no account.

AI contentGoogle policy

AI Content and Google Policy: What the Rules Actually Say

What Google's AI content policy actually says in 2026, which patterns trigger penalties, and why transcribed audio is explicitly allowed. Primary-source verified.

May 26, 202611 min

podcastingSEO

Podcast SEO with Transcripts: What to Actually Expect

The strategy case for transcript SEO: what transcript pages can and cannot rank for, realistic timelines, and when to skip it.

May 26, 202610 min