クロール予算最適化のためのログファイル分析

2021年に遡ると、バーミンガムの電子商取引小売業者であるクライアントを引き継ぎました。その企業は約52,000のインデックス済みURLを保有していましたが、製品ページ約18,000ページが3か月以上クロールされていない理由がわかりませんでした。開発チームは推測で対応していました。XMLサイトマップを追加したり、Google Search Consoleにping を送ったり、何をしても効果がありませんでした。それから生のサーバーログを確認すると、約40分で答えは完全に明らかになりました。Googlebotは日々のクロール予算をページネーション化されたフィルターURL、セッションパラメーター、そして1週間に約4,000の独自だが無価値なURLを生成する壊れた内部検索ファセットに浪費していました。完全な無駄。全くのナンセンスです。

重要なポイント：サーバーログには、5万ページを超えるサイトでGooglebotが実際に読み込んだページが正確に記録されており、クロール予算の意思決定には、ログ分析だけが唯一の信頼できる情報源です。

ログファイル分析とはそもそもそのためのものです。虚栄指標のためではなく、取締役会用のスライドのためでもなく、任意の日にクローラーがサイト上で何をしているのかを正確に把握し、無駄を徹底的に削り落とすためのものです。

規模が大きくなるにつれてクロール予算が本当に重要な理由

ここが多くの人が誤解する点です。クロール予算は200ページのブロシュアサイトには関係ありません。Googlebotは数分で処理します。しかし、およそ20,000URLを超えると、確実に50,000URL以上になると、Googleのクローラーは優先順位付けに関して明示的な判断を下します。Googleの公式ドキュメントではこれを「クロール予算」と呼び、2つのコンポーネントに分解しています。クロール率の制限（サーバーに負荷をかけずにGooglebotがクロールする速度）とクロール需要（人気度と更新頻度信号に基づいてGoogleが実際にクロールしたい量）です。

これら両方を操作することはできます。しかし測定できないものは操作できません。そして、ログなしでは適切に測定することはできないのです。

Google Search Consoleなどのアナリティクスツールはクロール統計レポートを提供します。出発点としては悪くありません。しかし集計されており、遅延があり、どの特定のURLがバジェットを消費しているかは教えてくれません。サーバーログなら教えてくれます。Googlebotが行ったすべてのリクエスト、対象のURL、実行時刻、返ってきたHTTPステータスコードがすべて記録されています。それが生のデータです。

ログを取得する

当たり前に聞こえるかもしれませんが、ここで多くの人が止まります。ホスティング設定によって、ログは異なる場所に存在します。

WP EngineやKinstaなどのマネージドWordPressホストでは、ダッシュボードからまたはSFTPを経由して生のアクセスログを取得できます。/logs/ディレクトリを確認します。Nginxを実行しているVPSの場合、アクセスログは通常/var/log/nginx/access.logにあります。Apacheでは/var/log/apache2/access.logにあります。Cloudflareなどのコンテンツデリバリーネットワークを使用している場合、Cloudflare Logpush（エンタープライズティア）が必要です。そうでない場合、オリジンではなくCDNエッジリクエストのみが表示されます。重要な違いです。

バーミンガムのクライアントの場合、Kinstaマネージドサーバーを使用していました。30日分のログを取得しましたが、圧縮.gzファイルで約4.2GBでした。これは大きな50Kページサイトとしてはどうってことない量です。

生ログを解析する際の注意点

ここで本当に2つの選択肢があります。

Screaming Frog Log File Analyserですが、私は90%の時間これを使用しています。ログファイルを直接インポートし、Googlebot ユーザーエージェントでフィルタリングすると、クロールされたURL、クロール頻度、ステータスコード、応答時間の並び替え可能な分類が得られます。正直なところ、ほとんどのエージェンシー業務ではこれが適切なツールです。Screaming Frogのログアナライザーは数GBまでのファイルを処理でき、問題は発生しません。
ELK Stack（Elasticsearch、Logstash、Kibana）で、さらにセットアップが必要で、大幅に強力です。大規模なクライアントまたはエンタープライズ契約のための継続的な監視ニーズがある場合、この投資は価値があります。Seahawk Mediaには、ログを直接Kibanaダッシュボードにパイプしている複数のクライアントがあります。リアルタイム、美しく、Googlebotのクロール頻度が急に低下したときにアラートを設定できます。

1回限りの監査の場合、Screaming Frog Log File Analyserで十分です。継続的なものの場合、ELK Stackを構築するか、少なくともGoAccessを検討してください。オープンソースで、ターミナルで実行され、私がテストした他のほぼすべてのツールより速く大規模なログファイルを処理します。

実際に確認すべきこと

データを読み込んだら、ほとんどの人はそれをながめるだけで、どんな質問をすればいいかわかりません。ログ監査で実際に確認することはこれです：

