株式会社Telescope SEOブログ「クロールバジェット要素分解とクローラーの行動原理解説」サムネイル画像
Telescope SEO Blog

クロールバジェット要素分解とクローラーの行動原理解説

ウェブページが検索エンジンの検索結果に表示されるまでには, 大きく分けて「①ディスカバリ → ②クロール → ③インデックス → ④ランキング」の4つのプロセスが存在します.

ディスカバリとはURLの発見, クロールとはウェブページのソースコードの解読, インデックスとは解読した情報の検索エンジンデータベースへの格納, そして検索が行われた際にそのインデックス情報を元に表示順位を決定して返すのがランキングのプロセスです.

ウェブページはディスカバリされなければクロールはされず, インデックスされなければランキングされることは例外なくありません.

クロールされなくてもインデックスされることはありますがディスカバリされなければインデックスされることはありません.

SEOは高度になるほどこれら4プロセスの原理と要素を理解し, 現在何がボトルネックになっており, それを解決するためにはどのような打ち手が存在するのかを知っている必要があります.

今回はこれらのプロセスのうちディスカバリとクロールにフォーカスして解説します.

主にクローラーの行動原理と, クロールの主要な指標であるクロールバジェットの要素分解を行います.

1. クロールバジェットの定義

GoogleはCrawl Rate, Crawl Demand(以下1-1, 1-2)を考慮し, クロールの割り当てを「クロールの必要性があり, かつGooglebotがクロール可能なURLの数」と定義しています.

1-1. Crawl Rate

  • Googlebotでサイトのクロール時に使用する同時並行接続の数, 及び次回のフェッチまでに必要な待ち時間を表す → サイトに対する取得速度の最大値が制限される(クロール速度の制限)
  • クロール頻度を示す
  • 以下の要因によって変動する
  1. クロールの状態:しばらくの間サイトが迅速に応答している場合, クロール速度の上限(クロールレート)が上がり, クロール時に使用可能な接続の数が増える(サイトの応答が遅くなった場合やサーバーエラーが返される場合, クロール速度の上限が下がり, Googlebotによるクロールが減る)  
  2. Search Consoleで設定された制限:ウェブサイト所有者は自身のサイトのGooglebotによるクロールを減らすことができる(上限を高く設定しても自動的にクロールが増えることはない)
  • クローラーは各サーバーに対する負荷を考慮しながらクロール回数を決定する(サーバー容量が十分であればクロール回数が増えやすい)
  • サーバースピードとサーバーレスポンス
  • サイトスピード / サーバースピードを上げればクロールレートは随時引き上げられる
  • クロールレートに満たなくてもインデックスの必要がないと判断すればGooglebotの活動は抑えられる

1-2. Crawl Demand

  • クロール速度が上限に達していない場合でも, インデクシングにおける必要がなければGooglebotによるクロールは少なくなる
  • 以下メイン2要素によってクロールの必要性が決まる
  1. 人気度:インターネット上で人気の高いURLほどGoogleのインデックスで情報の新しさが保たれるよう頻繁にクロールされる傾向がある → PageRank / リンク(内部, 外部), 検索結果でのインプレッション, クリック数, コンテンツの質等を見ていると予測される
  2. 鮮度:Googleのシステムではインデックス内のURL鮮度が落ちないようにしている
  • サイト移転など, サイト全体に関わる事象が発生した場合, 新しいURLのコンテンツをインデックスに再登録するためにクロールの必要性が高まる場合がある

2. クロールバジェットに悪影響を及ぼす要素

付加価値の低いURLがサイトに多数ある場合, そのサイトのクロール/インデックスに悪影響が及ぶ可能性があります.

以下に価値の低いURLを重要度順に記載します.

  1. ファセットナビゲーション
  2. Session Identifier:セッションID, アフィリエイトトラッキングコード, URLパラメーター, トラッキングパラメーター等
  3. サイト内の重複コンテンツ:canonicalを使う, オリジナルコンテンツと見なされるようにコンテンツを調整するなどの対応が必要
  4. ソフトエラーページ
  5. ハッキングされたページ:ハッキングされたページは削除してGooglebotには404を返す
  6. 無限のスペースとプロキシ
  7. 質の低いコンテンツやスパムコンテンツ

