SEO のログファイル分析：サーバーログを読み、クロールの無駄を修正する

クイック診断

SEOはあなたに向いている？どう始めるべき？

質問 1 / 425%

あなたの商品はGoogleで検索されていますか？

はい、そう思ういいえ、新しいか非常にニッチわからない

サーバーログが記録するもの、そしてほかのデータより優れている理由

ファイルがサーバーからリクエストされるたびに、サーバーはアクセスログに 1 行を書き込みます。多くのサーバーは Apache の「combined」形式に近い形式を使用します。Googlebot のリクエストは次のようになります。

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

左から右へ読みます。IP アドレス、タイムスタンプ、HTTP メソッドと URL、ステータスコード（ここでは 200）、送信されたバイト数、リファラー、ユーザーエージェントです。画像、CSS ファイル、リダイレクト、404 エラーなど、アナリティクスツールではページビューとして表示されないリクエストも含め、すべてのリクエストが記録されています。

ほかのデータソースは、それぞれ一部しか見ていません。Search Console のクロール統計レポートは集計されたデータで、Google のクローラーのみを対象とします。アナリティクスツールは、ブラウザがサイトの JavaScript を実行した訪問者しか記録しません。Screaming Frog のようなサイトクローラーは、リンクをたどって到達できる範囲を示すものであり、Google が実際にリクエストした内容とは同じではありません。実際に起きたことを記録するのは、サーバーログだけです。

ログ分析が重要な理由：クロールバジェットをわかりやすく

クロールバジェットとは、Google がサイト上でクロールできて、かつクロールしたいと考える URL の集合です。Google はこれを次の 2 つの要素で説明しています。1 つ目はクロール容量の上限で、Google のクローラーがサーバーに負荷をかけずに開ける接続数のことです。この上限は、サイトが健全に保たれていると上がり、応答が遅くなったり 5xx や 429 エラーを返したりすると下がります。2 つ目はクロール需要で、サイトの規模、コンテンツの更新頻度、品質、ページの人気度によって決まります。

Google はこのテーマを、大規模サイト向けの上級ガイドとして扱っています。おおよその目安は、コンテンツがおよそ週に 1 回更新される 100 万ページ以上のユニークページを持つサイトと、コンテンツが毎日更新される 10000 ページ以上のユニークページを持つサイトです。「Discovered - currently not indexed」の状態にある URL が多いサイトも対象になります。小規模なサイトは通常、最新のサイトマップと、ページのインデックス登録レポートの定期的な確認で足ります。だからといってログが役に立たないわけではありません。クロールに問題がある場合、ログは問題の所在を最も速く正確に示してくれます。

サイトがその範囲に入る場合、問題はログを読むかどうかではなく、どのくらいの頻度で読むかです。単発の監査では現時点の無駄がわかり、月次のエクスポートでは、修正によって Googlebot の時間配分が変わったかどうかがわかります。用語の背景については、クロールバジェットの用語集が基礎を説明し、Discovered, currently not indexed のガイドは、この種のレビューのきっかけになることが多いステータスを説明しています。

手順ごとの方法

以下のワークフローは、どのサーバーやどのツールでも機能します。後続のセクションでは各ステップを詳しく説明し、今日すぐに生のログファイルに対して実行できるコマンドを示します。

適切な層からログを取得する

開発者またはホスティング事業者に、Web サーバー（Apache、Nginx、IIS）の生のアクセスログを依頼します。開始前に、ログ形式、タイムゾーン、保持期間の 3 点を確認してください。設定によっては、古いログが数日から数週間でローテーションにより削除されることがあるため、後回しにせず今エクスポートを依頼してください。

この層は多くの人が想像する以上に重要です。CDN がキャッシュからリクエストに応答すると、オリジンサーバーはそのリクエストを一切見ません。Googlebot はオリジンのログに現れない URL をクロールすることがあるため、オリジンだけのエクスポートでは、キャッシュされたコンテンツに対するクロール活動を過小に数えてしまいます。CDN のログもエクスポートし、どちらかの合計を信頼する前に、いくつかの URL で両方のソースを比較してください。

