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

一律に付けず、除外してよいページの判断を示します。ECサイト向け解説記事のアイキャッチ

noindexの使い方|ECサイトで検索結果から除外するページの判断

一律に付けず、除外してよいページの判断を示します。記事の結論と3つの要点をまとめた図
目次
  1. noindexの基本
  2. robots.txtとの違い
  3. canonicalとの違い
  4. noindexを検討しやすいページ
  5. 在庫切れ商品に一律設定しない
  6. 0件カテゴリや検索結果の扱い
  7. テンプレート設定の事故を防ぐ
  8. リンクをどう扱うか
  9. 設定後の確認
  10. よくある間違い
  11. 判断のチェック項目
  12. noindex対象を管理表で運用する
  13. 大量ページへ設定する前の検証
  14. 除外を解除するときの注意
  15. 検索結果の一時削除との違い
  16. ECサイトでの判断例
  17. まとめ
  18. 次に読みたい関連記事

noindexは、検索エンジンに対して、そのページを検索結果へ登録しないよう伝えるための指示です。ECサイトでは、会員向け画面、価値のない検索結果、重複性の高い一時ページなどに使うことがあります。

便利な一方、主要商品やカテゴリへ誤って付くと検索流入を失う可能性があります。ページ数を減らすために一括設定するのではなく、ページの役割、公開期間、代替URLの有無を確認して使います。

noindexの基本

HTMLページではrobots metaタグ、PDFなどHTML以外のファイルではX-Robots-TagのHTTPヘッダーを使えます。クローラーがページを取得し、指示を読み取ることで除外が進みます。

設定後すぐに結果から消えるとは限りません。再クロールの時期はURLやサイトの状況によって異なります。Search Consoleで対象URLの状態を確認し、短期間に設定を何度も切り替えないようにします。

robots.txtとの違い

robots.txtはクロールを制御し、noindexは検索結果への登録を制御します。noindexを読ませたいURLをrobots.txtでブロックすると、クローラーが指示を確認できない可能性があります。

検索結果から除外する目的なら、ページへアクセスできる状態でnoindexを返すことが基本です。機密情報はnoindexに頼らず、認証やアクセス制御で保護します。

canonicalとの違い

canonicalは、重複または非常に似た複数URLの中で、代表として扱ってほしいURLを示す仕組みです。noindexは対象ページそのものを検索結果から除外します。

同じ内容のURLを一つへまとめたい場面では、転送やcanonicalが意図に合う場合があります。正規化したいURLへnoindexを付けると、そのページが検索対象にならず、目的と矛盾します。

noindexを検討しやすいページ

ログイン後の注文履歴、カート、決済途中、内容のないサイト内検索結果、短期間だけ使う確認画面などは検索結果へ出す必要がありません。利用者が公開検索から訪れる価値があるかを基準にします。

絞り込みページやタグページは一律ではありません。独立した需要と安定した商品集合があり、説明と内部リンクを整えられるなら検索対象にできます。任意の組み合わせで自動生成されるページは、対象外を検討します。

在庫切れ商品に一律設定しない

一時的な在庫切れなら、商品情報、再入荷案内、代替商品が役立つ場合があります。商品が買えないという理由だけで即座にnoindexにすると、再入荷時に再登録を待つことになります。

恒久的な販売終了では、後継商品や近い代替先があるか、外部リンクや検索流入があるかを確認します。適切な統合先があるなら転送、代替がなくページを終了するなら404や410など、状態に合う方法を選びます。

0件カテゴリや検索結果の扱い

商品が一時的に0件でも再入荷予定があり、カテゴリとして継続するなら、案内を残して維持する選択があります。任意の検索条件で生成された0件URLは、検索対象にする価値が低く、404やnoindexを含めて設計します。

重要なのは、見た目が同じ0件でも原因を分けることです。商品登録の遅れ、季節終了、カテゴリ廃止、存在しないパラメータでは対応が異なります。

テンプレート設定の事故を防ぐ

ECサイトではnoindexを商品単位ではなくテンプレートや公開フラグから自動出力することがあります。在庫数、公開状態、カテゴリ所属など、どの条件で付与・解除されるかを明文化します。

一度付与したnoindexが、再入荷や再公開後も残る事故は珍しくありません。状態変更時のテストに、画面表示だけでなくrobots metaとレスポンスヘッダーの確認を含めます。

