ANSWER FIRST

結論

公開管理では、robots.txtをクロール要求の制御、noindexを検索結果からの除外、XMLサイトマップを重要な正規URLの発見支援に使い分けます。機密情報はこれらに頼らず認証で保護します。検索やAIに届けたいページは取得を許可し、本文・canonical・内部リンク・サイトマップの指定を一致させることが基本です。

01

四つの手段を目的で使い分ける

最初に区別したいのは、クロール、インデックス、発見支援、アクセス制限です。robots.txtは指定したクローラーへURLの取得可否を伝える仕組みであり、検索結果からの削除や情報保護を保証するものではありません。RFC 9309でも、この規則はアクセス認可ではないと明記されています。URLが他ページから参照されていれば、本文を取得されていなくてもURLだけが認識される可能性があります。

検索結果へ表示したくないHTMLにはrobots metaのnoindexを、PDFなどHTML以外のファイルには必要に応じてX-Robots-Tagを使います。ただし、クローラーがnoindexを確認できるよう、そのURLの取得をrobots.txtで同時に止めないことが重要です。XMLサイトマップは、検索へ届けたい正規URLと更新情報を伝える発見支援です。送信しても取得や掲載が保証されるものではありません。社内資料、確認用URL、個人情報を含む画面など、第三者に見せない情報はログインや適切なアクセス制御で保護します。

  • 取得頻度や不要な経路を制御する：robots.txt
  • 検索結果へ表示させない：noindexまたはX-Robots-Tag
  • 重要な正規URLの発見を助ける：XMLサイトマップ
  • 閲覧そのものを制限する：認証・権限管理
  • 緊急削除は対象サービスの公式削除手順も確認
02

URLごとの公開方針を先に決める

設定ファイルから考え始めると、部署ごとに異なる意図が混ざります。まずURLを「検索・AIから見つけてほしい公開情報」「公開はするが検索結果へ出さない情報」「指定クローラーの取得を抑えたい経路」「関係者だけが閲覧する情報」に分類します。企業サイトならサービス、会社情報、実績、FAQは原則として公開対象です。一方、確認中のプレビュー、管理画面、検索結果ページ、重複する絞り込みURLなどは、目的とシステム構成を確認して個別に扱います。

自治体・団体サイトでは、終了した制度や募集のページを単純に隠すと、過去情報を確認したい利用者の手掛かりも失われます。現行情報への案内、終了日、後継ページの有無、保存方針を決めたうえで、公開継続、終了案内、転送、noindex、削除のいずれが適切かを判断します。設定の担当者だけで決めず、情報所管、広報、システム管理の確認者を台帳に残します。

  • URLとページの目的
  • 想定する利用者と公開範囲
  • 検索・AIから発見される必要性
  • canonicalとして扱うURL
  • 掲載開始日・終了日・後継情報
  • 情報所管・承認者・実装担当
公開・クロール制御・検索除外・認証保護を目的別に選びサイトマップへ接続する判断フロー
VISUAL GUIDE見せる・検索に出さない・アクセスさせないを分け、目的に合う制御方法を選びます。
03

本文・canonical・内部リンク・サイトマップを一致させる

検索へ届けたいページは、200の正常な応答、自己参照または適切なcanonical、たどれる内部リンク、XMLサイトマップへの収録を同じ方針に揃えます。サイトマップには、検索結果へ出したい正規URLを選びます。noindexのURL、転送元、エラーページ、重複URLを機械的に含めると、サイト側の意図が矛盾します。更新日は、デザイン部品の再生成ではなく、主要な本文や判断情報が実際に変わった時に更新します。

検索から外すページはnoindexを返し、サイトマップと主要な案内リンクから外すか、利用者に必要な導線だけを残します。既に認識されているURLへnoindexを追加する場合は、クローラーが変更を確認できる状態を保ちます。robots.txtで先に遮断するとnoindexを読めないため、意図した除外を確認できません。公開前はHTMLだけでなく、HTTPヘッダー、canonical、レスポンスコード、robots.txt、サイトマップを実URLで確認します。

  • 公開対象：200・取得許可・canonical・内部リンク・サイトマップを整合
  • 検索除外：noindexを取得可能な状態で返す
  • 非公開：認証で保護し公開URLとして扱わない
  • 転送：移動先と目的が対応する場合に設定
  • サイトマップ：正規URLだけを自動生成
  • 公開後：検査画面と実際のレスポンスを照合
