サーバーの記録で取りこぼしを見つける5工程｜解析に映らない動き

記事を100本増やしたのに、検索からの流入が伸びない。解析の画面を何度見ても原因が分からない。こういうとき、見ている場所が違う可能性があります。解析の道具に映るのは、画面が正しく開かれた訪問だけです。エラーで返っていた頁、巡回されていない頁はそこには出てきません。この記事では、サーバーの記録から取りこぼしを見つける手順を整理します。

解析の画面に映らない訪問がある

まず、見えていない範囲を確かめます。多くの解析の道具は、頁の中に置いた記述が実行されることで訪問を数えます。記述が実行されなければ、その訪問は数えられません。実行されない場面は意外に多くあります。

代表的なのは、エラーで返った要求です。存在しない所在への要求、サーバーが応えられなかった要求。これらは頁が表示されないため、記述も実行されません。つまり、エラーが何件起きているかは解析の画面では分かりません。

次に、検索側の巡回です。巡回は人の閲覧とは仕組みが違い、解析の道具の数字には原則として含まれません。どの頁が何回巡回されたかを知りたい場合、別の場所を見る必要があります。

さらに、画像や資料への直接の要求も映りません。資料の所在を直接開かれた場合、頁を経由していないため記録が残りません。配った資料がどれだけ開かれているかを知りたい場合、この違いが問題になります。

これらすべてが残っているのが、サーバー側の記録です。要求が届いた時点で記録されるため、応えられたかどうかに関わらず残ります。実際に何が起きているかを知るには、この記録がいちばん正直です。

サーバーの記録には何が残るか

記録の中身を見ておきます。一行につき一つの要求が記録されます。含まれるのは、要求してきた所在、日付と時刻、要求された所在、応答の番号、送ったデータの量、そして名乗りです。

名乗りというのは、要求してきた側が自分を何と称しているかの記述です。利用者の閲覧の道具の名前、あるいは巡回の仕組みの名前が入ります。この記述を手がかりに、巡回だけを抜き出せます。

応答の番号は、サーバーがどう答えたかを示します。正常に返した、別の所在へ案内した、見つからなかった、処理に失敗した。この番号を集計するだけで、サイトの健康状態が分かります。

応答にかかった時間が記録されている場合もあります。設定によりますが、残っていれば遅い頁を特定できます。表示の速さの問題を実際の応答から確かめられるのは、この記録の強みです。

記録の形式はサーバーの種類によって違いますが、含まれる項目はおおむね共通です。初めて見ると文字の羅列に見えますが、項目の並びが分かれば読めるようになります。表計算の道具に取り込めば、並べ替えや絞り込みもできます。

解析の道具との使い分け

両者は競合しません。見えるものが違うため、目的で使い分けます。人の行動を知りたいなら解析の道具、機械の動きと応答を知りたいならサーバーの記録です。

知りたいこと	見る場所	理由
どの頁がよく読まれているか	解析の道具	滞在や遷移まで分かる
どの頁が巡回されているか	サーバーの記録	巡回は解析には映らない
エラーが何件起きているか	サーバーの記録	表示されない要求は解析に映らない
資料が何回開かれたか	サーバーの記録	頁を経由しない要求も残る
巡回の概要を手早く見る	サーチコンソールの報告	設定なしで見られる

表の最後の行にあるとおり、サーチコンソールにも巡回の統計の報告があります。こちらは設定が不要で、応答の番号の分布やファイルの種類ごとの内訳が見られます。まずここを見るのが手軽な出発点です。

では、なぜサーバーの記録まで見るのか。報告は集計された形でしか見られず、どの所在が巡回されたかまでは分からないためです。頁の単位で巡回の状況を知りたい場合、記録に戻る必要があります。

進め方としては、報告で概要を見て異常の気配があれば記録を掘る、という順番が効率的です。毎月記録を掘る必要はありません。何も起きていないときに深く掘っても得るものは少ないでしょう。

ログを取り出せるかを確かめる

実務の第一歩は、記録が取り出せるかの確認です。共用のサーバーでは、記録が提供されない場合があります。管理の画面に書き出しの機能があるか、契約の内容に含まれているかを確かめます。

提供されている場合、多くは圧縮された形で日ごとに用意されています。保存されている期間にも限りがあることが多く、数週間で消える設定になっている場合があります。必要なら定期的に自社へ移します。

配信の網を通している場合は、話が変わります。利用者からの要求は網の側で受け止められるため、自社のサーバーの記録には一部しか残りません。この場合、網の側の記録を取り出す必要があります。