クロール頻度の分布

URLをクロール頻度で並べ替えてください。つまり、30日間のウィンドウでGooglebotが各URLにアクセスした回数です。ほぼ常に二峰性分布が見つかります。重要なURLのクラスターが頻繁にクロールされています（良い）そして、同様に頻繁にクロールされている無駄なURLの長い尾（非常に悪い）です。その無駄な尾があなたの問題です。

バーミンガムのサイトでは、クロール済みURL上位500個に340個のフィルタ/ファセットの組み合わせが含まれていました。どれもインデックスされていません。検索ボリュームもありません。Googlebotは実際のカテゴリページより?colour=red&size=M&sort=price_ascをより頻繁に訪問していました。信じられません。

ステータスコードの内訳

200以外のすべてをフィルタリングします。具体的には：

繰り返しクロールされている404エラーは、クロール予算の大量出血です。301リダイレクトで修正するか、それらを指す内部リンクにパッチを当ててください。
301チェーン。A → B → Cのようなリダイレクトは2つの無駄なホップです。Googlebotはそれらをフォローしますが、予算がかかり、ジャンプするたびにPageRankが漏れます。
500エラー。Googlebotが500を返すページにヒットして再試行している場合、予算を無駄にしているうえに、時間とともにGoogleのクローラビリティスコアを傷つけています。
304 Not Modified。実際には問題ありません。Googleが鮮度をチェックしており、キャッシュヘッダーが正しく機能していることを意味します。

レスポンスタイムのスパイク

Googleは公開で、サーバーレスポンス時間が遅いとGooglebotがより積極的にクロールしなくなると述べています。ログでクロールされたURLの平均レスポンス時間が500msを超えている場合、特にカテゴリページまたは商品ページの場合、それは他の何よりも先にサーバーサイドキャッシュを修正する必要があるシグナルです。

クロールバジェットキラーの特定

大規模サイトでクロールバジェットを食い潰しているものを、遭遇頻度の高い順にリストアップします。

noindexまたはdisallowのないファセット型ナビゲーション。フィルター、カラーピッカー、サイズセレクター、ソート順序。これらはURL数を幾何級数的に増やします。10個のフィルターオプションと5つのソート順序がある商品カテゴリは、50以上の重複URL変種を生成します。50Kページのサイト全体で、それは潜在的に数十万のURLです。
無限にクロールされるページネーション付きアーカイブ。/page/2、/page/3.../page/847。ブログアーカイブの200ページ目のコンテンツがオーガニック検索値がない場合、noindexするか、robots.txtでページネーションパスをdisallowする必要があります。
URLのセッションID。古いCMSプラットフォーム（および一部のレガシーWooCommerceセットアップ）は?sessionid=abc123def456のようなセッショントークンをURLに追加します。すべてのセッションが一意のURLを生成します。Googlebotはすべてをクロールします。これは古いサイトでの致命的な予算漏れです。
URLパラメータによる重複コンテンツ。内部リンク内の?utm_source=email、クロール可能なURLに漏れるトラッキングパラメータ、アフィリエイトプラグインによって追加される?ref=homepage。Google Search ConsoleのURLパラメータツールで修正し、HTMLレベルで正規化してください。
内部リンクがないが、サイトマップには含まれているオーファンページ。Googlebotはサイトマップを介してそれらを見つけ、クロールし、内部シグナルを見つけず、時間とともに優先度を下げます。しかし、それでも発見クロール時に予算を消費します。
200ステータスを返すソフト404ページ。検索結果がない検索ページ、空のカテゴリページ、削除されたアカウントのユーザープロフィールページ。Googleはこれらをクロールするのに時間を無駄にし、時々インデックスしてしまいます。

見つけた問題の修正

正直なところ、分析のほうが簡単です。実装がプロジェクトを政治的にしてしまいます。

ログ監査を終えて推奨事項を提示する必要があるときの、私の実際のワークフローです：

