OAI-SearchBotだけをサイト全体で拒否する場合は、robots.txtにUser-agent: OAI-SearchBotとDisallow: /を記述します。許可する場合は、OAI-SearchBotに適用される拒否ルールを置かないか、個別グループでAllow: /を指定します。
ただし、robots.txtで示せるのは対応クローラーに対するクロール方針です。OAI-SearchBotを拒否しても、ChatGPT上でのリンク表示、第三者サイトにある情報、ユーザーが直接提供した情報まで一律に消せるわけではありません。
設定前に、「ChatGPT検索での表示方針」「AIモデル改善のためのクロール方針」「機密情報の保護」を分けて考えることが重要です。この記事では、記述例、既存設定への追加方法、WordPressでの確認方法、GPTBot・ChatGPT-Userとの違いを解説します。
OAI-SearchBotを許可・拒否するrobots.txtの記述例
OAI-SearchBotの設定は、サイト全体を許可または拒否するだけなら短い記述で対応できます。目的に対応するボット名だけを指定することで、Googlebotなど他のクローラーへの影響を避けられます。
サイト全体を拒否する場合
OAI-SearchBotだけにサイト全体のクロールを拒否する場合は、robots.txtに次のグループを追加します。
User-agent: OAI-SearchBot
Disallow: /Disallow: /のスラッシュは、サイトのルート配下すべてを表します。この記述はOAI-SearchBot専用であり、Googlebotなど別のクローラーを直接拒否するものではありません。
OpenAIは、OAI-SearchBotをChatGPTの検索機能でWebサイトを表示するためのクローラーとして案内しています。OpenAIのドキュメントでは、OAI-SearchBotを拒否したサイトはChatGPT検索の回答に表示されない一方、ナビゲーション目的のリンクとして表示される場合があると説明されています。
出典：OpenAI Developers「Overview of OpenAI Crawlers」
サイト全体を許可する場合
OAI-SearchBotに適用される拒否ルールがなく、全クローラー向けの拒否ルールにも該当しなければ、通常はクロールを許可する方針になります。許可を設定ファイル上で明確にしたい場合は、次のように記述できます。
User-agent: OAI-SearchBot
Allow: /すでにUser-agent: *でサイト全体を拒否している場合、OAI-SearchBotだけを許可するには、このような個別グループが必要です。個別のUser-agentグループに一致するクローラーには、一般的な*グループではなく、個別グループのルールが適用されます。
robots.txtの標準仕様では、許可・拒否のどちらにも一致しないURLは許可として扱われます。不要な拒否ルールを残さないことも、許可方針を明確にするうえで大切です。
出典：RFC Editor「RFC 9309: Robots Exclusion Protocol」
特定ページ・ディレクトリだけを許可または拒否する書き方
OAI-SearchBotの対象をサイト全体で一律に決める必要はありません。公開記事は許可し、会員エリアやテストページなどだけを拒否する運用もできます。パスはドメイン名を含めず、先頭をスラッシュで始める形で指定します。
特定ディレクトリを拒否する例
たとえば、/members/配下と/wp-admin/配下をOAI-SearchBotから除外したい場合は、次のように記述します。
User-agent: OAI-SearchBot
Disallow: /members/
Disallow: /wp-admin/この例では、公開記事や商品ページなど、上記以外のURLはクロールを許可する方針です。/members/のように末尾のスラッシュまで書くと、対象ディレクトリ配下を指定しやすくなります。
一方、Disallow: /memberのように短いパスを書くと、/member-news/など意図しないURLまで対象に含むおそれがあります。実際の公開URLを確認して指定するようにしてください。
原則拒否で一部ディレクトリだけを許可する例
原則として拒否し、たとえば/blog/配下だけを許可したい場合は、DisallowとAllowを併用します。
User-agent: OAI-SearchBot
Disallow: /
Allow: /blog/この例では、より具体的なパスである/blog/への許可が適用される考え方です。RFC 9309では、AllowとDisallowの両方に一致する場合、最も長く一致するパスを使うことが示されています。同じ長さで両方に一致する場合は、Allowを使うことが推奨されています。
例外を多数追加すると、公開方針の確認や将来の変更が難しくなります。例外ルールは少なく保つほうが、誤設定を防ぎやすくなります。
出典：RFC Editor「RFC 9309: Robots Exclusion Protocol」
既存のrobots.txtへOAI-SearchBotルールを追加する手順
すでにrobots.txtを運用している場合は、コードを末尾へ貼り付ける前に公開中の全体を確認してください。重要なのは記述順だけではなく、同じUser-agentの設定が重複していないか、既存の全体ルールと方針が矛盾していないかです。
User-agent: * のルールと個別ルールの関係
たとえば、現在のrobots.txtが次の内容なら、個別ルールがないクローラーにはサイト全体を拒否する設定です。
User-agent: *
Disallow: /この状態でOAI-SearchBotだけを許可したい場合は、個別グループを追加します。
User-agent: *
Disallow: /
User-agent: OAI-SearchBot
Allow: /反対に、全クローラーを許可し、OAI-SearchBotだけを拒否する場合は次の構成です。
User-agent: *
Disallow:
User-agent: OAI-SearchBot
Disallow: /空のDisallow:は、そのグループで拒否するパスを指定しない書き方です。設定を読み違えないよう、同じボットの設定は集約することをおすすめします。
追記前に確認したい重複・矛盾しやすい設定
編集前後には、少なくとも次の点を確認してください。
- 同じ
User-agent: OAI-SearchBotが複数の場所に存在していないか - 同じURLパスに対して、意図せずAllowとDisallowを重ねていないか
- SEOプラグインが出力する仮想robots.txtと、サーバー上の実ファイルが競合していないか
- CDN、WAF、ボット対策、Basic認証などでアクセスを別途遮断していないか
- ステージング環境用の全体拒否設定を本番環境へ持ち込んでいないか
OpenAIは、robots.txtで許可していても、WAF、CDN、ボット軽減機能、認証、レート制限などがクローラーのアクセスを妨げる可能性があると案内しています。robots.txtだけで判断せず、HTTPステータスやセキュリティ製品のログも確認してください。
出典：OpenAI Help Center「Advertiser Guidance for Allowing OpenAI Web Crawlers」
WordPressでrobots.txtを編集し、公開内容を確認する方法
WordPressでは、robots.txtの編集場所がサイトごとに異なります。WordPress本体やSEOプラグインが仮想的に返している場合もあれば、サーバー上の実ファイルやCDNが配信している場合もあります。管理画面ではなく公開URLを基準にすることが重要です。
まずブラウザで配信中のrobots.txtを確認する
ブラウザで、次の形式のURLを開きます。
https://example.com/robots.txtexample.comは自サイトのドメインに置き換えてください。wwwあり・なしの両方を運用している場合は、実際に公開されているホスト名で確認します。OAI-SearchBotの記述、意図したAllowまたはDisallow、想定外の全体拒否がないかを確認しましょう。
robots.txtは対象ホストの最上位パスにある/robots.txtとして提供される仕様です。たとえばhttps://www.example.com/robots.txtとhttps://shop.example.com/robots.txtは、別のホストの設定として扱われます。
出典：RFC Editor「RFC 9309: Robots Exclusion Protocol」
編集場所を特定して変更する
公開中の内容を確認したうえで、次の順に編集元を探すと切り分けしやすくなります。
- WordPressのSEOプラグインやrobots.txt編集機能を確認する
- サーバーのファイルマネージャー、FTP、SSHでドキュメントルートの
robots.txtを確認する - テーマや独自プラグインでrobots.txtを出力するカスタマイズがないか確認する
- CDN・WAFでキャッシュ、リダイレクト、アクセス制御が設定されていないか確認する
変更前には、現在のrobots.txt全文をローカルに保存してください。企業サイトでは、技術担当だけで変更せず、必要に応じて広報、法務、情報システム、コンテンツ責任者と公開方針を確認すると安全です。
変更後に反映を確認する
保存後は/robots.txtを再読み込みし、意図した内容が配信されているかを確認します。コマンドを使える環境では、次のようにHTTPヘッダーと本文を確認できます。
curl -i https://example.com/robots.txtHTTP 200でテキスト内容が返るか、ログイン画面や403エラーになっていないかを確認してください。古い内容が表示される場合は、ブラウザ、WordPressのキャッシュプラグイン、サーバーキャッシュ、CDNキャッシュが残っている可能性があります。
robots.txtはクローラー側でもキャッシュされることがあります。OpenAIの現行ドキュメントでは、ChatGPT検索に関するrobots.txtの更新がシステムへ反映されるまで約24時間かかる場合があると案内されています。即時反映を前提にしないで、公開内容と必要に応じたアクセスログを確認してください。
出典：OpenAI Developers「Overview of OpenAI Crawlers」
OAI-SearchBot・GPTBot・ChatGPT-Userの違いと設定対象
OpenAI関連のアクセスをまとめて「ChatGPTのクローラー」と扱うと、設定目的を誤りやすくなります。OAI-SearchBot、GPTBot、ChatGPT-Userは役割が異なるため、目的ごとに設定対象を分ける必要があります。
| 名称 | 主な役割 | robots.txtで検討する場面 |
|---|---|---|
| OAI-SearchBot | ChatGPTの検索機能でWebサイトを表示するための自動クロール | ChatGPT検索の回答・要約・スニペットの対象とする方針を決めるとき |
| GPTBot | 生成AI基盤モデルの有用性・安全性の向上に利用され得るコンテンツのクロール | AIモデル改善に関するクロール方針を示したいとき |
| ChatGPT-User | ユーザーがChatGPTやCustom GPTで実行した操作に伴うアクセス | ユーザー起点のアクセスへの対応を検討するとき |
OpenAIは、OAI-SearchBotとGPTBotの設定は独立していると説明しています。たとえば、ChatGPT検索への表示を検討してOAI-SearchBotは許可しつつ、GPTBotは拒否する方針も選べます。
出典：OpenAI Developers「Overview of OpenAI Crawlers」
OAI-SearchBotだけを拒否しても他のOpenAIボットは別設定
User-agent: OAI-SearchBotだけを拒否しても、GPTBotやChatGPT-Userまで自動的に拒否されるわけではありません。AIモデル改善のためのクロールについても拒否方針を示したい場合は、GPTBotに対する個別設定を検討します。
User-agent: OAI-SearchBot
Disallow: /
User-agent: GPTBot
Disallow: /なお、OpenAIはChatGPT-Userを、ユーザーの要求に伴うアクセス用であり、自動的にWebをクロールする目的では使わないと説明しています。検索掲載の設定対象はOAI-SearchBotです。
出典：OpenAI Developers「Overview of OpenAI Crawlers」
robots.txtで制御できること・できないこと
robots.txtは、クローラーに対してどのURLをクロールしてよいかを伝える仕組みです。公開コンテンツのクロール方針を示す用途には適していますが、すべての公開・利用・表示を制御する仕組みではありません。robots.txtはアクセス制御そのものではないと理解して運用してください。
拒否してもChatGPT上の露出を完全には保証できない理由
OAI-SearchBotを拒否すると、OpenAIの説明上はChatGPT検索の回答への表示対象から外れる方針になります。ただし、第三者の検索プロバイダーや他ページの情報からURLを取得し、関連性があると判断された場合には、リンクとページタイトルだけが表示される可能性があります。
また、外部サイトに転載・紹介されている情報、他の検索サービスにある情報、ユーザーが直接入力した内容まで、robots.txtだけで取り除くことはできません。許可しても掲載は保証されないため、許可は掲載の申請や順位保証とは別のものです。
出典：OpenAI Help Center「Publishers and Developers – FAQ」
機密情報や検索結果の制御にrobots.txtだけを使わない
機密情報、会員限定コンテンツ、未公開資料を守る目的では、robots.txtではなく認証、権限管理、IP制限、アプリケーション側のアクセス制御を使ってください。robots.txtに禁止パスを書くと、パス名自体が公開されることにも注意が必要です。
検索エンジンのインデックスから除外したい場合は、目的に応じてnoindexも検討します。ただし、クロール自体を拒否すると、クローラーがページのnoindex指定を読めない場合があります。検索結果から外す対策と、特定ボットのクロールを止める対策は、別の問題として設計してください。
RFC 9309でも、robots.txtは有効なコンテンツセキュリティ対策の代替ではなく、URLへのアクセス制御にはHTTP認証など適切な手段を用いるよう示されています。
出典：RFC Editor「RFC 9309: Robots Exclusion Protocol」
OAI-SearchBotの許可・拒否を判断する実務上の基準
許可・拒否に一律の正解はありません。自サイトの公開方針、コンテンツの性質、権利処理、ブランド管理、社内ルールをもとに判断します。迷う場合は、対象を限定して運用し、公開範囲を見直す方法もあります。
- 許可を検討しやすいケース：自社ブログ、商品・サービス紹介、採用情報、FAQ、ニュースリリースなど、広く見つけてもらいたい公開情報が中心の場合
- 拒否を検討しやすいケース：AI検索での扱いに慎重な方針がある場合、権利処理が未整理の場合、サイト全体の公開方針を社内で確定できていない場合
- 部分的な拒否が向くケース：会員向け領域、サポート対応中の資料、テストページ、重複しやすい検索条件ページなど、公開範囲を明確に分けられる場合
企業サイトでは、著作権、契約、個人情報、業界規制に関する判断が含まれることがあります。技術設定だけで公開方針を決めないようにし、必要に応じて法務・セキュリティ・コンテンツ責任者と確認してください。
OAI-SearchBotとrobots.txtに関するよくある質問
設定時に迷いやすい点を補足します。設定内容だけでなく、実際に配信されているrobots.txtと周辺のアクセス制御を確認することが重要です。
Allow: / は必ず書く必要がありますか？
必須ではありません。OAI-SearchBotに適用される拒否ルールがなければ、許可として扱われるのが基本です。ただし、User-agent: *で広く拒否しているサイトや、許可方針を担当者間で明確に共有したいサイトでは、OAI-SearchBot専用のAllow: /を置く意味があります。
robots.txtを変えても以前の内容が表示されるのはなぜですか？
よくある原因は、編集した場所と配信元が違うこと、CDNやサーバーのキャッシュが残っていること、ブラウザキャッシュ、wwwあり・なしで別ホストを確認していることです。まず公開URLの/robots.txtを確認し、必要に応じてキャッシュを削除してください。
サブドメインにも同じ設定が必要ですか？
必要になる場合があります。たとえばwww.example.comとshop.example.comは別ホストです。ブログ、EC、採用サイト、ヘルプセンターをサブドメインで運用している場合は、それぞれの/robots.txtを開き、OAI-SearchBotへの方針が意図どおりか確認してください。
まとめ：公開中のrobots.txtを確認してからOAI-SearchBotの方針を反映する
OAI-SearchBotを拒否する最小設定は、User-agent: OAI-SearchBotとDisallow: /です。許可する場合は、OAI-SearchBot向けの拒否を置かないか、Allow: /を明記します。
設定前には、既存のUser-agent: *、OAI-SearchBotの重複ルール、GPTBotとの違い、CDN・WAF・認証の影響を確認してください。変更後は必ず公開中の/robots.txtを確認し、意図した内容が配信されていることを基準に運用しましょう。
OAI-SearchBotの拒否はChatGPT検索向けの自動クロールに関する方針です。AIモデル改善のためのクロール方針にはGPTBot、機密情報の保護には認証・アクセス制御など、目的に合う別の対策が必要です。
