AIクローラーを弾いていないか確認する手順｜ログとWAFの設定

AIクローラーを弾いていないかは、robots.txt・アクセスログ・WAF（ワフ）の3か所を順番に見れば切り分けられます。robots.txtは正しいのに、WAFの海外アクセス制限やレート制限でAI検索用のボットだけが403や429を受け取っている、という状態は実際に起こります。所要時間は環境によって変わり、SSHでログを直接見られるなら短く済みますが、共用サーバーの管理画面からログをダウンロードする場合はもう少しかかります。

この記事は、Google検索のAIによる概要（AI Overviews）やChatGPT・Perplexityでの引用が急に減った企業サイトの担当者に向けたものです。読み終わる頃には、どのボットが何番のステータスコードを受け取っているかを自分で確認し、原因を robots.txt・WAF・サーバー設定のどれかに絞り込める状態を目指します。

扱うのは「意図せず弾いてしまっていないか」の確認です。逆に「AIに学習させたくないので意図的に止めたい」場合は、向きが反対の作業になります。そちらはAIクローラーの拒否設定｜学習用と検索用のボットを分ける手順にまとめているので、先にそちらをご覧ください。

Contents / 目次

1. まず見るのはrobots.txt・WAF・サーバー設定の3か所
2. ログとcurlで切り分ける5ステップ
3. WAF・CDN側で見る4つの設定項目
4. 現場で実際に起きる誤ブロック4パターン
5. 直したあとに戻るものと、戻らないもの
6. 全部通すのが正解にならない場面
7. よくある質問
8. まず今日、ログを1回だけ数えてみてください

まず見るのはrobots.txt・WAF・サーバー設定の3か所

AIクローラーが自社サイトに入れているかどうかは、この3か所のどこかで決まります。robots.txtだけを直して安心してしまうのが、もっとも多い取りこぼしです。

• robots.txt：ボットへの「お願い」。守るかどうかは相手次第で、強制力はない
• WAF・CDN：サイトの手前で通信を止める層。国別制限・レート制限・ボット対策ルールが該当する
• サーバー設定：.htaccess、Basic認証、セキュリティプラグイン、WordPressの検索避け設定

順番も大事です。robots.txtは全公開されているので誰でもすぐ読めますが、WAFで弾かれている場合はボットがrobots.txtにすらたどり着けません。だから「robots.txtに問題がない＝通っている」とは言えないのです。

AIボット10種の役割と、止めたときに失われるもの

ボットは「学習用」「検索用」「利用者の操作で動くもの」の3種類に分かれます。名前が似ているので、ここを取り違えると「学習だけ止めたつもりが、AI検索からも消えた」という事故になります。下の表は、各社の公式ドキュメントを読むときの見取りとして名前と系統だけを並べたものです。各ボットの目的・robots.txtでの扱い・止めたときに何が起きるかは、必ず運営元の公式ページで確認してください。ボット名も仕様も各社の都合で変わるため、設定前にリンク先の最新版で表記をそのまま確認し、公式ページに載っている名称だけをrobots.txtに書いてください。

• Google：Googlebot／Google-Extended／GoogleOther（Googleの一般的なクローラー）
• OpenAI：GPTBot／OAI-SearchBot／ChatGPT-User（OpenAIのボット一覧）
• Anthropic：ClaudeBot／Claude-User（Anthropicのクローラー説明）
• Perplexity：PerplexityBot／Perplexity-User（Perplexityのボット一覧）

名前の末尾に -User が付くものは、利用者がその場でURLを渡したときに動くボットです。クロール用のボットとは扱いが別なので、公式ページで挙動を確認してから止めるかどうかを判断してください。

ここが一番の勘違いポイント。GPTBotやClaudeBotを止めても、Google検索のAIによる概要には影響しません。AIによる概要とAIモードへの掲載を決めているのはGooglebotです。GoogleのAI機能に関する公式ドキュメント（英語）には、AI Overviews や AI モードに表示されるための追加要件や特別な最適化は必要ないと書かれており、管理はGooglebot向けのrobots.txtで行うと説明されています。

もうひとつ、判断材料として使える公式の記述があります。Googleの一般的なクローラーの一覧ページ（英語）には、Google-Extended はサイトの Google 検索への掲載に影響せず、Google 検索のランキング要素としても使用されないという趣旨の説明があります（原文は英語で、ここでの日本語は要約です）。つまり「Geminiの学習には使わせたくないが、検索やAIによる概要には出たい」という要望は、Google-Extendedだけを拒否することで両立できます。

