クロールの割り当ては気にしなくていい｜見るべき別の指標

「巡回の割り当てが足りないから順位が上がらない、と社内で言われた」「対策すべきだと言われたが、何をすればよいのか判然としない」——検索対策の現場で広まっている誤解です。この考え方が効いてくる場面は、実はかなり限られます。大半のサイトで起きているのは、割り当て不足とは別の問題です。この記事では、代わりに見るべき指標を整理します。

言葉だけが先に広まっている

クロールの割り当ては、もともと大規模なサイトの運用のために説明された考え方です。それが一般的な話として広まり、登録されない理由をすべて説明できる万能の答えのように扱われるようになりました。しかし公式のガイドは、冒頭で対象を明確に絞っています。

対象として挙げられているのは2種類です。重複のないページが100万以上あり、1週間に1回程度更新されるサイト。そして重複のないページが1万以上あり、毎日かなり頻繁に更新されるサイト。いずれも大まかな目安で正確なしきい値ではない、とも明記されています。

BtoBのオウンドメディアで、この規模に当てはまるものはほとんどありません。毎日1本書き続けても、1万ページに届くには何十年もかかります。ページ数が数百から数千のサイトは、はじめから対象外という前提で考えるほうが実態に合います。

もうひとつ、公式が対象として挙げている条件があります。住所の大部分が「検出されたが登録されていない」という分類に入っているサイトです。これは規模ではなく状態の条件で、数千ページ規模でも当てはまることがあります。ただしこの状態の原因も、多くは内容の重なりにあります。

そもそも何を指す言葉なのか

クロールの割り当ては、単独の数値として存在するものではありません。2つの要素の掛け合わせで決まる結果を、便宜的にそう呼んでいます。ひとつは能力の上限、もうひとつは必要性です。

能力の上限は、サーバーに負担をかけない範囲を指します。同時にいくつの接続を張ってよいか、どれくらいの間隔で取りに行ってよいか、という制限です。これはサイト側の事情ではなく、相手が勝手に決めて勝手に調整します。

必要性は、そのサイトをどれだけ取りに行きたいかという度合いです。サイトの規模、更新の頻度、ページの品質、関連性で決まると説明されています。こちらは中身の問題であり、設定でどうにかなるものではありません。

要素	何で決まるか	サイト側でできること
能力の上限	サーバーの応答の速さと安定	応答時間の改善・エラーを減らす
必要性	規模と更新頻度と品質と関連性	内容の質を上げる・不要な住所を減らす

この2つを分けて理解しておくと、対策の当たり外れが読めるようになります。サーバーを増強しても、必要性が低いサイトでは取りに来る回数は増えません。逆に良い記事を出しても、サーバーが遅ければ上限が下がって取りに来られません。どちらか一方だけを直しても効かない構造になっています。

上限は上がるより下がりやすい

能力の上限は自動で調整されます。公式の説明では、一貫して応答し、応答時間が安定しているか改善している場合は上限が上がります。逆に応答が遅くなったり、サーバー側のエラーや過負荷を示す応答が返ったりすると下がります。

ここで押さえたいのは、上げるより下げるほうが起きやすいという点です。上げるには継続的に速い状態を保つ必要がありますが、下がるのは一度の障害でも起こり得ます。共用のサーバーで他のサイトが重い日にも影響を受けます。

つまり、割り当てを増やそうとして何かを足すより、遅くなる原因を作らないほうが効果が確実です。重い画像を大量に置く、応答に時間のかかる仕組みを増やす、といった変更のほうが影響が大きくなります。

BtoBのサイトで見落とされやすいのが、共用の契約で運用している場合です。同じサーバーに同居している別のサイトが重い処理を回していると、こちらの応答も遅くなります。自社は何も変えていないのに応答時間が悪化する、という現象はここで起きます。原因が自社の外にあるため、記事を直しても改善しません。

複数のクローラーで上限は共有される

見落とされやすい仕様があります。必要性はクローラーごとに異なりますが、能力の上限はすべてのクローラーで共有されます。本文用、画像用、動画用が別々の枠を持っているわけではありません。

この仕様が効いてくるのは、画像や動画を大量に持つサイトです。本文のページを取りに来てほしいのに、枠を画像の取得が使ってしまうという状態が起こり得ます。数万点の商品画像を持つサイトでは実際に問題になります。

