2021年にさかのぼると、インデックス済みURLが約52,000個あるバーミンガムのeコマース小売業者のクライアントを引き継ぎました。彼らは、約18,000の商品ページが3ヶ月以上クロールされていない理由がわかりませんでした。開発チームは推測していました。XMLサイトマップを追加したり、Google Search Consoleにpingを送ったり、何もうまくいきませんでした。その後、生のサーバーログを取得して、約40分で答えは完全に明らかになりました。Googlebotは1日のクロール枠をページネーションされたフィルターURL、セッションパラメータ、および毎週約4,000個の一意だが価値のないURLを生成する壊れた内部検索ファセットに費やしていたのです。完全な無駄でした。完全なナンセンスでした。
重要なポイント：サーバーログには、5万ページを超えるサイトでGooglebotが実際に読み込んだページが正確に記録されており、クロール予算の意思決定には、ログ分析だけが唯一の信頼できる情報源です。Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.
ログファイル分析の本当の目的はそこにあります。虚栄心のメトリクスでもなく、会議室のスライドでもなく、特定の火曜日にクローラーがあなたのサイトで何をしているかを正確に知り、無駄を容赦なく削減することなのです。
規模が大きくなるにつれてクロール予算が本当に重要な理由
ここが多くの人が間違えるところです。クロール予算は200ページのパンフレットサイトにはほとんど関係ありません。Googlebotは数分で処理します。しかし、20,000個のURLを超えた時点で、特に50,000個以上のURLがある場合には、Googleのクローラーは何を優先するかについて明確な決定を下します。Googleの公式ドキュメントではこれを「クロール予算」と呼び、クロールレート制限（Googlebotがサーバーに負荷をかけずにクロールする速度）とクロール需要（人気度と鮮度シグナルに基づいてGoogleが実際にクロールしたい量）の2つの要素に分けています。Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).
これら両方を操作することはできます。しかし測定できないものは操作できません。そして、ログなしでは適切に測定することはできないのです。
Google Search Consoleなどのアナリティクスツールはクロール統計レポートを提供します。出発点としては悪くありません。しかし集計されており、遅延があり、どの特定のURLがバジェットを消費しているかは教えてくれません。サーバーログなら教えてくれます。Googlebotが行ったすべてのリクエスト、対象のURL、実行時刻、返ってきたHTTPステータスコードがすべて記録されています。それが生のデータです。which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.
ログを取得する
当たり前に聞こえるかもしれませんが、ここで多くの人が止まります。ホスティング設定によって、ログは異なる場所に存在します。
WP EngineやKinstaなどの管理されたWordPressホストでは、ダッシュボードまたはSFTPを使用して生のアクセスログを取得できます。/logs/ディレクトリを確認してください。NginxでリアルVPSを実行している場合、アクセスログは通常/var/log/nginx/access.logにあります。ApacheはそれをApacheはそれを/var/log/apache2/access.logに配置します。Cloudflareなどのcdn上にある場合、Cloudflare Logpush（エンタープライズティア）が必要です。そうでなければ、CDNエッジリクエストのみが表示され、オリジンは表示されません。これは重要な区別です。WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.
バーミンガムのクライアントの場合、Kinstaマネージドサーバーを使用していました。30日分のログを取得しましたが、圧縮.gzファイルで約4.2GBでした。これは大きな50Kページサイトとしてはどうってことない量です。.gz files. That's a normal size for a busy 50K-page site.
生ログを解析する際の注意点
ここで本当に2つの選択肢があります。
- Screaming Frog Log File Analyser――これは私が90%の時間に使用するものです。ログファイルを直接インポートして、Googlebot user agentでフィルタリングすると、クロールされたURL、クロール頻度、ステータスコード、応答時間の分類可能な内訳が得られます。正直に言うと、ほとんどのエージェンシー業務にはこれが正しいツールです。Screaming Frogのログアナライザーは数GBまでのファイルを処理でき、これは重要です。 -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
- ELK Stack（Elasticsearch、Logstash、Kibana）――セットアップはより多く、はるかに強力です。大規模なクライアントまたはエンタープライズ契約のための継続的な監視ニーズがある場合、これは投資する価値があります。Seahawkには、ログを直接Kibanaダッシュボードにパイプしているクライアントが数社あります。リアルタイムで美しく、Googlebotのクロール頻度が突然低下したときにアラートを設定できます。 -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.
1回限りの監査の場合、Screaming Frog Log File Analyserで十分です。継続的に行う場合は、ELKスタックを構築するか、少なくともGoAccessを検討してください。これはオープンソースで、ターミナルで実行され、大規模なログファイルをほぼ他のすべてのツールよりも高速に処理します。GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.
実際に確認すべきこと
データを読み込んだら、ほとんどの人はそれをながめるだけで、どんな質問をすればいいかわかりません。ログ監査で実際に確認することはこれです：
クロール頻度の分布
URLをクロール頻度でソートしてください。30日間の期間でGooglebotが各URLにアクセスした回数です。ほぼ常に二峰分布が見つかります。重要なURLのクラスターが頻繁にクロールされている（良好）と、ゴミURLの長い尾部がやはり頻繁にクロールされている（非常に悪い）です。そのゴミの尾が問題です。
バーミンガムのサイトでは、クロール済みURL上位500個に340個のフィルタ/ファセットの組み合わせが含まれていました。どれもインデックスされていません。検索ボリュームもありません。Googlebotは実際のカテゴリページより?colour=red&size=M&sort=price_ascをより頻繁に訪問していました。信じられません。?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.
ステータスコードの内訳
200以外のすべてをフィルタリングします。具体的には：
- 繰り返しクロールされている404――これはクロール予算の大出血です。301リダイレクトで修正するか、それらを指している内部リンクを修正してください。 -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
- 301チェーン――A → B → C へとリダイレクトが連鎖すると、無駄なホップが2つ増える。Googlebotは追跡しますが、バジェットを消費し、毎回のジャンプでPageRankが流出します。 -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
- 500エラー――Googlebotが500を返すページにヒットして再試行している場合、バジェットを浪費しているだけでなく、時間とともにGoogleでのクローラビリティスコアも傷つけています。 -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
- 304 Not Modified――実は問題ありません。Googleが鮮度チェックしており、キャッシュヘッダーが正しく機能していることを意味します。 -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.
レスポンスタイムのスパイク
Googleは公式に、低速なサーバーレスポンスタイムがGooglebotのクロール攻撃性を低下させると述べています。ログに、クロール対象URLの平均レスポンスタイムが500msを超える記録がある場合――特にカテゴリページやプロダクトページ――それは他の何よりも先にサーバーサイドキャッシングを修正する必要があるシグナルです。 that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.
クロールバジェット キラーの特定
大規模サイトでクロールバジェットを食い潰しているものを、遭遇頻度の高い順にリストアップします。
- noindexまたはdisallowなしのファセットナビゲーション――フィルター、カラーピッカー、サイズセレクター、ソート順。これらはURL数を幾何級数的に増やします。10個のフィルターオプションと5つのソート順を持つプロダクトカテゴリは、50以上の重複URL変種を生成します。50Kページのサイト全体では、それは潜在的に何十万ものURLになります。 -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
- 無限にクロールされるページング付きアーカイブ――/page/2、/page/3…/page/847。ブログアーカイブの200ページ目のコンテンツにゼロのオーガニックサーチ価値がある場合、noindexするか、robots.txtのページング経路をdisallowする必要があります。 --
/page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt. - URLのセッションID――古いCMSプラットフォーム（および一部のレガシーWooCommerceセットアップ）は?sessionid=abc123def456のようなセッショントークンをURLに追加します。セッションごとに一意のURLが生成されます。Googlebotはすべてをクロールします。古いサイトでは壊滅的なバジェット漏出です。 -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like
?sessionid=abc123def456to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites. - URLパラメータ経由の重複コンテンツ――内部リンクの?utm_source=email、トラッキングパラメータがクロール可能なURLに漏出、アフィリエイトプラグインによる?ref=homepageの追加。Google Search ConsoleのURLパラメータツールで修正し、HTML レベルでcanonicalを指定してください。 --
?utm_source=emailin internal links, tracking parameters leaking into crawlable URLs,?ref=homepageappended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level. - 内部リンクはないがサイトマップにはあるオーファンページ――Googlebotはサイトマップ経由で見つけ、クロールし、内部シグナルなしで見つけ、時間とともに優先度を下げます。しかし発見クロール上でもバジェットを消費します。 -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
- 200ステータスを返すソフト404ページ――検索結果なしの検索ページ、空のカテゴリページ、削除されたアカウントのユーザープロファイルページ。Googleはこれらのクロールに時間を浪費し、時にインデックスしてしまいます。 -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.
見つけた問題の修正
正直なところ、分析のほうが簡単です。実装がプロジェクトを政治的にしてしまいます。
ログ監査を終えて推奨事項を提示する必要があるときの、私の実際のワークフローです：
- Robots.txtでクロール対象から除外すべきURLパターン（セッションパラメータ、フィルタの組み合わせ、内部検索結果URL）に対して使用します。私はDisallow: /*?sessionid=styleのようなワイルドカードルールを使っています。本番環境にデプロイする前に、Google Search Consoleのrobots.txtテスターですべてのルールをテストしてください。 for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use
Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying. - ページネーション2～3ページ目以降にnoindex + nofollowを設定します。コンテンツの更新頻度によって調整してください。ページネーション全体をdisallowすると、Googlebotがリンク先コンテンツを発見できなくなるため注意が必要です。 on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
- パラメータ付きURL全てにcanonicalタグを設定し、クリーンなcanonical URLに統一します。これはrobots.txtの設定と併せて、二重の対策になります。 on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside robots.txt.
- 404エラーはソースで修正する——内部リンクを更新するか、301リダイレクトを実装するかのどちらかです。私はScreaming Frogのメインクローラーとログデータを組み合わせて、デッドURLにリンクしているページを見つけています。 -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
- XMLサイトマップの衛生管理——200以外のステータスコード、noindexが設定されている、またはリダイレクトされるURLはサイトマップから削除してください。サイトマップは、インデックスしたいページの厳選されたリストであるべきで、それ以外は何も含めないでください。 -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.
Seahawkは去年、ファイナンステック企業のクライアント（約65,000ページ、ほとんどが動的コンテンツ）を担当していました。内部検索URLパターンをブロックするようrobots.txtを修正しただけで、GooglebotがジャンクURLをクロールする頻度が6週間以内に61%削減されました。残りの39%のクロール予算は商品ページとカテゴリーページにシフトしました。新しいコンテンツのインデックス登録期間が平均23日から6日に短縮されました。これが実際の効果です。
継続的なモニタリングの設定
1回のログ監査はスナップショットにすぎません。優れたクロール予算管理は継続的です。実際のところ、それはどのような形になるのでしょうか?
最低限、30,000ページ以上のサイトであれば、月1回はログを取得して解析することをお勧めします。売上を牽引する上位100ページのクロール頻度トレンドを確認してください。そうしたページへのGooglebotの訪問頻度が低下している場合は、何か変わっています——新しいクロール予算の漏れ、サーバーパフォーマンスの問題、またはPageRankシグナルの低下のいずれかです。
より高度な対応をしたい場合は、GoAccessをcronジョブとして設定して日次ログスナップショットを処理し、サマリーレポートをメール送信するようにしてください。設定に約2時間かかりますが、四半期ごとの監査の間にクロール予算が少しずつ減少することを見逃さずに済みます。
よくある質問
すでに完全にインデックスされている場合、クロール予算は関係ありますか?
ある程度はそうです。今日の完全なインデックス登録が将来も継続することを意味していません。新しいコンテンツを定期的に公開している場合（新しい商品、新しいブログ記事、新しいランディングページなど）、クロール予算によってそのフレッシュコンテンツがどのくらい速く発見されるかが決まります。クロール予算が漏れているサイトでは、新しいページが数週間、確認されないまま放置されることがあります。これは急速に変化するニッチ市場では実際の競争上の不利となります。
robots.txtを使用して特定のサブフォルダからGooglebotを完全にブロックする必要がありますか?
はい、特定の場合はそうです。管理者エリア、ステージングパス、内部検索結果、パラメータの多いフィルタURLはすべてDisallowルールの合理的な候補です。注意したい1つのポイントは、JavaScriptまたはCSSファイルをブロックしないことです——Googlebotはページを適切にレンダリングするためにこれらが必要です。古いSEOアドバイスの多くはJSをブロックするよう言っていますが、それは無視してください。
どのくらいのログデータを分析する必要がありますか?
ほとんどのサイトにとって、30日間が最適なスパンです。それ以下だと低頻度のクロールパターンが見えません。それ以上だと、きちんとしたELKスタックを運用していない限り、ファイルサイズが扱いづらくなります。季節変動のあるeコマースサイトの場合、トラフィック負荷下でのクロール動作を理解するために、ピークシーズンをまたぐ60日間を見ることもあります。
ホスティングプロバイダーが生ログへのアクセスを提供していない場合はどうしたらいいですか？
ホスティングプロバイダーに働きかけてください——ほとんどのマネージドホストはダッシュボードで目立たないにしても、これを利用できます。どうしてもロハログを取得できない場合は、Cloudflareのボット分析がCloudflareプロキシの背後にあるサイトの部分的なデータを提供できますが、これは実際のログデータの代替品としては劣るものです。これが大規模クライアントアカウントの継続的なブロッカーになっている場合は、ホストの変更を検討してください。Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.
Google Search Consoleのクロール統計で十分ですか？
小規模なサイトであれば、おそらくそうです。20,000ページを超えるサイトの場合は、いいえ。Google Search Consoleのクロール統計は日ごとに集計されており、URLレベルのデータは表示されません。火曜日にGooglebotが12,000ページをクロールしたことは確認できますが、どの12,000ページなのかはわかりません。ログファイルはその分解能を提供します。両方のツールを一緒に使う——それが完全な画像です。which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.
---
正直なところ、ほとんどのSEOはログファイル分析をスキップします。DevOpsの領域のように感じるからです。派手ではありません。ギガバイト単位のタイムスタンプとユーザーエージェント文字列をgrepしています。しかし大規模なサイトでは、クロール予算がどこに使われているかを推測することと、実際に知ることの違いです。そして私の経験では、知ることは常にその2時間の手間の価値があります。