いくつかのコマンドで Googlebot をフィルタリングして数える

combined 形式のログでは、ステータスコードは 9 番目のフィールド、URL パスは 7 番目のフィールドです。この 2 つの列で、最初の疑問の大半に答えられます。次のコマンドは、Googlebot のリクエストをステータスコードごとに数えます。

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

次のコマンドは、Googlebot が最も多くリクエストした 20 のパスを、クエリ文字列を取り除いて表示します。フィルターのバリエーションがまとめて表示されるようにするためです。

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

最初のコマンドはユーザーエージェントのテキストを読み取るため、誰でも偽装できます。次のセクションが終わるまでは、その出力を候補リストとして扱ってください。また、ログがカスタム形式の場合はフィールド番号が変わるため、列を信頼する前に 1 行を目で確認してください。

Google の説明どおりに Googlebot を検証する

訪問者が Googlebot であることを確認する Google 自身の方法は DNS を使います。ログの IP アドレスに対して逆引き DNS を実行し、ホスト名が googlebot.com、google.com、または googleusercontent.com で終わることを確認します。その後、そのホスト名に対して正引きを実行し、元の IP が返ってくることを確認します。Google のドキュメントでは、66.249.66.1 が crawl-66-249-66-1.googlebot.com に逆引きされるという例を使っています。

host 66.249.66.1

正引きのチェックは 2 つ目のコマンドで、同じ IP を返さなければなりません。

host crawl-66-249-66-1.googlebot.com

数百万行を処理する場合、DNS の検索は遅くなります。Google は、Googlebot 用の common-crawlers.json を含む、クローラーの IP 範囲の JSON ファイルも公開しています。それらの範囲と照合するほうが速く、公式の検証ガイドではGoogle の Googlebot 検証ガイドで両方の方法が説明されています。

グループ化し、計測して結果を読む

URL ごとの生の件数は行動に移しにくいものです。修正は通常ページ単位ではなくテンプレート単位で適用されるため、まず URL をテンプレートごとにグループ化します。そのうえで、各グループについて 4 つを計測します。事業上の重要度に比べて Googlebot のヒットをどれだけ得ているか、ステータスコードの構成、公開後に新しいページが最初のヒットを得るまでの速さ、そしてヒットが順位を付けたいページに集中しているかどうかです。

結果は単一の数値ではなくパターンとして読みます。Googlebot のヒットの大半がフィルター URL に当たり、製品ページにはわずかしか当たっていなければ、クロールバジェットが漏れており、問題は製品ページではなく、内部リンクまたはパラメータの処理にある可能性が高いです。次のセクションでは、探すべきシグナルを挙げます。

ログに隠れている 7 つのシグナル

Googlebot の行が検証されグループ化されると、7 つのシグナルでほとんどのクロールの問題が説明できます。表には、探すべきパターンと、通常の修正方法を示しています。各修正はサイトへの変更なので、次のエクスポートで確認してください。

シグナル	ログに表れる内容	対処方法
クロールの無駄	フィルター、並べ替え順序、サイト内検索、セッション URL への Googlebot のヒット	canonical で統合し、これらの URL への内部リンクを削除し、統合できない場合は無意味なバリエーションを robots.txt でブロックする
リダイレクト	301 または 302 のレスポンスへのヒット、および 2 回以上のホップのリダイレクトチェーン	最終 URL に直接リンクする。301 と 302 のガイドで適切なリダイレクトの種類を選べます
エラー	404 または 410 の繰り返しのヒット、および 5xx レスポンスの急増	重要なページは復元またはリダイレクトし、5xx レスポンスは Google のクロール量を減らすため、サーバーエラーを修正する
クロールの欠落	期間内に Googlebot のヒットが一切ない重要な URL	内部リンク、サイトマップのエントリ、クローラーを遠ざけている可能性のある robots.txt のルールを確認する
重複	末尾のスラッシュ、大文字、パラメータなど、複数の URL で同じコンテンツがヒットしている	1 つの正規 URL を選び、あらゆる場所からそれにリンクする
最初のクロールまでの時間	新しいページの公開から最初の Googlebot のヒットまでの時間	頻繁にクロールされているページから新しいページにリンクし、サイトマップを整理しておく
応答時間	Googlebot のヒットが最も多いテンプレートでの遅い応答	Google は応答が遅いとクロールを減らすと述べているため、これらのテンプレートを最初に高速化する