逆に言えば、画像が数百枚程度のサイトでは気にする必要がありません。共有されているという事実は正しくても、そこに詰まりが生じるほどの量がなければ、実務上の影響は出ません。仕様として正しいことと、自社で効いてくることは別だと切り分けます。

この切り分けは、社内で説明するときにも役立ちます。「共有されているから画像を減らすべきだ」という主張は、仕様の説明としては間違っていません。しかし数百枚の規模では効果が測れないため、同じ工数を記事の見直しに使ったほうが成果につながります。

取得の目的は検出と更新に分かれる

クロールの統計情報のレポートには、取得の目的別の内訳があります。分類は2つ。検出と更新です。検出は、まだ知らない住所を新しく見つけに来た取得を指します。更新は、すでに知っている住所の中身が変わっていないかを確かめに来た取得です。

この内訳が読めると、詰まりの位置が推測できます。新しい記事がなかなか登録されないのに、更新の取得ばかりが積み上がっている場合、既存のページの確認に手間を取られて、新しい住所へ手が回っていない可能性が見えてきます。

ただしこの読み方が成立するのも、ある程度の規模からです。月に数本しか記事を出さないサイトでは、検出の取得はもともと少なく、内訳が偏っていること自体は異常ではありません。数字が動いた理由を説明できないなら、その数字は見ないほうが判断を誤りません。

中小のサイトで起きている問題は別にある

では、数百ページのサイトで記事が登録されない場合、本当の原因はどこにあるのでしょうか。現場で確かめていくと、原因はだいたい3つのどれかに落ち着きます。

1つ目は、同じ内容が複数の住所から見える状態です。絞り込みの条件、並べ替えの指定、印刷用のページ、同じ記事が10通りの住所を持っているサイトは珍しくありません。取りに来る回数は同じでも、中身の種類は10分の1になります。

2つ目は、消したはずのページが残り続けている状態です。削除したページが見つからないという応答ではなく、内容の薄い案内のページを返している場合、それは削除として扱われず、いつまでも確認され続けます。

3つ目は応答の遅さです。ページを開くのに数秒かかる状態が続けば、上限は下がります。この3つはいずれも割り当ての話ではなく、サイトの整理と速度の話です。

さらに言えば、この3つのどれにも当てはまらないのに登録されない記事もあります。その場合の原因は、内容が既存のページと重なっていることがほとんどです。取りに来た上で、登録する価値がないと判断されている状態です。これは回数を増やしても解決しません。記事の側を変える必要があります。

原因1 同じ内容が複数の住所から見える

この問題への対処は、住所の設計を見直すことです。並べ替えや絞り込みの結果に固有の住所を与えているなら、その多くは検索から見つかる必要のないページです。

正規化の指定で本来の住所を示すのが基本の対応です。それでも取りに来る回数が減らない場合は、パラメータの付いた住所そのものを生成しない作りに変えるほうが根本的です。仕組み側の話になるため、開発と一緒に検討します。

ここで出さない指定を使うのは避けます。公式は割り当ての管理に出さない指定を使わないよう明記しています。指定を読むために結局は取りに来るため、回数は減らないからです。

実務でまず確かめるのは、自社の記事1本が何通りの住所から開けるかです。並べ替え、絞り込み、印刷用、追跡用の印が付いた住所を数えます。配信の効果を測るために付けた印が、そのまま別の住所として扱われている例は多い。この場合は正規化の指定を入れるだけで解消します。

原因2 消したページが残り続ける

削除したページの扱いは、意外と雑になりがちです。多いのは、削除したページを一律でトップページに転送してしまう形です。これは内容の一致しない転送として扱われ、削除と認識されません。

正しくは、そのページが完全に削除されたことを示す応答を返します。内容が別の場所に移ったのであれば、その内容に対応する個別のページへ転送します。一括でトップに送るのは、どちらの意味にもなりません。

あわせて確かめたいのが、削除されたのに正常な応答を返しているページです。「お探しのページは見つかりません」と表示しながら200を返す作りは、相手からは正常なページに見えるため、確認され続けます。

公式もこの状態を無駄として名指ししています。存在しないのに正常を装うページは取得され続け、その分の時間が消えていくためです。終了したセミナーの案内や、販売を止めた製品のページで起きやすい。終了時の処理を運用の手順に入れておくと、後からの棚卸しが要りません。

原因3 応答が遅い

応答の遅さは、上限を直接下げます。ここは推測ではなく公式に書かれている因果関係です。レイテンシや最初の1バイトが返るまでの時間が改善すれば上限は上がり、悪化すれば下がります。

