AIO対策ができているか自分で確かめる方法｜サイトの点検手順

llms.txtも置いたし、robots.txtでAIのクローラーも許可した。 AIO対策はひととおり済んだ、と思っている会社は多いかもしれません。

でも、置いたファイルが本当にAIに読まれているかまで、確かめたことはありますか。 ZUBOLANDは自社と関連サイトを点検して、「やったつもり」の穴をいくつも見つけました。 どれも、ブラウザで見ているだけでは気づけない穴でした。

ここでは、私たちが実際に使っている点検の順番を、見つかった穴といっしょにまとめます。

AIO対策の点検とは

AIO対策の点検は、「対策をした」ではなく「AIに届いている」を確かめる作業です。 ファイルを置くまでが対策で、届いているかを見るのが点検、と分けて考えると分かりやすいと思います。

「置いた」と「読まれている」の間には、いくつも段差がある

AIがサイトの情報を使うまでには、いくつかの段階があります。

1. AIのクローラーが、サイトに入ってよいと分かる（robots.txt）
2. AI向けのファイルや本文を、ちゃんと受け取れる
3. AIが実際にそれを読んで、答えに使う
4. お客さんがAIに聞いたとき、名前が出てくる

どこか1つで止まっていると、その先は全部ゼロになります。 しかも、ブラウザで自分のサイトを見ているだけでは、どこで止まっているか分かりません。

Googleと、Google以外のAIでは見る場所が違う

点検するときは、どの入口の話かを先に決めておきます。 Googleは、検索の評価にllms.txtを使わないと公式に説明しています（2026年6月）。 なので、llms.txtの点検は、ChatGPTやClaudeなどGoogle以外のAIに向けたものです。

Googleの検索結果に出るAIの概要は、ふつうの検索と同じ土台の上で動いています。 こちらは、ページがきちんと検索に登録されているかを見るのが基本です。 入口ごとの違いは、AIO対策のやり方にまとめています。

AIO対策を自分で点検するやり方

ここからは、私たちが点検するときの順番です。 コマンドを1行打てる人なら、ここまでは自分でできます。

手順1：名前を入れずに、AIに聞いてみる

最初に、お客さんが聞きそうな質問をAIに聞いて、自社の名前が出るかを見ます。 このとき、質問に自社の名前を入れないのがポイントです。

2026年9月に、首都圏の10の地域で、Googleマップの並びで6番目に出てくるお店を1店ずつ選び、AIに何度か聞いてみました。 有名店ではない、地域の中堅のお店です。 結果は、10店中6店が一度も名前の出ないまま。 マップでは上から6番目に出ているのに、AIの答えの中では存在しないのと同じでした。

名前を入れて聞けば、たいてい出てきます。 でも、質問に名前が入っているのだから、答えに名前が出るのは当たり前ですよね。 お客さんに見つけてもらえている証拠にはなりません。

手順2：robots.txtの「中身」を見る

次に、AIのクローラーがサイトに入れるかを確かめます。 ターミナルで、次のように打ってみてください。

curl -sL https://（自社ドメイン）/robots.txt | head -20

User-agent: から始まるテキストが出てくれば、ファイルはあります。 <!DOCTYPE html> で始まるページが出てきたら、robots.txtは無いのと同じです。

私たちの製品サイトの1つでは、robots.txtとsitemap.xmlとllms.txtの3本とも、ログイン画面に転送されていました。 サイトのログインの仕組みが、テキストファイルまで飲み込んでいたのです。 クローラーから見ると、「robots.txtが無いサイト」でした。 3本とも、です。

手順3：AI向けファイルの先頭と種類を見る

llms.txtやllms-full.txtも、同じように先頭を見ます。 あわせて、ファイルの種類（Content-Type）も確かめておきます。

curl -sI https://（自社ドメイン）/llms.txt

content-type: text/plain のようにテキストとして返っていれば大丈夫です。 「ページが開けたからファイルがある」と判断してしまう失敗は、前の記事にくわしく書きました。

手順4：AIに実際に読ませてみる

ファイルが返っていても、AIが読めるとは限りません。 なので、最後はAIに直接URLを渡して、読めるかを確かめます。

このとき、質問文に次の一文を足すのがおすすめです。

読めなかった場合は、回答の1行目に「URLを読めませんでした」と書いてください。

この一文がないと、AIは読めなかったことを言わずに、それらしい答えを作ってしまうことがあります。 私たちはこの一文を足したその場で、3本渡したURLのうち1本が読めていないことに気づきました。

手順5：同じサイトの「分身」がないかを見る

最後に、同じ内容のサイトが別のアドレスにないかを確かめます。 ホスティングサービスの仮のアドレス（〜.vercel.app など）が、本番と同じ中身を返していることがあるからです。

代表が運営している別の会社のサイトで、これが見つかりました（2026年8月）。 仮のアドレスが本番と同じページを返していて、どちらが本物かを示す指定（canonical）もありませんでした。 検索エンジンやAIから見ると、同じ内容のサイトが2つある状態です。 仮のアドレスは、本番のアドレスへ転送しておきましょう（いまは直してあります）。

うまくいくポイント

名前を入れない質問を多めにする

お客さんがAIに聞くとき、まだ会社の名前を知らないことがほとんどです。 なので、点検の質問も「地域名＋業種＋おすすめ」のような、名前を入れない形を中心にします。 名前入りの質問は、出てきた情報が正しいかを見るときだけ使うのがいいと思います。