AIによる概要そのものの読み方や、AIモードとの違いを先に整理したい方は、AIによる概要とAIモードの違い｜企業サイトへの影響と確認手順もあわせてご覧ください。

この章の結論。「AI検索対策としてボットを止める／通す」を判断するときは、相手が学習用か検索用かを必ず公式ドキュメントで確認してください。そのうえで、robots.txtで通していてもWAFで止まっていることがあるので、次の章の実測に進みます。

ログとcurlで切り分ける5ステップ

確認は、robots.txtを読む・ログを数える・curlで応答を試す、の3つで足ります。SSHでログを直接見られる環境なら短時間で終わりますが、共用サーバーの管理画面からログをダウンロードする場合はその分だけ時間がかかります。順番に進めてください。

ステップ1 robots.txtをボット名ごとに読む

まず自社のrobots.txtをそのまま取得します。ブラウザで開いてもいいのですが、キャッシュに惑わされないようコマンドで取るのが確実です。

# ［example.com を自社ドメインに変更］
curl -s https://example.com/robots.txt

読むときに知っておきたい仕様がひとつあります。robots.txtは、クローラーが自分に最も具体的に一致するグループを1つだけ見るという決まりです。GPTBot用のグループを作った場合、そのボットは User-agent: * のグループを一切読みません。この性質が、次のような事故を生みます。

# 【NG例】よくある事故
# User-agent行を続けて書くと1つのグループになり、
# 検索用の OAI-SearchBot まで全ページ拒否になる
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: OAI-SearchBot
Disallow: /

意図どおりに「学習用は止めて、検索用は通す」を書くと、次の形になります。空の Disallow: は「制限なし＝全許可」の意味です。ボット名は各社の公式ページに載っている表記をそのまま書き写してください。

# 【OK例】学習用を止め、検索用と利用者操作は通す
# ［自社の方針に合わせて増減させてください］
# ［ボット名は各社の公式ページの表記をそのまま使ってください］

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# 検索用は明示的に全許可にしておく
User-agent: OAI-SearchBot
Disallow:

User-agent: PerplexityBot
Disallow:

# 上のどれにも当てはまらないクローラー向け
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap.xml

WordPressには、検索エンジンにインデックスされないよう要求する設定項目があります。制作時にオンにしたまま公開されているケースが実際にあるので、robots.txtの中身が想定と違う場合は真っ先にここを確認してください。設定の場所や、オンにしたときにrobots.txtの出力がどう変わるかはバージョンや使用プラグインで変わります。判断はステップ1のcurlで自社のrobots.txtの中身を実際に見て行ってください。

ステップ2 アクセスログでボット別のステータスコードを数える

ここが本題です。robots.txtが正しくても、サーバーが403を返していれば意味がありません。ログのどの位置にステータスコードが入るかは、サーバーの種類とログ形式の設定によって変わります。ApacheであればApache公式のログ形式の解説に書式の読み方がまとまっています。コマンドを実行する前に、必ず自社のログを1行だけ表示して、ステータスコードが左から何番目かを数え、$9 の数字を書き換えてください。

# まず1行だけ見て、ステータスコードが何番目かを数える
head -n 1 access.log

# ［access.log のパスを契約サーバーのログ置き場に変更］
# ［$9 は上で数えた番号に書き換える］
# 直近ログから、AIボットごとの応答ステータスを数える
for bot in "GPTBot/" "OAI-SearchBot/" "ChatGPT-User/" "ClaudeBot/" "Claude-User/" "PerplexityBot/" "Perplexity-User/" "Google-Extended" "Googlebot/"
do
  echo "===== $bot"
  grep -F "$bot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
done

ボット名を単純に grep すると、名前の一部が重なるものを取り違えます。たとえば Perplexity だけで検索すると PerplexityBot と Perplexity-User が合算されます。実際のUser-Agent文字列は各社の公式ページに掲載されているとおりで、社名やプロダクト名が共通していることも多いため、上のコマンドのように区切り（/）まで含めて検索してください。そのうえで、数が合わないときは実際のログ行を1件開き、UA文字列全体を目視して確認します。

圧縮された過去ログもまとめて見たいときは、grep を zgrep に変え、対象を access.log* にします。出てきた数字の読み方は次のとおりです。