04

AI検索のクローラーは目的別に確認する

AI関連の取得方針を「AIはすべて許可」「AIはすべて拒否」の一行で決めるのは適切ではありません。検索表示、回答への参照、学習など、サービスとユーザーエージェントで目的が異なるためです。採用するサービスの公式情報で、クローラー名、用途、robots.txtの解釈、変更時の影響を確認し、承認した方針を記録します。robots.txtは協調的なクローラーへの要求であり、機密情報の保護手段にはなりません。

OpenAIの公式案内では、ChatGPT検索で内容を発見・表示・引用しやすくするにはOAI-SearchBotのアクセスを妨げないこと、検索への表示を望まない場合はnoindexを使い、その規則を読むためにクロールを許可する必要があることが説明されています。またGPTBotは学習に関する別のユーザーエージェントとして案内されています。公開方針を変える際は、Google等の検索クローラーとAIサービスを同じ設定だと決めつけず、公式情報の確認日と変更理由を管理します。

  • 対象サービスとユーザーエージェントを特定
  • 検索・回答参照・学習など用途を区別
  • 許可・拒否の理由と承認者を記録
  • noindexを読ませる経路を遮断しない
  • 機密情報はクローラー設定に依存しない
  • 公式仕様の確認日を台帳へ残す
05

公開前後の七段階チェックで誤設定を防ぐ

実装は、①URL台帳を最新化、②各URLを公開・検索除外・クロール制御・認証保護へ分類、③canonicalと内部リンクを確認、④robots metaとHTTPヘッダーを確認、⑤robots.txtとXMLサイトマップを生成、⑥PC・スマートフォンとクローラー向け応答を検査、⑦公開後に検索管理画面とサーバーログを確認、の順で進めます。設定を一つずつ追加するのではなく、同じURLに対する指示を横並びで確認することが重要です。

公開後の点検では、重要ページが誤ってnoindexになっていないか、テスト環境の設定が本番へ残っていないか、サイトマップへ終了URLが混ざっていないかを優先します。CMSやテンプレートの共通設定は多数のページへ影響するため、個別ページだけでなくカテゴリ単位の抽出確認も行います。異常を見つけたら、変更前の設定、影響URL、修正内容、再確認日時を記録し、同じ原因を公開手順へ戻して再発を防ぎます。

  • 本番TOP・主要サービス・最新記事を抽出確認
  • noindex・canonical・HTTPヘッダーを実URLで確認
  • robots.txtの対象クローラーとパスを確認
  • サイトマップのURL・最終更新日・応答を確認
  • テスト環境と管理画面が認証されているか確認
  • 検索管理画面とアクセスログで取得状況を確認
  • 変更履歴・影響範囲・再確認結果を保存
FAQ

よくある質問

robots.txtでDisallowにすれば検索結果から消えますか？

検索結果からの削除手段としては使いません。robots.txtは主にクロール要求を制御する仕組みで、外部リンクなどからURLが認識される可能性があります。検索結果へ表示させない場合は、取得可能な状態でnoindexを返すか、非公開情報なら認証で保護します。

noindexのページをXMLサイトマップに残してもよいですか？

サイトマップには検索へ届けたい正規URLを載せるため、原則としてnoindexのURLは外します。既に検索側が認識しているページへnoindexを追加した直後は、クローラーが規則を確認できる状態を保ち、反映を確認してから運用を整理します。

テスト環境はrobots.txtだけで隠せますか？

隠せません。robots.txtはアクセス制御ではなく、URLの存在や内容を第三者から保護する仕組みではありません。テスト環境は認証やネットワーク制限で保護し、本番公開時にnoindexや認証設定が誤って引き継がれていないことも確認します。

PRIMARY SOURCES

参考にした一次情報

外部仕様は変更される場合があります。最新情報は各公式ページをご確認ください。

PUBLISHER / UPDATE株式会社ファーストイノベーション

提供サービス：FIRST INNOVATION WEB