「クロールの欠落」の行は多くの人が見落とす行で、しばしば最もコストが高くつきます。コンテンツが優れていても、ログに一度も現れないページは何のランキングも得られないかもしれません。サイトマップに URL があるのに、ログに一度も現れない場合、そのページはおそらくクローラーがたどらない経路からしか到達できません。Crawled, currently not indexed のガイドは、Googlebot がページを訪れたものの、まだインデックスしていないという反対側の状況を扱っています。

分析を実行する 3 つの方法の比較

ログ分析は、スクリプト、デスクトップアプリケーション、またはプラットフォームで実行できます。それぞれ適したデータ量やチームが異なります。適切な選択は、サイトの規模よりも、答えが必要な頻度と、結果を読む人によって決まります。

コマンドライン：grep、awk、Python

原理: スクリプトで生のファイルを解析し、結果をファイルまたはスプレッドシートに書き出します。使いどころ: 単発のチェック、小規模なサイト、または完全な制御を求める開発者。利点: 無料で、すべての行を確認でき、スケジュールされたジョブで自動化できます。制限: 作成と保守に時間がかかり、速度はマシンに依存し、グラフはなく、ボットは自分で検証する必要があります。

例: 方法のセクションのコマンドを、同じエクスポートに対して月に 1 回実行すると、Googlebot のステータスコードの構成と上位のパスが得られます。短い Python スクリプトでも同じことができ、DNS チェックを加えられます。これは遅いものの、より正確です。

デスクトップツール：Screaming Frog Log File Analyser

原理: 生のログをデスクトッププロジェクトにインポートすると、ツールがボットをグループ化し、その身元を確認し、グラフを描画します。使いどころ: 数万の URL を持つサイトで作業するコンサルタントや社内アナリスト。利点: W3C Extended 形式の Apache、IIS、Nginx のログを読み取り、検索エンジンのボットを検証し、大きいまたは遅いページにフラグを立てます。制限: 無料版には上限があり、読み込めるデータ量はハードディスクに依存します。

購入前に Screaming Frog の Log File Analyser のページを読んでください。それと組み合わせて使うクローラーの詳しい解説は、Screaming Frog SEO Spider のガイドをご覧ください。ログアナライザーは、クローラーにはできない 1 つのことを行います。リンクから推測される内容ではなく、ボットが実際にリクエストした内容を示すのです。

プラットフォーム：継続的なログ監視

原理: プラットフォームは、多くの場合 CDN またはサーバーから、スケジュールに従ってログを受け取り、サイトのクロールデータやインデックスデータと結合します。使いどころ: 大規模な EC サイトや、複数の市場にわたって毎週クロールを監視するエンタープライズチーム。利点: 非常に大規模なログに対応し、履歴を保持し、複数のチームでダッシュボードを共有できます。制限: コストが高く、導入に時間がかかり、ベンダーロックインは現実的な問題なので、契約前にデータのエクスポート方法を確認してください。このカテゴリのベンダーには Oncrawl や Botify があり、それぞれにボットの検証方法を尋ねてみる価値があります。

