絞り込み機能が無数のURLを生む問題を抑える方法

5つの絞り込み条件を持つカテゴリーページは、気付かないうちにクロール可能な数千のアドレスに膨れ上がることがあります。色、価格、場所、日付、並べ替えの各オプションは、単独では無害に見えます。しかし組み合わさると、ほとんど違いのないページにクロールが費やされ、新しく有用なページが発見されるのを待たされることになります。解決策は、よく見ずにすべてのパラメーターを遮断することではありません。

Googleのファセットナビゲーションに関するガイダンスは、事実上無限のURL空間が生まれ、新しいページを発見するクロールが遅くなるリスクを説明しています。これは商品カタログ、求人サイト、イベント一覧、大規模な記事アーカイブに当てはまります。最初の判断は編集上のものです。どの絞り込みの組み合わせが、実際のランディングページとして維持するに値するほど検索ニーズによく応えているでしょうか。

robotsのルールを書く前にURL空間を把握する

クロールログ、内部ナビゲーション、利用できる場合はSearch ConsoleからURLの例を集めます。URLを目的ごとに分類してください。正規のカテゴリーページ、有用な絞り込みのランディングページ、一時的な並べ替え、トラッキング用パラメーター、サイト内検索の結果、意味をなさない組み合わせです。通常の閲覧で、どれだけの異なるURLが生成され得るかを見積もります。サンプルがあれば暴走しているパターンを特定するには十分ですが、正確な総数を断言することはできません。

?color=blue&size=mと?size=m&color=blueのように、パラメーターの順序だけが異なるURLで同じコンテンツが表示されていないかを探します。セッションIDや、日付を際限なく生成できるカレンダーのルートも調べてください。すべての組み合わせが通常のリンクから発見できる状態になっていないかを確認します。リンクの生成方法を修正するほうが、クローラー側だけに対処するよりも多くの無駄を防げることがよくあります。

インデックス対象とする範囲を意図的に選ぶ

有用な常設の絞り込みランディングページには、安定した商品や結果、独自の内容、内容を表すタイトル、直接たどれるナビゲーションの経路が必要です。独立した価値がほとんどない組み合わせは、訪問者が使えるように残しつつ、インデックス対象のページとして自動的に打ち出さないようにします。無制限に自動生成されるURLではなく、価値のある絞り込み条件の許可リストを作成してください。

クロールさせたくないURLについて、Googleはrobots.txtによる制限を選択肢の1つとして説明しています。厳密なルールは、それが何に一致するかを確認してから適用してください。robots.txtでURLを遮断すると、クローラーはそのページのcanonicalやnoindexの指示も読めなくなるため、これらの方法を互いに置き換えられるものとして扱わないでください。整理のためにnoindexを認識させる必要がある場合、そのシグナルが処理されるまでの間、ページをクロール可能な状態にしておく必要があります。

クロール可能なルートを技術的に一貫させる

インデックスされる可能性のある絞り込みページでは、パラメーターの区切り文字を標準的なものにしてください。キーと値の間には=、パラメーター同士の間には&を使います。GoogleのURL構造に関するガイダンスも、不要なパラメーターを避けるよう推奨しています。絞り込みの値をパスに含める場合は、決まった順序を使い、同じ絞り込みの重複を防いでください。

存在しない、または無効な絞り込みの組み合わせには、常にステータス200で空のカテゴリーページを返すソフトエラーではなく、必要に応じて本物の404ステータスを返すべきです。最終ページより後のページ送りや、あり得ない組み合わせを確認してください。不正なURLをすべてホームページにリダイレクトしても、正しいステータスコードの代わりにはなりません。

具体的な練習として、6つの都市、8つのイベントカテゴリー、5つの日付の範囲、3つの並べ替えを持つディレクトリを想像してください。ページ送りや自由入力の検索を考慮する前でも、すべての軸が独立してアドレスを持つ場合、720通りの組み合わせが生まれます。これは仮定に基づく計算例であり、実際に測定したクロール数ではありません。多くの組み合わせは空であったり同じ意味であったりするため、URLを自動生成することは特に無駄になります。

小さなテスト表を作成してください。有用な絞り込みのランディングページ1つ、パラメーターの順序が異なる重複1つ、結果が空のもの1つ、無効な値1つ、結果の最終ページより後のページ1つです。それぞれについて、想定するステータスコード、正規URLの指定、robotsでの扱い、内部リンクの挙動を記録します。この表によって、矛盾が何百万ものURLに広がる前に明らかになります。たとえば、優先する正規URLを宣言していてもクロールが遮断されているページは、そのヒントをGoogleに伝えられない可能性があります。

サイトでクエリ文字列を使っているというだけの理由で、一律にDisallow: /*?*を適用してはいけません。パラメーターは、必要不可欠なページ送りや本当に有用なコンテンツを表している場合があります。同様に、すべての絞り込みURLをXMLサイトマップに残しておくと、それらを遮断するのとは逆のシグナルを送ることになります。サイトマップ、正規URLの宣言、ステータスコード、リンクを、実際に維持するつもりのインデックス対象の範囲にそろえてください。公開後は、通常の訪問者と同じように自分のサイトをクロールし、ナビゲーションが引き続き機能することを確認します。

成功を宣言するのではなく効果を監視する

ナビゲーション用のウィジェットや自動生成されるアーカイブページが追加する内部リンクについて、専用の確認項目を設けてください。robotsのルールを厳しくした後でも、1つのテンプレートが不要な絞り込みリンクを何百も再び生み出すことがあります。テーマやプラットフォームのアップグレード後にそれらのテンプレートを監視する責任者を1人決めておきます。

変更を反映した後、正規URLと絞り込みURLへのクローラーのリクエストについて、ログのサンプルを比較します。必要なページに引き続きアクセスできること、不要な組み合わせがクロール活動の大半を占めなくなったことを確認してください。処理の遅れを考慮しながら、Search Consoleのインデックス登録レポートを継続的に確認します。収益やコンバージョンが価値のある絞り込みページに結び付いている場合は、そのクロール経路を取り除く前に、そのページを個別に測定してください。

robotsの編集で帯域幅を節約できても、根本的なコンテンツの改善には何もつながらない場合があります。優れた構造は、有用なページを発見しやすくし、価値の低い組み合わせを生成しにくくします。トラフィック減少のガイドは実際のパフォーマンスの変化を調べるのに役立ち、Discover画像のガイドは別の露出経路を扱っています。