この記事はAhrefs公式ブログの日本語訳です。
原文：How to Do an SEO Log File Analysis [Template Included]
（著者：Sam Underwood / 原文の最終更新日：April 11, 2022）
※フルスピード註：この記事は2022年4月11日時点の記載をもとに翻訳しています。Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。
過去 5 年間、ログ ファイルは技術的な SEO 担当者からの評価が高まっていますが、それには十分な理由があります。
これらは、検索エンジンがクロールした URL を理解するための最も信頼できる情報源であり、技術的な SEO の問題を診断するのに役立つ重要な情報となります。
Google 自体もその重要性を認識しており、Google Search Console に新機能をリリースし、以前はログを分析することでしか入手できなかったデータのサンプルを簡単に確認できるようにしています。
さらに、Google 検索擁護者のジョン ミューラー氏は、ログ ファイルにどれだけの有益な情報が保持されているかを公に述べています。
ログ ファイル内のデータが誇大宣伝されているため、ログ、ログの分析方法、作業中のサイトがログから利益を得られるかどうかについて、より深く理解したいと思うかもしれません。
まず、サーバー ログ ファイルとは何ですか?
サーバー ログ ファイルは、サーバーによって作成および更新され、実行されたアクティビティを記録するファイルです。一般的なサーバー ログ ファイルはアクセス ログ ファイルで、（ユーザーとボットの両方による）サーバーへの HTTP リクエストの履歴が保持されます。
開発者以外がログ ファイルについて言及する場合、通常はアクセス ログを指します。
しかし、開発者は、サーバーで発生した問題を報告するエラー ログを確認することに多くの時間を費やしていることに気づきました。
上記は重要です。開発者にログをリクエストすると、開発者は最初に「どれですか?」と尋ねます。
したがって、ログ ファイルのリクエストは常に具体的にしてください。クロールを分析するためにログが必要な場合は、アクセス ログを要求します。
アクセス ログ ファイルには、サーバーに対して行われた各リクエストに関する次のような多くの情報が含まれています。
- IPアドレス
- ユーザーエージェント
- URLパス
- タイムスタンプ (ボット/ブラウザがリクエストを行ったとき)
- リクエストのタイプ（GET または POST）
- HTTPステータスコード
サーバーがアクセス ログに含めるものはサーバーの種類によって異なり、場合によってはデベロッパーがログ ファイルに保存するようにサーバーを構成した内容によっても異なります。ログ ファイルの一般的な形式は次のとおりです。
- Apache 形式 – これは Nginx サーバーと Apache サーバーで使用されます。
- W3C 形式 – これは Microsoft IIS サーバーによって使用されます。
- ELB 形式 – これは Amazon Elastic Load Balancing によって使用されます。
- カスタム形式 – 多くのサーバーはカスタム ログ形式の出力をサポートしています。
他の形式も存在しますが、遭遇する主な形式は次のとおりです。
ログファイルがSEOにどのようなメリットをもたらすのか
ログ ファイルの基本を理解したところで、ログ ファイルが SEO にどのように役立つかを見てみましょう。
主な方法をいくつか紹介します。
- クロール モニタリング – 検索エンジンがクロールする URL を確認し、これを利用してクローラー トラップを特定したり、クロール バジェットの無駄に注意したり、コンテンツの変更がどの程度の速度で検出されるかをより深く理解したりできます。 .
- ステータス コード レポート – これは、エラーの修正に優先順位を付ける場合に特に役立ちます。 404 であることを知るのではなく、ユーザーや検索エンジンが 404 URL に何回アクセスしているかを正確に確認できます。
- 傾向分析 – URL、ページ タイプ/サイト セクション、またはサイト全体へのクロールを長期的に監視することで、変化を特定し、潜在的な原因を調査できます。
- 孤立ページの検出 – ログ ファイルのデータと自分で実行するサイト クロールを相互分析して、孤立ページを検出できます。
すべてのサイトはログ ファイル分析からある程度のメリットを得られますが、メリットの量はサイトのサイズによって大きく異なります 。
これはログ ファイルであり、主にサイトの クロール管理 を改善するのに役立ちます。 述べています。サイトを変更するとメリットが得られます。は、クロール予算の管理は大規模または頻繁なものであるとGoogle 自体。
ログファイルの分析にも同じことが当てはまります。
たとえば、小規模なサイトでは、Google Search Console で提供される「クロール統計」データを使用することで、ログ ファイルに触れることなく、上記のメリットをすべて享受できる可能性があります。
はい、Google はクロールされたすべての URL を提供するわけではなく（ログ ファイルなど）、傾向分析は 3 つに限定されます。数か月分のデータ。
ただし、頻繁に変更されない小規模なサイトでは、継続的な技術的な SEO の必要性も低くなります。サイト監査人に問題を発見して診断してもらうだけで十分である可能性があります。
たとえば、サイト クローラー、XML サイトマップ、Google アナリティクス、Google Search Console による相互分析により、孤立したページがすべて検出される可能性があります。
サイト監査人を使用して、内部リンクからエラー ステータス コードを検出することもできます。
私がこれを指摘する主な理由は次のとおりです。
- アクセス ログ ファイルを入手するのは簡単ではありません （これについては次に説明します）。
- 頻繁に変更されない小規模なサイトの場合、ログ ファイルのメリットはそれほど大きくありません。つまり、SEO の焦点は他のところに移る可能性があります。
ログファイルにアクセスする方法
ほとんどの場合、ログ ファイルを分析するには、まず開発者にログ ファイルへのアクセスをリクエストする必要があります。
その場合、開発者はいくつかの問題を抱えている可能性があり、それがユーザーに通知されます。これらには次のものが含まれます。
- 部分データ – ログ ファイルには、複数のサーバーに分散した部分データが含まれる場合があります。これは通常、開発者がオリジン サーバー、ロード バランサー、CDN などのさまざまなサーバーを使用するときに発生します。すべてのログの正確な状況を把握するには、すべてのサーバーからのアクセス ログを編集する必要がある可能性があります。
- ファイル サイズ – トラフィックの多いサイトのアクセス ログ ファイルは、ペタバイトではないにしても、テラバイト単位に達する可能性があり、転送が困難になります。
- プライバシー/コンプライアンス – ログ ファイルには、個人を特定できる情報 (PII) であるユーザーの IP アドレスが含まれています。ユーザー情報は、共有する前に削除する必要がある場合があります。
- ストレージ履歴 – ファイル サイズの関係で、開発者はアクセス ログを数日間のみ保存するように設定している可能性があり、傾向や問題を特定するのには役に立ちません。
これらの問題は、特に開発者がすでに優先順位の長いリストを持っている場合（これはよくあることですが）、ログ ファイルの保存、マージ、フィルタリング、転送が開発の労力に値するかどうかという疑問を引き起こします。
デベロッパーは、SEO 担当者に、なぜデベロッパーがこれに時間を投資する必要があるのかを説明/構築する責任を課す可能性が高く、他の SEO の焦点の中でも優先する必要があります。
これらの問題 こそ、ログ ファイルの分析が頻繁に行われない理由です。
開発者から受け取ったログ ファイルは、一般的なログ ファイル分析ツールでサポートされていない形式でフォーマットされていることが多く、分析がより困難になります。
ありがたいことに、このプロセスを簡素化するソフトウェア ソリューションがあります。私のお気に入りは Logflare です。これは、ログ ファイルを保存できる Cloudflare アプリ です。あなたが所有するBigQuery データベース 。
ログファイルを分析する方法
今度はログの分析を開始します。
特に Logflare のコンテキストでこれを行う方法を説明します。ただし、ログデータの使用方法に関するヒントは、どのログにも適用できます。
すぐに共有するテンプレートは、どのログでも機能します。データシートの列が一致していることを確認するだけです。
1. まず Logflare をセットアップします (オプション)
Logflare はセットアップが簡単です。また、BigQuery との統合により、データが長期保存されます。データを所有することになり、誰でも簡単にアクセスできるようになります。
問題が 1 つあります。 ドメイン ネーム サーバーを Cloudflare のものを使用するように交換し 、そこで DNS を管理する必要があります。
ほとんどの場合、これで問題ありません。ただし、よりエンタープライズ レベルのサイトを操作している場合、ログ分析を簡素化するためにネームサーバーを変更するようサーバー インフラストラクチャ チームを説得できる可能性は低いでしょう。
Logflare を動作させる方法についてすべての手順を説明するわけではありません。ただし、始めるには、ダッシュボードの Cloudflare アプリの部分に移動するだけです。
次に、Logflare を検索します。
これ以降の設定は一目瞭然です（アカウントの作成、プロジェクトに名前を付ける、送信するデータの選択など）。追加で読むことをお勧めする唯一の部分は、Logflare の BigQuery 設定ガイドです。
ただし、BigQuery には、実行するクエリと保存するデータの量に応じた費用がかかる ことに注意してください。サイドノート。 BigQuery バックエンドの大きな利点の 1 つは、
データを所有できることです。つまり、IP アドレスなどの PII を送信しないように Logflare を構成し、SQL クエリを使用して BigQuery から PII を削除することで、PII の問題を回避できるということです。
2. Googlebot を検証する
ログ ファイルを保存しました（Logflare または別の方法を使用）。次に、分析したいユーザー エージェントからログを正確に抽出する必要があります。ほとんどの場合、これは Googlebot になります。
その前に、越えなければならないハードルがもう一つあります。
多くのボットは、Googlebot になりすましてファイアウォールを通過します（ファイアウォールがある場合）。さらに、一部の監査ツールは、サイトがユーザー エージェントに対して返すコンテンツを正確に反映するために同じことを行います。これは、サーバーが Googlebot に対して異なる HTML を返す場合（例: < を設定している場合）に不可欠です。 a i=1>ダイナミック レンダリング。
Logflare を使用していません
Logflare を使用していない場合、Googlebot を特定するには、リクエストが Google からのものであることを確認するために逆引き DNS ルックアップが必要になります。
Google では、Googlebot を手動で検証するための便利なガイドをここで提供しています。
これは、IP 逆引き検索ツール を使用し、返されたドメイン名を確認することで、1 回限りで行うことができます。
ただし、これをログ ファイル内のすべての行に対して一括で行う必要があります。また、Google が提供する リストから IP アドレスを照合する必要もあります。
これを行う最も簡単な方法は、偽の bot をブロックするサードパーティが管理するサーバー ファイアウォール ルール セットを使用することです（その結果、ログ ファイル内の偽の Googlebot が減少するか、まったく存在しなくなります）。 Nginx で人気のあるものは「Nginx Ultimate Bad Bot Blocker」 です。
また、Googlebot IP のリスト で注目すべき点は、IPV4 アドレスがすべて「66」で始まることです。
100% 正確ではありませんが、ログ内のデータを分析するときに「6」で始まる IP アドレスをフィルタリングして Googlebot をチェックすることもできます。
Cloudflare/Logflareを使用しています
Cloudflare のプロ プラン（現在月額 20 ドル）には、偽の Googlebot リクエストによるサイトへのアクセスをブロックできるファイアウォール機能が組み込まれています。
Cloudflare はこれらの機能をデフォルトで無効にしていますが、ファイアウォール > に移動すると見つけることができます。管理ルール > 「Cloudflare スペシャル」を有効にする > [「詳細」を選択します。
次に、検索タイプを「説明」から「ID」に変更し、「100035」を検索します。
Cloudflare には、偽の検索ボットをブロックするオプションのリストが表示されます。関連するものを「ブロック」に設定すると、Cloudflare は検索ボット ユーザー エージェントからのすべてのリクエストが正当であることを確認し、ログ ファイルをクリーンな状態に保ちます。
3. ログファイルからデータを抽出する
最後に、ログ ファイルにアクセスできるようになり、ログ ファイルが本物の Googlebot リクエストを正確に反映していることがわかりました。
スプレッドシートに慣れている可能性が高く、サイト クロールなどの他のソースとログ ファイルを相互分析するのが簡単であるため、まず Google スプレッドシートまたは Excel 内でログ ファイルを分析することをおすすめします。
これを行う唯一の正しい方法はありません。次のものが使用できます。
これはデータポータル レポート内で行うこともできます。データポータルは長期にわたるデータのモニタリングに役立ちますが、技術監査時の 1 回限りの分析には Google スプレッドシート/Excel が適しています。
BigQuery を開いて、プロジェクト/データセットに移動します。
[クエリ] プルダウンを選択し、新しいタブで開きます。
次に、分析するデータを抽出するための SQL を記述する必要があります。これを簡単に行うには、まずクエリの FROM 部分の内容をコピーします。
そして、私が作成した以下のクエリ内にそれを追加できます。
SELECT DATE(timestamp) AS Date, req.url AS URL, req_headers.cf_connecting_ip AS IP, req_headers.user_agent AS User_Agent, resp.status_code AS Status_Code, resp.origin_time AS Origin_Time, resp_headers.cf_cache_status AS Cache_Status, resp_headers.content_type AS Content_Type
FROM `[Add Your from address here]`,
UNNEST(metadata) m,
UNNEST(m.request) req,
UNNEST(req.headers) req_headers,
UNNEST(m.response) resp,
UNNEST(resp.headers) resp_headers
WHERE DATE(timestamp) >= "2022-01-03" AND (req_headers.user_agent LIKE '%Googlebot%' OR req_headers.user_agent LIKE '%bingbot%')
ORDER BY timestamp DESC
このクエリは、SEO 目的のログファイル分析に役立つデータのすべての列を選択します。また、Googlebot と Bingbot のデータのみを取得します。
サイドノート。分析したい他のボットがある場合は、WHERE ステートメント内に別の OR req_headers.user_agent LIKE ‘%bot_name%’ を追加するだけです。 WHERE DATE(timestamp) >= “2022-03-03” の行を更新することで、開始日を簡単に変更することもできます。
上部の [実行] を選択します。次に、結果を保存することを選択します。
次に、データを Google ドライブの CSV に保存します（ファイル サイズが大きくなるため、これが最適なオプションです）。
BigQuery がジョブを実行してファイルを保存したら、Google スプレッドシートでファイルを開きます。
4. Google スプレッドシートに追加
これからいくつかの分析を始めます。 Google スプレッドシートのテンプレートを使用することをお勧めします。ただし、私が何をしているのか説明します。必要に応じて、レポートを自分で作成できます。
テンプレートは、データをコピーして貼り付けるための 2 つのデータ タブで構成されており、Google スプレッドシートのQUERY 関数サイドノート。設定後に実行するレポートがどのように完成したかを確認したい場合は、各表の最初のセルを選択してください。
まず、BigQuery からのエクスポート出力をコピーして、[データ – ログ ファイル] タブに貼り付けます。
分析を少し容易にするために、シートの最後（濃い灰色）に複数の列が追加されていることに注意してください（ボット名や最初の URL ディレクトリなど）。
5. Ahrefs データの追加
サイト監査人がいる場合は、Google スプレッドシートにさらにデータを追加することをおすすめします。主に、以下を追加する必要があります。
- オーガニックトラフィック
- ステータスコード
- クロールの深さ
- インデックス可能性
- 内部リンクの数
Ahrefs の サイト監査からこのデータを取得するには、ページ エクスプローラー [列の管理] を選択します。
次に、以下に示す列を追加することをおすすめします。
次に、そのデータをすべてエクスポートします。
そして、コピーして「Data – Ahrefs」シートに貼り付けます。
6.ステータスコードを確認する
最初に分析するのはステータス コードです。このデータは、検索ボットが 200 以外の URL でクロール バジェットを無駄にしているかどうかを明らかにします。
これは必ずしも問題を指摘しているわけではないことに注意してください。
場合によっては、Google が古い 301 を何年にもわたってクロールできることがあります。ただし、200 以外のステータス コードを多数内部的にリンクしている場合は、問題が浮き彫りになる可能性があります。
[ステータス コード – 概要] タブには、ログ ファイル データを要約し、結果をグラフで表示するクエリ機能 があります。< /span>
ボットの種類でフィルタリングし、200 以外のステータス コードを最も多くヒットしているボットを確認するためのプルダウンもあります。
もちろん、このレポートだけでは問題の解決には役立たないため、「URL – 概要」という別のタブを追加しました。
これを使用して、200 以外のステータス コードを返す URL をフィルタリングできます。 Ahrefs の サイト監査のデータも含めているので、これらの 200 以外の URL のいずれかに内部リンクしているかどうかを確認できます。 「リンク」列。
URL への内部リンクが多数表示される場合は、内部リンクの機会レポートを使用して、これらの誤った内部リンクを見つけることができます。 [ターゲット ページ] を選択した状態で、検索バーに URL をコピーして貼り付けるだけです。
7. クロールバジェットの無駄を検出する
200 以外のステータス コードのクロールによるものではないログ ファイルのクロール バジェット の無駄を強調する最善の方法は、頻繁に見つけることです。クロールされたインデックス不可能な URL（正規化されているか、インデックスが登録されていないなど）。
ログ ファイルと Ahrefs の サイト監査からのデータを追加しているため、これらの URL を見つけるのは簡単です。
[クロール予算の無駄遣い] タブに移動すると、200 を返してもインデックス付けできない、クロール数の多い HTML ファイルが見つかります。
このデータを取得したので、ボットが URL をクロールしている理由を調査します。一般的な理由は次のとおりです。
- 内部的にリンクされています。
- XML サイトマップに誤って含まれています。
- 外部サイトからのリンクが含まれています。
大規模なサイト、特にファセット ナビゲーションを備えたサイトでは、多くのインデックス不可能な URL に内部リンクしているのが一般的です。
このレポートのヒット数が非常に高く、クロール予算を無駄にしていると思われる場合は、URL への内部リンクを削除するか、クロールをブロックする必要がある可能性があります。 robots.txt を使用します。
8. 重要な URL を監視する
サイト上に非常に重要な特定の URL がある場合は、検索エンジンがその URL をクロールする頻度を確認するとよいでしょう。
[URL モニター] タブはまさにそれを行い、追加できる最大 5 つの URL のヒット数の日次傾向をプロットします。
ボットの種類でフィルタリングすることもできるため、Bing または Google が URL をクロールする頻度を簡単にモニタリングできます。
サイドノート。このレポートを使用して、最近リダイレクトした URL を確認することもできます。古い URL と新しい URL をドロップダウンに追加するだけで、Googlebot がどれだけ早く変更に気づくかを確認できます。
ここでのアドバイスは、Google が URL を頻繁にクロールしないのは悪いことであるということです。それは単に事実ではありません。
Google は人気のある URL をより頻繁にクロールする傾向がありますが、頻繁に変更されない URL のクロールは少なくなる可能性があります。あ>
それでも、ニュース サイトのホームページなど、コンテンツの変更をすぐに検出する必要がある場合には、このように URL を監視すると便利です。
実際、Google が URL を頻繁に再クロールしていることに気付いた場合は、<lastmod> を追加するなどして、クロール レートをより適切に管理できるようにすることをお勧めします。 XML サイトマップへ。次のようになります。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.logexample.com/example</loc>
<lastmod>2022-10-04</lastmod>
</url>
</urlset>
その後、<lastmod> を更新できます。ページのコンテンツが変更されるたびにこの属性を設定し、Google に再クロールするよう通知します。
ヒント
Google はこの属性に関してさまざまなフィードバックを提供していることに注意してください。 2015 年、Gary Ilysses はほとんど無視されていると述べました。 2017 年に、ジョンはそれが使用されていることを示唆しました。最近、2022 年に、ゲイリーは「私たちはそれを使用するつもりはない」と述べました。 Google の XML サイトマップ ドキュメント では、この属性が使用されることが示唆されています。ただし、正確でない場合は無視されます。
9. 孤立した URL を見つける
ログ ファイルを使用するもう 1 つの方法は、孤立 URL、つまり、検索エンジンにクロールしてインデックスに登録させたいが、内部的にリンクされていない URL を検出することです。
これを行うには、Ahrefs のサイト監査で内部リンクのない 200 個のステータス コード HTML URL をチェックします。
このために私が作成した「孤立 URL」という名前のレポートをご覧ください。
ここで注意点が 1 つあります。 Ahrefs はこれらの URL を発見していませんが、Googlebot は発見しているため、これらの URL はインデックス付けできないため、リンクしたい URL ではない可能性があります。
Ahrefs プロジェクトのクロール ソースを設定する場合は、「カスタム URL リスト」機能を使用してこれらの URL をコピーして貼り付けることをおすすめします。
これにより、Ahrefs はログ ファイル内で見つかった孤立した URL を考慮し、次回のクロールで問題があれば報告するようになります。
10. ディレクトリごとのクロールを監視する
サイトをどのように構成したかを示す構造化 URL を実装したとします（例: /features/feature-page/）。
その場合、ディレクトリに基づいてログファイルを分析して、Googlebot がサイトの特定のセクションを他のセクションよりも多くクロールしているかどうかを確認することもできます。
この種の分析は、Google スプレッドシートの [ディレクトリ – 概要] タブに実装しました。
ディレクトリへの内部リンクの数とオーガニック トラフィックの合計に関するデータも含めていることがわかります。
これを使用すると、Googlebot が価値の高いディレクトリよりもトラフィックの少ないディレクトリのクロールに多くの時間を費やしているかどうかを確認できます。
ただし、特定のディレクトリ内の一部の URL は他の URL よりも頻繁に変更されるため、このようなことが発生する可能性があることに注意してください。それでも、奇妙な傾向を見つけた場合は、さらに調査する価値があります。
このレポートに加えて、サイトのディレクトリごとのクロール傾向を確認したい場合は、「ディレクトリ – クロール傾向」レポートもあります。
11. Cloudflareのキャッシュ率を表示する
[CF キャッシュ ステータス] タブに移動すると、Cloudflare がファイルをエッジサーバーにキャッシュする頻度の概要が表示されます。
Cloudflare がコンテンツをキャッシュすると (上のグラフの HIT)、リクエストはオリジン サーバーに送信されなくなり、そのグローバル CDN から直接処理されます。これにより、特にグローバル サイトのCore Web Vitalが向上します。サイドノート。 また、オリジンサーバーにキャッシュを設定することも価値があります (Varnish、Nginx FastCGI、Redis フルページ キャッシュなど)。これは、Cloudflare が URL をキャッシュしていない場合でも、キャッシュの恩恵を受けることができるようにするためです。
大量の「Miss」または「Dynamic」レスポンスが表示された場合は、Cloudflare がコンテンツをキャッシュしていない理由を理解するためにさらに調査することをおすすめします。一般的な原因としては次のことが考えられます。
- パラメータを含む URL にリンクしています – Cloudflare は、デフォルトでパラメータ
- キャッシュの有効期限が短すぎます – キャッシュの有効期間を短く設定すると、キャッシュされていないコンテンツを受信するユーザーが増える可能性があります。
- キャッシュをプリロードしていない – キャッシュが頻繁に期限切れになる必要がある場合（コンテンツが頻繁に変更されるため）、キャッシュされていない URL にユーザーをアクセスさせるのではなく、プリローダー ボットを使用します。 Optimus キャッシュ プリローダーなどのキャッシュを準備します。
サイドノート。 また、オリジンサーバーにキャッシュを設定することも価値があります (Varnish、Nginx FastCGI、Redis フルページ キャッシュなど)。これは、Cloudflare が URL をキャッシュしていない場合でも、キャッシュの恩恵を受けることができるようにするためです。
自動プラットフォーム最適化を使用して簡単に行うことができます。
12. どのボットがサイトを最もクロールしているかを確認する
最終レポート（[ボット – 概要] タブにあります）には、どのボットがサイトを最もよくクロールしているかが表示されます。
「ボット – クロール トレンド」レポートでは、その傾向が時間の経過とともにどのように変化したかを確認できます。
このレポートは、サイトでボット アクティビティが増加しているかどうかを確認するのに役立ちます。また、URL の移行など、最近大きな変更を行ったときに、ボットが新しい情報を収集するためにクロールを増やしているかどうかを確認したい場合にも役立ちます。データ
まとめ
これで、サイトを監査するときにログ ファイルを使用して実行できる分析についてよく理解できたはずです。私のテンプレートを使用して、この分析を自分で行うのが簡単だとわかっていただければ幸いです。
著者プロフィール
私が言及していない、ログ ファイルに対して何かユニークなことを行っていますか? ツイートしてください。
Sam Underwood
Sam Underwood は、オンページ SEO、テクニカル SEO、コンテンツ戦略を通じて e コマース企業の本的収益の拡大を支援する個人コンサルタントです。
コメント