基準	コマンドライン	デスクトップツール	プラットフォーム
コスト	無料	1000 件のログイベントまで無料、フルライセンスは年 99 ポンド	サブスクリプション、価格はボリュームによる
セットアップ	スクリプトを自分で書いて保守する	インストール、インポート、開始	コネクターとオンボーディング
ボリューム	マシンの性能に依存	ハードディスクとライセンスに依存	非常に大規模なログ向けに構築
ボット検証	手動、DNS または IP 範囲チェックを使用	組み込み	ベンダーに確認
最適な用途	一次的なチェックと小規模なサイト	コンサルタントと中規模のサイト	週次監視を行うエンタープライズおよび EC チーム

Google のクロール統計レポート：有用だが十分ではない

ログを 1 つもエクスポートする前に、Search Console のクロール統計レポートを開いてください。このレポートには、クロールリクエストの合計、ダウンロードの合計サイズ、平均応答時間、タイプごとにグループ化された応答、ファイルタイプ、クロールの目的、各リクエストを行った Googlebot の種類が表示されます。傾向を確認するには、これが最も速く得られる表示です。その場所はGoogle Search Console のチュートリアルで説明されています。

その制限が、ログがなお重要な理由を説明しています。このレポートはドメインプロパティとルートレベルの URL プレフィックスプロパティでしか利用できません。Google のクローラーのみを対象とするため、GPTBot、ClaudeBot、その他のボットは含まれません。URL を 1 つずつ一覧表示せずデータをグループ化するため、クロールリクエストが減ったことはわかっても、どのテンプレートがそれを失ったのかはわかりません。このレポートで変化が起きたことを見つけ、ログで何が起きたのかを確かめてください。

Google のクロール統計のヘルプページでは、各グループ分けについて説明しています。グラフとログのエクスポートが一致しない場合は、時間枠と検証の手順を確認するまで、どちらも信用しないでください。このような不一致の多くは、時間枠の違い、キャッシュから応答する CDN、または未検証のリクエストを含むボット数から生じています。

無駄に気づいたらクロールの無駄を修正する

修正はシグナルから導かれます。その大半は 3 つの動きに集約されます。重要でないページにクローラーを向けないこと、ページが移動した場合は最終 URL へ直接送ること、そして重要なページを読み込みやすくすることです。

ファセットナビゲーション。フィルターや並べ替え順序は、ほぼ同じ内容の多数の URL を生成します。可能な場合は canonical で統合し、検索価値のないバリエーションへの内部リンクを削除してください。統合できず、クロールから除外しなければならないバリエーションは、robots.txt でブロックしてください。ここでの Google のガイダンスは明確です。この目的で noindex を使わないでください。Google はタグを見るためにまずページをリクエストしなければならないからです。テストすべきルールの例は次のとおりです。

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

robots.txt の変更は控えめにしてください。Google は、サイトがすでに容量の上限に達していない限り、URL をブロックしても他のページのクロールバジェットは解放されないと述べています。ブロックは価値のない URL のためのものであり、最良のページへバジェットを押し出す手段ではありません。当社の robots.txt の用語集では、このファイルがどのように読み取られるかを説明しています。

リダイレクトチェーン。ページが 2 回移動した場合、クローラーは毎回 2 つのリダイレクトを経由します。内部リンクを最終 URL を指すように更新し、外部リンクのために古いリダイレクトは残しておきます。恒久的リダイレクトと一時的リダイレクトのどちらを選ぶかも同じ理由で重要で、301 と 302 のガイドで詳しく扱っています。

削除されたページ。恒久的に削除されたページには 404 または 410 を返してください。Google は、soft 404 が繰り返しクロールされ、クロールバジェットを無駄にすると述べています。そのため、200 ステータスで「ページが見つかりません」というメッセージを返すのは、本物の 404 よりも悪い対応です。

応答時間とキャッシュ。Google は、応答が遅いまたは失敗していると、クロールを減らすと述べています。304（Not Modified）応答をサポートすると、変更のないページをキャッシュから提供できます。そのうえで、Googlebot のヒットを最も多く受けているテンプレートを確認し、その応答を最初に高速化してください。

最も損失の大きいミスと、その回避方法