実務でまず見るのは、画像の大きさと数です。表示に必要な寸法の何倍もある画像を置いている記事は多く、画像の書き出しを見直すだけで応答が目に見えて改善します。次に外部から読み込んでいる部品の数を数えます。

公式は、内容が変わっていないときに変更なしを返す仕組みへの対応も挙げています。これに対応していると、変わっていないページは保存された内容が再利用されます。その分の余力が、新しいページの取得に回ります。

なお、この項目は割り当てのためだけの施策ではありません。応答が速いサイトは読者にとっても快適で、離脱が減ります。割り当ての話を抜きにしても、投資して損のない唯一の項目がここです。他の対策と違い、効果が読者側にも同時に出ます。

転送の連鎖とサイトマップを整える

公式が挙げている項目のうち、中小のサイトでも起きやすいものが2つあります。ひとつは転送の連鎖です。住所を変えるたびに転送を足していくと、1つの住所にたどり着くまでに何回も転送を経由する状態になります。

リニューアルを2回、3回と重ねたサイトでよく見つかります。古い住所から新しい住所へ、さらに新しい住所へと数珠つなぎになっている形です。転送は経由するたびに時間がかかり、途中で追跡を打ち切られることもあります。最初の住所から最終の住所へ、1回で届くように張り直します。

もうひとつがサイトマップです。実在しない住所が大量に載っていると、そこに時間を使わせることになります。更新日の情報も、実際に更新していないのに毎日書き換えていると、情報としての信頼性が下がり、参照されなくなります。

確かめ方は簡単です。サイトマップに載っている住所を10件ほど無作為に開いてみる。1件でも見つからない住所が混じっていれば、生成の仕組みを見直す合図です。自動で作られているから正しいとは限りません。月に一度、この抜き取りの確認を入れておくだけで足ります。

やってはいけない3つの対策

割り当てを気にするあまり、逆効果の手を打つ例が後を絶ちません。公式が明確に否定しているものを挙げます。

• 割り当てを空けるために、価値の低いページへ出さない指定を入れる
• 他のページに回すために、一時的に通信の制御で範囲を絞る
• 更新していないのに日付だけを書き換えて、頻繁な更新を装う
• サイトマップに登録するだけで登録されると考え、中身を見直さない

1つ目が効かない理由は単純です。出さない指定は読まれてはじめて効くため、そのページには結局取りに来ます。クロールの時間は変わらず消費されます。

2つ目については、公式がはっきり述べています。すでに能力の上限に達していない限り、空いた割り当てが他のページに再配分されることはありません。上限に達していない大多数のサイトでは、単に減るだけです。

3つ目の日付だけの書き換えも、期待した効果は出ません。内容が変わっていなければ、確認した側にはそれが分かります。更新を装う操作を繰り返すと、日付の情報そのものが参照されなくなります。本当に更新したときに気づかれない、という損のほうが大きくなります。

見るべき指標は統計情報ではない

クロールの統計情報のレポートは、名前の印象ほど万能ではありません。公式のヘルプには「サイトのページ数が1,000未満の場合、このレポートを使用する必要はありません」と明記されています。

このレポートが役に立つのは、取得の回数や応答の内訳を見てどこで詰まっているかを推定したい規模のサイトです。数百ページのサイトでは、数字が動いても意味のある解釈ができません。日々の変動を追っても打ち手に結びつきません。

見るとすれば、ホストのステータスの部分だけで足ります。ここは通信の制御ファイルの取得、住所の解決、サーバー接続の3つが正常かを示します。ここに問題が出ていれば、割り当て以前にサイトへ到達できていません。

ホストのステータスで見る3つの経路

ホストのステータスは、サイトに到達するまでの3つの段階を示します。1つ目は通信の制御ファイルの取得。2つ目は住所を実際の場所に変換する解決。3つ目はサーバーへの接続です。この3つはどれか1つでも失敗すると、その先へ進めません。

公式のヘルプでは、ある日に失敗した割合が一定を超えると問題として扱われる、という形で説明されています。たとえば住所の解決については、その日の失敗が5%を超える場合が例として挙げられています。対象となる期間は過去90日間です。

ここに赤が出ている場合、記事の内容や割り当ての話は一切関係ありません。サーバーの契約先や名前の設定側で何かが起きています。まずサイトの管理者か、契約している事業者に連絡するのが正しい動きです。自分で記事を直しても状況は変わりません。

