AI検索向けのサイト点検：取得・本文・根拠と、流入が少ない原因の切り分け

AI検索への対策を始めるときは、まず「公開したいページを取得できるか」「読者の質問に答えているか」を確認します。特殊なファイルの設置数や自作ツールの点数だけで、引用されるかは判断できません。

この記事はサイト運営者向けの点検手順です。作業の成果を確認できるよう、各工程で保存する証拠まで示します。後半では、検索流入が少ないときに原因を断定せずに切り分ける手順も扱います。

1. 対象とする利用場面を分ける

サイトへAI向けの機能を追加する前に、対象とする利用を決めます。検索結果に記事を出したいのか、資料を参照してもらいたいのか、コードの変更を任せたいのかで、必要な整備は違います。

場面	利用者の目的	最初に確認すること	完了を確かめる方法
公開記事を検索する	疑問に答えるページを探す	取得、登録、本文と出典	URL検査と公開ページの確認
API資料を読む	正しい使い方を調べる	資料の版、リンク、使用例	対象の例を実行して期待結果と照合
リポジトリを変更する	テストを通す変更を作る	作業規則、実行環境、権限	差分レビューと必要な検証

一つのサービスが複数の場面で使われても、公開記事向けの対策をそのままコード作業の規則に置き換えることはできません。この記事では、SEOからAI向けの最適化へ移行する、あるいは特定のファイルが全サイトの必須要件になる、という見方は取りません。主に扱うのは一つ目の、公開記事を検索で見つけてもらう場面です。

2. 代表ページと読者の目的を決める

トップページだけでなく、記事、比較表、ツール説明など異なる種類から一つずつ選びます。「このページを読んだ人が何を判断できるか」を一文で書き、その答えが本文にあるか確認してください。

たとえば料金比較なら、対象プラン、確認日、通貨、税の扱いが必要です。実装記事なら、実行環境、入力、期待結果、失敗条件が必要です。根拠が揃わない部分は、未確認と表示するか断定を取り下げます。

記録にはURL、確認日、対象読者、検証した主張、参照先、残る制約を残します。文字数を増やすための段落は追加しません。

既存ページを役割で分ける

この記事では、一般論を言い換えただけのページはAIの回答で代わりが利きやすく、実測、事例、価格、条件、確認日、判断基準のように、そのサイトで確かめた情報を持つページのほうが確認先として残りやすい、という見立てを前提にしています。測定した結果ではなく、どのページから手を入れるかを決めるための前提です。

この前提で既存ページを分けると、代表ページの候補と、手を入れる順番を決めやすくなります。

分類	例	対応
一次情報	実測、導入記録、独自の調査	条件、確認日、出典を補う
判断支援	比較、選び方、失敗例、チェックリスト	対象読者と判断基準を明確にする
一般論	定義や基礎知識の言い換えだけ	冒頭で答え、独自の情報へつなぐか統合する
古い記事	仕様変更済み、根拠が不明	更新、統合、取り下げ、noindexを検討する

分類の目的は記事を増やすことではありません。根拠を補えないページを、統合や取り下げの候補として見つけることです。

3. 取得と登録を別々に調べる

次の表を一つのURLについて埋めます。どれか一つの成功を、すべての成功に読み替えないことが大切です。

確認対象	残す証拠	それだけでは分からないこと
HTTP応答	最終URL、ステータス、本文	検索エンジンの登録状況
robots.txt	対象botと対象パスに適用するルール	CDNやWAFで拒否されないか
noindexとcanonical	HTMLとレスポンスヘッダー	Googleが実際に選んだ正規URL
Search Console	URL検査の登録・取得結果	今後の順位、他社AIでの引用
本文	質問に対する答え、出典、実例	内容の正確性全体

Search ConsoleのURL検査では、検索に出したい代表記事を選んで状況を読みます。HTTPエラーや意図しないnoindexなら、まず配信と設定を修正します。意図的に検索対象から外した検索結果ページや実験ページのnoindexは、設定ミスとは限りません。公開方針と突き合わせてから変更します。

未登録の理由が「クロール済み」や「検出済み」であっても、設定変更だけで登録されるとは限りません。正規URL、重複、内部リンク、本文の内容を合わせて確認します。トップページ一つの結果を、サイト全体の結果として報告しないでください。

4. 検索と学習の許可を混同しない

OpenAIの説明では、OAI-SearchBotは検索用、GPTBotはモデル改善に関するクローラーで、制御は独立しています。検索へ掲載したいという理由だけで学習利用の許可まで変更する必要はありません。OpenAIのbot資料

robots.txtは対象パスで判定します。たとえば仮のルールで /private/ を禁止しても、それだけで /posts/example/ まで禁止したことにはなりません。個別botのグループと全体のグループを、無条件に足し合わせることも避けます。各社のUser-Agentと用途はAIクローラーのUser-Agent一覧にまとめています。

5. 任意ファイルを必須条件にしない

GoogleはAI機能への掲載に特別なAI向けテキストファイルや専用の構造化データを求めていません。GoogleのAI機能の説明

この要件と任意の整備を混ぜないことが、導入判断の出発点になります。ファイル名から導入を決めず、役割を分けておきます。robots.txtはクローラーへの取得方針を伝える場所です。llms.txtは資料への案内を提供する提案で、採用する場合も読者が使う資料と更新方法を決めてから設置します。リポジトリ向けのAGENTS.mdは、サイトに置くだけで検索への掲載に有利になるファイルではありません。作業手順を書いても、利用するツールがその規則を読むか、実際に守るかは別途確認が必要です。