上記ページでサーバーリソースが浪費されると実際に価値あるページのクロールの妨げとなり, サイト上の優れたコンテンツの発見が遅れることになります.

Googleはエラーを返すページは数時間内に再評価を行いますが, 該当のページがエラーを返さないと認識した後, 以前表示されていた順位よりも下位に表示されるようになる可能性があります.

3. サイトの表示速度とクロール

  • サイトの表示速度を上げるとクロール速度も上がる
  • Googlebotは速度に優れたサイトはサーバーが健全な状態であることを表すものとみなすため, 同じ接続の数でより多くのコンテンツの取得が可能になる
  • 5xxエラーや接続タイムアウトが多い場合はサーバーの状態に問題があるとみなされ、クロールが遅くなる

4. クロールバジェットを消費するコンテンツ

  • 通常GooglebotによりクロールされるURLはいずれもサイトのクロールバジェットにカウントされる
  • AMP, hreflang 等の代替URL, CSSやjavaScript 等の埋め込みコンテンツについてもクロールが必要となる可能性があり, その場合にはサイトのクロールバジェットが使われることになる
  • 長いリダイレクトチェーンはクロールに悪影響を及ぼす場合がある
  • AMPはクロールバジェットを使う
  • CSS, JavaScriptファイルはクロールバジェットを使用する(現在のGooglebotはページ内のCSS, JavaScriptファイルをクロールする)

5. nofollowとクロール

  • nofollowのクロールバジェットへの影響は場合による
  • ページ内でURLをnofollowと指定しても, サイト内の別のページやウェブ上のページでリンクがnofollow指定されていない場合はクロールされる可能性がある

6. キャッシュとクロールバジェット

  • キャッシュを保存させればクロールバジェットを節約できる

7. サイトマップとクロールバジェットの関係

  • 手動で作成した部分サイトマップをGoogleに送信した場合:クローラーは, サイトマップに記載されておらず外部リンク / 内部リンクを通じて独立して発見したURLよりもサイトマップに記載されているURLを優先する
  • サイトマップが自動で生成されている場合, 全URLがサイトマップに入れられている場合はサイトマップ内のURLが優先されることはない
  • クロールレートを上げるためにサイトマップを定期的に送信する必要はない

8. クロールレートの上昇, 急上昇

  • Googleのアルゴリズムの判断でURLを二重にクロールする場合があり, クロールの急増は問題ではない
  • クロールレートの上昇はGoogleのアルゴリズム変更を意味するものではない
  • クロールレートの上昇は手動対策の予兆でもない
  • クロールレートの上昇はパンダアルゴリズムを当てられているということではない
  • リアルタイムペンギンはクロールレートの上昇を招かない
  • サイト移転が行われた場合, より頻繁にサイトがクロールされる傾向にある(httpsへの変更や重要なサイト構造の変化も含む)
  • サイト移転, httpsへの変更, URL構造の変更の後クロールレートが急上昇するのは自然な現象である

9. クロールレートの減少

  • スパム的なサイトであるとGoogleが特定した場合Googleのクロール優先度が下がる
  • 低品質なスパムコンテンツは長期間に渡ってクロールされないこともある

10. クロールレートの多様性

  • 同一サイト内でもURLによってクロールレートが異なる
  • URLによって数分おきにクロールされるものから2~3ヶ月に1回のものまである
  • サイト内のページのうちクロール頻度が低いページは品質が低い可能性がある → クロール頻度はページクオリティの代替変数になり得るが, 更新頻度の低いページはクロール頻度が下がるので一概にページ品質と相関するとは断定できない(あくまで代替変数的指標)

11. コンテンツの更新頻度とクロール頻度

  • 一般的にGoogleは原則的にページが更新されると予測される時期, またはページの更新頻度の予測値をベースにクロールを行おうとしている → 更新頻度の低いページは自ずとクロール頻度が下がる

12. Crawl Priority(クロール優先度)

  • サイト内のページによってクロールの優先度が異なる
  • 多くのサイトではホームページが最優先とされる(実際に多くのサイトではトップページが最も多くクロールされている)
  • クロール優先度の要素:PageRank / リンク, 人気度, 前回のクロールからの時間等
  • 優先度の高いURLほど頻繁に再クロールされる
  • 重要度の高いURLをクロールしたらクローラーが離脱する場合がある

