はじめに
調査の目的
本調査は、Googleサーチコンソール（以下、サチコ）で報告されるバグや不具合の種類と原因、対応方法を整理することを目的としています。運営者が問題を正しく把握し、適切に対処できるように分かりやすくまとめました。
対象範囲と構成
調査は主に次の2つに分けて分析します。1) Google側のシステムエラー、2) ユーザー側のサイト設定や実装に起因する問題。それぞれの特徴、よくあるエラー例、確認手順、対応方法、予防策を順に解説します。
本記事の読み方
専門用語はできるだけ避け、具体例を交えて説明します。まず全体像を把握した後、該当する章にある手順に従って問題を確認してください。技術的な箇所には実例と簡単な対処案を示しますので、必要に応じて順を追って対応できます。
注意事項
サチコの表示や通知は一時的に変化することがあります。まずはデータの一時的なズレと恒常的な問題を分けて考えてください。
Googleサーチコンソールで発生するバグの種類と特徴
概要
Googleサーチコンソール（GSC）で報告される不具合は、大きく「Google側のシステムエラー」と「ユーザーサイト側として示される問題」に分かれます。本章では代表的なバグの種類と具体的な特徴を分かりやすく解説します。
主なバグの種類と特徴
- 表示・カバレッジの誤判定
-
特徴：インデックス済みのページが「除外」になったり、存在しないエラーが出たりします。例：noindexを付けていないのに除外扱いになる。短時間で復旧するケースが多いです。
-
インデックス情報の遅延や不一致
-
特徴：実際の検索結果とGSCのインデックス数が合わない。新規ページがいつまでも“未検出”になることがあります。
-
URL検査ツールの不一致
-
特徴：同じURLを検査してもAPI版と画面版でステータスが異なる場合があります。クロール時刻の違いが原因のことが多いです。
-
サイトマップ・クロールエラーの誤報
-
特徴：サイトマップに正しいURLが含まれているのにエラー判定される、またはクロール統計が急にゼロになることがあります。
-
モバイル使用性やAMPの誤検出
-
特徴：特定のCSSや外部スクリプトで誤判定が起き、問題がないページにエラーが出ることがあります。
-
レポートの遅延やデータ欠落
- 特徴：検索パフォーマンスのデータが遅れて表示されたり、特定の期間だけデータが抜けることがあります。
判別のポイント
- 突発的に多数サイトで同じ症状が出る場合はGoogle側の可能性が高いです。
- 自サイトだけで発生し、再現できるならサイト側の問題を優先して調査します。
各種バグは症状の出方でおおよそ切り分けられます。次章ではGoogle側のシステムエラーに焦点を当てて詳しく説明します。
Google側のシステムエラー
概要
Search Consoleに「エラーが発生しました」と出る場合、多くはGoogle側の一時的なシステムエラーです。基本は放置して様子を見る対応が適切で、解決まで数時間から数日かかることがあります。
起きる原因の例
- Googleの内部システム変更（処理の更新や設定変更）
- ロギングや集計処理の一時的な失敗
- 一部サーバーでの不具合や通信障害
こうした原因では、データ収集や表示ロジックだけに影響します。
特徴的な挙動（わかりやすい例）
- インデックスや順位はほとんど変わらないのに表示回数（インプレッション）が急激に減る
- クリック数や平均掲載順位は大きく変わらないケースが多い
このため見た目の数値に乱れがあっても実際のユーザー流入は安定していることが多いです。
対応手順（やさしく丁寧に）
- 焦らず時間をおく：まず数時間〜48時間ほど待ちます。
- 他の指標を確認：クリック数、CTR、掲載順位などを見て実際の影響を判断します。
- Search Consoleのメッセージを確認：トップ画面や通知に案内が出ることがあります。
- 再読み込みとキャッシュ確認：ブラウザや他のプロパティで差がないか確認します。
- 長引く場合は報告：数日経っても改善しなければGoogleのヘルプフォーラムやサポートに報告します。
注意点
短期的な表示異常で大きな対策を取ると、かえって混乱を招きます。まずは影響範囲を冷静に見極めてください。
ユーザーサイト側の問題として認識されるエラー
概要
Googleサーチコンソールで「サイト側の問題」として出るエラーは、サイトの設定やサーバー状態が原因です。代表的なものにカバレッジエラー（401、403、404、ソフト404）、リダイレクトエラー（ループやチェーン）、サーバー接続エラーがあります。
主なエラーと原因
- 401（認証が必要）：ページがログインで保護されていると発生します。例：管理画面や会員ページ。
- 403（アクセス禁止）：ファイルやディレクトリの権限やIP制限、WAF設定が原因です。
- 404（未検出）：URLの削除や誤ったリンクで起きます。
- ソフト404：実際は404相当でも200で返している場合。中身が薄いページに多いです。
- リダイレクトループ／チェーン：A→B→Aのような無限ループや、複数回転送する直列転送でクローラーが辿れなくなります。
- サーバー接続エラー（5xx、タイムアウト）：ホスティング障害やリソース不足、設定ミスが原因です。
確認と対処の手順（具体例）
- 実際のHTTPステータスを確認：curl -I やブラウザの開発者ツールでレスポンスを見ます。
- サーバーログ確認：アクセス／エラーログで原因を特定します。401なら認証設定、403ならパーミッションやWAFのルールを見ます。
- リダイレクト経路を確認：curl -I -L やオンラインのチェッカーでチェーンやループを把握します。可能なら直接1回の恒久的リダイレクト(301)に整理します。
- ソフト404対応：本当に存在しないなら正しい404を返すか、適切なコンテンツでページを充実させます。
- サーバー回復策：リソース増強、設定修正、ホスティング会社への問い合わせを行います。
予防のポイント
- 重要なURLは常に正しいステータスコードを返すようにする。
- リダイレクトは最小限にし、チェーンを避ける。
- サーバー監視とログの定期確認を習慣化する。
- CMSやプラグインの更新を怠らない。
これらを順に確認すると、多くの「サイト側の問題」は解消できます。
重複コンテンツに関するエラー
概要
Googleが複数のページを同一または類似のコンテンツと判断し、どのページを検索結果に表示すべきか決められないときに発生します。結果として一部のページがインデックスされない、または表示順位が低くなることがあります。
主な原因
- 同じ本文を複数のURLで公開している（例: /page と /page?ref=）
- 内部でコピーしたページやテンプレートの使い回し
- フィルターやソートで生成される類似ページ
- 別言語や地域版が適切に指定されていない
確認方法
- Googleサーチコンソールの「カバレッジ」や「URL検査」を確認し、「重複」や「canonical が異なる」などの表示を探します。
- サイト内をクロールして、同一の本文やタイトルが複数存在しないか確認します。
対応方法（実践的な手順）
- 正規化（rel=”canonical”）で代表ページを明示する。例: 複数URLが同じ内容なら代表URLを指定します。
- 301リダイレクトで不要な重複ページを代表ページにまとめる。
- indexさせたくない場合は meta robots=”noindex” を使う。
- URLパラメータが原因ならサーチコンソールやサーバー側で処理する。
- 外部サイトの転載がある場合はオリジナルに誘導するか、コンテンツを差別化する。
注意点
- rel=”canonical”はあくまで指示で、Googleが必ず従うとは限りません。運用後にサーチコンソールで再確認してください。
- 似たページを部分的に残すと、再び重複と判断されやすいので、意図的に差をつけるか統合することをおすすめします。
データの不一致問題
概要
クリック数や表示回数などが他のツールやレポートと合わないことがあります。計測のタイミングや集計方法が異なるためで、必ずしもバグではありません。
よくある原因と具体例
- 計測タイミングのずれ：Search Consoleは処理に遅延が出ることがあり、同じ日付でも数値が変わることがあります。例：昨日のデータが今日更新される。
- 集計方法の違い：ツールごとにセッションやクリックの定義が違います。例：GAはセッション単位、Search Consoleはクリック単位。
- フィルタやプロパティ設定：URLプレフィックスとドメインプロパティで結果が変わります。例：wwwあり/なしで分かれる。
- タイムゾーンやクエリ正規化：時間帯設定やパラメータ処理で差が出ます。
確認手順（簡単）
- 同じ期間・時間帯で比較する。
- 比較するプロパティ（ドメイン/プレフィックス）を揃える。
- フィルタや除外設定をチェックする。
- 数日待って再確認する（処理遅延の可能性）。
対処のポイント
- すぐにバグと断定せず、原因を順に潰すことをお勧めします。
- 必要ならデータをエクスポートして行単位で突き合わせてください。
エラーを確認する方法
概要
Googleサーチコンソールでは「インデックス＞ページ」と「カバレッジ（カバレッジレポート）」でエラーを確認できます。各レポートからエラーの種類と具体的なURLを把握できます。
確認する場所
- インデックス > ページ：サイト内のページごとのインデックス状況を一覧で確認します。エラーや警告の数がわかります。
- カバレッジ：エラー／警告／有効の分類ごとに原因と影響ページ数を示します。
- URL検査ツール：個別URLの現在のインデックス状況やライブテスト結果を確認できます。
手順（簡潔）
- サーチコンソールで対象プロパティを選びます。
- 「インデックス＞ページ」または「カバレッジ」を開きます。
- エラーや警告の項目をクリックすると、影響を受けるURL一覧が表示されます。
- 問題のあるURLをクリックして詳細を確認し、URL検査でライブテストを実行します。
エラー詳細の読み方（例）
- 「クロールエラー」＝サーバー応答が不安定／500番台の問題
- 「ブロック（robots）」＝robots.txtやnoindexが原因
- 「リダイレクト問題」＝無限ループや不適切なリダイレクト
各メッセージには推奨アクションが表示されるので、その指示に沿ってください。
データの活用
影響URLはCSVでエクスポートできます。修正後はURL検査で再テストし、修正が反映されたか追跡してください。
補助確認
ライブテストやサーバーログ、robots.txtの手動確認で原因を絞り込めます。
バグ発生時の対応方法
1. 初動で行うこと
- 冷静に状況を把握します。いつから、どのURLで、どのエラーが出ているかを記録します。スクリーンショットや発生時刻を残すと後で役立ちます。
2. 一時的なGoogle側のエラーの対応
- 一時的な障害は放置して定期確認します。まずはSearch Consoleのステータスや公式フォーラムを確認してください。数時間〜数日で解消することが多いです。
3. ユーザーサイト側の問題を調べる
- URL検査ツールで該当ページをチェックします。よくある原因：サーバーエラー（例：502）、アクセス制限（403）、ページが見つからない（404）、robotsでブロックされているなど。
- 該当する場合は原因を修正し、修正後に再クロールをリクエストします。
4. 他者への問い合わせ方法
- 管理会社やホスティング会社に連絡する際は、以下を明確に伝えます：発生日時、該当URL、スクリーンショット、行った確認手順。対応を依頼する具体的な要望（例：サーバー再起動・ログ確認）を付けてください。
5. 長期間続く場合の対応
- Google側の不具合が長引く場合は、公式の修正を待つしかないことがあります。その間、影響範囲を記録し、必要なら代替の対策（例：影響ページの一時非公開や通知表示）を検討します。
6. 修了後の確認
- 修正後はURL検査で再クロールとインデックス状況を確認します。サイトマップを再送信することも効果的です。記録した情報は運用改善に役立ててください。
予防と対策
早期発見と監視
- サーチコンソールの通知を受け取る受信設定を有効にします。日次でメールやダッシュボードを確認し、異常を速やかに把握します。
サイト設定の基本を整える
- サイトマップを常に最新に保ちます（例：新しいページは自動で追加）。
- robots.txtやnoindexタグを慎重に扱います。誤設定の例として、誤って重要ページをnoindexにすることがあります。
重複と正規化の対策
- canonicalタグを適切に設定します。重複ページがある場合、代表ページを明示します。
- 不要なクエリパラメータは統一（例：utmパラメータはcanonicalで制御）します。
リリースと変更管理
- 大きな変更はステージングで事前確認します。ロールアウト時は段階的に行い、問題が出たら即ロールバックできる体制を整えます。
テストと検証
- モバイル表示、構造化データ、リダイレクトを事前テストします。Search ConsoleのURL検査で個別確認します。
対応フローと記録
- 発生時は誰が何をしたかをログに残します。対応手順をマニュアル化し、担当者に共有します。
定期メンテナンス
- 定期的にサイト巡回（クローラビリティ）やインデックス状況を確認します。月次のチェックリストを作ると継続しやすくなります。
