インデックス肥大化と薄いコンテンツ：文字数ではなく価値を監査する

店舗の商品は8,000点なのに、Search Consoleには120,000を超える既知のURLがあります。大半は色フィルター、並べ替え、タグアーカイブ、サイト内検索結果、パラメータの変種です。SEOチームはインデックス肥大化と呼び、300語未満の全ページへnoindexを提案します。

これは危険な2つの近道です。各ページに固有のニーズと価値があれば、URL数が多くても肥大化とは限りません。文字数が少なくても薄い内容とは限らず、為替レート、バス時刻表、商品仕様のページは、長い論文がなくても十分役立ちます。解くべき問題は、登録可能なURLと、実際にクエリへ応える価値のあるURLとの比率です。

インデックス肥大化とは？

インデックス肥大化とは、戦略的ページ群に比べて、価値の低いURLを検索エンジンが過剰に発見、クロール、保持しなければならない状態です。こうしたURLには、次のような特徴があります。

• 内容が重複、またはほぼ重複しています。
• 独立した検索需要がありません。
• 順序、追跡パラメータ、表示だけが変わります。
• 実際の項目、データ、回答がありません。
• 終了しているのに200を返します。
• フィルターやカレンダーが無限に生成します。

肥大化と判断する公式な割合はありません。100万URLの基盤でも、100万の有用な商品、場所、資料を表すなら健全です。500投稿のブログでも、CMSが20,000の薄いタグ、著者、日付、空のページ送りを作れば肥大化します。

薄いコンテンツは短いコンテンツと同義ではありません

「薄い」は文字数の少なさではなく、価値の薄さと考えるべきです。次を比べてください。

• 180語でも、独自画像、最新価格、在庫、寸法、規約、レビュー、配送詳細がある商品ページ。
• 1,500語でも、他の情報源の一般的な定義を繰り返すばかりで、読者の判断を助けない記事。

前者の方が役割をよく果たすかもしれません。長さは補助的なデータにすぎません。評価では、次を問いかけてください。

1. ページは固有のニーズを解決していますか？
2. データや経験に独自性がありますか？
3. 読後にユーザーは行動を完了できますか？
4. 同じテンプレートのURLと十分に異なりますか？
5. 情報は正確で、維持されていますか？

1つの「いいえ」だけでは削除の理由になりません。複数の「いいえ」が重なると、対処が必要なシグナルになります。

URL肥大化のよくある発生源

ファセットナビゲーション

ECでは色、サイズ、ブランド、価格、素材、評価で絞り込めます。組み合わせごとに新URLを生成できます。10個のフィルターは10ページを生むのではなく、数千の組み合わせを生み得ます。多くは数商品の違いしかないか、結果がありません。

「メンズのランニングシューズ」「$1,000未満のノートPC」のように、実際の検索需要を満たすフィルターもあります。選んだ組み合わせには、整ったURL、独自情報、自己参照canonical、安定したリンクを用意します。並べ替えや極端に狭い組み合わせは、通常、登録不要です。

自由なタグと分類体系

編集者がそれぞれタグを作ると、「technical SEO」「SEO technical」「技術監査」「サイト監査」が、ほぼ同じ4つのアーカイブになる場合があります。十分な数があり、明確に定義した集合の閲覧を助ける場合にだけ、タグを設けるべきです。

サイト内検索結果

ユーザーが入力する各クエリからURLを作れます。通常、これらはランディングページとして設計されておらず、品質が変動し、ほぼ無限です。サイト内検索に役立てるべきで、既定でインデックスに加えるべきではありません。

追跡とセッションのパラメータ

utm_source、アフィリエイトID、セッションID、表示パラメータは、同じ本文に多数のアドレスを作ります。Canonical、整った内部リンク、システム設定で、代表URLを統一する必要があります。

日付・著者アーカイブとページ送り

著者が少ないブログで、同じ記事群を日、月、年、著者、カテゴリ、タグの全アーカイブへ並べる必要はありません。分類体系は、CMSの全機能を有効にするためでなく、実際の閲覧方法に合わせるべきです。

期限切れページと販売終了商品

終了したイベント、募集終了の求人、販売終了商品、キャンペーンのランディングページは忘れられがちです。「終了しました」の1文だけで200を返し続けると、大規模な薄いページやソフト404になる可能性があります。

