クロール バジェットに影響を与える 7 つの主な要因

公開: 2022-11-22

ページが Google でランク付けされる前に、ページが発見され、インデックスに登録される必要があります。

これを達成するための最初のステップは、クロールと呼ばれます。

クロールすると、Google (または検索エンジン) はリンクを介してページに移動します。 ボットは、ページ上のすべてのコンテンツを取得し、ページ内のリンクを識別して、それらもフォローします。 ただし、Google のリソースが無制限ではないことはあまり知られていません。 世界中のあらゆる場所からすべてのページをクロールするために、Google はいくつかの妥協点を見つけ、いくつかの変数に基づいてすべてのサイトのクロール バジェットを設定する必要があります。

今日のガイドでは、クロール バジェットに大きく影響する 7 つの要因とその方法を探り、それらを特定して対処するための準備を整えます。

1. ファセット ナビゲーションと無限のフィルタリングの組み合わせ

ファセット ナビゲーション (またはファセット検索) は、ユーザーがアイテムをフィルター処理できるページ内ナビゲーション システムです。

ナビゲーションのフィルタリング オプションの例。

ユーザーがこれらのオプションのいずれかを選択すると、選択したパラメーターに一致するアイテムのみがページに表示されるため、消費者は探しているものを簡単に見つけることができます。

この変更は、通常、次の 2 つの方法で行われます。

  • JavaScript を使用してリストを動的に更新する
  • JavaScript を使用せずにページをリロードして新しいリストを表示する

ただし、実際に興味深いのは、この変更に対して URL がどのように反応するかです。

ファセット ナビゲーションの性質上、ほとんどの場合、変更に対応するためにユーザーが選択したファセットに基づいて新しい URL が生成されます。 一般的なファセットの実装は 3 つあります。

  • URL の末尾に新しいパラメーターを適用する
  • 選択したファセットを識別する URL にハッシュを追加する
  • 新しい静的 URL の生成

上記の例では、URL は次のようになります。

https://www.zumiez.com/snow/snowboards.html

いくつかのファセットを適用するとどうなるか見てみましょう。

  • ショップ別 > メンズ: https://www.zumiez.com/snow/snowboards.html?en_gender_styles=Men%27s
  • ブランドの追加 > バートン: https://www.zumiez.com/snow/snowboards.html?brand=Burton&en_gender_styles=Men%27s
  • 形状の追加 > 指向性: https://www.zumiez.com/snow/snowboards.html?brand=Burton&en_gender_styles=Men%27s&en_shape=指向性
スノーボードで「メンズ」フィルターを使用した例

ご覧のとおり、選択したファセットごとに新しい URL バリエーションがあります。つまり、検索エンジンによってクロールされる新しい URL があります。

クローラーは非常に単純に動作します。リンクを見つけ、ページへのリンクをたどり、そのページ内のすべてのリンクを収集し、それらもたどります。 このプロセスは小規模なサイトでは非常に高速であるため、クロール バジェットの浪費を心配する必要はありません。

サイトに約 500 ページある場合、Googlebot は非常に高速にクロールできます。 しかし、ファセット URL が混在し、すべてのページに 10 個のバリエーションがあるとしたらどうなるでしょうか? 500 ページのサイトが 5,000 ページのサイトになり、クロール バジェットが無駄になります。 Google が同じコンテンツを 10 回もクロールする必要はありません。

実際、多くの場合、すべてのバリエーションがクロール バジェットを消費するため、少数の重要なページのみがクロールされ、新しいより重要なページのクロールとインデックス作成に時間がかかります。

サブフォルダー、タグ、フィルター

e コマース プラットフォームである Magento 2 の場合、フィルターを実装すると、これらのファセット URL がサイトを肥大化させる可能性があります。 ただし、Magento のより明確な問題は、1 つの URL がカテゴリによって複数のサブフォルダーの一部になる可能性があり、同じコンテンツを表示する複数の URL バリエーションが生成され、クロール バジェットが浪費されることです。 Shopify ユーザーは似たような問題に悩まされていますが、タグが原因です。

タグは通常、URL の末尾に追加されますが、ページ上ではあまり変化しません。 カテゴリと同様に、同じ製品/ページで複数のタグを使用して、SEO 値を追加せずにクロールされる複数の URL バージョンを作成できます。

2. セッション ID とトラッキング ID

セッション ID とトラッキング ID は、分析に使用されるパラメーターであり、場合によっては、特定のユーザー設定を記憶するために使用されます。 これらが URL を介して実装されると、サーバーは同じページの複数のインスタンスを生成するため、クローラーが処理する必要がある重複ページの数が増えます。