1回ではなく、何回か聞いて数える

AIの答えは、聞くたびに変わります。 1回出なかったからといって、出ないとは限りません。 同じ質問を何回か聞いて、何回出たかを数えるのが基本です。

直したら、同じ条件で測り直す

直したあとは、直す前と同じ質問・同じAI・同じ回数で測り直します。 条件を1つでも変えると、直ったのか、測り方が変わっただけなのか分からなくなるからです。

自分のサイトから先に測る

人のサイトを点検する前に、まず自分のサイトを同じ物差しで測ります。 2026年10月に自社のサイトを点検したときも、会社のホームページで足りない項目が2つ見つかりました。 ふだん見慣れているサイトほど、穴には気づきにくいものです。

よくある失敗と注意点

ここも、全部私たちが実際にやった失敗です。

きれいな仮説に飛びついて、直ったつもりになる

手順4で、ChatGPTがzuboland.jpのllms.txtだけ読めなかったときの話です。 調べると、サイトにある6本のAI向けファイルのうち、その1本だけファイルの種類の設定が違っていました。

6本中1本だけ違って、しかもその1本が失敗している。 これだと思って設定を直し、本番に出しました。 結果は、失敗のまま。

さらに試すと、同じファイルのURLの末尾に ?v= をつけただけで読めました。 同じファイル・同じサーバーで、URLの書き方だけで結果が変わったのです。 原因は、いまも不明のまま。

なので、やめました。 読めないURLを渡すことを、です。 渡すURLを3本から2本に減らし、必要な情報は全部、読める側のファイルにまとめています。 原因が分からなくても、届く形に変えることはできます。

片方だけ直して、隠れていた問題を起こす

手順2で、robots.txtがログイン画面に転送されていた話には続きがあります。 転送を止める設定を直す前に、robots.txtの中身を開いてみたら、「すべてのクローラーを拒否する」と書いてありました。

転送を先に直していたら、それまで誰にも読まれていなかった「全部拒否」が本当に効いて、公開中のページが検索から消えていたはずです。 2つの問題が打ち消し合って、たまたま無害になっていたわけですね。 壊れているもの同士が、釣り合っていた状態です。 どちらか片方だけを直していたら、外から見て分かるほうの問題を解決したつもりで、見えていなかったほうの問題を、自分の手で表に出していたことになります。 直す前に、直したあとに何が有効になるかを読む。 この順番で、事故を1つ防げました。

「分からなかった」を「0回」と読む

AIへの質問を自動で数える仕組みを作ったとき、最初の回はGeminiの結果が全部「分からない」になりました。 使っていたAIのモデルが、途中で新しい受付を終えていたのが原因です。

これを「0回だった」と読んでいたら、どうなっていたか。 まちがった結論です。 測れなかったものは、測れなかったとして記録する。 それだけで、まちがいを1つ減らせます。

事例：ZUBOLANDの点検で見つかった穴と、いまの状態

この記事で書いた穴は、どれも点検で見つけて直したものです（2026年10月時点）。

• ログイン画面に転送されていたrobots.txtなど3本 → 正しく返るように直した（中身の「全部拒否」も先に書き換えた）
• 本番と同じ中身を返していた仮のアドレス → 本番のアドレスへ転送
• AIが読めなかったURL → 渡すのをやめ、読める側のファイルに情報をまとめた
• まねき番のサイトにも、AI向けの索引（llms.txt）と完全版データを置いている

点検で見つかる穴は、どれも小さなものです。 でも、1つ止まっていると、その先は全部ゼロ。 作ったら終わりにせず、作ったあとに同じ物差しで測り直す。 私たちが続けているのは、その地味な作業です。

お店の場合、この「測る」「正しい情報を届ける」を毎週続けるのは、なかなか手間がかかります。 すぐ下で紹介しているまねき番は、それをお店の代わりに続けるサービスです。 会社のサイト全体を点検したい場合は、AIの導入支援でいっしょに見ていくこともできます。 全部入りプランのuniLinksでは、AI向けの説明文で向いていない人まで書いています。 その説明文がAIにどう読まれたかは、AIに自社の商品を勧めてもらえない理由に書きました。 ZUBOLANDがどんな体制で製品を作っているかは、代表のブログにあります。

よくある質問

点検は、どれくらいの頻度でやればいいですか？

ファイルの点検（手順2〜5）は、サイトを作り直したときや、設定を変えたときに必ずやります。 私たちの穴も、サイトの仕組みを変えたときにできたものがほとんどでした。 AIに聞く点検（手順1）は、月に1回など決まった間隔で、同じ条件で続けるのがおすすめです。

コマンドが使えなくても点検できますか？

手順1と手順4は、ふだん使っているAIの画面だけでできます。 robots.txtやllms.txtも、ブラウザのアドレス欄にURLを入れて開けば、中身は見られます。 ただ、ログイン画面への転送のように、ブラウザでは気づきにくい穴もあります。 ブラウザで見るときは、出てきたのがテキストか、ふつうのページかを必ず確かめてくださいね。

AIに名前が出ないのは、ファイルが無いせいですか？

ファイルが無いことは、原因の1つでしかありません。 AIは、口コミや他のサイトでの紹介など、いろいろな材料から答えを作ります。 まずは手順1で、名前が出るかどうかと、出たときに内容が正しいかを確かめましょう。 そのうえで、AIが読める材料を自分のサイトに正しく置いておくのが、いちばん確実な一歩だと思います。