llms.txtをドキュメントの案内として整備する用途はあります。ただし、設置した事実と検索・引用の改善を分けて記録します。書式と検証の手順はllms.txtの設置と検証で扱っています。構造化データも、実際のページ内容に合うものを選びます。

機械向けの出力も同じ原稿から作る

HTMLとMarkdownを別々に手で編集すると、訂正や料金変更が片方にだけ反映されることがあります。二つの形式を配信するなら同じ原稿から生成し、公開対象を共通の規則で選びます。

実装時には、下書きの除外、公開URLとの一致、更新日の根拠、出力に秘密情報が入らないことを確認します。構造化データも画面の内容と一致させます。ファイルを増やしたこと自体を成果とせず、誤った情報を配信しない仕組みまで含めて検証します。

6. CodeAgentの診断で実際に直した点

2026年9月21日、AEOチェッカーの実装を見直しました。旧版には、学習用botの許可やllms.txtの設置へ加点する仕組みがありました。現在はこれらを参考表示に変更し、点数へ含めていません。

また、robots.txtの部分的な禁止をサイト全体の禁止として扱わないよう修正しました。実際の解析処理に、学習設定だけを変えたケース、llms.txtだけを削除したケース、対象パスを検索botに禁止するケースを渡すテストを用意しています。

これは診断処理の修正を確認するテストです。検索エンジン側の取得や引用の実験ではありません。配点と限界も合わせて確認してください。

チェッカーは公開ページの技術項目を確認する補助です。点数は独自の重み付けで、サービスがページを選ぶ確率ではありません。高得点でも、実際の引用や流入を確認したことにはなりません。取得やメタ情報の不備を見つけた後は、本文へ戻り、読者が必要な判断をできるか確認します。

7. 流入が少ないときに原因を切り分ける

検索流入が少ないとき、技術の問題か記事の問題かを最初から決めつけると、修正が空回りします。取得、検索への登録、検索結果での表示、クリック、来訪後の行動を順に確認します。取得と登録の確認は3の手順のとおりです。

「登録済みなら技術では直らない」「低順位の原因は被リンクや競合」のように、単一の画面から原因を確定することはできません。ここでは残りの指標の読み方と、次の修正の決め方を扱います。

先に集計の範囲を揃える

Search ConsoleとGA4は同じ指標を測っているわけではありません。検索クリックとページビューの数字が一致しなくても、それだけで異常とは判断できません。

記録すること	確認する理由
対象プロパティとURL	別ドメインや別ページを混ぜない
開始日・終了日	異なる長さの期間を比べない
データの確定状況	集計途中の値を減少と誤認しない
フィルター	国、端末、検索種別の違いを残す
欠損・計測開始日	行が無い状態をゼロ扱いしない
本番変更日	変更前後を区別する

アクセス解析のタグを直した直後にPVが増えても、来訪者が増えたのか計測範囲が変わったのかを切り分けます。

表示回数とクリックをページ単位で読む

表示がほとんどない場合は、登録状況のほか、対象クエリと記事の答えが合っているかを読み直します。表示がありクリックが少ない場合は、クエリ、端末、掲載位置、タイトルの内容を並べます。

平均順位は条件の異なる検索をまとめた値です。サイト全体の平均だけで、特定記事が何ページ目に出ると断定しないようにします。母数が小さい期間の増減率も安定した傾向とは限りません。

競合サイト数や被リンク数は補助資料として使えますが、それだけで需要の大きさや勝てる確率を算出しません。原因の仮説と、観測した事実を記録欄で分けます。

次の修正は一つの仮説から決める

たとえば読者が必要とするエラーの再現手順がないなら、対象バージョン、入力、実際の出力、回復手順を追加します。その変更の完了条件は、読者が手順を追えることです。検索流入の増加は別の観察項目にします。

記録欄	記入例（架空）
観測	記事Aに表示はあるが、該当エラーの解決手順がない
仮説	検索者の質問と記事の答えがずれている
修正	再現条件と復旧手順を追記
内容の検証	記載した手順を同じ環境で実行
後日の観察	同じ長さの期間で記事Aのクエリとクリックを確認
残る不確実性	季節性、順位変動、ほかの更新の影響

8. 改善の効果は同じ条件で観察する

変更日を残し、同じ長さの期間、同じページ群でSearch Consoleの表示回数とクリックを比較します。集計途中の日は避け、季節性や別の更新も記録してください。問い合わせや資料の利用など、サイトの目的に合う行動がある場合は、同じ期間で並べて記録します。流入の増減だけでは、ページの役割を果たせているかは分かりません。

AIの引用を観察する場合は、通常の検索とは別の記録にし、サービス名、日付、質問文、引用URLを保存します。一度引用されたこと、数回引用されなかったことのどちらも、一般的な引用確率には換算できません。

資料の案内を小さく試す

資料の案内を整えた効果を見るときは、一つの目的に絞ります。架空のAPIドキュメントなら、「認証エラーの原因を調べる」という質問から始められます。

正解に必要な資料と対象バージョンを決める。
現在の案内から、その資料へ到達できるか確認する。
案内を修正し、同じ質問で参照先の変化を記録する。
回答中のコードを実行し、実際に動くか確かめる。
誤回答、未参照の注意事項、古い資料へのリンクを残す。

この試験で分かるのは、設定した場面で資料が使いやすくなったかです。全サービスでの引用率や検索流入の増加は別に測ります。

修正後に再測定できる記録を残せたら、点検の第一段階は完了です。点数が上がったという理由だけで記事を量産せず、読者が解決できなかった問題を次の修正に使います。成果が出ない理由を一つに決めるより、次に確かめる対象を絞ることを目指します。