ファセット ナビゲーションとは異なり、Google はこれらのパラメータを無関係なものとして認識し、元の URL を選択することができます。そのため、少なくともインデックス作成に関しては、無関係なバージョンがインデックスに登録されたり、正規バージョンよりもランク付けされたりすることはあまり一般的ではありません。

ただし、重複コンテンツの問題が発生し、Google がサイトをスパムと見なすことさえあります。 これは、サイトに割り当てられたクロール バジェットに影響を与えます (Google は低品質の Web サイトでリソースを浪費したくないため)。また、すべてのページの無関係なインスタンスに割り当てられたリソースを浪費します。

3. リンク切れとリダイレクト チェーン

前述のように、Google はすべてのリンクをたどり、セッションのクロール バジェットが使い果たされた場合にのみバウンスします。 クロール バジェットはサーバー リソースと時間に関するものです。 すべてのリダイレクトまたは壊れたリンクは時間の無駄です。

最も問題となるシナリオの 1 つは、リダイレクト チェーンが生成される場合です。 リダイレクト チェーンごとに、クローラーは最終的に宛先に到達するまで、リンクからリンクへとジャンプする必要があります。 以前にリダイレクトを経験したことがある場合、各ジャンプには数ミリ秒から数秒かかることがあります。これは、マシン時間では非常に長い時間です。

ここで、クローラーが 3 回、4 回、または 7 回ジャンプしなければならない場合に、コンテンツに到達するまでにかかる時間を想像してみてください。 また、Web サイトに複数のチェーンがある場合、これらのチェーンだけでクロール バジェットを簡単に使い果たしてしまう可能性があります。

無限のリダイレクト ループ

これらのチェーンの中で最も危険なのは、無限のリダイレクト ループです。

基本的に、各リダイレクト チェーンは最終的に最終的な宛先に到達する必要があります。 しかし、技術的なミスの場合、最終的な目的地がチェーンの先頭にリダイレクトし続ける場合はどうなるでしょうか?

これを視覚化するために、ページ A がページ B にリダイレクトされ、ページ B がページ C にリダイレクトされ、ページ C がページ A にリダイレクトされると想像できます。これにより、宛先ページが解決されない閉ループが作成されます。

クローラーがこのプロセスを経て、ループに陥っていることに気付くと、接続を切断し、おそらくサイトを離れます。 残りのページはクロールせずに残します。

4. 最適化されていないサイトマップ

サイトマップは、URL とそれらに関する情報 (hreflang のバリエーションなど) を Google や Bing などの検索エンジンに提供するテキスト ファイルです。 クロールに関しては、サイトマップは、検索エンジンがクロールを優先する URL を決定し、それらの関係をよりよく理解するのに役立ちます。

ここで重要な用語は優先順位付けです。

多くのウェブマスターは戦略を考慮せずにサイトマップを作成し、既存のすべての URL をファイルに追加し、Google が無関係なページ バリエーション、低品質のページ、またはインデックスに登録できないページをクロールする可能性があります。 この問題は、CMS 機能のみに依存して自動サイトマップを生成する場合にも発生する可能性があります。

代わりに、サイトマップは、インデックス化してランク付けしたいメイン ページに優先順位を付けるための手段であるべきです。 たとえば、変換のみのページを (ランキングの意図なしに) サイトマップに追加することは、それらのページをインデックスに登録しても何の違いもないため、リソースの浪費です。

200 HTTP ステータス コードを返し、ランキングに関連し、正規 URL であるページのみを追加してください。 検索エンジンはこれらのページに注目し、クロール バジェットをより賢く使用します。孤立したページや階層の深いページを発見するのにも役立ちます。

5. サイトのアーキテクチャ

Web サイトのサイト アーキテクチャは、分類法と内部リンクに基づくページの編成です。 Web サイトの開始点はホームページであり、そこから、Web サイトの残りの部分が階層構造でどのように編成されているかを想像できます。

Web サイトのアーキテクチャ - 階層と分類法

出典:ハブスポット

では、クロール バジェットとはどのように関係しているのでしょうか。 より生の意味では、サイトは、1 つのドメイン名の下に編成されたハイパーリンクによって接続されたさまざまなページの組み合わせにすぎません。 検索エンジンはホームページからクロールを開始し、見つけたすべてのリンクを下に移動します。

このプロセスを通じて、クローラーは Web サイトをマッピングして、その構造、ページ間の関係 (トピックによる分類など) を理解し、それらの重要性を認識します。より具体的には、ページがホームページに近いほど、より重要です。

これは、ホームページに近いページが優先的にクロールされることを意味し、ページが構造の奥深くになるほど、クローラーがページを見つけるのに時間がかかり、重要性が低いと見なされるため、クロールの頻度が低くなります。

