クロールエラー修正の進め方 Search Consoleとログで決める5つの優先順位

クロールエラー対応が長引く事業組織には、ほぼ共通した失敗があります。Search Console の件数を見続け、一覧の上から順に処理してしまうことです。ところが、検索流入や商談に響くのは件数の多いエラーではなく、売上に近い重要 URL の停止です。Google: クロールとインデックス登録 と Google Search Console: ページのインデックス登録レポート が示す通り、Google は URL 単位で状態を見ています。そうであれば、こちらも URL 群ごとに優先順位を分けて考える必要があります。

結論は明快です。クロールエラー修正は「件数を減らす仕事」ではなく、「重要 URL が止まる理由を特定し、再発を防ぐ仕事」です。最初に重要 URL を決め、次に Search Console の URL 検査ツール で代表 URL を確認し、最後にログで事実を裏づける。この順番を守ってください。月間 PV が 10 万未満で総 URL 数が 5,000 未満のサイトなら、最初からログ全量分析に入る必要はありません。反対に、月間 PV が 100 万を超え、CDN や WAF を挟む環境では、5xx や 403 が絡んだ時点でログ確認を前倒しするべきです。条件ごとに着手順を変えることが、遠回りを減らします。

件数より重要URLから先に直す判断軸を定める

最初にやるべきことは、エラー一覧を見ることではありません。重要 URL の定義を先に決めることです。具体的には、自然検索からの流入が大きいページ、問い合わせや資料請求の直前にあるページ、事業説明や料金など指名検索で見られやすいページ。この 3 群から着手するのが基本です。月間 PV が 10 万未満なら、最初に見る URL は 20 本で足ります。カテゴリ一覧、詳細、料金、導入事例、資料請求、記事上位流入ページの代表を入れれば、原因の多くはそこから見えてきます。

一方で、終了したキャンペーンページや古い絞り込み URL の 404 を先に片づけても、成果はほとんど戻りません。実務では、自然検索の落ち込みが出る案件ほど、主力カテゴリや高流入記事の 5xx、canonical の不整合、内部リンク切れが混ざっています。重要 URL の選定が曖昧なまま件数だけ減らしても、作業報告は作れても検索流入は戻らないままです。

次の表の基準で着手順を分けると、実務で扱いやすくなります。

もっとも、ここでの目安にも例外はあります。月間 PV が少ないサイトでも、リニューアル直後で URL 構造を大きく変えたなら、重要 URL だけに絞りすぎるのは危険です。旧 URL から新 URL への転送漏れが広く出るためです。その場合は、代表 URL に加えて、旧 URL 群をページ種別単位で 100〜300 本ほど抽出して確認した方が早く収束します。

優先順位づけに迷うなら、次の 3 条件で採点すると判断しやすくなります。

• 自然検索から月間 100 クリック以上ある
• その URL、または直後の導線で問い合わせや資料請求が発生する
• サイトマップと主要な内部リンクの両方に載っている

この 3 つを満たす URL は、クロールエラーが少数でも即対応が必要です。逆に 1 つも満たさない URL は、件数が多くても後回しで構いません。

最初の三十分で確認範囲と仮説を絞り込む手順

クロールエラー修正が迷走するのは、初動で見る範囲が広すぎるからです。最初の三十分は、原因を断定する時間ではなく、調査対象を絞る時間に充てるべきです。Google: サイトマップの概要 と Google: サイトマップの作成と送信 にある通り、サイトマップは重要 URL の集合です。サイトマップに入っているのに拾われない URL は、真っ先に仮説を立てる価値があります。

三十分で見る対象は 4 つに絞るのが現実的です。ページのインデックス登録レポート、URL 検査、サイトマップ、直近 7〜14 日の Googlebot ログ。この範囲を超えると、調査のための調査に変わります。特に月間 PV10 万未満のサイトでは、クローラーツールの全件結果や BI ダッシュボードまで最初から開く必要はありません。情報が多いほど前に進むわけではなく、代表 URL の見え方がぼやけるだけです。

使い分けは次の表の通りです。