結果	疑うべき場所	次にやること
200が並んでいる	クロールは通っている	ステップ4へ進み、中身が返っているか確認
403が並んでいる	WAF・.htaccess・セキュリティプラグイン	ステップ3とWAFの章へ
429・503が混じる	レート制限（同一IPからの短時間の連続アクセス）	制限値の見直し
401が返る	Basic認証、メンテナンスモードの消し忘れ	認証設定の解除
ボット名が1件も出ない	CDN・WAFがサーバーの手前で遮断、またはログにUAが記録されない設定	CDN側のログを確認

「1件も出ない」がいちばん厄介です。原因が2つに分かれるからです。CDNを使っているなら、サーバーのログではなくCDN管理画面のログを見てください。CDNを使っていないのに1件も出ないなら、そもそもAI側に見つかっていない可能性が高く、この記事の範囲を超えます。その場合はサイトマップ送信と内部リンクの設計から見直すことになります。

ステップ3 curlでボットを名乗って応答コードを確かめる

ログが取れない共用サーバーでも、手元のパソコンから応答を試せます。ターミナル（Windowsならコマンドプロンプト、Macならターミナル）に貼り付けてください。

# ［example.com を自社ドメインに変更］
URL="https://example.com/"
for ua in "GPTBot" "OAI-SearchBot" "ChatGPT-User" "ClaudeBot" "PerplexityBot" "Googlebot"
do
  code=$(curl -s -o /dev/null -w "%{http_code}" -A "$ua" "$URL")
  echo "$ua -> $code"
done

全部200なら、少なくともUser-Agent文字列だけを見て弾くルールは存在しません。特定のボットだけ403なら、その名前を含むブロックルールがどこかにあります。

この方法の限界を先に書いておきます。実際のボットはもっと長いUser-Agent文字列を送っており、正確な文字列は各社の公式ページに掲載されています。また、日本のオフィスから実行している以上、IPアドレスで判定しているルール（国別制限など）は再現できません。curlで200が返っても、海外IPからは403という状態はふつうにあります。だからステップ2のログ確認が主で、curlは補助です。

ステップ4 200が返っているのに中身が空になっていないか確かめる

ステータスコードが200でも、HTMLの中に本文が入っていなければAIは引用できません。JavaScriptで本文を描画しているサイトで起きます。次のコマンドで、記事本文にある特徴的な一文がHTMLに含まれているかを数えます。

# ［URLと、本文に実在する10文字程度の一節を書き換えてください］
curl -s -A "OAI-SearchBot" "https://example.com/column/sample/" | grep -c "本文にある特徴的な一節"

結果が0なら、そのボットにはページの中身が届いていません。0が返ったときは、サーバー側で描画した状態のHTMLを返す構成に変えるか、少なくとも見出しと本文の要点はHTMLに直接書く形に直します。

あわせて、ページのHTMLに nosnippet や data-nosnippet が残っていないかも見てください。Googleのロボットメタタグの公式仕様では、nosnippet は検索結果にテキストのスニペットを表示させない指定、data-nosnippet はページ内の指定範囲をスニペットに使わせない指定と説明されています。クロールは通っていても、これらが付いた範囲は要約への引用対象から外れます。意図して使う場面と副作用はnosnippetの使い方｜AI要約から外す範囲指定とCTRの注意点で解説しています。

ステップ5 直したあとに再取得を確認して記録を残す

修正したら、Google Search ConsoleのURL検査で対象URLを取得し直します。ここではGooglebotが実際に受け取ったHTMLを見られるので、200が返っていること、本文が入っていることをその場で確認できます。画面上のボタン名やタブ名は変わることがあるため、操作手順はGoogleのURL検査ツールの公式ヘルプで現在の表記を確認しながら進めてください。確認したいのは次の3点です。

1. 登録済みインデックスの情報ではなく、いまの状態を取得し直した結果を見ること
2. 取得したHTTPレスポンスのステータスコードが200であること
3. 取得したHTMLの中に、記事本文の一節が含まれていること

そして、確認した内容を1枚のメモに残してください。次に同じ症状が出たとき、探す時間が大きく変わります。記録する項目は次の5つです。

1. 確認日と、確認した人
2. robots.txtの内容（コピーをそのまま保存）
3. ボット別のステータスコード集計の結果
4. WAF・CDNで有効になっているルール名と、その時点の設定値
5. 変更した箇所と、変更前の値