記録が取り出せない場合の代替は、サーチコンソールの報告です。頁ごとの細かさは得られませんが、応答の番号の分布や巡回の量の推移は分かります。取り出せないことを理由に何も見ないのはもったいないところです。

なお、記録を触るにはサーバーの管理の権限が必要です。情報システムの部門や制作を任せている会社に依頼する形になることが多いでしょう。依頼するときは「巡回の状況を確かめたい」と目的を伝えると、必要な範囲だけを出してもらえます。

期間と量の見積り

次に、どれだけの期間を見るかを決めます。巡回の傾向を見るなら、2週間から1か月ぶんあれば足ります。1日だけでは偶然の偏りが混ざります。

量については、サイトの規模と資産の数に比例します。画像や装飾の部品への要求も一行ずつ記録されるため、行数は頁の閲覧数よりはるかに多くなります。

表計算の道具で扱う場合、行数の上限に当たることがあります。先に絞り込んでから取り込むのが現実的です。名乗りに特定の文字列を含む行だけを抜き出す処理を先に済ませておきます。

絞り込みの処理は、文字列を検索して該当する行を書き出す簡単な操作で足ります。情報システムの担当に頼めば数分で済みます。自分で行う場合も、手順を一度覚えれば毎回同じ操作です。

初回は、小さく始めるのが得策です。1週間ぶんを一つのディレクトリに絞って見る。そこで何が分かるかを掴んでから、範囲を広げます。最初から全部を扱うと、量に負けて続かなくなります。

巡回だけを抜き出す

記録を絞り込みます。検索側の巡回を抜き出すには、名乗りに巡回の仕組みの名前が含まれる行を選びます。主要な検索の巡回にはそれぞれ決まった名前があり、公式に公開されています。

抜き出したら、所在ごとに件数を数えます。どの頁が何回巡回されたか。この一覧が分析の土台になります。件数の多い順に並べると、巡回の力がどこに使われているかが一目で分かります。

多くのサイトで、この一覧を見ると驚きがあります。上位に並ぶのが、重要な記事ではなく絞り込みの結果や古い所在であることが少なくありません。巡回の力が無駄な場所に使われている状態です。

逆に、重要な記事がほとんど巡回されていないことも分かります。公開したのに気づかれていない。この場合、内部からのリンクが足りていない可能性があります。

集計の単位は、所在そのものだけでなくディレクトリや頁の型でも取ります。「記事の頁」「分類の頁」「絞り込みの結果」といった型ごとに集計すると、構造上の問題が見えやすくなります。

名乗りは偽装できる

重要な注意点があります。名乗りは自由に設定できる記述であり、巡回の仕組みの名前を騙って要求を送ることは技術的に可能です。名乗りだけを信じて集計すると、偽の巡回を本物として数えてしまいます。

確かめる方法は、要求してきた所在の逆引きです。所在から名前を引き、その名前から再び所在を引く。両方が一致すれば正当な巡回と判断できます。

この検証は、全件に対して行う必要はありません。件数の多い所在から数件を確かめれば、傾向は分かります。偽の巡回が多く混ざっている場合、特定の所在から大量の要求が来ている形として現れます。

公式に、巡回に使われる所在の範囲が公開されている場合もあります。その一覧と照らし合わせる方法も確実です。定期的に更新されるため、使う際は最新のものを取得します。

偽の巡回が大量にある場合、サーバーの負荷にもなります。対処としては遮断が考えられますが、本物を誤って遮断すると検索から消えます。この判断は慎重に行い、情報システムの担当と相談して進めてください。

応答の番号を数える

次の集計は、応答の番号です。巡回に対してサーバーが何を返したか。正常に返した割合と、エラーで返した割合を出します。ここに問題が出ていれば、巡回の効率が落ちている証拠です。

見るべき番号は四つです。正常、案内（転送）、見つからない、そして処理の失敗。見つからないが多ければ、存在しない所在への巡回が続いている状態です。

処理の失敗が混ざっている場合は、優先して手を打ちます。巡回のたびに失敗していると、その頁は評価の対象になりません。断続的に起きる失敗は気づきにくいため、記録から見つける価値が特に高い症状です。

転送が多い場合も確かめます。転送は必要な処理ですが、数珠つなぎになっていると巡回の力を無駄に使います。同じ所在が繰り返し転送されている形が見えたら、対応表を見直します。