初動でやるべき確認は、実務では次の 7 項目で足ります。

• ページのインデックス登録レポートで、影響の大きい理由を 3 種類まで絞る
• それぞれの理由から、重要 URL を 3〜5 本ずつ選ぶ
• URL 検査ツールで、インデックス状態、Google が選んだ canonical、最終クロール日を記録する
• 公開テストを実行し、現在の取得結果と過去の判定に差がないかを見る
• 対象 URL がサイトマップに含まれているかを確認する
• 過去 7〜14 日のログで Googlebot のアクセス有無、HTTP ステータス、応答時間、転送回数を抜き出す
• 同じページ種別で 10 URL 以上に同症状があるかを見て、個別不具合か構造不具合かを分ける

ここで重要なのは、代表 URL を先に決めてから全体へ広げることです。100 URL を浅く見るより、同じページ種別の 5 URL を深く見る方が、修正すべき実装箇所に早くたどり着けます。記事詳細、カテゴリ、商品詳細、検索結果、タグ、固定ページのようにページ種別を分けて考えるだけで、原因の輪郭はかなりはっきりします。

Search Consoleとログの役割分担を明確にする

Search Console の画面だけで完結させようとすると、5xx と JavaScript の問題、CDN の制御、bot 対策の誤判定で詰まりやすくなります。逆にログだけを見始めると、どの URL から確認すべきかが決まらず、調査範囲が膨らみます。Search Console で仮説を作り、ログで事実を確かめる。この役割分担を崩さない方が、修正も説明も早くなります。

Google: JavaScript SEO の基本を理解する を読むと、レンダリング後の HTML を確認する重要性が繰り返し示されています。つまり、ブラウザで見えている画面と Google が取得した内容は、一致しない場合があります。初回 HTML に本文が載っていない、API 応答待ちで主要ブロックが空になる、canonical がクライアント側で遅れて差し込まれる。こうしたケースは Search Console だけでは断定しきれません。公開テストとログの両方が必要です。

構成ごとの見方は次の通りです。

• 静的配信や SSR が中心なら、URL 検査とログを組み合わせるべきです。初回 HTML に本文と canonical が出ている前提なら、JavaScript を疑う前に 5xx、転送、内部リンク切れを詰める方が早く片づきます。
• CSR 中心や headless 構成なら、レンダリング後の HTML 確認を最優先にするべきです。API の遅延が 1〜2 秒でも、Google 側では本文欠落として扱われることがあります。特に一覧ページや記事詳細で soft 404 が増えているなら、この確認は省けません。
• CDN や WAF を強く使うなら、アプリログより CDN 側のログを先に見るべきです。Googlebot だけに 403 や 429 が返る例は珍しくありません。社内ブラウザで再現しない時ほど、ここを疑ってください。

ただし、例外もあります。静的配信中心のサイトでも、最近フロント実装を大きく入れ替えたなら JavaScript 由来の崩れは除外できません。逆に CSR 構成でも、重要 URL で 503 が連続しているなら、まずはサーバー負荷と外部 API の失敗を止める必要があります。構成だけで決めつけず、Search Console とログの両方に同じ兆候が出ているかで判断してください。

Search Console の使い方を深めたい場合は、Google インデックス登録を早めたいときの実務手順 Search Console を道具として使い切る も合わせて確認すると、URL 検査の見方を整理しやすくなります。

404とsoft 404を別の問題として見分ける

404 と soft 404 をひとまとめに扱うのは危険です。404 は、本当に不要な URL に正しく返しているなら問題ではありません。むしろ、存在しない URL に 200 を返し続ける方が、Google にも利用者にも不親切です。Google: インデックス登録 や Google Search Console: ページのインデックス登録レポート を見ても、4xx は一定期間クロールされ続けることがあります。だからこそ、404 の件数そのものより、内部リンクとサイトマップに残っていないかを優先して確認するべきです。

