EC事業者・担当者が「今日・明日で改善できるSEO施策」をまとめた超実務寄りのEC SEO専門メディア

対象URLを一つに絞って原因をたどる手順を解説します。ECサイト向け解説記事のアイキャッチ

カテゴリページがインデックスされない原因|EC担当者向け確認手順

対象URLを一つに絞って原因をたどる手順を解説します。記事の結論と3つの要点をまとめた図
目次
  1. まず対象URLを一つに絞る
  2. Search ConsoleのURL検査を使う
  3. HTTPステータスを確認する
  4. robots.txtとnoindexを確認する
  5. canonicalの向き先を確認する
  6. 内部リンクから到達できるか
  7. JavaScript後に内容が表示される場合
  8. XMLサイトマップを確認する
  9. 内容と重複を確認する
  10. クロール頻度と公開からの時間を考える
  11. サーバー負荷とクロールを確認する
  12. 手動対策とセキュリティの確認
  13. 再公開・URL変更後の確認
  14. ECサイトでの具体例
  15. よくある間違い
  16. 確認項目
  17. 原因を直した後の再確認
  18. 複数ページで同じ症状が出る場合
  19. まとめ
  20. 次に読みたい関連記事

カテゴリページが検索結果に出ないとき、説明文の文字数を増やす前に、GoogleがURLを発見できるか、クロールできるか、インデックスを許可しているか、正規URLとして認識しているかを順に確認します。

クロールされたページが必ずインデックスされるわけではありません。技術的な問題がなくても、内容がほかの一覧とほぼ同じ、商品が少ない、検索需要がないなどの理由で選ばれない場合があります。原因を段階に分けることが大切です。

まず対象URLを一つに絞る

同じカテゴリに末尾スラッシュ、パラメータ、httpとhttps、別階層など複数URLがあると、確認対象を間違えます。メニュー、canonical、サイトマップで使っている正規URLを特定します。

ブラウザで開いた最終URL、HTTPステータス、title、h1、canonicalを記録します。転送が複数回続いていないか、ログインやCookieによって表示が変わらないかも確認します。

Search ConsoleのURL検査を使う

URL検査では、Googleに登録されているか、クロールが許可されているか、ユーザーが指定したcanonicalとGoogleが選んだcanonicalなどを確認できます。公開URLのテストでは、現在取得できるページの状態も見られます。

「検出-インデックス未登録」「クロール済み-インデックス未登録」などの表示だけで原因を断定しないでください。内部リンク、ページ内容、重複、サイト全体のURL増加を合わせて調べます。

HTTPステータスを確認する

インデックスさせたいカテゴリは、通常200を返す必要があります。404、410、5xx、ログインページへの転送、地域制限などがないか確認します。

画面上はカテゴリが表示されても、サーバーがエラーを返している場合があります。反対に商品ゼロのページが200を返し、soft 404と判断されることもあります。開発者ツールやHTTP確認ツールで応答を確認します。

robots.txtとnoindexを確認する

robots.txtでカテゴリディレクトリやパラメータが誤ってブロックされていないか確認します。robots metaやX-Robots-Tagにnoindexが付いていないかも見ます。

CMSの「検索エンジンに表示しない」設定、検証環境の設定が本番へ残るケースがあります。robots.txtでクロールを禁止していると、ページ内のnoindexやcanonicalをGoogleが確認できないため、設定の組み合わせも見ます。

canonicalの向き先を確認する

カテゴリ自身ではなく、トップページ、上位カテゴリ、1ページ目、別言語URLへcanonicalが向いていると、対象URLが正規ページとして選ばれにくくなります。テンプレートの変数ミスを確認します。

ユーザー指定canonicalが正しくても、Googleが別URLを選ぶ場合は、内容の重複、内部リンク、転送、サイトマップの不一致を調べます。タグだけを付け直すのではなく、サイト全体の手掛かりを統一します。

内部リンクから到達できるか

メニューや上位カテゴリから通常のa要素リンクで到達できるか確認します。サイト内検索やJavaScriptの操作からしか表示されないカテゴリは、発見されにくい場合があります。

モバイル表示で重要リンクが省略されていないかも確認します。パンくずリスト、関連カテゴリ、ガイド記事からのリンクを含め、孤立ページになっていないかを見ます。

JavaScript後に内容が表示される場合

初期HTMLが空で、JavaScript後にh1、説明文、商品リンクを取得するサイトでは、レンダリング結果を確認します。スクリプトエラー、API制限、遅い応答、Cookie同意の影響でGoogleが内容を取得できない場合があります。

URL検査のスクリーンショットやレンダリングHTMLを確認し、商品リンクがhref付きで存在するかを見ます。人のブラウザで表示できることだけでは十分ではありません。

XMLサイトマップを確認する

インデックスさせたい正規カテゴリURLをサイトマップへ含めます。noindex URL、転送URL、404 URL、パラメータURLを混ぜないようにします。

サイトマップは発見を助けますが、掲載すればインデックスが保証されるわけではありません。内部リンクとページ内容の改善も必要です。

内容と重複を確認する

技術的に取得できても、上位カテゴリ、タグ、フィルタと同じ商品集合で、titleと説明文も似ている場合、別ページとして選ばれないことがあります。商品数が少ない、長期間0件、説明が定型文だけといった状態も確認します。