この章の結論。ここまでで「robots.txtの問題か、サーバーの手前で弾かれているか、中身が空か」の3つに切り分けられます。403が並んでいた場合だけ、次のWAFの章に進んでください。

WAF・CDN側で見る4つの設定項目

403の原因は、ほぼこの4項目のどれかです。サービスごとに設定画面の呼び名は違いますが、探すべき機能の中身は共通しています。上から順に確認してください。

• 国別アクセス制限：「日本以外からのアクセスを遮断」を有効にしていると、日本国外のIPアドレスから来るボットは遮断されます。許可リストにどのボットが入っているかは契約先やサービスの設定によって違うため、管理画面で対象を1つずつ確認してください
• ボット対策のマネージドルール：提供元があらかじめ用意した自動化トラフィック向けのルール群です。既定で有効になっているものがあり、AIボットが「未検証の自動化トラフィック」として扱われることがあります
• レート制限：同一IPからの短時間の連続アクセスを止める設定です。クローラーはまとまった数のページを続けて取りに来るので、しきい値が低いと途中から429になります。ログに200と429が混ざっているときはこれです
• 過去に自分たちで追加したUser-Agentブロックルール：スクレイピング対策として何年か前に入れたまま忘れられている記述です。.htaccessに残っているケースもあります

.htaccessに残っている記述は、次のコマンドで探せます。

# ドキュメントルートで実行。User-Agentで弾いている記述を洗い出す
grep -rn -E "SetEnvIf|BrowserMatch|Deny from|RewriteCond.*HTTP_USER_AGENT" .htaccess

CDNやWAFの既定値は変わります。とくにAIクローラーの扱いは各社が方針を見直している領域なので、自社が意図せずブロック側の設定に入っていないか、管理画面の該当設定を一度は目視してください。設定項目の正確な名称も変更されることがあるため、各サービスの公式ドキュメントで最新の表記を確認するのが確実です。

クラウド基盤側のWAFを使っている場合も、考え方は同じです。Azureを使っている場合はApplication Gateway上のWAFでのボット保護の概要に、ボット保護ルールセットの考え方がまとまっています。

共用レンタルサーバーの場合、海外からのアクセス制限やWAFに相当する機能が管理画面に用意されていることがあります。機能の有無・名称・既定値は契約先によって違い、変更されることもあるので、さくらのレンタルサーバのサポートサイトやエックスサーバーのマニュアルのように、契約先の公式マニュアルで現在の仕様を確認してください。

この章の結論。403が出ていたら、国別制限とレート制限の2つを先に疑ってください。この2つで説明がつかない場合だけ、マネージドルールと過去の個別ルールを掘る、という順番が最短です。

現場で実際に起きる誤ブロック4パターン

ここからは、実際に見つかる典型パターンです。どれも「状況→何が起きるか→どう防ぐか」の順で書いています。心当たりがあるものから確認してください。

パターン1 User-agent行を並べて書いてしまい、検索用まで止まる

起きる状況。「AIの学習には使わせたくない」という方針が決まり、担当者が拒否したいボット名を思いつくまま並べて書きます。GPTBot、ClaudeBot、そして名前が似ているOAI-SearchBotも一緒に並べてしまいます。

こうなります。robots.txtは連続するUser-agent行を1つのグループとして扱うため、その下に書いた Disallow: / が全部に効きます。学習は止まりますが、ChatGPTの検索機能からも自社サイトが消えます。しかも、消えたことに気づくきっかけがありません。Search Consoleには何も出ないからです。

防ぎ方。ボット1つにつき空行で区切って1グループずつ書きます。そのうえで、検索用のボットには Disallow:（空欄）を明示的に書いて「意図して通している」と分かる形にしておきます。書いたあとは、記事内のOK例と1行ずつ見比べてください。

パターン2 海外IP遮断を入れた翌週から引用が消える

起きる状況。不審なアクセスが増えたので、サーバー会社の「海外からのアクセスを制限する」機能をオンにします。日本国内向けのサイトなので、業務上はまったく問題がありません。

こうなります。アクセス元が日本国外のIPアドレスであるクローラーは、robots.txtで許可していても403で止まります。どのボットが許可リストに入っているかは契約先の仕様によって違うため、Googlebotは通っているのにChatGPTやPerplexityのボットだけが漏れている、という状態も起こります。「SEOは問題ないのにAI検索から消えた」という相談は、この構成で起きていることがあります。実際にどのボットが止まっているかは、ステップ2のログ集計で確認してください。