一方の soft 404 は、200 を返しているのに内容が薄い、代替先のないページを一律でトップへ転送している、在庫切れや削除済みで実質的に空になっている、といった状態で起きます。これは「存在しない」ではなく、「存在していても役割を果たしていない」問題です。本文を少し足すだけでは解決しません。残すのか、統合するのか、消すのかを決め直す必要があります。

判断基準は次の表で揃えておくと運用しやすくなります。

具体的な方針も明確です。削除済み URL をすべてトップへ送るのは避けるべきです。関連性の弱い転送は、検索評価も利用体験も悪化しやすいためです。商品詳細が終売したなら、同系統の商品一覧か後継商品へ 301、代替がないなら 404 のままにする方が筋が通ります。

サイトの種類ごとの判断も分ける必要があります。

• 記事メディアなら、古い記事の 404 件数より、関連記事や一覧ページに古い URL が残っていないかを先に直すべきです。不要クロールの多くは内部リンクの残りで発生します。
• EC や比較サイトなら、在庫切れページを 200 の薄い状態で放置しない方がよいでしょう。再入荷予定、代替商品、上位カテゴリへの導線がない 200 ページは soft 404 になりやすく、収益ページほど影響が大きくなります。
• BtoB サイトなら、終了した資料ページの 404 より、料金ページ、導入事例、問い合わせ導線に近いページの soft 404 を優先するべきです。件数が少なくても、商談数への影響は大きく出ます。

内部リンクの整理まで詰めたい場合は、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 が、不要なリンク露出を減らす考え方の参考になります。

5xxと転送不備は時刻と経路で再現して追う

5xx と転送不備は、クロールエラーの中でも放置コストが高い項目です。件数が少なく見えても、重要 URL に集中していれば影響は大きくなります。重要ページ種別で 5xx が 1 日 5 件以上、3 日連続で発生しているなら、その日のうちに止血するべきです。月間 PV100 万超のサイトなら、1 日 5 件でも軽く見てはいけません。Googlebot が回る時間帯に失敗していれば、後から件数以上の落ち込みとして表れます。

5xx の原因は、実務では次の 3 つに集まりやすくなります。デプロイ直後のアプリ例外、外部 API や DB 負荷による応答遅延、CDN や WAF の制御ミスです。Search Console の表面上は同じ 5xx に見えても、対処はまったく異なります。だからこそ、対象 URL の発生時刻、応答時間、ステータス、User-Agent、転送回数をログで追う必要があります。

転送不備も同じです。1 hop で終わる 301 は問題になりにくい一方、3 hop を超えるチェーン、ループ、空 URL への転送、JavaScript 依存の転送は修正対象です。特に `http -> https -> www 付与 -> 末尾スラッシュ付与 -> 新 URL` のような多段転送は、設計段階で整理し直すべきです。転送は原則 1 hop、長くても 2 hop まで。これを超えたら、運用上の負債と捉えた方がよいでしょう。

実務での切り分けは次のように進めます。

• デプロイ直後 30 分にだけ 5xx が増えるなら、まずロールバック、キャッシュ削除、アプリ再起動で止血するべきです。原因分析を先に始めると、被害が広がります。
• 深夜バッチや在庫連携と同じ時間帯に 5xx が増えるなら、DB 負荷や外部 API の呼び出し制御を疑ってください。応答時間が 2 秒を超えている重要 URL は、503 が出ていなくても要注意です。
• Googlebot だけに 403、429、503 が返されるなら、WAF や bot 対策、CDN のレート制限を最優先で確認するべきです。アプリのコードだけ見ていても解決しません。
• リニューアル後に転送エラーが増えたなら、旧 URL から新 URL への転送表をページ種別ごとに作り直すべきです。1 本ずつの場当たり修正では収束が遅れます。

例外として、計画メンテナンスで一時的に 503 を返す運用自体は否定されません。ただし、重要 URL でそれを定常的に発生させるなら設計の見直しが必要です。夜間だから問題ないと判断するのは危険です。Googlebot は都合よく避けてくれません。

canonicalとrobotsの衝突を先に解消する

