SEO Mythbusting S2エピソード2：クロールバジェットを徹底的解説

Google WebmastersのYouTubeチャネルで配信されたSEO都市伝説の誤解を解くシリーズ「SEO Mythbusting」のシーズン2、エピソード２を翻訳してお届けします。
（エピソード1はこちら）

今回のテーマはクロールバジェット、ゲストはMerkleのシニアアカウントマネージャーのAlexis Sanders氏です。細かい質問に対し、具体的な回答がたくさんある有意義なエピソードです。

以下、エピソードの内容をご紹介します。

以下、シーズン2エピソード2の内容をまとめます。一部省略や言い換えをしておりますが、主な意味が失われないようにまとめるようにしております。

①クロールバジェットとは

Sanders氏：

クロールバジェットの定義から始めませんか？Garyさんがウェブマスターブログの記事で説明した内容をまとめましょう。

Splitt氏：

良いですね。クロールバジェットを理解するためにはじめにその記事を読むと良いと思います。ウェブサイトをクロールする際に、できるだけ多くの情報を取得することと、クロールしているサイトのサーバーに負荷をかけすぎないことのバランスを考えなければなりません。

②クロール頻度とクロールの必要性とは

Sanders氏：

これはクロールの制限ですか？

Splitt氏：

そうですね、クロール頻度（クロールレート）です。サーバーが落ちない程度でどれぐらいサイトに負荷をかけられるかという意味です。また、Googleのリソースを効率的に使う必要があります。ウェブは非常にサイズが大きいので常に全ページをクロールするのではなく、優先度をつける必要があります。例えば、ニュースウェブサイトの更新頻度は高いため、頻繁に確認する必要があります。逆に、例えばキムチの歴史についてのウェブサイトだったら、あまり更新されないため頻繫にクロールする必要はありません。こちらは「クロールの必要性」と言います。クロールの必要性は、サイトが頻繫にクロールされるか、時々クロールされるかに影響します。

③クロール頻度とクロールの必要性の判断条件

Sanders氏：

クロールの必要性をどのように判断していますか？

Splitt氏：

サイトをクロールするとそのサイトについての情報を取得します。その情報は重複排除などに使われますが、最後の更新時期を確認するのにも使っています。ウェブマスターが構造化マークアップやページ上の日付などでページの更新日をGoogleに知らせることができて、Googleが更新頻度をモニタリングします。更新頻度が低ければ、頻繫にクロールする必要がないと判断します。これはコンテンツの品質とは全く関係なく、上位にヒットする素晴らしいコンテンツでも変わりません。単純にどれぐらいの頻度でサイトを見るべきか判断しています。

④ETag、HTTPヘッダー、Sitemap.xmlの最終更新日など

Sanders氏：

サイトのクロール頻度の判断にETagやlast-modifiedレスポンスヘッダーは使用していますか？それとも、コンテンツから取得した情報を元に判断していますか？

Splitt氏：

ウェブマスター側からGoogleに提供できるヒントは色々あって、先程話した構造化マークアップ、ETagとHTTPヘッダーもそうですし、Sitemap.xmlの最終更新日もそうです。ただ、例えばSitemap.xmlで常に自動的に最終更新日を更新しているだけでそれが実際のページの更新日と合わない・微調整しか行わなかったと判明した場合、その情報に頼れなくなります。

Sanders氏：

リソースを無駄に使いたくないですよね。

Splitt氏：

それだけではなく、このサイトではこの情報に頼れないと判断してその情報を使わないようになります。ウェブマスターが提供して使えそうな情報はすべて更新頻度の判断に使います。

⑤クロールバジェットに注意するべきサイトの規模

Sanders氏：

クロールバジェットを気にするべきウェブサイトはどのようなウェブサイトですか？

Splitt氏：

百万単位のURL数がある大規模サイトです。

Sanders氏：

ということは、URL数が100万以下だったら、クロールバジェットはあまり気にするべきではないということですよね？

Splitt氏：

おそらく大丈夫ですが、サーバーがあまりにも弱いと別です。ただその場合、問題はクロールバジェットではなくサーバーですね。

⑥クロールバジェットの「問題」

Sanders氏：