集計は、番号ごとの件数と、番号ごとの代表的な所在を並べる形にします。「見つからないが1,200件、うち上位はこの5つの所在」という形です。この形にすれば、直す対象がそのまま作業の一覧になります。

見つかる典型的な取りこぼし

実際に見つかる型を並べておきます。一つ目は、重要な記事が巡回されていない型です。公開から数週間たっても巡回の記録がない場合、内部からのリンクを確かめます。

二つ目は、無数の所在が巡回の力を吸っている型です。絞り込みの結果、並べ替えの結果、検索の結果の頁。これらが上位に並んでいれば、巡回の対象から外す検討をします。

三つ目は、古い所在への巡回が続いている型です。何年も前に消した頁に今も要求が来ている。他のサイトからのリンクが残っている場合、無いと返すだけでなく転送先を用意する価値があります。

四つ目は、画像や部品が巡回の大半を占めている型です。この場合、頁への巡回が相対的に少なくなります。資産の数を減らすか、配信の網に載せるかで改善できることがあります。

五つ目は、特定の時刻に応答が遅くなっている型です。記録に時間が残っていれば見つかります。その時刻に重い処理が動いている可能性があり、巡回と処理の時間をずらすことで解消する場合があります。

内部のリンクの不足を記録から見つける

巡回されていない頁が見つかったとき、原因の多くは内部のリンクです。どこからも辿れない頁は、巡回の順番が後ろに回ります。記録を使えば、この状態を推測ではなく事実として掴めます。

記録には、どの所在から辿って来たかが残っている場合があります。巡回の記録でこの項目を見ると、その頁がどの経路で見つけられたかが分かります。経路がサイトの地図に相当する記述だけであれば、内部からのリンクがない可能性が高いです。

対処は単純で、関連する記事からリンクを通すことです。1本通すだけで、次の巡回から扱いが変わることがあります。どこから通すかは、内容が近い記事を選べば足ります。

逆に、巡回が多すぎる頁もリンクの構造から生まれます。すべての頁からリンクされている頁は、巡回の対象として重く扱われます。重要でない頁が全頁から張られていないかを確かめてください。

この分析は、記事の本数が増えたサイトで特に効きます。本数が増えると、古い記事へのリンクが自然に減っていきます。記録から巡回の減った頁を見つけ、新しい記事からリンクを通す。この循環がサイト全体の巡回を保ちます。

巡回の量が急に変わったとき

巡回の総数は、日によって変動します。しかし、急に大きく変わった場合は原因があります。増えた場合と減った場合で、疑う先が違います。

急に減った場合、最初に疑うのはサーバー側の応答です。エラーや遅い応答が続くと、巡回の量は自動的に絞られます。応答の番号の分布を見て、失敗が増えていないかを確かめてください。

遮断の設定も疑います。防御の仕組みを新しく入れた、設定を変えた。正当な巡回を弾いてしまうと、記録から巡回そのものが消えます。設定を変えた日と巡回が減った日が一致していれば、原因はほぼ確定します。

急に増えた場合は、所在が大量に増えていないかを見ます。絞り込みの条件の組み合わせで所在が無数に生まれる作りにすると、巡回の量が跳ね上がります。サーバーの負荷にもなるため、早めに手を打ちます。

偽の巡回が増えている場合もあります。名乗りを騙った要求が大量に来ている状態です。逆引きで確かめ、偽であれば遮断を検討します。ただし遮断の判断は本物を止める危険があるため、担当と相談して進めてください。

巡回されやすくする打ち手

記録から問題が見えたら、打ち手に移ります。巡回を増やす方法はいくつかありますが、効果の順番はおおむね決まっています。

最も効くのは、無駄な所在を減らすことです。巡回に使われる力には限りがあります。無数の絞り込みの結果に力を使わせなければ、その分が記事の頁に回ります。

次に効くのが、応答を速くすることです。応答が速いサイトは、同じ時間でより多くの頁を巡回されます。重い処理を軽くする、画像の容量を落とす。利用者にとっても良い改善になります。

三つ目は、更新の知らせ方です。サイトの地図に相当する記述を正しく保ち、更新の通知の仕組みを使う。新しい頁に早く気づかれるようになります。

四つ目が、内部のリンクの整備です。前の節で扱ったとおりです。この四つを上から順に手を付ければ、巡回の状況は着実に改善します。逆に、本数を増やすだけでは巡回の効率は上がりません。

外部に依頼するときの伝え方

記録の分析を自社で行えない場合、外部に依頼する選択があります。その際、何を知りたいのかを具体的に伝えるかどうかで、返ってくるものが変わります。