防ぎ方。海外IP遮断は、管理画面のログイン URL と入力フォームだけに限定して適用します。公開ページ全体にかけるのはやめてください。全体にかける必要がある場合は、各社が公開しているIPレンジの一覧を許可リストに入れます。公開先のURLとファイル名は各社の都合で変わるため、OpenAIのボット一覧、Anthropicのクローラー説明、Perplexityのボット一覧、GoogleのGooglebot検証手順の各公式ページから、その時点の配布ファイルをたどってください。

パターン3 レート制限が低すぎて、途中から429になる

起きる状況。攻撃対策としてレート制限を入れます。「1つのIPから1分間に◯回まで」といった値を、人間のアクセスを基準に低めに設定します。

こうなります。クローラーは数十ページを続けて取りに来るので、最初の数ページは200、途中から429という状態になります。ログを眺めても200が混ざっているので「来ているから大丈夫」と見えてしまい、見落とします。結果として、サイトの一部だけがAI側に把握され、深い階層の記事は引用対象から外れます。

防ぎ方。ステップ2の集計コマンドを、ステータスコードだけでなくボット別に必ず分けて実行してください。同じボットの中に200と429が混在していたら、この症状です。対処は、公開ページ側のレート制限を緩めるか、検証済みのボットをレート制限の対象外にする設定を使います。

パターン4 ステージング環境の設定が本番に残る

起きる状況。制作会社が構築中にBasic認証や Disallow: / をかけ、公開時に外し忘れます。あるいは、リニューアル後にステージング用の.htaccessが一緒にアップロードされます。

こうなります。ログには401が並びます。人間はブラウザに保存された認証情報で入れてしまうので、社内では誰も気づきません。公開から数か月経ってから「そういえば検索に出ない」と発覚します。

防ぎ方。公開日のチェックリストに「シークレットウィンドウでトップページを開く」「robots.txtをcurlで取得して中身を目視する」の2つを入れてください。どちらも数十秒で終わります。リニューアルを外注する場合は、この2項目を検収の条件に入れておくと確実です。

この章の結論。4つのうち3つは「セキュリティ設定を強めた副作用」です。だから、AI検索からの流入が落ちたときは、直近3か月のサーバー・WAFの設定変更履歴をまず洗い出すのが、原因特定の最短ルートになります。

直したあとに戻るものと、戻らないもの

誤ブロックを解除すると、クロールは再開されます。ただし「いつ引用が戻るか」は自分で決められません。ここを正しく期待値設定しておかないと、直した翌日に「効果がない」と判断してしまいます。

すぐ確認できること。Search ConsoleのURL検査は、その場でGooglebotに取得させて結果を見られます。robots.txtの修正が効いているか、200が返るか、本文がHTMLに入っているかは、修正の直後に判定できます。ここまでが自分の手でコントロールできる範囲です。

時間がかかること。robots.txtの内容はクローラー側で一定時間キャッシュされるため、保存した瞬間に全ボットの挙動が変わるわけではありません。また、各AIサービスが自社のインデックスを更新して再び引用に使うまでのタイミングは公開されていません。数日で戻ることもあれば、もっとかかることもあります。「◯日で戻ります」と言い切れる根拠はないので、ここは断定しない前提で社内共有してください。

判断材料として使える公式の事実。Googleは、AIによる概要やAIモードに表示されるための追加要件はなく、必要なのは通常の検索と同じ技術要件だと明記しています。つまり、誤ブロックを解除してGooglebotが正常にクロールできる状態に戻せば、AIによる概要に出るための前提条件はそろいます。ここで特別な施策を追加購入する必要はありません。

成果を追う場合は、直したあとの流入を測れる状態にしておいてください。ChatGPTやPerplexityからの参照をどこまで見分けられるかは、計測ツールの設定次第で変わります。設定方法はGA4でChatGPT流入を可視化する手順｜カスタムチャネル設定とSearch ConsoleでAI検索の表示回数を確認する手順｜GA4で補うにまとめています。

復旧の作業量そのものは大きくありません。robots.txtの修正は数分、WAFの設定変更も管理画面上の操作としては短時間で終わります。時間がかかるのは作業ではなく、「どこで止まっているかを探す時間」です。だからこそ、ステップ5の記録が効いてきます。