クロールエラー修正で見落とされやすいのが、canonical、robots.txt、noindex、サイトマップの役割を混同してしまうことです。ここは厳密に分けるべきです。重複の整理は canonical、検索結果から外す判断は noindex、クロール負荷の制御は robots.txt。この担当を入れ替えると、意図した挙動になりません。

Google: robots.txt の概要 と Google: robots.txt ファイルの作成と送信 にある通り、robots.txt で遮断しても、外部や内部からリンクされていれば URL 自体は把握されます。さらに Google: noindex を使用してページを検索インデックスから除外 では、noindex を見せたいなら robots.txt で塞いではいけないと案内されています。ここを取り違えて、`noindex + robots disallow` を同時に入れる運用は避けるべきです。Google が noindex を読めなくなるためです。

重複 URL の扱いも同じです。Google: 重複した URL の正規化 と Google: 重複 URL の統合 を前提にすると、並び替え、絞り込み、パラメータ付き URL を整理したい時に robots.txt を使うべきではありません。canonical、内部リンク、サイトマップを揃えるべきです。サイトマップに canonical ではない URL が混ざっている案件では、未登録理由がいつまでも揺れます。

判断基準を表にしておくと、実装指示がぶれません。

ここでも例外はあります。絞り込みページやタグページでも、実際に検索需要があり、独自の説明文と内部リンクが整っていて、月間クリックが一定以上あるなら、一律で noindex にするべきではありません。一般的な目安として、直近 3 か月で自然検索クリックが月 50 以上ある URL は残す余地があります。逆に、クリックがほぼなく、ページ差分も薄いなら、残す理由は弱いと言えます。

内部リンクの露出制御まで見直したいなら、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 も合わせて読むと、canonical だけでは片づかない問題を整理しやすくなります。

修正後三十日間の監視まで運用に組み込む手順

クロールエラー修正は、直した瞬間に終わる作業ではありません。再送信、再クロール確認、再発監視まで回して初めて完了です。修正後に何を見るかを決めていないと、改善したのか、別の問題に置き換わったのか判断できません。Google Search Console: URL 検査ツール で代表 URL の再クロール依頼を出し、Google: サイトマップの作成と送信 に沿ってサイトマップを更新する。この 2 つはセットで実行するべきです。

見るタイミングは、3 日後、14 日後、28 日後の 3 点で十分です。3 日後は技術的な失敗が消えているかを確認します。5xx が止まったか、canonical が修正されているか、robots や noindex の衝突がなくなったかを見る段階です。14 日後は、代表 URL の再クロールが進み、ページのインデックス登録レポートの理由分布が動き始めたかを確認します。28 日後は、流入や掲載順位まで含めて改善が定着したかを評価します。この区切りがないと、「直したはずなのに戻らない」という会話だけが残ります。

再発を防ぐなら、公開前確認にもクロールの視点を入れるべきです。新規ページ公開、URL 変更、リダイレクト追加、サイトマップ更新、robots.txt 変更、canonical の共通部品変更。この 5 点は、担当者が違っても同じ確認表で見る方が安全です。JPSM SEO 編集事業部でも、単発修正より、公開前確認と公開後監視を一体で設計した案件の方が、2〜3 か月後の自然検索の戻り方が安定します。

最後に、今日から動ける形に落とし込みます。クロールエラー対応で迷ったら、次の順で進めてください。

1. ページのインデックス登録レポートから、売上や問い合わせに近い重要 URL の未登録理由を 3 種類まで絞る
2. それぞれの理由から代表 URL を 3〜5 本選び、URL 検査で canonical、最終クロール日、公開テストの結果を記録する
3. 同じ URL をログで追い、5xx、403、429、転送回数、応答時間を確認する
4. サイトマップ、内部リンク、canonical、robots、noindex の整合を取り、代表 URL だけ再送信する
5. 3 日後、14 日後、28 日後の確認日を先に予定へ入れ、理由分布と重要 URL の状態が改善したかを見る

この順番を崩さなければ、件数に振り回される修正から抜け出せます。最初に確認するべきなのは、エラー一覧の総数ではなく、重要 URL が今も機会損失を生んでいるかどうかです。そこから着手してください。