自社サイトがAIに読まれているか、curl 一発で調べる方法コピペで使えるチェックコマンド付き

前回の記事では、「AI対策・LLMO対策を考えるうえで、まず自社サイトが知らないうちにAIを遮断していないかを確認すべき」という話をしました。今回はその続きとして、実際にどうやって確認するのかという実務に踏み込みます。

特別なツールは要りません。使うのは curl（カール）という、ターミナルに標準で入っているコマンド1つだけです。コピペで動くものを並べていくので、手を動かしながら自社サイトを診断してみてください。

なぜ「確認」から始めるのか

AI検索での露出を増やそうとすると、つい「良いコンテンツを作る」「構造化データを入れる」といった攻めの施策から手をつけたくなります。ですが、その前に土台として「そもそもAIがサイトを読める状態か」を確かめておかないと、施策の効果が土台から漏れてしまいます。

やっかいなのは、Google検索が正常に見えていても、AIだけが遮断されているケースがある点です。AIのクローラーと検索エンジンのクローラーは別物なので、片方だけ弾かれていても管理画面のSEOレポートには異常が出ません。だからこそ、目視ではなくコマンドで実際のサーバーの反応を見る必要があります。

準備：ターミナルを開く

Macなら「ターミナル」、Windowsなら「PowerShell」や「コマンドプロンプト」を開きます。あとは以下のコマンドをコピーして貼り付け、Enterを押すだけです。curl はほとんどの環境に最初から入っているので、追加インストールは基本的に不要です。

以下では、確認対象を仮に example.com と書きます。実行するときは自社ドメインに置き換えてください。

チェック1：AIボットを名乗ってアクセスしてみる

まず、AIのクローラーになりすましてサイトにアクセスし、サーバーがどう応答するかを見ます。-A は「User-Agent（名乗り）」を指定するオプションで、ここに ClaudeBot（Anthropicのクローラー）や GPTBot（OpenAIのクローラー）を入れます。



curl -A "ClaudeBot" -s -o /dev/null -w "%{http_code}\n" https://example.com/

curl -A "GPTBot"    -s -o /dev/null -w "%{http_code}\n" https://example.com/curl -A "ClaudeBot" -s -o /dev/null -w "%{http_code}\n" https://example.com/

-s -o /dev/null -w “%{http_code}” は「ページの中身は表示せず、ステータスコード（3桁の数字）だけを出す」という指定です。結果の読み方は次の通りです。

200 が返れば、そのAIボットはサイトを取得できています（正常）。403（や 503）が返る場合は、サーバーがそのボットを拒否しています。301 や 302 はリダイレクト（www有無やhttpsへの転送など）で、遮断ではありません。この場合は末尾に -L を足すと転送先まで追って最終的なコードが見られます。

チェック2：通常ブラウザと比べる

AIボットが 403 だったとして、それが「サイト全体が誰にも見えない状態」なのか「AIだけ狙い撃ちで弾かれている」のかを切り分けます。通常のブラウザを名乗って、同じURLを叩いて比較します。


curl -A "Mozilla/5.0" -s -o /dev/null -w "%{http_code}\n" https://example.com/

ここでブラウザ（Mozilla）は 200、AIボットだけ 403 なら、それは「AIを名指しで遮断している」というサインです。逆に、両方とも同じコードなら、AIを特別扱いしているわけではありません。

一度に確認したい場合は、複数サイト・複数ボットをまとめて回すこともできます。


for s in https://example.com/ https://example2.com/ ; do
  echo "=== $s ==="
  echo -n "  ClaudeBot : "; curl -A "ClaudeBot"   -s -o /dev/null -w "%{http_code}\n" "$s"
  echo -n "  GPTBot    : "; curl -A "GPTBot"      -s -o /dev/null -w "%{http_code}\n" "$s"
  echo -n "  Mozilla   : "; curl -A "Mozilla/5.0" -s -o /dev/null -w "%{http_code}\n" "$s"
done

チェック3：robots.txt の中身を見る

ステータスコードの次は、サイトのアクセスルールを書いた robots.txt を確認します。これはブラウザで https://example.com/robots.txt を開くだけでも見られますが、AIボットに対して違う内容を返す設定になっている場合もあるので、curl でAIボットを名乗って取得しておくと確実です。


curl -A "ClaudeBot" https://example.com/robots.txt

見るべきポイントは主に2つです。User-agent: * の下に Disallow: /（スラッシュ1本だけ）があれば、全てのボットに対してサイト全体を拒否しています。一方、GPTBot や ClaudeBot といったAIボット名の下にだけ Disallow: / が並んでいれば、AIを狙い撃ちで拒否している状態です。どちらの記述もなければ、robots.txt の中身としては開放されています。

チェック4：隠れた「X-Robots-Tag」ヘッダーを確認する

ここが見落とされやすいポイントです。robots.txt の中身が開放されていて、ステータスも 200 なのに、なぜかAIに敬遠される――そういうケースでは、目に見えない「レスポンスヘッダー」が原因になっていることがあります。-I を付けるとヘッダーだけを取得できるので、その中に X-Robots-Tag が含まれていないかを見ます。


curl -A "ClaudeBot" -I https://example.com/robots.txt | grep -i x-robots
curl -A "ClaudeBot" -I https://example.com/ | grep -i x-robots

ここで x-robots-tag: noindex という行が表示されたら、それが「このリソースはインデックス・利用しないでほしい」という指示です。特に robots.txt という“クローラーの入り口”のファイルにこれが付いていると、一部のAIフェッチャーがサイト全体を敬遠する挙動につながることがあります。何も表示されなければ、このヘッダーの問題はありません。

なぜこのヘッダーが付くのか、どう対処するのかは、それ自体が奥の深いテーマなので別の記事で詳しく扱います。

まとめ：結果の判定フロー

ここまでのチェックを、結果別に整理します。

トップページも記事ページも 200 で、robots.txt も開放、x-robots も出ない場合は、AIに読める状態がひとまず整っています。AIボットだけ 403 が返る場合は、サーバーやCDN、あるいはレンタルサーバーの機能でAIを遮断している可能性が高い状態です。ステータスは 200 なのに robots.txt や記事ページに x-robots-tag: noindex が出る場合は、ヘッダー由来で敬遠されているケースです。

ただし一点、補足しておきます。403 が返る＝「AIに一切使われない」とは限りませんし、逆に 200 が返る＝「AIが中身を自由に使える」とも限りません。ステータスコードはあくまで「入り口が開いているか」を示す一次情報で、実際の扱いはサイトの規約や認証など別の要素も絡みます。数字は決定的な結論ではなく、状況を絞り込むための手がかりとして捉えるのが実態に近いはずです。

遮断していた場合はどうするか

チェックの結果、自社サイトがAIを遮断していた場合、その原因は「どの層で弾いているか」によって対処が変わります。レンタルサーバーの遮断機能が原因のケース、robots.txt に付いた X-Robots-Tag が原因のケースなど、パターンごとの見分け方と解除方法は、それぞれ別の記事で具体的に解説していきます。

まずはこの記事のコマンドで、自社サイトが今どういう状態にあるのかを把握してみてください。現状を正しく知ることが、AI検索時代のサイト運用の出発点になります。