site:演算子を正確な登録数として使わない

site:example.com検索は、予想外のURLを抽出するのに役立ちますが、件数は推定で変動します。URL一覧の作成には、次を組み合わせてください。

• Search Consoleのページのインデックス登録レポート。
• サイトマップと子サイトマップ別のURL数。
• 内部リンクからのクロール。
• クローラーのリクエストログ。
• CMSやデータベースのURL一覧。
• 表示回数、クリック、セッションがあるランディングページ。

目標は、唯一の絶対数を見つけることではありません。「生成された数」と「価値がある数」の差が大きいテンプレート群を把握することです。

テンプレート別に登録可否の表を作る

URLを個別に見るのではなく、パターンでまとめてください。

この例示の数値から、優先順位が分かります。70,000の深いフィルターを修正する方が、タグページを10件編集するより構造を大きく変えます。

URL群ごとの5つの判断

1. 維持して改善する

固有の需要があり、トラフィックやコンバージョンを生む一方、情報が不足する場合に使います。改善は文字数を増やすことと同義ではありません。カテゴリページでは、次が必要かもしれません。

• 適切で在庫のある商品群。
• 明確なタイトル、説明文、見出し。
• ニーズに沿った短い導入文。
• 不要URLを生まない有用なフィルター。
• 実際の顧客からのFAQ。
• 関連ハブからの内部リンク。

2. 統合してリダイレクトする

複数URLが同じニーズを満たし、別々に存在する必要がない場合に使います。独自データを最も強いページへ移し、内部リンクを修正してから直接転送します。無関係なURLを一括でホームページへ転送しないでください。

3. 代表ページへcanonicalを向ける

ユーザー向けに変種を残す必要があっても、内容が重複・類似する場合に適しています。例えば、商品順だけを変えるページです。Canonicalはシグナルであって命令ではありません。矛盾するメッセージを避けるため、サイトマップと内部リンクには代表URLを使うべきです。

サイト全体のフィルターへルールを適用する前に、Canonical URLガイドを読んでください。

4. アクセス可能なままnoindexにする

サイト内検索結果、個人向けフィルター、公開範囲が限定されたアカウントページ、十分な違いのないアーカイブなど、機能はあるものの検索結果には向かないページに使います。

<meta name="robots" content="noindex, follow">

クローラーはページにアクセスできて初めてnoindexを読めます。同時にrobots.txtでURLを遮断すると、Googleが指示を確認できず、意図どおり除外されない可能性があります。

5. 404または410で削除する

目的がなくなり、同等の代替もない場合に使います。実態に合うステータスを返し、サイトマップから除き、内部リンクを直します。有用なカスタムエラーページでも、404を維持する必要があります。

noindexとrobots.txtを処理する順序

多くのプロジェクトが、ここで自ら整理を妨げます。技術者がnoindexを追加し、直ちにディレクトリ全体のクロールを禁止します。クローラーは指示を読みに入れず、既知のURLが十分なスニペットなしで残る場合があります。

慎重な手順は次のとおりです。

1. 除外したいURLのクロールを許可します。
2. HTMLまたはX-Robots-Tagで、一貫してnoindexを返します。
3. サイトマップから除外し、内部リンクを減らします。
4. 大半がインデックスから消えるまでSearch Consoleで追跡します。
5. Googleによる指示の継続確認が不要で、URLパターンが高負荷を生む場合にだけ、その後クロール制限を検討します。

Robots.txtはクロールを管理するもので、直接の削除指示ではありません。Robots.txt Checkerでルールを確認し、Sitemap CheckerでXMLに登録対象のURLだけが含まれているか確認してください。

ファセットナビゲーションを全面閉鎖せず、需要に応じて扱う

良いフィルター計画では、組み合わせを3層に分けます。

管理するランディングページ

需要があり、十分な商品と事業価値がある組み合わせに、静的URLや整ったルールを用意します。タイトル、H1、自己参照canonical、適切な文章、カテゴリからの内部リンクを備えます。

体験のためのフィルター

ユーザーは引き続き絞り込めますが、URLをサイトマップや大量のクロール可能リンクには加えません。基盤に応じ、noindex、canonical、無限にリンクを生成しない仕組みを使えます。判断は実際のクローラーでテストする必要があります。

