AI検索で公式ページを見つけてもらうには、内容だけでなく、検索・取得に必要なクローラーを意図せず拒否していないことが前提です。ただし、すべてのAIクローラーを許可すれば掲載されるわけではありません。検索用、ユーザー操作用、学習用の役割を分け、事業方針に沿って設定します。
結論:検索可視性と学習許可を分けて考える
OpenAIは、検索に使うOAI-SearchBot、ユーザーの操作に応じてページへアクセスするChatGPT-User、モデル改善の学習に関係するGPTBotを別のユーザーエージェントとして案内しています。
GPTBotを拒否しながら、OAI-SearchBotを許可する設定は可能です。学習を許可しないことと、ChatGPT Searchの検索結果へ出したくないことは同じではありません。
GoogleのAI OverviewsやAI Modeは、Google検索のインデックスと品質システムを基盤にしています。Googleで対象になるには、通常の検索でクロール・インデックス可能で、スニペット表示の要件を満たすことが前提です。
OpenAIの3つのユーザーエージェント
OAI-SearchBotは、ChatGPTの検索機能でウェブサイトを見つけ、リンクを示すために使われる検索用クローラーです。ChatGPT Searchでの発見性を確保したい場合、このエージェントを意図せず拒否していないか確認します。
GPTBotは、OpenAIの基盤モデルを改善するために利用される可能性があるコンテンツのクロールに関係します。学習利用の方針に応じて許可・拒否を判断します。
ChatGPT-Userは、ユーザーがChatGPTへ特定のページを読ませる、ブラウズ操作を行うなど、ユーザー起点の取得に使われます。自動巡回ではないため、robots.txtの扱いと、認証・アクセス制御を分けて検討します。
ユーザーエージェント名やIP情報は変更される可能性があります。設定時はOpenAI公式ドキュメントの最新情報を確認してください。
- OAI-SearchBot:ChatGPT Searchでの検索・発見
- GPTBot:モデル改善のためのクロール
- ChatGPT-User:ユーザー操作を受けたページ取得
Googleの生成AI機能は通常の検索基盤を使う
Googleは、AI OverviewsやAI Mode向けに特別なAIファイルや特別なschemaを要求していません。通常のSEO要件、クロール可能性、インデックス、独自で有用なコンテンツが基礎です。
robots.txtでGooglebotを拒否している、noindexがある、canonicalが別ページを指す、本文が取得できない場合は、通常検索と生成AI機能の双方へ影響する可能性があります。
サイトマップへURLを載せるだけでは、クロール、インデックス、表示を保証しません。Search ConsoleのURL検査で、ライブページと登録済みページを分けて確認します。
robots.txtで最初に見る項目
robots.txtはドメイン直下の公開ファイルです。規則はユーザーエージェントごとに評価されます。全体許可の後に特定エージェントの拒否がある場合など、順序と対象パスを確認します。
robots.txtで許可されていても、HTTP 403、429、JavaScriptエラー、Cookie同意、地域制限で本文を取得できないことがあります。実際のレスポンスとレンダリング結果も確認します。
- robots.txtがHTTP 200で取得できるか
- User-agent: * に重要ページのDisallowがないか
- Googlebot、OAI-SearchBot、GPTBotの個別規則があるか
- サイトマップの正規URLが記載されているか
- CDN、WAF、bot対策がrobots.txt以外で拒否していないか
- ステージング用noindexやBasic認証が本番へ残っていないか
設定例をそのままコピーしない
次の考え方は一例です。サイトの法務、著作権、セキュリティ、サービス方針に合わせて決定してください。
robots.txtはアクセス制御ではありません。拒否したURLが外部リンクから知られる可能性があり、機密情報を隠す用途に使えません。
- 検索流入を得たい:GooglebotとOAI-SearchBotが重要ページへアクセスできるか確認
- 学習利用を拒否したい:GPTBotの公式規則を確認し、対象パスを設定
- 会員・機密情報を守りたい:robots.txtではなく認証とアクセス制御を使う
- 重複URLを減らしたい:robots.txtだけでなくcanonicalや内部リンクを整理
HTMLとJavaScriptの確認
GoogleはJavaScriptを処理できますが、JavaScriptサイトのSEOは複雑になります。重要な本文、見出し、リンク、会社情報が初期HTMLまたは安定したサーバーレンダリングで取得できるかを確認します。
AI検索サービスごとにJavaScript処理能力は異なります。ボタン操作後だけ表示される情報、canvas内の文字、画像だけの料金表、クライアント側エラーで消える本文は、取得経路によって利用されない可能性があります。
- curlなどで取得したHTMLに主要本文があるか
- JavaScript無効時でも重要情報とリンクが残るか
- 見出しとリンクが意味の分かるテキストか
- 料金、仕様、更新日が画像内だけに閉じていないか
- エラー時もHTTP 200の空ページを返していないか
Search Consoleで確認する
URL検査では、Googleに登録済みか、クロールが許可されているか、ユーザー指定とGoogle選択のcanonical、最終クロール日、取得結果を確認します。
「公開URLをテスト」が成功しても、すでにインデックス登録されたことを意味しません。「インデックス登録をリクエスト」も、優先クロールの依頼であり、登録や順位の保証ではありません。
新しいページは、サイト内の関連ページからリンクし、サイトマップへ追加し、内容と正規URLを確認したうえで、重要なページだけリクエストします。
サーバーログで確認できること
アクセスログが利用できる場合は、Googlebot、OAI-SearchBot、GPTBotなどのリクエスト日時、URL、ステータス、応答時間を確認できます。ただし、ユーザーエージェント文字列は偽装できるため、必要に応じて公式IP情報で検証します。
クローラが来ていないことだけで、設定ミスとは断定できません。新しいサイト、外部リンクが少ないサイト、公開直後のページでは、発見まで時間がかかることがあります。
よくある誤解
llms.txtを置けばGoogleのAI機能で順位が上がる、構造化データを増やせばChatGPTに掲載される、すべてのbotを許可すれば引用される、という保証はありません。
Googleは、llms.txtをGoogle検索の順位や生成AI機能に使用しないと案内しています。構造化データは通常の検索でページの意味やリッチリザルト適格性を補助しますが、生成AI向けの特別なschemaはありません。
- クロール可能は、インデックスや引用の必要条件になり得るが十分条件ではない
- 構造化データは画面上の事実と一致させる
- AI専用ファイルより、読者に有用なHTML本文を優先する
- 本文の量より、独自性、根拠、責任主体、更新性を重視する
公開後の確認手順
まずrobots.txt、sitemap、対象URLのHTTP状態を確認します。次にGooglebot相当と通常ブラウザで主要本文が取得できるかを比較します。
Search ConsoleでライブURLを検査し、登録状況とcanonicalを記録します。ChatGPT Searchでは、指名質問と非指名質問を分け、公式URLが引用されるかを複数回観測します。
クローラー設定を変更した場合は、変更日時、理由、対象ユーザーエージェント、影響範囲をログへ残します。可視性が変わっても、設定変更だけが原因とは断定せず、同時期のコンテンツ、インデックス、モデル更新も確認します。