13. Crawl Schedules(クロールスケジュール)

GoogleはURLのクロールスケジュールを作成しています. 以下のプロセスでURLの発見からページのクロールまでが行われています.

  1. ページをクロールした際にそのページにあるリンク(URL)を発見する
  2. サイトマップで送信されたURLの情報を参照する
  3. 上の2種の情報を元にクロールするURLのリストを作成する
  4. URLリストに従ってクロールする

クロールされるページ数はあくまでページの重要度によって決まり, URLの数によっては決まりません. URLがサイトマップに載っていることもページ重要度の要因の一つになります.

また, クローラーはクロール対象のURLリストを作成してそのURLに直接アクセスするため, Googlebotはリファラーを記録しません.

14. クロールするURLの選択

クロールスケジュールの中から実際にクロールされるURLは以下のプロセスで決定されています.

  1. クロールスケジュールに使用するシグナル(サイトマップ, PageRank等)を元にURLを区分
  2. 一定時間ごとに(厳密には一日単位ではないらしい)サイト内のクロール対象URL一覧を作成
  3. この一覧のトップから順番にURLをクロール
  4. 一覧をクロールしきればクローラーは離脱する(サーバー速度が落ちたりしたら一覧をクロールし終えずともクロールを中止する)

サイトマップ, PageRankはそのURLがクロールされるかどうかの重要指標です.(PageRankが最大指標)

15. Googleがクロール時に無視するページ

  • 前提:Googleがサイト内の全ページをインデックスしないことは自然な現象
  • noindexタグ
  • robots.txtでGooglebotがブロックされているページ
  • 複製された類似ページ:Googleは同一 / 類似ページをフィルタリングする(特に商品ページなど)

16. 内部リンクのクロールバジェットへの効用

  • 内部リンクは Crawl Demand 観点でクロールバジェットに影響する
  • 内部リンクはクロールするページの決定とその優先度の判断の一指標となる

17. nofollowとクロールバジェット

  • クロールバジェット関連の目的でサイト内でnofollowを使用することは問題ない(とGoogleのJohn Mueller氏が言っていました)
  • しかし同時に, GoogleはGooglebotが特定ページのヒエラルキーと重要度を判断する指標となるためnofollowリンクを使用しないことを推奨もしている
  • 上記2点が矛盾するのでnofollowについては正しい答えがないのが現状
  • クロールバジェットの観点でサイト内の特定のページをインデックスさせたくないならnoindexを使うべき
  • nofollowを使ってもそのページがインデックスされる可能性もあるしクロールバジェットを浪費する可能性がある(nofollow を当てたらインデックスされなくなることもある)

18. noindexとクロールバジェット

  • noindexを設置すればクロール頻度が極端に低下する(noindexが取り除かれたか見るためにたまにクロールする)
  • noindexページのクロール頻度は平均的に2~3ヶ月に一回
  • noindexページでもクロールされればクロールバジェットを消費する(robots.txtでGooglebotをブロックすればクロールされない)

19. noindexとrobots.txt

検索結果に表示されたくない, またはクロールされたくない, またはその両方の目的のために, noindexとrobots.txtを併用しているウェブページをたまに見かけます.

しかし, この対応を行ったウェブページは検索結果に表示されてしまう場合があります.

なぜなら, robots.txtでクローラーをブロックしているが故に検索エンジンがnoindexを認識できないからです.

Googleはクロールできないウェブページであっても, リンクが集まっているなど, コンテンツ以外の要因で検索結果に表示することがあります.

検索結果に表示されたくないならnoindexのみを実装し, noindexを認識させるためにクロールを許可する必要があります.

20. サーバーエラーのクローラーへの影響

  • サイトのレスポンスが遅い, またはサーバーエラーが返された場合, Googlebotがクロールするページ数が制限される

21. リダイレクトとクローラー

  • 301, 302リダイレクトによるPageRankの損失はない
  • Googlebotは一連で5本の301リダイレクトまでしか追わない(5本辿って目的のページに届かなかった場合次回のクロール時に回される)