問題が発生した場合、原因としてよくあるのはサーバーとクロールの必要性のどちらですか？

Splitt氏：

「問題」とはどのようなものかによります。クロールバジェットが関係ないところで良く「クロールバジェットの問題」だと言われることがあります。例えばクロールはしたが、コンテンツの品質が悪くてインデックス登録をしなかったことがあります。そういうときは良く「クロールバジェットの問題ですか？」と聞かれます。いいえ、クロールはしたが品質が良くなかっただけです。

Sanders氏：

これはGoogle Search Consoleのカバレッジレポートの除外で見るようなURLですか？

Splitt氏：

その通りです、そのレポートを見るとわかりやすいです。また、「クロールバジェットが低くて困っています」と言われるときに、「それが本当に問題なのか？頻繁に更新されるコンテンツがあるか？」と聞くと、週1回更新されるブログだったと判明します。それなら本当に問題ではないですよね。またURLの公開がたまたまそのウェブサイトのクロールタイミングに間に合わないケースもあります。新URLをSitemap.xmlで提出しない限り、サイト内のどこかしらのページにあるリンクからそのURLにたどり着いてクロールしますので、タイミングが関係してきます。そのためSitemap.xmlを活用すると良いですね。ただし、数百万単位のURLを持つサイトでなければ、クロールバジェットが問題になることはめったにないです。

⑦コンテンツの品質とクロール頻度の関係

Sanders氏：

大規模のEコマースウェブサイトや不動産サイトなど、URL数が億単位のサイトでページごとのコンテンツ量が少なかったり、コンテンツ内容が一部重複したりするサイトがあると思います。そのような業種のサイトがよりクロールされるために、よりGoogleに好まれるために何かできる施策はありますか？

Splitt氏：

クロール頻度は別に役に立つことではありません。クロール頻度が高いからと言ってページの品質が良いとは限りません。クロールされて、一度インデックスされて、その後変更されなくてもGoogleの観点から全く問題ありません。ただし、Eコマースの場合、Sandersさんが言った通りのコンテンツ量が少なくて似たようなページがたくさんあったとき、似たようなページがたくさんある必要は本当にあるか？が気になります。例えば商品の色など、色別に10ページに分けるのではなく、1ページ内に各色を表示するテーブルがあるなどの方がどのような色があるかわかりやすくて良いと思います。

Sanders氏：

クロールバジェットに影響する要素が色々ありますね。

Splitt氏：

そうですね、例えばサーバーのレスポンス速度もあります。例えばたまに不安定になるサーバーだったら、Googleから単純にそういう不安定なサーバーなのか、クロールの影響で落ちそうになっているかはわからないので、クロールしすぎないように注意しています。

⑧サーバーがGoogleに試されているときのサーバーログ

Sanders氏：

例えば不安定なサーバーからより安定した強いサーバーに移転したとします。そうするとGoogleが新しいサーバーに対してどれぐらいの頻度でクロールできるか試すかと思いますが、サーバーログでどのような現象が見られますか？

Splitt氏：

はじめに少しクロール数が上がって、その後は下がって、その後はまた上がって、波のような動きが見られます。ウェブサイトは何も変えず、以前と同じようなスペックのサーバーに移転しただけでは特に何も起こらないこともあります。でも不安定なサーバーから良いサーバーに移転したら、おそらくクロール頻度が上がることが見られます。

⑨サイト移転のポイント

Sanders氏：

ウェブマスターは特にサイトリニューアルの際にクロールバジェットを気にしています。リニューアルの際に正しくクロールされるために何かポイントありますか？

Splitt氏：

サイト側に更新があるたびにSitemap.xmlを併せて更新すると良いです。更新されたものをクロールして、リダイレクトされていることに気づきます。ここはGoogleに対して大事な変更点です。Sitemap.xmlを活用することは、Googleがリニューアルの変更を見つけることにある程度影響します。以前のサーバーと新サーバーがどちらも問題なく動いていて、エラーを出していないこと、不安定でないことを確認してください。また、リダイレクトが正しく設定されていること、新サイトで重要なURLをrobots.txtでブロックしていないことを確認してください。以前のrobots.txtがあってそれを一気に変更するとGoogleが混乱する可能性があります。一気にサーバー、ドメイン、URL構造とコンテンツを変更するのではなく、順番にやる方が無難です。