伝えるべきは三つです。対象の期間、見たい単位（頁ごとか分類ごとか）、そして知りたい問いです。「巡回の状況を見てほしい」だけだと、一般的な報告が返ってきます。

問いの形にすると精度が上がります。「先月公開した20本が巡回されているか」「見つからないの応答がどの所在で起きているか」。問いが具体的であれば、答えも具体的になります。

渡すデータの範囲も決めます。巡回の行だけを抜き出して渡せば、人の閲覧の情報を外に出さずに済みます。秘密保持の取り決めと、終わった後の廃棄も先に決めておいてください。

報告を受け取ったら、打ち手の優先順位まで聞いておきます。見つかった問題が10個あっても、全部を直すことはできません。「どれから直すと効きますか」と尋ねれば、実務に落とせる答えが返ってきます。

5つの工程にまとめる

ここまでを作業の順番に落とします。初回は半日、2回目以降は1時間ほどで回せます。

この五つのうち、三つ目を飛ばす人が多いのですが、偽の巡回を本物として数えると、以降の判断がすべて狂います。数件でよいので必ず確かめてください。

続ける形にする

毎月掘る必要はありません。四半期に一度、あるいは大きな変更のあとに見るのが現実的です。日常の監視はサーチコンソールの報告で足ります。

掘るべき場面は決まっています。サイトを作り替えた後、所在の付け方を変えた後、サーバーを移した後、そして流入が説明できない形で落ちたとき。この四つです。

特に、作り替えの直後は見る価値が高い場面です。転送の設定漏れや、新しい所在が巡回されていない状態が、記録にはっきり出ます。早く見つければ回復も早くなります。

記録を残す形も決めます。見た日、対象の期間、巡回の総数、番号ごとの内訳、打った手。この五つを一枚に残せば、次に見たときに比べられます。

比べられるようにしておくことが、この作業の価値を上げます。前回より見つからないの件数が減っている。重要な頁の巡回が増えている。こうした変化が見えれば、打った手が効いたことを数字で示せます。

記録の取り扱いにも配慮が要る

最後に、扱いの注意です。サーバーの記録には要求してきた所在が含まれます。これは個人を識別し得る情報として扱うべき場合があります。無造作に共有するのは避けてください。

実務としては、巡回の分析に使う場合は人の閲覧の行を除いて扱えばこの問題を小さくできます。巡回だけを抜き出した後のデータを共有する形にします。

保管の期間も決めます。分析が終わったら元の記録は消す。集計した結果だけを残せば、必要な情報は保てます。長く持ち続ける理由はほとんどありません。

外部の会社に分析を依頼する場合は、渡す範囲を絞ります。秘密保持の取り決めを結び、渡したデータの扱いと廃棄を決めておいてください。自社の方針や規程がある場合は、そちらに従います。

• サーバーの記録を取り出せる状態か、契約と管理画面を確かめたか
• 配信の網を通している場合、網の側の記録も取れるか
• 巡回だけを抜き出したうえで、名乗りを逆引きで検証したか
• 所在ごとと応答の番号ごとの、二つの集計を出したか
• 人の閲覧の行を含むデータを、必要以上に共有していないか
• 見た日・期間・総数・内訳・打った手を記録に残したか

• 名乗りだけを信じて集計し、偽の巡回を本物として数える
• 1日ぶんの記録だけを見て、偶然の偏りを傾向と判断する
• 全部の取りこぼしを一度に直そうとして、途中で止まる
• サーチコンソールの報告を見ずに、いきなり記録を掘り始める
• 要求してきた所在を含む記録を、権限を絞らずに共有する

• 巡回に使われる所在の一覧は更新される。使う際は最新のものを取得する
• 偽の巡回の遮断は、本物を誤って止める危険がある。担当と相談して進める
• 記録の保管と共有は、自社の情報の取り扱いの方針に従う

まとめ

解析の道具に映るのは、頁が正しく開かれた訪問だけです。エラーで返った要求、検索側の巡回、資料への直接の要求は映りません。これらが残っているのがサーバーの記録で、実際に何が起きているかを最も正直に示します。

手順は五つです。記録を取り出し、巡回だけを抜き出し、名乗りを逆引きで検証し、頻度と応答の番号を集計し、対象を三つに絞って手を打つ。毎月やる必要はなく、作り替えの後や説明できない落ち込みのときに掘る。日常の監視は巡回の統計の報告で足ります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。