Googleがページを無視する理由：よくあるインデックス問題の解決法
ページを公開します。待ちます。数日が数週間になり、ページがGoogleに表示されません。Search Consoleにインプレッションはなく、トラフィックもなく、Googleがそのページの存在を知っているという兆候すらありません。これはSEOにおいて最もフラストレーションの溜まる経験の一つであり、同時に最も一般的な経験の一つです。
良い知らせ：Googleはほぼ常に、ページを無視した理由を教えてくれます。悪い知らせ：シグナルが複数のツールやレポートに分散しており、根本原因は明らかな設定ミスから微妙なアーキテクチャの欠陥まで多岐にわたります。このガイドでは、Googleがコンテンツのインデックスを拒否するすべての主な理由を、それぞれの実践的な診断ステップとともに解説します。
1. noindexディレクティブ
最も直接的な原因です。ページにnoindexディレクティブがある場合、Googleはクロールしますがインデックスから明示的に除外します。
noindexが現れる場所：
- メタタグ：HTMLの
<head>内の<meta name="robots" content="noindex">。 - X-Robots-Tagヘッダー：HTTPレスポンスヘッダーとして送信される
X-Robots-Tag: noindex。これはページソースに表示されないため特に厄介です—レスポンスヘッダーを直接検査する必要があります。
診断方法
- Google Search Consoleでページレポートに移動します。「『noindex』タグにより除外」のステータスを探します。
- URL検査ツールを使用して特定のURLを確認します。Googleが
noindexを検出したかどうかが表示されます。 - ドメインに対してSpider.esレポートを実行し、どのボットが
noindexディレクティブに遭遇するか、その発生源がどこかを確認します。 curl -IまたはブラウザのDevToolsでHTTPレスポンスヘッダーを確認します。サーバーやCDNレベルで設定されたX-Robots-TagがCMSの意図を上書きしている可能性があります。
よくある原因：ステージング環境のnoindex設定が本番環境にそのまま反映された場合、CMSプラグインがページネーションやアーカイブページにnoindexを追加する場合、CDNやリバースプロキシレイヤーがX-Robots-Tagヘッダーを挿入する場合。
2. canonicalが別の場所を指している
rel="canonical"タグは、ページの「優先」バージョンがどのURLかをGoogleに伝えます。ページAがcanonicalをページBと宣言すると、ページAにユニークなコンテンツがあっても、GoogleはページBをインデックスしページAを無視する可能性があります。
よくあるcanonicalの間違い
- 誤った自己参照canonical：クエリパラメータを含む、プロトコルが異なる（http vs https）、または末尾のスラッシュが一致しないcanonicalタグ。
- CMSが生成したcanonical：一部のシステムがページネーションページ、フィルタービュー、AMPバージョンを誤ったcanonicalターゲットに指定します。
- クロスドメインcanonical：コンテンツをシンジケートし、シンジケーションパートナーのcanonicalが自社URLを指している場合、Googleはあなたのバージョンより相手のバージョンを選ぶ可能性があります。
- 矛盾するシグナル：HTMLのcanonicalは一つのことを言い、HTTPヘッダーは別のことを言い、サイトマップは第三のURLをリストします。Googleは推測しなければならず、間違える可能性があります。
診断方法
Search ConsoleのURL検査ツールを使用します。「ページのインデックス登録」の下で、ユーザーが宣言したcanonicalとGoogleが選択したcanonicalが表示されます。異なっている場合は問題があります。
3. クロールバジェットの浪費
Googleは各サイトに有限のクロールバジェットを割り当てます—クロール頻度（需要）とサーバーが処理できる速度（容量）の組み合わせです。サイトが価値の低いページにバジェットを浪費すると、重要なページがまったくクロールされない可能性があります。
バジェットキラー
- ファセットナビゲーション：数千のフィルター組み合わせがほぼ重複するページを生成します（
/shoes?color=red&size=10&brand=nike&sort=price）。 - 内部検索結果ページ：すべてのクエリがGoogleがクロールしようとする新しいURLを作成します。
- 無限カレンダーやページネーション：クローラーが「次へ」リンクを無限に辿る可能性があります。
- URL内のセッションID：各セッションがすべてのページの複製を作成します。
- ソフト404：200ステータスコードを返すが「結果なし」コンテンツを表示するページ。Googleはクロールにバジェットを浪費した後、中身がないことを判断しなければなりません。
診断方法
Search Consoleのクロールの統計情報レポートで、総リクエスト数、平均応答時間、レスポンスコードの内訳が表示されます。クロールされたURLの大部分が価値の低いフィルターページであれば、バジェットが漏れています。サーバーログ分析はさらに深い洞察を提供します—Googlebotが最もアクセスするパスを特定してください。
4. シンコンテンツまたは重複コンテンツ
Googleはページをクロールした後、インデックスする価値がないと判断する場合があります。ページインデックスレポートでは、「クロール済み - 現在インデックスに登録されていません」または「検出 - 現在インデックスに登録されていません」と表示されます。
理由には以下が含まれます：
- シンコンテンツ：ユニークなテキストが非常に少ないページ—最小限のコンテンツのボイラープレートテンプレート、スタブ記事、説明のない自動生成カテゴリページ。
- ほぼ重複するコンテンツ：実質的に類似したテキストを持つ複数のページ。Googleは1つを選び、残りを除外します。
- 低品質または低需要：Googleは、ページがインデックスへの含有を正当化するほどの十分な価値を加えていないと単純に判断する場合があります。
修正方法
シンページをより少なく、より充実したページに統合します。テンプレートページにユニークで実質的なコンテンツを追加します。canonicalタグを使用して重複を優先バージョンに指定します。ページに本当に価値がない場合は、削除するかrobots.txtでブロックして、重要なページのためのクロールバジェットを確保することを検討してください。
5. サーバーエラー（5xx）
Googlebotが持続的な5xxサーバーエラーに遭遇すると、クロールレートを下げ、最終的に影響を受けたページをインデックスから削除する可能性があります。一時的な障害時の単発の500エラーは問題ありません—Googleはリトライします。しかし、繰り返されるサーバーエラーは信頼性の低いホストを示し、Googleはクロール頻度と深さを減らして対応します。
診断方法
- Search Console > クロールの統計情報：5xxレスポンスの急増を探します。
- Search Console > ページレポート：「サーバーエラー（5xx）」のエントリを確認します。
- サーバーモニタリング：稼働監視ツールを使用して、Googlebotより先にダウンタイムや遅延レスポンスを検知します。
6. リダイレクトチェーンとループ
リダイレクトチェーンは、URL AがBに、BがCに、CがDにリダイレクトされるときに発生します。Googleはチェーン内で最大10個のリダイレクトを辿りますが、各ホップはクロールバジェットを浪費しリンクエクイティを希薄化します。長いチェーンやループはGoogleに完全に諦めさせます。
よくあるシナリオ
- HTTP-to-HTTPSマイグレーションがwwwからnon-wwwへのリダイレクトの上に重なる：
http://www.example.com→https://www.example.com→https://example.com。すべての古いリンクに対して2ホップが発生します。 - CMSスラッグ変更によるチェーン作成：古いスラッグが中間スラッグにリダイレクトし、それが現在のスラッグにリダイレクトします。
- リダイレクトループ：AがBにリダイレクトし、BがAに戻ります。Googlebotは即座に断念します。
修正方法
チェーンをフラット化して、すべてのリダイレクトが最終目的地を直接指すようにします。マイグレーション後にリダイレクトを監査します。Spider.es、Screaming Frog、またはコマンドラインのcurl -Lを使用して完全なリダイレクトパスをトレースします。
7. 孤立ページ
孤立ページは、サーバー上に存在するがそこを指す内部リンクがないURLです。サイト上のどのページもリンクしておらず、サイトマップにも含まれていない場合、コンテンツがどれほど優れていてもGoogleはそれを発見する方法がありません。
診断方法
サイトマップとサーバーログのURLを、フルサイトクロールで発見されたURLと比較します。サイトマップにあるがクロールグラフにないURLは、事実上孤立しています。また、Search Consoleの「検出 - 現在インデックスに登録されていません」レポートも確認してください：Googleが（外部リンクや古いサイトマップを通じて）URLを発見したが再訪問しない場合、内部リンクの弱さが原因かもしれません。
修正方法
関連性があり、よくクロールされるページからコンテキストに合った内部リンクを追加します。孤立ページがXMLサイトマップに含まれていることを確認します。サイト構造を定期的に監査してください—特にリデザイン、マイグレーション、大量のコンテンツ削除の後は既存のリンクが壊れる可能性があります。
8. robots.txtによるブロック
robots.txtがGooglebotのURLへのアクセスをブロックしている場合、Googleはページをクロールできません。他のページがリンクしている場合、URLをインデックスすることは可能ですが、コンテンツなしで—結果として最小限の役に立たないリスティングとなります。Search Consoleのページレポートでは「robots.txtによりブロック」と表示されます。
これは特定と修正が最も簡単な問題の一つです。Spider.esレポートを実行して、すべてのパスでGooglebotに影響を与えている正確なルールを確認し、robots.txtを適切に更新してください。
診断チェックリスト
ページがインデックスされていないときは、以下の順序で確認してください：
- Search ConsoleでURL検査：Googleはそのページを認識しているか？どのステータスを報告しているか？
- noindexの確認：メタタグおよびHTTPレスポンスヘッダーを検査します。
- canonicalの確認：自分自身を指しているか、別の場所を指しているか？
- robots.txtの確認：URLがブロックされているか？Spider.esでボット別の内訳を確認します。
- HTTPステータスコードの確認：200か？リダイレクトか？404や5xxか？
- 内部リンクの確認：ホームページからリンクを辿ってそのページに到達できるか？
- サイトマップの確認：URLが含まれているか？
- コンテンツ品質の確認：インデックスを正当化するのに十分なユニークで価値あるコンテンツがあるか？
まとめ
Googleがページを無視するのは、ほとんどの場合ランダムではありません。クローラーにスキップ、延期、または優先順位の低下を指示する技術的なシグナルがほぼ常に存在します。課題は、数十の可能性のある原因の中からそのシグナルを見つけることです。Search Consoleから始め、Spider.esのようなクローラーの視点を示すツールで補完する体系的な診断が、不透明な問題を解決可能なものに変えます。根本原因を修正し、URLを再送信し、Googleがピックアップするまでモニタリングしてください。