Googleの公式ポッドキャストがPDFを取り上げた
Google Search Central のポッドキャスト「Search Off the Record」は2026年10月13日、第115回「PDFs in Search: Indexing, AI & Pitfalls」を公開しました。出演は Google の Search Relations チームの John Mueller（ジョン・ミューラー）氏と Martin Splitt（マーティン・スプリット）氏で、Google 検索が PDF をどのように処理し、ランキングや AI 機能でどう扱い、どこに落とし穴があるかを約25分にわたって話しています（出典：Search Off the Record: PDFs in Search: Indexing, AI & Pitfalls、PDFs in Search: Indexing, AI & Pitfalls – YouTube）。
本記事は、2026年10月19日時点で YouTube に公開されている英語字幕をもとに、発言の内容を整理したものです。以下の時刻は動画内の位置を示します。IR 資料・ホワイトペーパー・料金表・採用案内など、日本の組織サイトでは PDF が多く使われているため、実務に関わる部分を中心にまとめます。
PDFはインデックス時にHTMLへ変換される
Splitt 氏によると、Google のインデックス処理には「コンバーター（converter）」と呼ばれる部品があり、レンダリングの直後、インデックスに入る直前の段階で動作します。コンバーターは PDF のほか、リッチテキストや各種の文書ファイル、Excel のシートなど複数の形式に対応しており、PDF の場合は「HTML 版を生成し、以降の処理はほぼ HTML だけを扱う」と説明されています（出典：PDFs in Search: Indexing, AI & Pitfalls – YouTube 3:08〜3:58）。
このため、PDF 内のリンクも変換後の HTML に引き継がれ、通常のページと同じように認識されます。Splitt 氏は PDF を「コンテナ」にたとえ、本文・リンク・図表などを含む文書を、元の形にできるだけ忠実な HTML 表現に変換していると述べています（出典：同上 4:12〜5:02）。一方、PDF に埋め込まれた画像については、画像の存在は認識するものの、画像検索は URL を起点に処理するため「通常の画像のようには処理できないと思う」と、本人の理解として留保つきで話しています（出典：同上 5:09〜5:46）。
ファイルサイズの上限は「明言しない」
PDF のサイズ上限について Mueller 氏が尋ねると、Splitt 氏は「クロール側に上限はあるはずだが、PDF 固有の数値は知らない」「動画や画像と同じように、HTML より大きい上限になっていると思う」と答えています。さらに、上限は将来変わり得るため、数字を示すと長く独り歩きしてしまうことから「文書化には積極的でない」とも述べました（出典：同上 5:59〜8:33）。番組内で具体的な上限値が示されたわけではない点に注意が必要です。
ランキングとAI機能での扱いは通常ページと同じ
HTML に変換されるため、PDF のインデックスとランキングは「ほかの文書とほぼ同じ」で、AIによる概要（AI Overviews）やAIモードにも「表示されると思う」というのが両氏の見解です。Splitt 氏は「JavaScript で生成された内容かどうかを追跡しないのと同じで、元が PDF だったかどうかは気にしない」と表現しています（出典：同上 9:32〜10:04）。
ただし、本1冊分を1つの PDF にしたような長大な文書は、1枚の HTML ページに本を丸ごと載せるのと同じで、検索エンジンがそのページの主題を理解しにくくなるという課題も挙げられています（出典：同上 10:05〜10:31）。
番組の終盤では、Google 以外の AI システムでも PDF が参照されていること、学習やグラウンディング（根拠づけ）に PDF が使われていると考えられることに触れ、「サイトで機能する PDF は AI システムでも機能する。少なくとも Google のものでは」とまとめています（出典：同上 23:00〜24:01）。
PDFの落とし穴
両氏が挙げた問題点は、日本の組織サイトでもそのまま当てはまるものばかりです。
画像化（ラスタライズ）されたPDF
Splitt 氏が「最悪」と表現したのが、ページ全体が画像として保存された PDF です。テキストが存在しないため、Google は内容を読み取れません。確認方法は簡単で、PDF を開いて全選択・コピーし、Google ドキュメントやテキストファイルに貼り付けて文字が出てくるかを見るだけです。文字が出なければ問題があります（出典：同上 11:32〜12:19）。紙をスキャンした資料も同じ状態になりやすく、OCR（光学文字認識）が働く場合はあるものの「当てにはできない」とされています（出典：同上 12:52〜13:15）。画像化されたページは、スクリーンリーダーなど支援技術の利用者にとっても扱いにくいだろう、と Splitt 氏は推測を交えて述べています（出典：同上 12:20〜12:39）。
モバイルでの読みにくさ
PDF は全体をダウンロードしてから表示されるため、HTML のように読み込みながら表示することができず、遅い回線や端末では時間がかかります。印刷レイアウトに固定されているため、ズームしても文字が折り返されない点も挙げられています（出典：同上 13:15〜14:08）。
同じファイルが複数の場所にあると正規化が難しい
PDF はバイナリの塊であるため、同じファイルを別のサイトやパスに置くと、検索エンジンからは「完全に同一」に見えます。HTML の「ほぼ同じページ」とは違い、どれを正規 URL とするかの判断が難しくなります。対策として、HTTP レスポンスヘッダーで rel="canonical" を返す方法（手間がかかるため使う人は少ない、との注釈つき）と、PDF の冒頭に自サイトへのリンクを入れておく方法が紹介されました。後者は、HTML に変換されてもリンクが残るため、少なくとも利用者がサイトにたどり着けるようになります。あわせて、著者・内容の説明・元の掲載場所などのメタデータを埋めておくことも勧められています（出典：同上 14:11〜16:13）。
読ませたくない場合
パスワード保護をかければ検索エンジンは内容を読めず、robots.txt でブロックすれば PDF 自体を見に行かなくなります（出典：同上 16:14〜16:47）。
更新時はファイル名を変える
PDF は HTML に比べて編集が面倒で、元ファイルから再生成する必要があります。Mueller 氏は、自身の理解としてと断ったうえで、Google 側も画像と同様に「PDF はあまり変わらない」前提で動いており、頻繁には再クロールしないと説明しました。そのため、内容を変更したときは新しいファイル名で公開し、そこへのリンクを置くのが合理的だとしています。新しい URL と認識されれば、Google はそれをクロールしてインデックスしに行くからです。大きなファイルを何度も取得させないよう、HTTP のキャッシュ設定を整えることも勧められました（出典：同上 16:47〜18:53）。
また、かつて一部の CMS にあった「ページを PDF で表示する」機能のように、HTML ページと同じ内容の PDF を自動生成していると、古い内容の PDF と新しい HTML が同時にインデックスされて競合したり、内容がずれたりします。頻繁に更新される動的なコンテンツを PDF にする場合は、クロールやインデックスの対象にしない方がよい、というのが番組内での助言です（出典：同上 18:53〜20:23）。
PDFで公開してよいのか
「サイト運営者として PDF を公開すべきか」という問いに対する答えは「内容がそれを必要とするなら、はい」でした。印刷時の見た目を厳密に揃える必要がある場合や、記入用のフォームなど対話的な要素がある場合は PDF が向いており、長い文書を特定の書式で整える用途にも適しています。HTML の方が柔軟で望ましいとしつつ、レストランのメニューを例に「PDF しかないなら、メニューがないよりはよい」とも述べています（出典：同上 8:35〜9:31、21:07〜22:35）。
一方で、メニューを PDF にするか通常のページにするかを選べるなら、ズームや折り返しが効き、モバイルでも速く表示される通常のページの方が扱いやすい、というのが Mueller 氏の見方です。テキストが選択・コピーできる PDF であれば検索には使えるので、SEO の観点で「使えない」わけではない、とも付け加えています（出典：同上 21:34〜22:50）。
日本の組織サイトでの実務ポイント
番組の内容を踏まえると、PDF を多く公開している組織が確認すべき点は次のとおりです。
検索で見つけてほしい内容は HTML を主、PDF を従に。 決算資料やホワイトペーパーをすべて HTML 化するのが難しくても、要旨・主要な数値・目次に当たる内容を掲載ページの HTML に書き、PDF はそこからリンクする構成にすると、変換に頼らずに内容を伝えられます。
テキストレイヤーの有無を必ず確認する。 番組で紹介された「全選択してコピーし、テキストエディタに貼り付ける」確認は、誰でもすぐにできます。スキャンした紙資料や画像として書き出したスライドは、見た目は文書でも Google には読めません。日本語 PDF は縦書きや外字、フォントの埋め込み方法によってコピー結果が崩れることもあるため、実際に貼り付けて確かめるのが確実です。
更新した PDF を同じ URL で上書きし続けない。 料金表や決算資料を同じファイル名で差し替えると、検索結果に古い内容が長く残る可能性があります。年度や版を含むファイル名で公開し、掲載ページのリンクを切り替える運用が番組の助言に沿っています。
HTML 版と PDF 版の重複は整理する。 同じ内容を両方で公開する場合は、どちらを検索結果に出したいかを決め、PDF 側で rel="canonical" の HTTP ヘッダーを返すか、不要な PDF 版はインデックスさせない設定にします。URL の正規化の考え方は「URLの正規化方法 canonical属性の使い方」を、HTTP ヘッダーでの noindex の指定は「noindex/nofollowの使い方とX-Robots-Tag」を参照してください。
PDF の冒頭に自サイトへのリンクとメタデータを。 発行元のページへのリンクを文書の最初に置き、著者・説明・出典 URL のメタデータを埋めておくと、PDF が単体で転載・共有された場合でも元のサイトへの導線が残ります。
ファイルサイズについては、番組では PDF 固有の上限が示されませんでした。Google が公開している HTML のサイズ制限と、その読み方については「Googleの Martin Splitt と Gary Illyes の発言をもとに、SEOにおけるファイルサイズ制限の正しい理解と最適化の実務ポイントを解説」で整理しています。
まとめ
Google は PDF をインデックス時に HTML へ変換し、以降は通常のページと同じように扱います。したがって PDF も検索結果や AI 機能に表示され得ますが、画像化された PDF は読み取れず、モバイルでは扱いづらく、同じファイルの複製は正規化が難しく、更新も反映されにくいという弱点があります。両氏の結論は「PDF が必要な内容なら PDF でよい。ただし、HTML にできるものは HTML の方がすべてが少し楽になる」というものでした。2026年10月19日時点の番組内容に基づく整理ですので、Google の公式ドキュメントに新たな記載が加わった場合はそちらを優先してください。