うまくいかないログ分析の多くは、ごく一部のミスのどれかを犯しています。以下の各ミスには、データで見つけられる症状と、同じ週に適用できる修正があります。

ユーザーエージェント文字列を信頼する

内容: 「Googlebot」と名乗るすべてのリクエストを Google のクロールとして数えること。見つけ方: Google のホスト名に逆引きされない IP アドレスからの Googlebot のヒット、または単一のアドレスからの突然の急増。修正方法: 何かを数える前に、方法のセクションの検証を実行し、未検証のヒットは別のバケットに保管して、スクレイパーの活動も引き続き確認できるようにしてください。

200 レスポンスだけを読む

内容: 200 を返すページだけに注目し、残りを無視すること。見つけ方: レポートに 3xx、4xx、5xx のセクションがない、またはステータスコードの構成が一度も議論されていない。修正方法: 常にステータスコードの分布から始めてください。404 のヒットが増えている場合は壊れた内部リンクが、5xx のヒットが増えている場合は、クロール全体を遅くするサーバーの問題が見つかることがあります。

インデックスから削除したいページをブロックする

内容: noindex タグも付いているページに robots.txt のルールを追加すること。見つけ方: ページがインデックスに残り、クローラーがリクエストをブロックされているため、ログに Googlebot のヒットが現れない。修正方法: Google が noindex タグを読めるようにブロックを解除し、ページがインデックスから外れるのを待ち、まだ必要であればブロックを戻してください。Blocked by robots.txt のガイドは、この場合に表示される Search Console のステータスを説明しています。

長さの異なる時間枠を比較する

内容: 修正前の 3 日間のエクスポートと、修正後の 30 日間のエクスポートを比較すること。見つけ方: 合計は大きく動くのに、テンプレートごとの割合は動かない。修正方法: 可能であれば同じ日数、同じ時期で比較し、量が変わる場合は生の合計ではなく割合を比較してください。

価値ではなくヒットを測定する

内容: インデックスされるページに届いているかどうかを確認せずに、Googlebot のヒットの増加を喜ぶこと。見つけ方: ヒットがインデックスされていない、あるいはトラフィックを生まない URL に集中している。修正方法: ログのグループを Search Console の URL 検査ツールによるインデックス状況と結合し、クロールが重要なページへ移ったときにのみ、修正を成功として数えてください。

同じログの中で AI ボットはどこに位置するか

同じログは、AI クローラーがサイト上で何をしているかも示します。方法は同じです。グループ化し、ベンダーが検証手段を提供している場合は検証し、ステータスコードを読みます。AI クローラーのログのガイドでは、探すべきボットと、Googlebot との違いを扱っています。この記事では Googlebot の方法を詳しく扱い、次のセクションでは両方を 1 つのレポートにまとめる方法を示します。

ボットの種類	例	ログで確認すべき点	詳しく読む場所
検索クローラー	Googlebot	テンプレートごとのヒット、ステータスコードの構成、新しいページの最初のクロールまでの時間	この記事の上記のセクション
学習クローラー	GPTBot、ClaudeBot、CCBot	そもそもコンテンツをリクエストしているか、robots.txt を尊重しているか	AI クローラー向けの Robots.txt
検索拡張クローラー	ChatGPT-User、PerplexityBot	ユーザーの質問に結びついた短いアクセスの急増と、それらが到達したページ	AI クローラーのログ

学習と検索拡張の区別は、AI クローラーがどのように文書化されているかに由来します。学習クローラーはモデルのためにコンテンツを収集し、検索拡張クローラーはユーザーが質問したときにページを取得します。一方に対するポリシーの判断が他方に自動的に適用されるわけではないため、レポートではこの 2 つを分けておく必要があります。

これらの修正を出荷しながら Google のトラフィックと AI のトラフィックを並べて確認したい場合は、Sorank の GEO / SEO ダッシュボードが 1 つのビューで両方を表示します。ログから行った変更がクロール数だけでなくトラフィックを動かしたかどうかを確認するために使ってください。