ウェブサーバの「生ログ」とは？
ウェブサーバのアクセスログやエラーログ、いわゆる「生ログ」と呼ばれているものをご存じでしょうか？あるいは実際に見たことはあるでしょうか？例えば以下のようなものとなります。
アクセスログ
www.principle-c.com xx.xx.xx.xx – – [28/Aug/2018:00:51:26 +0900] “GET /column/marketing/google-optimize-additionalfunctions/ HTTP/1.1” 200 31248 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
www.principle-c.com xx.xx.xx.xx – – [28/Aug/2018:00:59:26 +0900] “GET /column/global-marketing/youtube_big_brand/ HTTP/1.1” 200 21127 “https://www.google.co.jp/” “Mozilla/5.0 (iPhone; CPU iPhone OS 11_0_2 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A421 Safari/604.1”
エラーログ
[Thu Mar 01 10:38:15.774578 2018] [access_limit:warn] [pid 88859] [client xx.xx.xx.xx:0] AccessExceededNumber
[Thu Mar 01 10:38:15.776677 2018] [access_limit:warn] [pid 88628] [client xx.xx.xx.xx:0] AccessExceededNumber
[Thu Mar 01 10:38:15.776731 2018] [access_limit:warn] [pid 88628] [client xx.xx.xx.xx:0] AccessExceededNumber
[Thu Mar 01 10:38:15.777388 2018] [access_limit:warn] [pid 88869] [client xx.xx.xx.xx:0] AccessExceededNumber
※実際のアクセスログやエラーログは、ウェブサーバの種類（ApacheやMicrosoft Internet Information Services (IIS)、Nginxなど）によって形式が違いますし、また自分で自由にカスタマイズもできますので、上記の通りであるとは限りません。あくまで「こんなもの」というイメージとして捉えてください。
※「xx.xx.xx.xx」は、実際はIPアドレスなどになります。セキュリティとプライバシーを考慮し、伏せ字としています。
ウェブサーバは、どこからかリクエストがあるたびに、そのリクエストの詳細や結果を、上記のようなログファイルに保存して記録しています。その内容をよく見てみると、以下のような情報が含まれています。
- リクエスト対象のドメイン（www.principle-c.com など）
バーチャルドメインを設定して、1台のウェブサーバで複数のサイトを運用している場合もあるので、ログ上でもドメインを明記していることが多いです。 - リクエスト元のIPアドレス（xx.xx.xx.xx など）
- リクエストされた日時（28/Aug/2018:00:51:26 +0900 など）
- リクエストの内容（GET /column/marketing/google-optimize-additionalfunctions/ など）
この場合は、/column/marketing/google-optimize-additionalfunctions/に対して、GETリクエスト（ページの取得）があった、ということになります。 - レスポンスコード（200 など）
リクエストに対して、サーバーが返したレスポンスコードです。 - リファラ（https://www.google.co.jp/ など）
直前に閲覧していたページのURLです。 - ユーザーエージェント
（Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) など）
ブラウザなど、ウェブサイトにアクセスする際に用いられたプログラムです。ハードウェアの情報が含まれることもあります。そのリクエストがgooglebotなどのクローラーによるものかを判別する際には、このユーザーエージェントを確認します。
※Googleのクローラーのユーザーエージェントについては、以下のページにまとめてあります。
https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers?hl=ja - エラー内容【エラーログの場合】（AccessExceededNumber など）
どのようなエラーが発生したかを判別することができます。例示した「AccessExceededNumber」はアクセスが制限数を超えてしまった場合に出るエラーです。
インターネットが普及しはじめた、1990年代後半の頃は、ウェブサイトへのアクセス状況を把握するためには、サーバーのアクセスログを分析するのが主流で、そのためのツール（analogなど）も多く開発されていました。しかし現在では、ウェブサイトへのアクセス状況を見たい場合は、Google Analyticsなどを利用するのが一般的だと思います。そのため、ウェブサーバのアクセスログやエラーログを直接分析することは、今ではそう多くはないでしょう。しかしこの「生ログ」は、ウェブサーバへのリクエストとレスポンスが逐次記録されたものであり、情報の宝庫なのです。
「生ログ」の分析は何の役に立つのか？
では、実際に「生ログ」を分析することで何が分かるのでしょうか？
クローラーの行動やAPIへのアクセスをより詳細に把握できる
生ログを分析することで、GoogleやBingといった検索エンジンのクローラーや、AhrefsやSEO SpyGlassといったサービスサイト、または学術・研究機関のクローラーの行動も詳細に把握することができます。また自社で何らかのAPIを外部に提供している場合、そのAPIへのアクセス状況を生ログを通じて把握することも可能です。
Googleが自分のサイトがどれくらいの頻度クロールしているかは、Search Consoleの「クロールの統計情報」を見ると把握することができます。
※クロールの統計情報については、弊社のブログでも以前とりあげました。下記URLを参照ください。
https://www.principle-c.com/column/seo/seo-crawl-data/
一方で、クロールの統計情報の画面からは、クローラーがウェブサイトのどのページをクロールしたのかを把握することはできません。最近Search Consoleに追加された「URL検査ツール」を使えば、特定のURLがいつクロールされたのかを把握することもできますが、「クローラーがどのページ/ディレクトリ/テンプレートを多くクロールしているのか」を把握するには、このツールでは不十分です。
※URL検査ツール
https://support.google.com/webmasters/answer/9012289?hl=ja
ウェブサイト管理者にとって、自分のサイトがどれくらいの頻度クロールされているかを把握することは重要ですが、そのクロール頻度がページ/ディレクトリ/テンプレートごとに集計できるなら、サイトのアクセス改善の施策を構築する上で、非常に有用な情報となります。クロールして欲しいページへのクロール頻度が不十分なら、それに対してのアクションが必要となりますし、その逆に、不必要なページが頻度高くクロールされているなら、また別のアクションが必要となります。生ログを取得して、例えばそのデータをExcelやTableauを用いて集計し、クロール頻度をページ/ディレクトリ/テンプレートごとに把握できるのであれば、本当に必要な対策を構築することが、可能となるのです。
例として、ある特定の日にGoogleのクローラー（googlebot）がアクセスしたページをテンプレートごとにグループ分けし、更にその際にサーバーが返したレスポンスコードを、Tableauを用いて集計した図を下記に示します。
円グラフの円が大きいほど、そのテンプレートが多くクロールしていることとなります。ここでは一覧ページAと詳細ページAが多くクロールされていますが、それに対して一覧ページBと一覧ページCのクロール量は少ないです。それが望ましいのか、あるいは望ましくないのかによって、次にとるべきアクション（送信するXMLサイトマップの構成を見直したり、ページ間のリンク構造を見直したり、など）は変わってきます。
また、例えばサイトのリニューアルがあってリダイレクトの設定をした際に、それが正しく機能しているかなどの確認も、生ログを用いれば網羅的に行うことができます。先の図では、一覧ページAと詳細ページBにおいて301のレスポンスコードが多く返されているのが分かります。それが意図的であれば問題ありませんが、そうでないのであれば、何らかの対処が必要となります。生ログがないのであれば、いくつかのURLをサンプリングしてチェックしたり、Screaming Frogなどのクローリングツールを使用する必要がありますが、生ログがあれば、実データをもとにした網羅的な調査・確認が可能となるのです。
クロールエラーの詳細を把握できる
一方で生ログは、「クロールエラー」の詳細を把握する際にも有用です。Search Consoleのインデックスカバレッジレポートには、様々なクロールエラーが報告されています。これらのクロールエラーは、そのすべてに対処が必要という訳ではありませんが、クローラーの動作、ひいてはユーザーのサイトの利用を妨げている可能性がありますので、数が多かったり、ECサイトにおける商品詳細ページなど、サイトにとって重要と思われるテンプレートに集中しているエラーは、早期に解決することが重要となります。
※インデックス カバレッジ レポート
https://support.google.com/webmasters/answer/7440203?hl=ja
ただ、いざエラーを解消しようとしても、その原因がなかなか分からない場合があります。「送信された URL に noindex タグが追加されています」などは、noindexタグを含むURLをサイトマップから削除するか、あるいはnoindexタグが誤って挿入されているのなら、それを解消すれば問題は解決します。一方「サーバーエラー（5xx）」や「送信された URL のクロールに問題があります」などのエラーは、HTMLのソースに問題があるとは限らず、サーバー側に何かしらの問題がある場合もあります。そのような際に、生ログは非常に有用な情報源となります。
生ログには、クローラーがウェブサーバにリクエストを送った際の日時やURL、レスポンスコードの情報が含まれています。これらの情報を分析することで、エラーの詳細を把握することができる可能性があります。例えば、クローラーのレスポンスコードを時間帯ごとに集計したときに、特定の日時に5xxのレスポンスコードが集中していたのなら、その時間帯に何か問題があったと考えることができます。また特定のURLでのみエラーが起きているのなら、そのURLに原因があると推察することもできます。インデックス カバレッジ レポート上で確かにエラーとして報告されているのに、そのURLをクローラーがクロールした形跡が生ログ上にないのなら、そもそもクローラーからのリクエストをサーバーが処理できなかった（海外からDDoS攻撃があり、サーバーレスポンスが一時的に低下していた、などの）可能性も出てきます。
生ログを調査したからといって必ず原因が特定できるとは限りませんが、Search Consoleで報告されている以上の情報を入手したいなら、生ログにあたってみることをまずはおすすめします。
ウェブサイトが攻撃を受けたとき、その原因や対象方法を調査することができる
最後はSEOとはあまり関係がありませんが、ウェブサイトにとっては重要な問題です。あなたが管理しているウェブサイトに対して、どこからか継続的な攻撃（例えばページをひたすらリロードするF5攻撃や、サーバーダウンを狙うDDoS攻撃）があったり、あるいは最悪にして、何らかのバックドア（サーバーに侵入するための裏口）を設置されて、ウェブサイトが改ざんされてしまった場合、あなたならどうしますか？
このような事態に遭遇した場合、私が考える最善な方法は専門の業者を頼ることです。世の中にはサイバーセキュリティに対する専門家がたくさんいます。攻撃の手口が多様化し複雑化している現在、個人でできることには限りがあります。問題が深刻なら、まずは専門家に相談することをおすすめします。
専門家に依頼する場合、まずはサーバーの生ログの提供を求められることが多いでしょう。生ログには、ウェブサーバがどのような攻撃をうけているか、どのようにしてバックドアが設置されたかの形跡が、くっきりと残っていることが多いからです。
このブログの最初にお見せしたエラーログは、弊社のウェブサイトが実際に海外のとあるIPアドレスから攻撃を受けていた際のエラーログです。この時は、特定のIPアドレスから大量のリクエストがあり、サーバーのレスポンスが極端に落ちてしまいました。このような場合は、そのIPアドレスからのアクセスをブロックするのも有用な手段となります。もっとも、攻撃者が複数のIPアドレス（あるいは踏み台のサーバ）を所有していることも多いので、根本的な解決のためには、サーバーのセキュリティホールを防ぐことがより重要となります。
そのセキュリティホールを防ぐためにも、生ログは有用な情報源となります。どこが集中的に攻撃されているかが分かるからです。例えばログインページに対してブルートフォースアタック（総当たり攻撃）をしかけて、パスワードを破ろうとしていることが分かった場合、ログインページのURLをデフォルトのものから変えることが有用な対策となり得ます。また万が一バックドアを設置された場合でも、そのファイル名が何であるのかの形跡が生ログに保存されていることがあります。その情報を手がかりにサーバーの掃除を行って、バックドアを完全に削除することなども有用です。
最後に
以上、ウェブサーバの「生ログ」について、特にSEOにおける有用性について説明してきました。普段、なかなか生ログを扱うことは少ないと思いますが、一度、まずは見てみることからはじめてみてはどうでしょうか。そこには何か、今までには気付かなかった発見があるかもしれませんよ。
本当の最後に・・・今回ご説明した「生ログ」の分析も含めて、SEOについてお困りのことがありましたら、ぜひプリンシプルにご相談ください！
デジタルマーケティング戦略、Web解析、SEO、リスティング広告、Facebook広告、Linkedin広告、Tableauでのデータビジュアライズなどなど、何か弊社でお役に立てそうなことがございましたら、お気軽にご相談ください。ご相談は無料で承っております。
ご興味のある方はこちらよりお気軽にお問い合わせください。
プリンシプルでは業界最高レベルの専門家として一緒にご活躍いただける方を募集しています。詳しくはこちら。