22. クローラーとコンテンツ性質

  • Googlebotはコンテンツを表示するためにボタンのクリック, スクロール, プログラムの実行をできない → クリックしないと表示されないコンテンツをGoogleは原則的にクロール / インデックスできない
  • HTMLソースとしては存在しているがレンダリング時に隠されているコンテンツは, 通常クロール / インデックスされるが重要度を下げて評価されるか無視されていたが, モバイルファーストインデックス以降は初期状態で隠されているコンテンツも初期レンダリング時にソースが読み込まれていれば一般コンテンツと同等に評価されるようになった(しかし, 初期状態で隠されたコンテンツを表示させる導線が存在しなければただのスパム)
  • タブのクリック等によってコンテンツがJavaScript等で動的に生成される構成の場合インデックスされない場合がある(Googlebotはクリックを実行しないため)→ ページのレンダリング時にHTMLソースコード上に存在するコンテンツならクロール / インデックスはされる
  • ページ内コンテンツが動的に変化する場合, Googlebotは最初に表示されているコンテンツしか認識することができない
  • ハイパーリンクしていないただのテキストのURLはリンクとしてランクへの効用を持たないがURLのディスカバリには使用される
  • 最近のGoogleはハイパーリンクでなくとも, JavaScriptファイルの中などにURLらしきストリングスを発見したらクロールしにいくということをやっている
  • cf. Googleのディスカバリチームは1本でも多くのURLを発見することを目指している

23. デスクトップとモバイルのクロール

  • MFI以前は大規模サイトではPC中心にクロールをかけて, スマホ版ページはパターン認識による推測で済ませている
  • PCクローラーとモバイルクローラーの割合はMFI以前で8:2、MFI後は逆転

モバイルファーストインデックスの概要については本記事では割愛します.

24. スマホページ用クローラーについて

  • Googleはデスクトップ向けサイト用とスマホ向けサイト用の2種類のクローラーを持っている
  • 現在の Googlet Smartphone のユーザーエージェントはAndroid Nexus5

25. クローラーのその他情報

  • クロールされるURLは全てクロールバジェットに影響する
  • クロールはランキング要素ではない
  • あらゆる新規のサイトはデフォルトのクロールバジェットを与えられる
  • Googleはインデックス内でURLを古い状態にしないようにしている
  • 更新されていないページは再クロールされにくい
  • RankBrainはクロールバジェットに影響なし

ディスカバリ, クロール, インデックスプロセスは明確に区別して考える

以上, クロールバジェットの要素分解とクローラーの行動原理を解説しました. 過不足もあると思うので, 随時追記などしていきたいと思っています.

ランキングとインデックスは分けて考えるのが常識ではありますが, ディスカバリ, クロール, インデックスはまだまだ混同して語られるケースが多いように感じます.

任意のウェブページが上位表示されていないのはディスカバリ, クロール, インデックス, ランキングのどのプロセスに問題があるのか.

これを切り分けて考えると, クリティカルな打ち手を指すことができます.

そもそもURLがディスカバリされていないならサイトマップで存在を知らせる, クロールされていないなら内部リンクでクロールデマンドを上げる, インデックスされていないならFetch as Googleでインデックスリクエストを行う.

インデックスされていないページでいくらコンテンツの改善を行っても問題と解決策がフィットしないので徒労に終わります.

実際クロールが問題となるウェブサイトなど, ほんの僅かで, ほとんどのウェブサイトでは何もしなくてもクロールについては問題がないと言われています.

だからそこまで気を揉むことではないのだと思いますが, SEO担当者が主戦場とする検索エンジンの仕組みの理解水準を引き上げることで, 少なくとも施策と分析の精度が上がるのではないかと思います.

株式会社Telescope SEO担当 山内遼

SEOのご相談は, 問い合わせフォーム よりご連絡ください.

Telescope SEO Blog トップ

株式会社Telescope概要

社名    株式会社Telescope(Telescope Inc.)

代表者   山内 遼(代表取締役)

所在地   東京都渋谷区円山町28-4 大場ビルA館 6階B室

設立    2016年7月7日

資本金   4,194万円

事業内容  自動車比較メディア「SUNROOF(サンルーフ)

Telescope Inc.(株式会社テレスコープ)トップ