リンクをどう扱うか

noindexページから重要な商品へリンクできる場合でも、そのページを主要な発見経路にはしません。検索対象のカテゴリや特集から通常リンクを用意します。

noindexとnofollowを機械的に組み合わせる必要はありません。リンクをたどらせたくない理由があるかを別に判断し、ページ除外とリンク評価を一つの設定で済ませないようにします。

設定後の確認

対象URLへ実際にアクセスし、HTMLのrobots metaとHTTPヘッダーを確認します。Googlebotへ異なる内容を返す仕組みがある場合は、URL検査の取得結果も見ます。

Search Consoleでは「noindexにより除外」のURL例を確認し、意図したページだけかを点検します。主要ページが混ざっていたら、個別修正だけでなく付与条件を調べます。

よくある間違い

  • 検索順位が低いページへ一律にnoindexを付ける
  • noindexページをrobots.txtでもブロックする
  • canonicalと同じ目的で併用する
  • 在庫切れ商品を即座に除外する
  • 再公開時の解除テストを用意しない

判断のチェック項目

  • 公開検索から訪れる価値があるか
  • 一時的な状態か恒久的な状態か
  • 統合できる適切な代替URLがあるか
  • クロールを許可してnoindexを読ませられるか
  • 付与と解除の条件が自動化されているか
  • Search Consoleで意図した除外を確認したか

noindex対象を管理表で運用する

ページ種別、URL例、除外理由、付与条件、解除条件、robots.txtの扱い、サイトマップ掲載、担当者を一覧にします。サイト内検索のような常時対象と、キャンペーン準備ページのような一時対象を分けます。

一時対象には必ず確認日を設定します。公開日を迎えた特集がnoindexのまま、販売再開した商品が除外されたままという事故は、解除条件と担当が曖昧なときに起こります。

大量ページへ設定する前の検証

まず数ページでrobots metaまたはX-Robots-Tagが正しく出るか確認します。通常ページ、ページネーション、印刷用ページ、API応答など、同じテンプレートを利用する別URLへ影響しないかを見ます。

CDNやキャッシュがある場合、管理画面で設定を変えても古いHTMLが残ることがあります。ブラウザ表示だけでなく、実際のHTTP応答とGooglebot向け取得を確認します。

除外を解除するときの注意

noindexタグを削除しても、robots.txtでクロールが禁止されたままでは再評価されません。内部リンク、サイトマップ、canonicalも検索対象のURLへ戻し、ページ内容が公開状態になっているかを確認します。

重要な少数URLではURL検査を使えますが、登録は保証されません。大量ページの再公開では、公開フローとサイトマップを正し、Googleが再クロールできる状態を作ります。

検索結果の一時削除との違い

Search Consoleの削除ツールは、検索結果から一時的に非表示にするための手段です。恒久的に除外するには、noindex、認証、404などページ状態に合う方法を実装します。

誤って公開した個人情報や機密情報は、検索結果だけでなく元ページから削除し、アクセス制御を行います。noindexは閲覧を防ぐセキュリティ機能ではありません。

ECサイトでの判断例

「赤いバッグ」の絞り込みページに安定した商品数と検索需要があり、カテゴリから継続してリンクできるなら、固定の着地ページとして検索対象にする余地があります。任意の価格帯と並び順を組み合わせただけのURLは、操作用としてnoindexを検討します。

会員限定セールは、誰でも見られる案内ページと、ログイン後の価格ページを分けます。公開案内は検索対象にできても、個別会員向けの画面は認証で守り、必要に応じてnoindexを返します。

予約商品は発売前から情報価値があれば200で公開し、noindexにする必要はありません。一方、社内確認中の下書きは公開URLを発行せず、認証されたプレビュー環境で確認するほうが安全です。noindexを公開管理の代わりに使わないことが大切です。

まとめ

noindexは、検索結果へ登録しないページを示すための指示です。クロール制御のrobots.txt、重複整理のcanonical、URL移動のリダイレクトとは役割が異なります。

ECサイトでは、ページ種別と状態ごとに判断し、主要商品へ誤って付かない仕組みを作ってください。設定後だけでなく、再入荷や再公開で正しく解除されるところまで確認することが重要です。

次に読みたい関連記事