ページインデックスレポートを開いて、赤い数字と「エラー」の文字を見て、とりあえず全部潰そうとする。SEO担当になって最初の頃、たいていこれをやります。
Googleの説明を追っていくと、この使い方はそもそも設計意図と違う、ということが分かります。レポートは修正すべき項目のリストではなく、変化を見つけるための道具だからです。
この記事では、公式ポッドキャスト「Search Off the Record」でSearch Consoleとインデックスについて語られた内容から、レポートの読み方を整理しました。直さなくていいものの見分け方と、逆に本当に直すべきパターンが中心です。
この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。
インデックスレポートは、修正リストではない
第112回（2026-07-16）で、Search Consoleチームからのアドバイスとして紹介されたのがこれです。ページインデックスレポートは「修正すべきリスト」ではなく、パターンや予期しない変化を発見するためのツールとして使うべきだ、と。
言われてみれば当たり前なのですが、UIの見え方がそう思わせてくれません。「エラー」という赤いラベルが並んでいたら、全部潰したくなります。
この認識のずれは、Googleの側もかなり前から把握していたようです。第80回（2024-08-22）では、Search Consoleの通知——canonicalタグにより非インデックス、noindexタグ、404など——は必ずしも問題ではなく単なる状態通知であることが多いのに、多くのユーザーが対応の必要なものと思い込んでしまう、という話が出ています。
考え方を切り替えるなら、こうです。数字の絶対値ではなく、動きを見る。 何かを変更したときにレポートがどう動いたか、あるいは何もしていないのに動いたか。そこに情報があります。
直さなくていい「エラー」
第112回で具体的に挙げられたものを整理します。
削除したページの404
404という文字とエラーというラベルが不安を煽りますが、削除したページに対して404が返るのは期待される正常な動作です。ページを消したなら404が出るのが正しい。
第80回では、5000件の404エラーが実は意図的な商品削除によるものだった、という相談事例が紹介されています。ECサイトなら普通に起きることです。
リダイレクト設定後の「未インデックス（リダイレクト）」の増加
サイト移転やURL変更でリダイレクトを設定したとき、このカテゴリの数字が増えます。これは正常です。
むしろ第112回で指摘されているのは逆で、リダイレクトを設定したのに増加が見られない場合こそ問題のサインだ、ということです。設定が効いていない可能性があります。移転作業のチェック項目として使えます。
canonicalの変更
Googleが別のURLを正規版として選んでいる状態も、それ自体は問題ではありません。むしろGoogleが自分のサイトをどう認識しているかを知る手がかりになる、と説明されています。
意図と違う正規化が起きているなら直す価値がありますが、意図通りなら見るべきは他のところです。
一時的なエラー
第112回では、一時的なサーバーエラーやクロールエラーは通常問題にならない、という文脈で “I think it’s important that people realize that computers don’t always work”（第112回、2026-07-16）という発言があります。
コンピュータは常に正しく動くわけではない。だから一時的なエラーは記録に残るし、それ自体は異常ではない。ここを飲み込めるかどうかで、レポートとの付き合い方がかなり変わると思います。
インデックス率という指標は、存在しない
これが第112回の目玉です。
インデックス済みページと未インデックスページの比率——いわゆるインデックス率——がサイトの品質を示す指標だ、という通説が明確に否定されました。健全なサイトでも大量の未インデックスページがあり得る、という説明です。
例として挙げられているのが、Google自身の開発者ドキュメントサイトのインデックス率は約5%だが健全な状態であるというものでした。Googleが運営していて、SEOの解説を載せているサイトが5%です。
レポート用に「インデックス率」という数字を作って毎月追いかけている場合、その指標には根拠がないことになります。何を代わりに見るかというと、第112回の枠組みで言えば「前月から何が動いたか」です。
site:検索の正しい使い道
インデックス数の確認にsite:検索を使う話は、3年を挟んで2回否定されています。
第61回（2023-06-22）では、site:検索演算子はインデックスされたページの一部しか表示せず、正確なインデックス数の把握には使えないと明言されました。正確な数値はSearch Consoleで確認すべき、と。
第112回でも改めて、site:クエリは正確な指標ではなくSearch Consoleが真実の源であると説明されています。サイト移転後に何年経ってもsite:クエリで古いドメインの結果が出ることがある、という例も挙がっていました。
ただし、site:検索が無価値というわけではありません。第61回では実用的な使い道が挙げられています。
- 望まないキーワードの混入チェック — 意図しない語がサイト内に出ていないか
- ローカライズ版ページの発見 — 地域別・言語別ページの存在確認
- UGCサイトでの不適切な画像のチェック — Google画像検索のsite:検索を使う
つまり「数える」用途には向かないが、「見つける」用途には使える、ということです。この切り分けを持っておくと便利だと思います。
「discovered」と「crawled」の違い
未インデックスの内訳でよく見る2つですが、意味がまったく違います。第112回の説明を整理するとこうなります。
| 表示 | 状態 | 読み方 |
|---|---|---|
| discovered – currently not indexed | URLは見つけたが、まだクロールしていない | クロールの順番待ち |
| crawled – currently not indexed | クロールしたが、インデックスしていない | 品質を見直すきっかけ |
後者は品質懸念のサインになることがある、とされています。ただし重要なのは、技術的に修正すべき問題ではないという位置づけです。直すべきバグではなく、コンテンツを見直すきっかけとして受け取るべきもの、ということになります。
第80回でも同様に、この2つは必ずしも技術的な修正が必要とは限らず、Googleが全ページをインデックスしない場合もあるため、ケースバイケースで判断すべきだと語られています。
品質の評価対象についても補足があります。第112回では、ページの品質はテキストだけでなく、広告やインタースティシャル、フィラーコンテンツを含めたページ全体の体験として評価されている、と説明されました。レシピサイトで本文の前に長い物語が置かれている例が挙げられています。
そしてもう一つ。「crawled – currently not indexed」が並んでいるからといって、そのページを一括削除するのは早計です。第66回（2023-11-21）では、低トラフィックのコンテンツを自動的に削除すべきという発想が否定され、統合やリダイレクトで対応すべきだとされています。
これは本当に直すべき、というパターン
逆に、レポートに出たら対応すべきものもあります。
ボット保護が200を返している
第112回で最も実務的だったのがこれです。CDNやホスティングのボット保護機能が、クロール時に誤って404や403を返したり、ボット確認のインタースティシャルページを200で返したりすることがあります。
200で返るということは、Googleから見れば正常なページです。結果として、複数のページが誤って同一のcanonicalに統合される、という深刻な問題が起きます。
これは第87回（2024-12-05）で語られた「ブラックホール」問題と同じ構造です。エラーページが200を返すと正常なページと同じチェックサムでクラスタリングされ、一度巻き込まれると抜け出しにくくなる、という話でした。
自社サイトがGooglebotに対して何を返しているか、URL検査ツールで一度確認する価値があります。WAFやCDNを入れているサイトほど確認したほうがいいと思います。
ホームページがインデックスされていない
第61回で明言されているのがこれです。新規サイトでホームページすら全くインデックスされない場合、それはほぼ必ず技術的な問題を示します。Googleは新規サイトのホームページを優先的にクロール・インデックスする設計になっているためです。
“it’s pretty hard to get stuff indexed”（第61回、2023-06-22）という発言もあるとおり、下層ページがインデックスされないこと自体は珍しくありません。ですがホームページは別です。ここが落ちているなら、コンテンツではなく設定を疑ってください。
「工事中」のプレースホルダー
ドメイン購入直後のプレースホルダーページは、正規化以前の段階でソフトエラーページと判定されてインデックスされません（第61回）。サイト公開前に「とりあえず」置いたページが残っていないか確認しておくといいと思います。
見え方がおかしいだけのケース
第61回では、hreflangと正規化の組み合わせで、ドイツ・オーストリア・スイス向けのほぼ同一コンテンツが1つに正規化され、レポート上は他の地域版が「インデックスから落ちた」ように見える、という例が挙げられています。実際は正規URLに統合されているだけです。
第78回（2024-07-25）では、hreflangクラスタ内でalternateページが「インデックスされていない」と表示されるのはバグではなく仕様だと説明されました。Search Consoleはcanonicalの情報のみを保存する設計になっているためです。
多言語サイトを運用していると、レポートの数字が実態より少なく見えることになります。焦る前に、これが仕様であることを思い出してください。
「修正済みとしてマーク」はいつ使うか
第112回で説明されています。この機能は、技術的な問題を実際に修正した場合に使うものです。サーバー設定のミスを直した、といったケースが該当します。
押すとGoogleがサンプルページを再チェックし、問題が解消されていれば他のページの再クロールを早めてくれます。逆に言えば、何も直していない状態で押しても意味がありません。
なお、Search Consoleの「インデックス登録をリクエスト」については、第61回で高品質なサイトでは通常不要だと説明されています。速報ニュースなど今すぐ確認したい場合や、テスト目的での利用に向いている機能だ、と。1ページずつ手作業でリクエストを送っている場合は、その時間を別のことに使ったほうがよさそうです。
UIで足りないときはAPI
第80回は、Search Console APIの実務的な使い方を扱った回です。ゲストのMihaiはルーマニアのSEO専門家で、10年近くAPIを使ってツールを作ってきた人物です。
要点はいくつかあります。
データ保持期間は16か月。 以前は90日でしたが延長されています。
パフォーマンスAPIはUIのサンプルとは違う。 UIで表示されるのはサンプルデータですが、APIでは実際に100万ページ分のデータでも取得できるとされています。”I think ranking questions are fundamentally impossible for us as Google to help with.”（第80回、2024-08-22）というJohnの発言もある回ですが、データを自分で取ってきて自分で判断する、という姿勢がこの回全体を貫いています。
URL Inspection APIで一括検査ができる。 UIでは1件ずつしかできない検査を、APIなら数千件まとめて実行できます。大規模サイトのインデックス状況を棚卸ししたいなら、ここが効きます。
インデックス関連レポートのAPI提供は要望段階。 MihaiがAPIへの追加を要望し、Johnが担当者に伝えると回答した、という状況が語られています。ただし大規模データの提供には技術的制約がある可能性も指摘されました。
注意: 第80回は収録から2年以上が経過しています。APIの対応範囲やデータ保持期間は変更されている可能性があるので、実装前に最新の仕様を確認してください。
Google側の障害を疑うとき
自分のサイトの問題ではなく、Google側で何かが起きている場合もあります。第75回（2024-06-06）は、その舞台裏を扱った回です。
内部ではSREチームが自動プローブと監視ルールで異常を検知し、インシデント管理システムが自動的に起票します。優先度が上がってmedium以上になるとSearch Relationsチームに届く仕組みです。
外部に公表するかどうかは、ユーザーやサイト運営者への実際の影響度で判断されます。軽微なものは公表されません。また、意図した仕様の変更が「バグ」として誤解されている場合も公表しないそうです。
具体例として語られているのが、2024年2月1日に発生したインデックス関連の大規模インシデントです。新しいドキュメントの処理ができなくなり、ニュースサイトが最新記事を検索結果に反映できない状態になりました。このときは内部アラートとGoogle Newsチームからの外部報告がほぼ同時（5分差）に届いたため、公表の判断が早くできた、と振り返られています。
第一報を受けたときのGaryの発言が “This is probably not good, and that’s a quote.”（第75回、2024-06-06）でした。
実務的な含意としては、Google検索ステータスダッシュボードを見る癖をつけておくことです。第75回では、このダッシュボードには検索結果の問題を伝えるだけでなく「Google側の問題であり、サイト運営者のせいではない」ことを伝える役割もある、と説明されています。
注意: 第75回は収録から2年以上が経過しており、ステータスダッシュボードの運用方針は変更されている可能性があります。
Googleが否定した、Search Console関連の通説
この記事で扱った否定項目をまとめます。
| 通説 | Googleの説明 | 出典 | 鮮度 |
|---|---|---|---|
| site:検索でインデックス数を正確に確認できる | 一部しか表示されず、確認用途には不向き | 第61回 2023-06-22 | 要確認 |
| site:クエリの結果はインデックス状態を正確に反映する | 人工的なクエリタイプ。Search Consoleが真の情報源 | 第112回 2026-07-16 | 新しめ |
| インデックス率がサイトの品質を示す | 健全なサイトでも大量の未インデックスページがあり得る | 第112回 2026-07-16 | 新しめ |
| レポートの「未インデックス」「エラー」はすべて修正すべき | 多くは期待される正常な動作 | 第112回 2026-07-16 | 新しめ |
| 410と404が同じ表示になるのは不具合 | 内部処理を反映した意図的な仕様 | 第60回 2023-05-30 | 要確認 |
| hreflangのalternateが未インデックス表示なのはバグ | 仕様。Search Consoleはcanonicalの情報のみ保存する | 第78回 2024-07-25 | 要確認 |
| Indexing APIで任意のURLをインデックスさせられる | 対象は求人情報とライブ動画配信のみ | 第94回 2025-06-26 | 新しめ |
| 低トラフィックのコンテンツは削除すべき | 統合やリダイレクトで対応すべき | 第66回 2023-11-21 | 要確認 |
日本のサイト運営者にとって
ここまでの内容で、日本のサイト運営者に特に関わりそうなものを挙げます。ただし、これらの回で日本語検索や日本市場に特化した言及があるわけではありません。日本のサイト運営者が置かれている状況に当てはまりやすい、という程度の意味です。
多言語・多地域サイトを運用している場合
第61回と第78回の内容が直結します。日本語と英語、あるいは日本と台湾のようにサイトを分けている場合、正規化の結果としてレポートの数字が実態より少なく見えます。これを不具合と受け取って設定をいじると、かえって壊れます。
WAFやCDNを入れている場合
第112回のボット保護の話です。国内のホスティングやCDNでも、ボット対策の設定によってGooglebotに意図しないレスポンスを返している可能性があります。URL検査ツールでの確認は、規模を問わず一度やっておく価値があります。
レポートを社内共有している場合
インデックス率を指標として報告している場合、その根拠がないことを共有しておいたほうがよさそうです。代わりに何を見るか——変化の有無と、それが自分たちの施策で説明できるかどうか——に置き換えるのが、第112回の枠組みに沿った形になります。
まとめ
Search Consoleのレポートについて語られてきた内容を並べると、共通しているのは「表示されているものを全部つぶそうとするな」という一点でした。
404も、リダイレクトによる未インデックスも、canonicalの変更も、多くは正常な動作の記録です。インデックス率という指標には根拠がなく、Google自身のドキュメントサイトでさえ5%程度です。site:検索は数える用途には使えません。
その代わり、本当に見るべきものははっきりしています。ホームページが落ちていないか。ボット保護が200でおかしなページを返していないか。変更したのにレポートが動いていない箇所はないか。 このあたりは、放っておくと確実に効いてきます。
レポートを開いたときに、赤い数字ではなく前月からの差分を見る。それだけで、使い方はだいぶ変わると思います。
なお、この記事で「要確認」と付けた項目は、収録から時間が経っており仕様が変わっている可能性があります。実際の対応を決める前には、Search Consoleヘルプと developers.google.com の最新情報を確認してください。
関連記事
- Search Off the Record 全54回まとめ — この記事の元になったピラー記事
- クロールの仕組みと誤解 — クロール量が何で決まるか、Googlebotの正体
- 国際化・hreflang実装ガイド — 多言語サイトでの正規化とレポートの見え方
- レンダリング・JavaScript SEOの現在地 — JSでページが空に見えるケース
コメント