クロール統計で障害を調べる｜時刻・応答・サーバーログの照合

流入の変化と取得障害を分ける

完成物は、障害の疑いがある期間、影響したURL群、確認資料、修正内容をまとめた記録です。検索クリックの減少だけでは、Googleがページを取れなかったとは判断できません。まずサイトが開くか、最近の公開や構成変更があったかを調べます。

Googleはクロール統計を高度な確認用として案内しています。小規模サイトで障害の兆候がなければ、個別URLの確認や本文の改善を優先し、取得回数を増やすこと自体を目的にしないようにします。

時刻と対象ホストを揃える

調査表に期間、タイムゾーン、ホスト、公開変更、障害通知、応答の種類を残します。wwwの有無や画像配信先が違う場合は、どのホストを見ているかを明記します。別サービスの画像リクエストを自サイトの統計に期待しないようにします。

クロール統計の例示URLは、問題の全件一覧として扱いません。代表例を手掛かりにサーバー側の記録を調べ、同じ時間帯に影響したページがどれくらいあるか確認します。

応答の変化からサーバー記録へ進む

取得失敗や応答時間の変化が目立つ期間を選び、直前のデプロイ、接続制限、認証設定、DB障害を確認します。サーバーログでは時刻、URL、応答コード、処理時間を照合します。Googlebotらしい名前だけで本物と決めないようにします。

少数の代表URLをURL検査と通常の閲覧で確認します。取得できない原因が認証や一時障害なのか、存在しないURLなのかを分けます。正しい404まで一律に成功応答へ変える対応は避けます。

サーバー担当へ渡す表には、利用者の情報を丸ごと貼らず、調査に必要な時刻と対象パスを中心に残します。取得回数の増加と負荷の原因は同じとは限らないため、通常の訪問や別処理の増加も併せて確認します。障害前後で同じ条件の代表URLを使い、別のページを見て復旧したと判断しないようにします。ログの保存期間が短い場合は、必要な範囲を早めに確保します。

公開変更と障害が重なった例

架空の例では、10時の公開後に商品ページの一部でエラーが増え、10時20分に修正したとします。調査表には10時前後の応答、対象テンプレート、修正内容を残します。検索統計の日単位の変化だけで20分の障害範囲を確定しません。

サーバー側の時刻と例示URLを照合し、商品ページ以外も影響したか調べます。修正後に同じURL群を確認し、取得成功と本文の表示を別々に確かめます。この例は診断の進め方であり、実際の障害実績ではありません。

調査を終える前に、再発を見つける条件も決めます。「重要な記事が取得できない」「特定の応答が連続する」など、担当者が判断できる条件にします。単に取得回数が減ったという理由だけで障害通知を増やすと、実際の公開不良を見落としやすくなります。復旧した代表URLと確認時刻を残し、同じ条件で再確認できるようにします。

復旧確認と検索への反映を区別する

修正後は外部から代表URLを開き、応答、本文、画像など必要な資源を確認します。サイトが正常になっても、検索側の統計や掲載状態が同時に変わるとは限りません。確認日と観測結果を残し、すぐに別の大きな変更を重ねないようにします。

再発する場合は、対象URL、時刻、変更履歴をホスティング担当へ渡します。原因が特定できていないときは「サーバー増強で必ず直る」と決めず、どの資源が不足したかを確かめます。

有料監査を足す判断と調査の終点

Search Consoleと既存のホスティングログで原因を絞れるなら、有料監査の契約は必須ではありません。Screaming Frogなどで再確認する場合も、自サイトへの負荷や認証範囲を決め、障害中の大量取得を避けます。

費用はログ保存、監視、調査時間、追加の基盤を分けます。調査の終点はグラフが以前と同じになることではなく、原因と対応を説明でき、重要URLを正常に取得でき、再確認する担当と日程が決まることです。

• 技術SEOの点検ガイド｜クロール・内部リンク・修正確認
• robots.txtの点検｜巡回制御・noindex・必要な素材を区別する
• Core Web Vitalsの実測データを読む｜グループと単発テストを区別する