逆に、ここが3つとも正常であれば、到達の経路には問題がないと分かります。その上で記事が登録されないなら、原因は内容と構造の側にあります。この切り分けができるだけでも、このレポートを開く価値はあります。毎日見る必要はなく、異変を感じたときに1回開けば足ります。

代わりに見る3つの数字

では何を見るのか。数百ページのサイトで実際に打ち手につながる数字は3つです。登録されている住所の数、登録されていない住所とその理由、そして表示の速さです。

1. 登録の状況を示すレポートで、登録済みと未登録の件数を月に一度確認する
2. 未登録の理由の内訳を見て、上位2つの理由に絞って原因をたどる
3. 主要なページの表示の速さを測り、遅い順に上から3ページだけ直す

未登録の理由には「検出されたが登録されていない」「クロール済み・未登録」などが並びます。前者が大量にある場合は、公式のガイドが対象として挙げている状態に近づいている合図です。ただしこの状態は、内容の質の問題であることのほうが多くなります。

後者が多い場合は、取りに来た上で登録しないと判断されています。これは割り当ての不足ではなく、内容の評価の問題です。同じ主題の記事が社内に複数あるなら、まとめる方向で検討します。

3つ目の表示の速さは、無料の測定の道具で足ります。全ページを測る必要はなく、流入の多い順に3ページだけを見ます。遅いページを直す作業は、割り当てにも読者の体験にも同時に効きます。月に一度、この3つを見る時間を30分だけ確保すれば運用として成立します。

大規模なサイトで初めて効いてくる打ち手

念のため、実際に対象となる規模のサイトで何をするのかも整理しておきます。商品数が数万点を超える通販サイトや、求人や物件のように在庫が日々入れ替わるサイトが該当します。

この規模では、住所の生成の仕方そのものが設計の対象になります。絞り込みの組み合わせで住所が無限に増える作りを止める。在庫が消えた住所は、内容が薄いページを返さずに削除の応答を返す。転送の連鎖を短くする。

あわせてサイトマップの運用も重要になります。更新日を正しく入れ、実在する住所だけを載せる。数万件の一覧が古いままだと、そこに時間を使わせることになります。

在庫型のサイトでは、掲載を終えた住所の処理が最大の論点になります。求人が締め切られた、物件が成約した、商品が廃番になった。こうした住所を一覧のページへ一律に転送する作りが、もっとも多い誤りです。内容の一致しない転送として扱われ、削除としても転送としても機能しません。

正しくは、掲載が終わった時点で完全に削除された旨を返すか、代わりになる個別のページへ転送します。この処理を掲載終了の手順に組み込んでおくことが、後から数万件を棚卸しする事態を防ぐ唯一の方法です。

判断の順番を決めておく

最後に、迷ったときにたどる順番をひとつ決めておくことを勧めます。登録されない記事が出たとき、割り当てを疑う前に確かめる項目です。

• その住所は、登録の状況を確かめる機能で実際に取得できる状態か
• 同じ内容が別の住所からも見えていないか
• 同じ主題の記事が社内に複数なく、内容が重なっていないか
• サイト全体のページ数は1,000を超えているか

最後の項目で1,000に届かなければ、割り当ての線は消えます。残るのは内容と構造の問題です。原因を1つずつ潰す順番を決めておくと、思い込みで時間を使わずに済みます。

この順番を社内の手順として書いておくと、担当が変わっても同じ判断ができます。検索まわりは言葉が独り歩きしやすい領域です。公式に書かれている基準を自分たちの手順に落としておくことが、流行の説明に振り回されない一番の備えになります。

まとめ

クロールの割り当ては、公式が対象を明確に絞って説明している考え方です。重複のないページが1万以上で毎日更新される規模から、というのがその線引きです。数百ページのサイトでこの言葉を持ち出すと、原因の切り分けがかえって遠回りになります。

実際に起きているのは、同じ内容が複数の住所から見えている、消したページが残り続けている、応答が遅い、のいずれかであることがほとんどです。どれも割り当ての話ではなく、整理と速度の話です。

見る指標も切り替えます。統計情報のレポートは1,000ページ未満なら不要と公式に書かれています。代わりに登録の状況と未登録の理由、そして表示の速さを見る。この3つを月に一度確かめる運用のほうが、はるかに打ち手につながります。

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