無意味な組み合わせや結果なし

空の集合へ向かう数百万の経路を作らせるべきではありません。不正な選択肢を無効にし、存在しないURLには正しいステータスを返し、カレンダーやフィルターによる無限のURL空間を防ぎます。

Canonicalだけにすべてを背負わせないでください。元カテゴリへcanonicalを向けても、クローラーはそのタグを見るために数千の変種を読み込む必要があるかもしれません。

ページ種別ごとに薄いコンテンツを改善する

商品ページ

正確な仕様、実物写真、使用動画、在庫、配送、返品、互換性、確認済みレビュー、顧客の質問など、購入を助けるデータを優先します。800語の説明でも、寸法や価格の不足は補えません。

場所のページ

住所、営業時間、サービス地域、道順、駐車情報、現地写真、独自のサービスは、テンプレートで都市名だけを変えた紹介文より価値があります。

カテゴリページ

良い項目群、絞り込み方法、適切な順序、選択を助ける説明が必要です。長文で商品を下へ押し下げると、体験が悪くなる可能性があります。

ガイド記事

経験、データ、スクリーンショット、失敗例、判断、限界を加えます。同じ概念を3つの見出しで定義して、長さを増やさないでください。

プログラマティックなページ

各URLには、十分に異なるデータ、品質管理ルール、ユーザーがそのページを探す理由が必要です。同じ段落で業界名や都市名を置き換えるだけなら、大規模化は価値ではなく薄さを複製します。

インデックス肥大化への対処を段階的に移行する

ロールバックの用意なく、サイトの80%を一度にnoindexにするべきではありません。テンプレート別に分けてください。

1. トラフィックのない並べ替えパラメータなど、低リスクの群を選びます。
2. 変更前のURL数、クロールリクエスト、表示回数、サーバー負荷を記録します。
3. 指示、サイトマップ、内部リンクを同時に変更します。
4. 4〜8週間監視します。
5. 価値のあるURLがルールに巻き込まれていないか確認します。
6. 安定してから次の群へ広げます。

登録ページ群の品質で成功を測る

目標は、登録ページ数を最小にすることではありません。次を追跡してください。

• 戦略的URLの登録率。
• 登録可能な1,000URL当たりのクリックと表示回数。
• 想定した理由で除外されたURL数。
• 低価値テンプレートに費やすクロールリクエスト。
• 公開から初回クロールまでの時間。
• ソフト404と重複の割合。
• 維持した群の自然検索による売上やリード。

URLが70%減っても、新商品ページのクロールが遅くなったなら、ルール、内部リンク、サイトマップを見直す必要があります。登録数が減ってもクリックが維持・増加し、クロールが集中し、重複エラーが減るなら、方向は適切です。

SEO Checkerでrobotsの指示、canonical、ステータスを抽出確認してください。無料SEO監査は、広範囲のルールを公開する前に、テンプレートの反復する問題を見つけるのに役立ちます。

URL群を閉じる前のチェックリスト

• この群に固有のクエリやコンバージョンがありますか？
• より良い代表URLはありますか？
• リダイレクトで守るべき被リンクはありますか？
• 内部リンクとサイトマップを同時に直す準備はできていますか？
• クローラーはnoindexを読めますか？
• ロケール、ページ送り、主要商品に影響しませんか？
• 基準データと再評価日はありますか？
• 良いURLが除外されたら、誰がロールバックしますか？

答えられないうちは、広範囲のDisallowから始めないでください。

まとめ

インデックス肥大化は、URLと価値の配分の問題であり、ページ数を減らす競争ではありません。薄いコンテンツも文字数不足ではなく、有用性の不足です。テンプレート別に監査し、各群の固有のニーズを定めてから、維持、改善、統合、canonical、noindex、削除を選んでください。

導入時は、ステータス、robotsの指示、サイトマップ、内部リンクを同じ意図にそろえます。基準データを持って段階的に進める方が、サイト全体を一括noindexにするより時間はかかりますが、管理しやすく、収益を生むページを失いにくくなります。

参考資料：Google Search Centralのrobots metaとX-Robots-Tagの解説、ファセットナビゲーション管理ガイド、有用なコンテンツ。