また、内部リンクの依存関係があることも意味します。 ページ H がページ G からのみリンクされ、ページ G がクロールされない場合、ページ H もクロールされません。

適切に設計されたサイト アーキテクチャは、クロール プロセスを通じてすべてのページを検出できるようにし、ページの優先順位付けに役立ちます。

6.ページオーソリティ/被リンクプロフィール

簡単に言えば、バックリンクとは、外部ドメインからドメイン上のページを指すリンクです。 これらのインバウンドリンクは、ページに対する投票のように機能し、コンテンツが信頼できるものであることを Google に知らせ、その信頼性を高めます。

バックリンクはランキング要因としてより一般的に語られていますが、ウェブサイトのクロール バジェットを増やすのにも役立ちます。

クロール バジェットを計算する際の要因の 1 つは、URL を再クロールする頻度を決定するクロール需要です。このプロセスで考慮される主な変数の 1 つは人気です。 URLに。

ページが内部的にも外部的にも多くのリンク エクイティを獲得している場合は、より頻繁にクロールする価値があることを意味し、より頻繁にクロールする必要があるページが増えるにつれて、サイトのクロール バジェットが増加します。

バックリンクがサイトのクロールを助けるもう 1 つの方法は、他の Web サイトから URL を発見することです。 クローラーが外部ソースからあなたの URL を見つけた場合、あなたのリンクをたどり、次にそのページのすべてのリンクをたどります。より質の高いバックリンクを獲得するほど健全なクロール効果が生まれます。

注:十分な量のトラフィックを生成する信頼できるページからのバックリンクは、トラフィックのないページからの大量の低品質のバックリンクよりも価値があります。

7. サイトの速度とホスティングの設定

サイトの速度は、ユーザー エクスペリエンスに大きく影響し、SEO パフォーマンスに確実に影響を与える可能性があるため、技術的な SEO トピックで最も話題になっているトピックの 1 つです。 これは非常に重要な指標であり、Google はコア Web バイタル スコアでさまざまな側面に分類しています。

クロール プロセスにおいて、Google は HTTP リクエストをサーバーに送信し、必要なすべてのファイルをダウンロードしてから、次のリンクに移動する必要があることを理解すると、Web サイトからの応答時間が遅いことが問題になる理由が明確になります。

クローラーがページの応答を待機しなければならない 1 秒ごとに、待機するだけでクロール バジェットが消費される 1 秒です。

Web サイトがどのように構築されているか (コード) だけでなく、ホスティング サービスによって Web サイトが応答しなくなる可能性があることに注意することが重要です。

これにはいくつかのコンポーネントがありますが、開始するのに適した場所は帯域幅です。 ホスティング プランの帯域幅によって、サーバーが転送できる情報量が決まります。 これは、インターネットの速度のようなものだと考えてください。 インターネット接続が遅いストリーマーの場合、視聴者のインターネット速度がどれほど速くても、遅くて苦痛な伝送になります.

ただし、クロール バジェットを消費するだけではありません。 Google は、何としてでもサーバーに負担をかけることを避けます。 結局のところ、クロール プロセスはサイトへのトラフィックです。 ウェブサイトがタイムアウトしたり、読み込みに時間がかかりすぎたりすると、Google は、サーバーが現在の頻度を管理できないと判断して、クロール バジェットを引き下げます。

Prerender でクロール バジェットを改善するには?

シングルページ アプリケーション (SPA) を構築している場合は、既にこれらの問題の 2 つ以上に対処しています。 その上、JavaScript は検索エンジンにとってプロセス全体をさらに難しくし、間違いなくサイトの速度を低下させます。

SPA では、次のことを行うのが非常に一般的です。

  • JavaScript を介して動的にリンクを追加し、Google が次にクロールする URL を見つける前にページをレンダリングする必要があるようにします。
  • ハッシュ URL とファセット URL を生成し、場合によっては、Google がクロールする膨大な数の URL を作成します
  • 特に JavaScript の実行時間が原因で、コア Web バイタルのスコアが低い

時間のかかる回避策を繰り返さずにクロール バジェットを最適化するために、Prerender は URL をフェッチし、必要なすべてのリソースをキャッシュし、完全にレンダリングされたすべてのページのスナップショットを作成し、静的 HTML を検索エンジンに提供します。 クローラーは、複雑な処理を行ったり、ページが読み込まれるのを待ったりする必要はありません。 Prerender は HTML ページを提供するので、ボトルネックを発生させずに次のページに移動できます。

クロール バジェットの最適化がいかに簡単かを確認したり、ドキュメントでその仕組みを詳しく知りたい場合は、Prerender を無料でお試しください。