⑩クロールバジェットとサイトの構造

Sanders氏：

クロールバジェットはウェブサイトのどこまで適用されますか？例えばCDNやサブドメインがある場合、クロールバジェットはどこまで影響しますか？

Splitt氏：

サイトによります。基本的にウェブサイトレベルでサイトを見ていますので、同じドメイン配下のページに適用されて、サブドメインは含まれる場合と含まれない場合があります。CDNは含まれているようで含まれないものであまり気にしなくて良いです。（コガン：CDNについて明確な回答が出ていないです。）
また一点UGC（ユーザーに作られたコンテンツ）があるサイトで1つ知っておくと良いことですが、もし品質の悪いコンテンツがある場合、それをインデックス登録しない、またはクロールしないように指定することができます。技術的な構造というよりコンテンツの話になります。

⑪レンダリングへの影響

Sanders氏：

クロールバジェットはクロールだけではなく、レンダリングにも影響しますか？

Splitt氏：

はい、レンダリングにも影響します。レンダリングする際に、ページ内の追加リソースを取得するため、そこもクロールバジェットに含まれます。クロールするときもレンダリングするときも同様にサーバーに負荷をかけすぎないようにしています。一気に数千リクエストを送ってサイトを落としたくないからです。特に数百万のURLがある大規模サイトで、例えばキャッシュの設定にミスがあったとします。キャッシュがないため、Googleはリソースを何度も取得することになります。同様にサーバーにたくさんのリクエストを送ります。サーバーレスポンス速度が大きく下がったら、Googleが取得頻度を落として、その結果リソースの取得が失敗することがあります。例えばクロールするとき、最初の50万ページを無事にレンダリングできて、それ以上はサーバーの負荷を鑑みて取得しないと判断される可能性があります。この場合、リソースの取得が失敗して正しくレンダリングできないパターンが考えられます。

⑫リソースのキャッシュ

Sanders氏：

キャッシュはどうすれば良いですか？ページだったらSitemap.xmlに含めたり、構造化マークアップやHTTP ヘッダーで色々対応できますが、リソースはどうすれば良いですか？

Splitt氏：

GoogleはCSS、JavaScript、APIコールなどのサブリソースをキャッシュする際に積極的になるべく多くキャッシュしようとしています。APIコールでGETリクエストじゃなければキャッシュできないため、POSTリクエストは注意してください。APIによってはデフォルトでPOSTになっていますが、そうするとキャッシュができずクロールバジェットがより早く上限に達します。また、なるべくリソースのURLを変えないことがベストです。キャッシュ対策として良い1つの施策はリソースの中でコンシステントハッシュを使うことです。そして例えばapplication.javascriptのかわりにapplication.のあとにAEFやCE–のようなコンテンツを表すハッシュを.javascriptにしてそれを永続的なものとします。JavaScriptを更新すれば新しいURLが生成されて、Googleはそれ以前のものをキャッシュしているので新しいHTML内に新しいJavaScriptのためのURLを取得することができます。

Sanders氏：

バージョニングのようなイメージですね。

Splitt氏：

そうです、URLでバージョニングするようなイメージです。

Sanders氏：

各バージョンのキャッシュはどれぐらい維持されますか？

Splitt氏：

状況によりますが、なるべくアグレッシブにキャッシュしようとしています。1日でも、1週間でも1ヶ月でも考えられて、キャッシュのヘッダーを無視することもあります。例えば、サイト側で明日までだと指定していても、Google側でそうでないと判断してキャッシュする場合があります。

⑭サイト業種とクロールバジェットの関係

Sanders氏：

クロールバジェットの課題を特に持ちやすい業種はありますか？

Splitt氏：

Eコマースとメディアサイトはページ数が多くクロールバジェットに引っかかることが比較的多いと思います。また、以前Zurichのウェブマスターカンファレンスで日本の面白い事例がありました。UGCコンテンツが非常に多いサイトで、機械学習を使ってコンテンツの品質が良いかどうか判断して、品質が悪いと判断されたページはクロールバジェットを無駄に消化しないようにnoindexタグを設定してrobots.txtに含めるようにしていました。毎日100万ページ程生成されていてその多くはスパムだったので、1日当たりのクロールバジェットが20万ページ程度に減少しました。インデックスもされないスパムにクロールバジェットを消化するのがもったいないと考えていたようです。
（コガン：サイバーエージェントの木村さんが2018年のGoogle Dance Zurichで紹介したアメブロの事例のようです！）