robots.txtで、クロール対象外にすべきURLパターン、セッションパラメータ、フィルタの組み合わせ、内部検索結果のURLに対してDisallowを設定します。私はDisallow: /*?sessionid=styleというワイルドカードルールを使用しています。デプロイ前に、Google Search Consoleのrobots.txt テスターですべてのルールをテストしてください。
ページネーション2～3ページ目以降にnoindex + nofollowを設定します。コンテンツの更新頻度によって調整してください。ページネーション全体をdisallowすると、Googlebotがリンク先コンテンツを発見できなくなるため注意が必要です。
パラメータ付きURL全てにcanonicalタグを設定し、クリーンなcanonical URLに統一します。これはrobots.txtの設定と併せて、二重の対策になります。
404エラーは出所で修正します。内部リンクを更新するか、301リダイレクトを実装するかのいずれかです。私はScreening Frogのメインクローラーをログデータと組み合わせて使用し、どのページが無効なURLにリンクしているかを特定しています。
XMLサイトマップの衛生管理。200以外のステータスを返すURL、noindexされているURL、またはリダイレクトされているURLをサイトマップから削除します。サイトマップはインデックスさせたいページの厳選されたリストであり、それ以外は何も含まれるべきではありません。

Seahawk は昨年、約65,000ページを持つフィンテックのクライアントを担当していました。その大部分が動的コンテンツで、robots.txtを修正して内部検索のURLパターンをブロックするだけで、GooglebotのジャンクURLs のクロールが6週間以内に61%削減されました。残りの39%のクロールバジェットは、製品ページとカテゴリページにシフトしました。新しいコンテンツのインデックス登録時間は平均23日から6日に短縮されました。これが実際の影響です。

継続的なモニタリングの設定

1回のログ監査はスナップショットにすぎません。優れたクロール予算管理は継続的です。実際のところ、それはどのような形になるのでしょうか?

最低限、30,000ページ以上のサイトであれば、月1回ログを取得して解析することをお勧めします。収益貢献度の高いトップ100のURLに対するクロール頻度の傾向を確認してください。これらのページへのGooglebotの訪問頻度が低下している場合は、何かが変わっています。新しいクロールバジェットのリークがあるのか、サーバパフォーマンスの問題があるのか、PageRankシグナルの低下があるのかを確認してください。

より高度な対応をしたい場合は、GoAccessをcronジョブとして設定して日次ログスナップショットを処理し、サマリーレポートをメール送信するようにしてください。設定に約2時間かかりますが、四半期ごとの監査の間にクロール予算が少しずつ減少することを見逃さずに済みます。

よくある質問

すでに完全にインデックスされている場合、クロール予算は関係ありますか?

ある程度は。完全なインデックス登録が今日実現していても、ずっと続くわけではありません。定期的に新しいコンテンツ、新しい製品、新しいブログ投稿、新しいランディングページを公開している場合、クロールバジェットはその新しいコンテンツがどのくらい素早く発見されるかを決定します。クロールバジェットにリークがあるサイトは、新しいページが数週間にわたって未検査のままになる可能性があります。これは、変化の速いニッチ分野にいる場合、実際の競争上の不利です。

robots.txtを使用して特定のサブフォルダからGooglebotを完全にブロックする必要がありますか?

はい、特定の場合です。管理者エリア、ステージングパス、内部検索結果、パラメータが多いフィルタURLは、すべてDisallowルールの候補として適切です。注意すべき点は、JavaScriptやCSSファイルをブロックしないことです。Googlebotがページを適切にレンダリングするにはこれらが必要です。古いSEOのアドバイスの中には、JSをブロックすべきと言っているものもありますが、それは無視してください。

どのくらいのログデータを分析する必要がありますか?

ほとんどのサイトにとって、30日間が最適なスパンです。それ以下だと低頻度のクロールパターンが見えません。それ以上だと、きちんとしたELKスタックを運用していない限り、ファイルサイズが扱いづらくなります。季節変動のあるeコマースサイトの場合、トラフィック負荷下でのクロール動作を理解するために、ピークシーズンをまたぐ60日間を見ることもあります。

ホスティングプロバイダーが生ログへのアクセスを提供していない場合はどうしたらいいですか？

ホスティングプロバイダーに働きかけてください。ほとんどのマネージドホストはこの機能を備えていますが、ダッシュボードに目立つように表示されていない場合もあります。本当に生ログを取得できない場合は、Cloudflareのボット分析がCloudflareプロキシの背後にあるサイトに対して部分的な情報を提供できますが、実際のログデータの代わりにはなりません。大規模なクライアントアカウントでこれが繰り返して問題になるのであれば、ホストの切り替えを検討してください。

Google Search Consoleのクロール統計で十分ですか？

小規模なサイトであれば、ある程度は。20Kページ以上であれば、いいえ。GSCクロール統計は1日単位で集計されており、URLレベルのデータは表示されません。火曜日にGooglebotが12,000ページをクロールしたことは確認できますが、その12,000ページがどのページであるかは分かりません。ログファイルはそういった解像度を提供します。両方のツールを組み合わせれば、完全な全体像が得られます。

---

正直なところ、ほとんどのSEOはログファイル分析をスキップします。DevOpsの領域のように感じるからです。派手ではありません。ギガバイト単位のタイムスタンプとユーザーエージェント文字列をgrepしています。しかし大規模なサイトでは、クロール予算がどこに使われているかを推測することと、実際に知ることの違いです。そして私の経験では、知ることは常にその2時間の手間の価値があります。

関連記事：2026年のAI検索キーワードリサーチ：その本質、従来型検索との違い、AI検索、多言語SEOについて。