この章の結論。直した直後に判定できるのはSearch ConsoleのURL検査までで、AI側の引用が戻るタイミングは制御できません。社内報告では「クロールできる状態に戻した」と「引用が戻った」を分けて書いてください。

全部通すのが正解にならない場面

ここまで「弾いていないか確認しよう」と書いてきましたが、全てのAIボットを無条件に通すのが正解とは限りません。実務では次のような妥協が必要になります。

1つ目は、クロールの負荷とコストです。クローラーは人間の閲覧と違い、リンクをたどってページを次々に取得していきます。共用レンタルサーバーで、しかもページ数が多いサイトの場合、この取得がサーバーの負荷になることがあります。現実的な落としどころは、全体を許可したうえで、負荷の割に引用価値が低いディレクトリだけをrobots.txtで外すことです。具体的には、サイト内検索の結果ページ、絞り込みパラメータ付きのURL、大量の画像ディレクトリあたりが候補になります。

2つ目は、robots.txtに強制力がないことです。利用者の操作をきっかけに動くボット（ChatGPT-User、Claude-User、Perplexity-Userなど）は、クロール用のボットとrobots.txtの扱いが異なる場合があります。実際の扱いはOpenAI・Anthropic・Perplexityの各公式ページに書かれているので、止めたいボットがある場合は必ず一次情報を確認してください。そもそもrobots.txtは相手の遵守を前提にした仕組みなので、確実に止めたいならWAFやサーバー側で止めることになります。逆に言えば、robots.txtで拒否しているつもりのボットが実際には来ている、という状態も起こります。ログで実態を見る意味はここにあります。

3つ目は、User-Agentは名乗ったもの勝ちだということです。UA文字列は誰でも詐称できるので、「OAI-SearchBotと名乗っているアクセス」が本物とは限りません。

本物かどうかを確かめる方法は、次の2つです。

• 公開IPレンジとの突き合わせ：各社が公式ページで配布しているIPレンジの一覧に、アクセス元IPが含まれるかを確認する
• 逆引きによる確認：アクセス元IPをホスト名に逆引きし、そのホスト名を正引きして同じIPに戻るかを確認する

ただし、これを中小企業のサイトで毎回手作業でやるのは現実的ではありません。実務では、月に1回まとめて確認するか、CDN側の検証済みボット判定に任せるかのどちらかになります。

4つ目は、ログが残っていない環境があることです。共用サーバーのプランによっては、アクセスログの保存期間が短かったり、そもそもダウンロードできなかったりします。この場合、ステップ2が使えません。代わりにできるのはcurlでの応答確認と、サーバー会社への問い合わせです。問い合わせるときは「AIクローラーのUser-Agentを遮断する既定のルールが有効になっているか、海外IP制限の適用範囲はどこか」と、確認したい対象を具体的に書いて送ると、回答が早く返ってきます。

5つ目は、学習と検索を分けられないベンダーがあることです。OpenAI・Anthropic・Googleは、学習用と検索用のボットを別のUser-Agent名で分けています。しかし、すべてのAIサービスが分けているわけではありません。分けていない相手に対しては、「学習は嫌だが検索には出たい」を両立できません。その場合は、自社にとって露出と学習のどちらを優先するかを決めるしかない、というのが率直なところです。

この章の結論。目指すのは「全部通す」ではなく、「どのボットを、どのディレクトリまで通すかを、意図して決めている状態」です。意図せず弾いている状態と、意図して弾いている状態は、まったく別物として扱ってください。

よくある質問

まず今日、ログを1回だけ数えてみてください

今日すぐできる一歩は1つです。ターミナルでこの記事のステップ3のコマンドを自社ドメインに書き換えて実行し、6つのボットが何番を返すかだけ見てください。すぐ終わります。全部200なら、少なくともUser-Agentで弾く設定は入っていないと分かります。

そのうえで「クロールは通っているのに引用されない」段階まで進んだ方は、検索1位でもAIに引用されない理由と、引用される会社の共通点を次に読んでみてください。原因が中身側にある場合の見直し方をまとめています。

ログの見方は分かったけれど、WAFの設定変更まで自社でやるのは不安、あるいは直したあとに何を書けばAIに引用されるのかまで含めて整理したい、という場合はお手伝いできます。AIクローラーの確認まで行うAI検索対策から、現状のサイトを一緒に見るところから始めましょう。まずは今の状況を聞かせてください。