Sanders氏：

そのサイトは品質が良くないコンテンツの割合が高かったからサイト全体への評価への影響があったと思いますか？

Splitt氏：

それはなく、この特定のページが良くないのでインデックス登録しないという形なので結果はインデックスされなかったページが多かったです。またはコンテンツが薄いときなど、例えばストック画像一枚と「(笑)」のようなテキストが投稿されたら、それはあまり良いコンテンツではないので、そのようなページはインデックスしません。

⑮Googlebotのクロールを手伝う基本的な方法

Sanders氏：

何かGooglebotのクロールとレンダリングを手伝うためのおすすめ方法はありますか？

Splitt氏：

ページをレンダリングするのに必要ないリソースがあるとわかっていれば、そのリソースをブロックして良いです。例えば、社内のアナリティクスやチャットツールなどはクロールされても意味がありません。ただ、ここは非常に気を付ける必要があります。例えばAPIがレンダリングに不要だと思っても実はJavaScriptがページをレンダリングするためにそのAPIが必要だった場合、そのAPIをブロックしてはいけません。そこをブロックしてしまったらGoogleがコンテンツを確認できないかもしれません。

Sanders氏：

そのブロックというのはrobots.txtで良いですか？

Splitt氏：

そうです。ただ、重要なリソースをrobots.txt内に含めないように気を付けてください。また、クライアントサイドのアプリでよくあるのは、APIコールの行き来が多いパターンです。それらをFaçadeのようなものを通してProxyすることができます。特定の1リクエストに必要なAPIコールとバックエンドリクエストを走らせて、1レスポンスを返すアプリのようなイメージです。更にスピードを上げるために、キャッシュを使っていると良いです。それで1リクエスト＝1レスポンスの受け渡しになります。

Sanders氏：

GraphQLのようなものですか？

Splitt氏：

その通りです。ただGraphQLでPOSTモードを使わないように注意して、必ずGETリクエストを使うようにしてください。
要は、クロールしてほしくない部分をブロックし、更新頻度の情報をSitemap.xmlなどで渡して、Googlebotがウェブサイトのどの部分に注目すべきかわかりやすくすると良いです。

⑮良く起こりえる課題

Sanders氏：

クロールバジェットで良く起こりえる課題はありますか？

Splitt氏：

robot.txtのミスはよく見ます。大事なリソースがブロックされてしまうことは良くありますね。「CSSは要らないよね！」と。

Sanders氏：

それはページの見た目が全然わからない、レイアウトがわからないと困る！

Splitt氏：

その通りです。またABテストをしているときに要らないページをnoindexにして、それでインデックスもされないページにクロールバジェットが消化されてしまいます。またサーバー設定が間違っていてサーバーが常に500のレスポンスコードを返しているパターンもありますね。「なんでGoogleにクロールされないの？」と聞かれますけど、サーバーが常にオーバーしているように見えるからですよ。失敗パターンは色々あります。

⑯クロール頻度を上げるための設定があるか

Sanders氏：

最強なサーバー上に大規模サイトを持っているとします。Googlebotに「もっとクロールして良いよ！もっとたくさんのクロールを期待しています！」と言う方法はありますか？

Splitt氏：

Google側で判断していますのでそういう方法はありません。逆に制限することはできます。クロールスケジュールがかなり賢く、新しいコンテンツがたくさんあって、Sitemap.xmlにたくさんのURLが乗っていれば、できるだけ多くのURLをクロールしようとします。サーバーパフォーマンスの低下がない限りクロールし続けます。そのため、最終的に期待しているクロール頻度まで上がると思います。

感想・まとめ（コガン）

具体的な注意点やアドバイスが多く、とても貴重なエピソードだったと思います。

エピソード3は表示速度についてです。表示速度はすべてのサイトに影響する非常に重要な指標になりますので、是非チェックしてください。