クローラー予算（Crawl Budget）は、検索エンジンが「どのURLを、どれだけ巡回するか」を決める“持ち時間”のようなもの。その実態を一番正直に記録しているのが サーバーログ です。
でも、ログはそのままだと“ただの文字列の山”。
どこから見ればいいの？ どの指標が大事？ bot の挙動ってどう読むの…？
そんな疑問を抱いたまま、GSC のクロール統計だけで判断してしまうケースも多いはずです。
そこで前編では、ログの集め方→整形→識別→基礎KPI→異常の見つけ方 までをひと続きの“型”として整理。
ツールに依存しない 判断基準・チェックリスト によって、誰でも URL粒度で“何が起きているか”を読み解ける状態 をつくります。
「クローラー回遊の実態を、表と数値で説明できるようになりたい！」
そんな人向けの“現場寄りの読み方”ガイドです。
📌 本記事でわかること
-
サーバーログの集め方・範囲の決め方・整形の型（期間・抽出）
-
ボット識別の考え方（UA／挙動／偽装の判断フロー）
-
基本となるクロールKPIの読み方（ヒット数・一意URL・4xx/5xx・応答時間・転送量）
-
ムダ巡回や危険シグナルの見つけ方（急増・偏り・パラメータ無限増殖）
-
URL粒度で「回遊」と「障害」を可視化するためのテンプレート
まず“どのログを、どれだけ集めるか”を決める
サーバーログ解析の第一歩は、「量」と「範囲」の設計です。
ここが曖昧なまま進めてしまうと、後で “必要な記録が足りない” あるいは “不要なノイズが混ざって判定がズレる” といった問題が起きがちです。
ログ解析は、一言でいえば 「観測範囲の設計が半分」。
どれだけ精度の良いツールを使っても、元データの設計がブレていると正しい判断にたどり着けません。
そこで本章では、期間・範囲・整形 の3ステップを「型」としてまとめます。
この型さえ押さえておけば、どのホスティング環境・どの規模のサイトでも再現性のある“読みやすいログ”にできます。
期間の目安 — 直近7〜30日の連続データ（季節変動は別枠）
まず集めるべき期間ですが、基本は 7〜30日の連続データ を確保します。
-
7日間：bot の“急増”や“偏り”をざっくり捉える
-
30日間：クロールの“傾向”や“季節変動”を判断できる
「毎日どれくらい来てる？」という短期観測と、
「1ヶ月でどんなURLが重要と見なされてる？」という中期観測を切り分けるためです。
注意点として、祝日やセール期などのイベント日は bot の挙動も変わるため、必要に応じて別枠で比較すると“ノイズ除去”がしやすくなります。
範囲の決め方 — 公開領域のみを主対象（管理/下書きは除外）
次に、どのURLを解析対象にするか。
基本は 「公開領域」だけに絞る のが鉄則です。
-
管理画面
-
下書き URL
-
ステージング環境
-
パラメータ付きの“内部用ページ”
こうした領域は、クローラーが本来見る必要のない場所。
ここが混ざると 4xx・5xx の比率が不自然に跳ねたり、botが迷ったように見える など、正しい判断ができなくなります。
特におすすめなのが、
「公開領域のパスだけを抽出するフィルタの型」を先に作ること
これだけで無駄なノイズがガッツリ減って、分析が一気に楽になります。
整形の型（ぼかし） — 日時／メソッド／URL／ステータス／サイズ／UA／応答時間 へ列化
最後に、ログの“整形”です。
どんな環境でも共通して扱いやすいのは、次の 7列の基本フォーマット。
-
日時（秒まで）
-
メソッド（GET/POST）
-
URL（クエリ含む）
-
ステータスコード（2xx/3xx/4xx/5xx）
-
レスポンスサイズ（KB）
-
UA（User-Agent）
-
応答時間（ms）
これを“列”として整えておくことで、
-
日時×URL の連打
-
botごとの巡回傾向
-
4xx/5xx の集中箇所
-
P95 応答の悪化ポイント
といった“読みどころ”が一瞬で見えてきます。
特に URLとステータスとUAの3点セット は、
“どのbotが・どこで・何に困っているか”を判断するための最小単位。
このセットが欠けるとクロール予算の可視化は成り立たないので、必ず確保してください。
ボット識別の基本
サーバーログを読むうえで避けて通れないのが 「これは本物のクローラーか？ それとも人間か？」 の判定です。
ここを間違えると、クロール予算どころか 全KPIがズレた状態 になってしまいます。
実務では、UA（User-Agent）で「まず分ける → 例外を補助判定する」という 二段構えの型 がもっとも安全です。
本章では、その“最低限で最大効果”の識別ルールをまとめます。
UAベースの一次判定 — “bot”“crawler” 等の語を含むUAを抽出
最初のフィルタはシンプルで OK。
UA に “bot / crawler / fetch / spider” といった語を含むものを抽出する、これが一次判定です。
例：
-
Googlebot
-
Bingbot
-
スマホ専用 crawler
-
サジェスト／画像検索向け bot
これだけでも、全体の 80〜90% の bot は拾えます。
特に目的別 bot（レンダリング・画像・AMP など）は UA で判別できるため、
-
巡回目的
-
アクセス頻度
-
URLの好み（HTML / 画像 / 動的URL など）
といった“性格”がログからつかめます。
ポイント：
UA は“名札”のようなものなので、まずは名札を信じて仕分けることが重要です。
偽装の考慮 — 一部はUA偽装があるため、挙動と頻度で補助判断（IP逆引きは概念のみ）
ただし困るのが、UA の偽装。
悪意ある bot や、名乗り方が雑なクローラーは UA を誤魔化すことがあります。
そのため、一次判定で漏れたものは 以下の“挙動フラグ”で補助判断 します：
-
単一URLを短時間に高速連打（人間ではありえない）
-
返却 4xx/5xx でもアクセス頻度が落ちない
-
サイトマップや robots を“毎分単位”で読みに来る
-
パラメータページを網羅的に爆撃する
こうした動きは“bot 的な巡回意図”が強く、人間とは明確に違います。
さらに余裕があれば、
IP → 逆引き → 主要クローラーに紐づくか
という概念的な確認も可能ですが、ツール依存になるため本記事では“考え方”のみに留めます
人間トラフィックの除外 — 既知のブラウザUAは別集計（混ぜない）
最後に重要ポイント。
人間のアクセスは、bot と絶対に混ぜないでください。
人間の UA（Chrome／Safari／Firefox／スマホブラウザなど）は、
クリック・滞在・遷移がログに写り、bot とは完全に異なる行動パターンになります。
混ざると、
-
平均応答時間が歪む
-
転送量が人間中心になり bot の傾向が消える
-
“クロール遅い”のか“表示が遅い”のか判別不能
といった“誤読リスク”が一気に跳ね上がります。
そのため、実務では：
-
既知ブラウザ UA は別テーブルへ退避
-
bot 系だけを専用ビューに集約
という二段分離が再現性の高い方法です。
基礎KPIの定義（最小セット）
サーバーログからクローラーの“回遊”と“障害”を読み解くには、まず 最低限の KPI をそろえること が不可欠です。
ここが曖昧だと「なんとなくクロールは来てる気がする…？」程度で止まってしまい、改善の優先順位がつけられません。
逆にいえば、この章の KPI さえ取れていれば、サイト規模に関係なく“クロールの状態”を数値で説明できるようになります。
ヒット数／一意URL数 — どれだけページを巡れているか
最初に見るべきは ヒット数（総アクセス） と 一意URL数（ユニークURL） のセットです。
-
ヒット数
→ bot が“どれくらいの量”巡回したか -
一意URL数
→ 何パスを“実際に見に来たか”
この2つには微妙なズレがあり、そこが読みどころになります。
例：
-
ヒットは多いのに、一意URLが少ない
→ 同じURLを何度も連打（＝ムダ巡回） -
ヒットは少ないのに、一意URLが多い
→ 広く浅く巡回（改善余地が大きい）
さらに、一意URL数は “重要URLのどれだけを見ているか” の基礎にもなるため、後編で扱う「配分の最適化」の土台になります。
ステータス比率 — 2xx/3xx/4xx/5xx の配分（ムダ巡回と障害の目安）
ステータスコードは、クローラーの旅路そのもの。
ここを比率で見るだけで、“ムダ”と“危険”の両方が可視化 できます。
特に注目すべきは、この4つの比率：
-
2xx 正常：どれだけストレスなく巡回できたか
-
3xx リダイレクト：URL正規化の一貫性
-
4xx クライアントエラー：リンク切れ・パラメータ乱立の兆候
-
5xx サーバーエラー：サイト負荷やアプリ障害のシグナル
読み方のポイント：
-
3xx が多すぎる → 正規URLが統一されていない
-
4xx が特定パスに偏る → 内部リンクの破損 or トラップ
-
5xx が連続 → 負荷・障害でクロール予算が奪われている
特に 5xx は“クロール予算を最も消耗させる要因”なので、日次で小さく監視する価値があります。
応答時間（P50/P95） — 混雑時の遅さを把握（INP/LCPへ波及）
クローラーがページを読みに来るときの“体感速度”が、応答時間（Response Time） です。
ここで使うのが、中央値 P50 と、遅い側の指標である P95。
-
P50（中央値）
→ ふだんの“安定”度 -
P95（95パーセンタイル）
→ 混雑や処理遅延の“悪い時の顔”
P95 が跳ねると、以下のような現象が起きがちです：
-
bot が 短時間で巡回を切り上げる
-
一意URLが 減る
-
5xx に近い挙動（タイムアウト）が混ざる
-
結果として 重要URLが見られない日が増える
また、応答遅延はユーザー側の INP/LCP にも波及するため、クロール×UX 両面の“共通ボトルネック”を発見できます。
転送量（平均サイズ） — 重すぎる配信の兆候を検知
意外と見落とされがちですが、転送量（レスポンスサイズ） は bot の巡回効率を決める重要指標です。
サイズが大きいと、単純に 「1URLあたりの時間が増える」＝予算を食う ためです。
特に見るべきは：
-
HTML の平均サイズ
-
画像入りページの極端な増量
-
パラメータページの肥大化
“サイズの急増”は 実装変更・CMS更新・広告タグの増量 などの変化点とリンクするため、月次比較で異常を見つけやすい指標です。
“ムダ巡回”と“危険信号”の見つけ方
ログ解析の醍醐味は、「どこでロスが出ているか」 を読み解けるようになること。
クロール予算は無限ではないため、ムダな巡回や、障害・偏りをいち早く見つけて止めることが最重要です。
この章では、誰でも再現できる “4つの危険シグナル”の見つけ方 を紹介します。
どれもサーバーログを見るだけで判断でき、特定ツールに依存しません。
同一URLの高頻度再訪（短時間の連打）
もっとも単純で、もっとも影響の大きいムダ巡回です。
短時間（数秒〜数分）に同じURLを何十回も叩く
→ これはほぼ間違いなく「状況が悪くて抜けられない」サイン。
典型的な原因は以下の通り：
-
レスポンスが遅く、タイムアウト手前で再訪
-
サーバーが混雑しており、5xx が断続的に出ている
-
リダイレクトループ手前で迷っている
この状態になると 一意URL数が増えない ため、結果として「重要ページを見てもらえない日」が発生します。
チェック方法はシンプルで、
（日時 × URL）のヒートマップを見るだけ で判別できます。
パラメータ違いの量産URL（フィルタ/ソート/検索結果）
次に多いのが パラメータURLの爆発的増殖 です。
-
?sort=
-
?page=
-
?filter=
-
?q=
など、動的に増えるパラメータは、何もしないと bot が“全パターンを読もうとする”ことがあります。
この状態の何が危険かというと：
-
クロール予算が一瞬で消える
-
4xx や 3xx が急増して読みづらくなる
-
正規URLの巡回が押し出される
特に 「検索結果ページ」 や 「無限にページが増えるフィルタリング」 は、もっとも典型的なクロール浪費ポイントです。
見分け方としては、
-
同一パス × 多数のクエリ違い
-
URL末尾のバラつきが異常に多い
この2点を見ればすぐ気づけます。
4xx/5xxの偏在（特定パスに固まる）
ステータスコードの偏りは、“構造的な欠陥”のサインです。
-
4xx が固まる → 内部リンクの破損 or 過剰なパラメータ巡回
-
5xx が固まる → 特定パスがアプリ・DB 負荷のボトルネック
ポイントは “偏り（集中）”を見ること です。
全体の比率より、どこに集まっているか の方が改善につながります。
特に5xxの偏在は危険で、以下の悪循環を引き起こします：
-
応答遅延（P95）が悪化
-
bot が再訪を早める
-
さらにサーバー負荷が増える
-
重要URLが巡回されない
つまり、1本の壊れたパスがサイト全体の巡回効率を壊す ことがあります。
クロールトラップ（無限カレンダー・未制限の内部検索 等）
最後が“もっとも危険”な兆候。
俗にいう クロールトラップ（Crawl Trap） です。
例としては：
-
無限に遡れるカレンダー
-
ソート × フィルタ の無限組み合わせ
-
内部検索でページ数が無制限に増殖
-
同じURLでも日付・IDが細かく変わる生成型ページ
トラップにハマった bot は、以下のような動きをします：
-
同一ディレクトリ配下でヒット数が急増
-
一意URLが異常に多くなる
-
正規URLがほとんど見られなくなる
これは サイト全体のクロール予算が吸い取られる もっとも深刻な状態です。
見つけ方はシンプルで、
-
同じパスで URL が無限に増える
-
ページ番号・日付・ID が規則的に変化し続ける
という2点だけ押さえておけば十分です。
可視化テンプレ（表・ログ雛形）
ログ解析は“読み方を知っていても、データが見づらいと何も気づけない”という壁があります。
そこで本章では、前編の内容をそのまま当てはめられる “可視化テンプレ” を紹介します。
どのツールでも作れるよう、構造だけに絞ったシンプルな型にしています。
■ 日次サマリーテンプレ（bot別の巡回状況）
日付 | Bot種別 | 総ヒット | 一意URL | 2xx% | 3xx% | 4xx% | 5xx% | P95応答(ms) | 平均サイズ(KB) | 備考
読み方のポイントは3つだけ：
-
ヒット × 一意URLの差 → 同一URL連打 or 広く巡回の傾向
-
4xx/5xx の急変 → リンク切れ・負荷・トラップの兆候
-
P95応答の悪化 → 巡回打ち切り → 重要URLの機会損失
毎日の“健康診断”として使うイメージです。
■ URL粒度テンプレ（問題箇所の深掘り）
URL | Bot種別 | ヒット | ステータス分布 | 応答P95(ms) | 備考（パラメータ/重複/トラップ疑い）
こちらは 異常の“原因”を特定するための表。
-
同一URLの高頻度
-
パラメータ爆発
-
5xx/4xx の集中
-
トラップ疑いの遷移パターン
…など、“どのURLがクロールを阻害しているか”を一発で切り出せます。
用語ミニ辞典
● クロール予算（Crawl Budget）
検索エンジンが「どのURLを、どれくらいの頻度で巡回するか」を割り当てる“持ち時間”のような概念。
エラー・遅延・ムダ巡回 があると、この予算が消耗して重要URLが巡回されにくくなる。
● P95（95パーセンタイル）
応答速度の“遅い方5%”の値。
平均では見えない“混雑時の遅さ・ボトルネック”を発見できる。クロール効率を左右する実務指標。
● クロールトラップ（Crawl Trap）
無限カレンダー・内部検索など、URLが無限に増える構造のこと。
bot が抜け出せず、サイト全体のクロール予算を吸い尽くす最悪パターン。
まとめ：ログ解析の設計——“URL粒度のKPI”で回遊と障害を同時に見える化する
サーバーログは、クローラーの“生の行動記録”そのもの。
GSC のサマリーでは見えない URL粒度の回遊実態・ムダ巡回・エラーの偏在 を、KPI で定点観測できるのが最大の強みです。
前編では、ログ解析の基礎として
-
期間・範囲の設計（ノイズ除去）
-
bot識別の型（UA＋挙動の二段判定）
-
基礎KPI（ヒット数／一意URL／4xx/5xx／P95応答／サイズ）
-
ムダ巡回と危険シグナルの見分け方
という“再現性のある読み方”を整理しました。
この設計が固まると、クロール予算の浪費ポイントと改善すべきパス が自然と浮かんできます。
次の後編では、これらの気づきをもとに 「減らす → 整える → 促す」 の順で、重要URLへクロールを寄せる最適化フローを解説します。
別記事への導線：クロール最適化の実務へ進むために
ログ解析で “どこにムダ巡回や障害が潜んでいるのか” が見えてきたら、次は クロール予算の最適化 に進むタイミングです。
後編では、前編で整理した KPI をもとに 重複・トラップ・4xx/5xx を削減し、重要URLへ配分を寄せる具体フロー を解説します。
-
Vol.12【後編】｜クロール予算の最適化：ムダ巡回を削り、重要URLへ優先配分する実務
-
Vol.11【後編】復習｜AIクローラー方針の実装と監視
前編で得た“読み解き力”を、後編では“改善の打ち手”へつなげていきましょう。
今回はここで終わりにしたいと思います！
最後までお読みいただきありがとうございました！
このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶
むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁
私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、
LINEスタンプのキャラ制作に挑戦したりしています👍
デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！
ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。
アイデアが出ないときも、相棒みたいに助けてくれます🎶
さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、
X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅
「AIって便利そうだけど、自分にも使えるのかな？」
と思っている人には、ぜひ読んでほしいです。
このブログは、AI初心者でも副業が始められるように、
体験ベースでわかりやすく書いています。
私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。
Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！
明日のあなたがより豊かになりますように😌
それでは、おやすみなさい😴