文章を増やす前に、そのURLが独立して必要かを判断します。必要なら商品群の範囲、比較軸、固有の内部リンクを整えます。不要なら統合や正規化を検討します。

クロール頻度と公開からの時間を考える

新規カテゴリは、公開直後にインデックスされないことがあります。サイト内リンクとサイトマップを整え、Googleが発見してクロールするまで待ちます。具体的な日数を保証することはできません。

重要な新規ページはURL検査から登録をリクエストできますが、リクエストはインデックスを保証しません。多数のカテゴリを公開する場合はサイトマップを使い、公開後の状態をまとめて監視します。

サーバー負荷とクロールを確認する

5xxエラーや応答遅延が多いと、Googlebotがアクセスを抑える場合があります。カテゴリのAPIが重い、フィルタURLが大量に生成される、画像処理で負荷が上がるといった原因を調べます。

Search Consoleのクロール統計とサーバーログを使い、エラー、応答時間、Googlebotのアクセス先を確認します。不要URLの増加が重要ページの発見を遅らせていないかを見ます。

手動対策とセキュリティの確認

サイト全体や一部に手動による対策、セキュリティ上の問題が報告されていないかSearch Consoleで確認します。カテゴリ一ページだけの問題に見えても、サイト全体の状態が関係する場合があります。

ハッキングで不正なcanonicalやnoindexが挿入される、CDN設定でbotだけ別応答になるケースもあります。最近のデプロイやセキュリティ変更を開発担当へ確認します。

再公開・URL変更後の確認

以前削除したURLを再利用する場合、過去の転送、noindex、外部キャッシュが残っていないか確認します。新URLへ変更した場合は旧URLからの転送と内部リンク更新が必要です。

Search Consoleの古いデータと新URLのデータを分け、移行日を記録します。同じカテゴリ名でもURLが変われば、ページ単位の履歴はそのまま連続しません。

ECサイトでの具体例

「北欧デザインの照明」カテゴリがインデックスされないとします。URL検査では、Googleが「照明」上位カテゴリをcanonicalとして選んでいました。調べると、両ページの商品集合がほぼ同じで、titleの違いも小さく、内部リンクは特集バナー一つだけでした。

北欧カテゴリを維持するなら、掲載基準を定義し、対象商品を整理し、デザインの特徴や選び方を説明し、上位カテゴリから通常リンクで案内します。独立した品ぞろえを維持できないなら、上位カテゴリへ統合し、フィルタで探せるようにします。

「インデックス登録をリクエスト」だけを繰り返すのではなく、URLの役割を改善する対応です。

よくある間違い

一つ目は、site:検索だけでインデックスを判断することです。確認にはSearch ConsoleのURL検査を使います。

二つ目は、説明文を追加すれば必ずインデックスされると考えることです。発見、クロール、noindex、canonicalの問題を先に確認します。

三つ目は、修正直後に何度も登録リクエストを送ることです。再クロールと処理には時間がかかり、登録も保証されません。変更内容と確認日を記録します。

確認項目

  • 正規URLと最終URLを特定したか
  • HTTP 200を返しているか
  • robots.txtでブロックされていないか
  • robots metaやX-Robots-Tagにnoindexがないか
  • canonicalが自身の正規URLを指しているか
  • モバイルでも内部リンクから到達できるか
  • レンダリング後に商品リンクと本文が存在するか
  • ほかの一覧と実質的に重複していないか

原因を直した後の再確認

修正後は、対象URLをブラウザで開くだけでなく、HTTP応答、HTML上のrobots指定、canonical、内部リンク、レンダリング後の商品リンクをもう一度確認します。設定ファイルを直してもキャッシュや配信環境に古い内容が残ることがあるため、本番URLで検証します。

Search Consoleからインデックス登録をリクエストできる場合もありますが、これは登録を保証するものではありません。XMLサイトマップの更新と主要ページからの内部リンクを整え、検索対象として一貫した手掛かりを用意します。同じURLへ短期間に申請を繰り返すより、原因が解消したかを確かめることが先です。

数日から一定期間を置いてURL検査やページレポートを見直し、Googleが選択した正規URL、クロール日時、インデックス状態を記録します。サイトの規模や更新頻度によって確認時期は異なるため、全URLが同じ速さで処理されるとは考えません。

複数ページで同じ症状が出る場合

一件の個別ミスに見えても、同じテンプレート、カテゴリ階層、公開日、URLパターンのページを抽出します。共通点があれば、ページごとに申請するのではなくテンプレートや生成ルールを直します。逆に一部だけなら、商品数、内部リンク、公開フラグ、例外設定など個別データを比較します。

調査記録には、確認した事実と推測を分けて書きます。「クロール済みだが未登録」と「robots.txtでブロック」は対処が異なります。状況を一語でまとめず、Search Consoleの表示、実際の応答、変更履歴を並べることで、開発担当にも原因を伝えやすくなります。

まとめ

カテゴリページがインデックスされないときは、URL、HTTP応答、クロール制御、canonical、内部リンク、レンダリング、内容の順に確認します。技術問題と、ページの独自性や必要性の問題を分けることが重要です。

URL検査の結果と実際のHTMLを記録し、一つずつ原因を除いてください。登録リクエストを繰り返すより、検索対象にする価値とサイト内の手掛かりを整えるほうが、再発防止につながります。

次に読みたい関連記事