Google AnalyticsにGPTBotが表示されることはありません。GA4をはじめとする多くの解析ツールは、ブラウザ上でJavaScriptが実行されることで訪問を記録します。しかし、GPTBotはJSを実行しないため、トラッキングコードも作動しません。OpenAIのクローラーが実際にページを巡回したのか、何を取得し、どのようなレスポンスを受け取ったのか。それを裏付ける信頼できる証拠は、サーバーの生のアクセスログだけです。
サーバーログだけが事実を示せる理由
AIクローラーと実際のユーザーでは、サイトへアクセスする経路が異なります。ユーザーはブラウザでページを開き、JSを読み込み、GA4のイベントを発火させます。そのため、訪問の一連の動きをダッシュボードで確認できます。一方、GPTBotのようなクローラーはHTTPリクエストを送り、返されたHTMLを収集すると、そのまま離脱します。トラッキングコードを実行しないため、解析ツールでは動きを捉えられません。サーバーログは別です。実際のユーザー、Googlebot、GPTBotのいずれであっても、リクエストを受けるたびにNginxやApacheが送信元IP、日時、リクエストパス、レスポンスのステータスコード、User-Agentを1行ずつ記録します。この記録はフロントエンド側で遮断されず、アクセス元がJSを実行しなくても消えることはありません。
GPTBotだけでは不十分。まずOpenAIの3種類のクローラーを把握する
OpenAIのクローラーは1種類だけだと考え、ログ内でGPTBotしか検索していないケースは少なくありません。しかし、それではAI上での可視性を大幅に過小評価してしまいます。OpenAIには目的の異なるクローラーが少なくとも3種類あり、それぞれUser-Agentも異なります。種類ごとに分けて抽出し、個別に集計することが重要です。
- GPTBot：モデルの学習と改善を目的にコンテンツを取得します。User-Agentには「GPTBot」が含まれます。robots.txtに従い、送信元IPはopenai.com/gptbot.jsonで公開されています。
- OAI-SearchBot：ChatGPTの検索機能で使うインデックスを作成します。User-Agentには「OAI-SearchBot」が含まれます。ChatGPTの回答で自社コンテンツが「引用」される可能性に、最も直接関係するクローラーです。
- ChatGPT-User：ユーザーがChatGPT上でリンク先の読み取りを求めたときに作動します。User-Agentには「ChatGPT-User」が含まれます。ログに現れた場合、実際のユーザーがChatGPTを介してそのページへアクセスしていることを意味します。
- さらに確認したい点：同じログには、通常PerplexityBot、ClaudeBot、Google-Extendedなど、ほかのAIクローラーも記録されています。解析の考え方はまったく同じです。
ステップ1：アクセスログからGPTBotの足跡を探す
一般的なNginxのcombined形式を例にすると、ログの1行には送信元IP、日時、「GET /blog/geo-audit HTTP/1.1」、ステータスコード200、レスポンスのバイト数、最後にUser-Agent文字列が並びます。GPTBotからのリクエストでは、User-Agentの末尾にcompatible; GPTBot/1.2; +https://openai.com/gptbotと記録されます。この特徴を使えば、数行のコマンドだけでアクセス状況を洗い出せます。
- GPTBotの全リクエストを抽出する：grep -i "GPTBot" /var/log/nginx/access.log
- 本日のアクセス回数を数える：grep -ic "GPTBot" access.log
- レスポンスのステータスコード分布を確認する（combined形式では9列目がHTTPステータスコード）：grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- 取得回数の多いページを確認する（7列目がリクエストパス）：grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- 3種類のクローラーの巡回回数をまとめて比較する：grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
出力結果から、まず3つのことが分かります。1つ目は頻度で、1日に何回来ているか、どの時間帯に集中しているか。2つ目はカバー範囲で、重要な製品ページや記事まで取得しているか、トップページ周辺だけを巡回しているか。3つ目はレスポンスの健全性で、ステータスコードがほぼ200になっているかです。grepの結果が空なら、対象期間中にGPTBotは一度も来ていません。その場合は、robots.txtやファイアウォールが遮断していないか確認してください。
ステップ2：正規のGPTBotか確認する
User-Agent文字列は自由に偽装できます。一般のクローラーはもちろん、悪意のあるトラフィックでさえ、ヘッダーに「GPTBot」と記載して正規のクローラーになりすまし、特定の制限を回避したり、サーバーリソースを消費したりする可能性があります。そのため、ログから抽出した後は真正性の確認が必要です。信頼性の高い方法は次の2つです。
- 公式IPリストと照合する：OpenAIは各クローラーの送信元IPレンジをopenai.com/gptbot.json、openai.com/searchbot.json、openai.com/chatgpt-user.jsonで公開しています。ログに記録された送信元IPが、該当するIPレンジに含まれる場合だけ正規のアクセスとして集計します。
- 逆引きDNSで検証する：送信元IPに対してPTRクエリ（hostまたはdig -x）を実行すると、正規のGPTBotであればOpenAI名義のドメインに逆引きされます。続いて、そのドメインを正引きし、元と同じIPに解決されることを確認します（forward-confirmed rDNS）。正引きと逆引きの両方が一致して初めて信頼できます。
ステップ3：取得したページとステータスコードを確認する
クローラーが来ただけでは、コンテンツを正常に取得できたとは限りません。ChatGPTから参照される可能性を左右するのは、各リクエストで「何を取得できたか」です。確認すべきシグナルは4つあります。
- ステータスコード：理想はすべて200です。403が大量にある場合は、CloudflareやWAFがGPTBotを不審なトラフィックとして遮断している可能性があります。404は、サイトマップや内部リンクが無効なURLを参照していることを示します。5xxが続く場合は、クローラーの訪問時にサーバーエラーが発生しています。
- 取得対象ページ：リクエストパスの一覧を確認し、引用される可能性の高い料金ページ、プランページ、詳細な解説記事が含まれているかを見ます。トップページと一部の古い記事しか取得されていないなら、主要コンテンツはAIから見えていません。
- llms.txtとrobots.txtへのアクセス：クローラーが/llms.txtや/robots.txtをリクエストしているか、ログで確認できます。llms.txtを設置しても一度も読み込まれていない場合、そのクローラーは現時点でこの仕組みを利用していません。効果を過大評価しないことが重要です。
- クロール頻度と情報の鮮度：記事の公開日や更新日時と照らし合わせ、GPTBotがどの程度の頻度で再取得しているかを確認します。再訪の間隔が長すぎる場合、新しいコンテンツがモデルの理解に反映されるまでにも時間がかかります。
最適化を始める前に、まずログを読む
llms.txtの作成、Schemaの修正、コンテンツのリライトに工数をかける前に、まず10分だけアクセスログをgrepしてみてください。Tentenが以前支援した案件では、顧客のllms.txtとSchemaはどちらも適切に実装されていました。しかしログを詳しく調べると、半年にわたりGPTBotへのレスポンスが毎回WAFによって403にされており、それまでの最適化がすべて無駄になっていたことが分かりました。GPTBotが来ているか、何を取得したか、どこで遮断されたか。ログはその事実を明確に示します。これは、あらゆるGEOの技術最適化において、最も低コストで重要な工程です。ログにどのような可視性の欠落が潜み、どこから修正すべきかを把握したい場合は、30分のGEO診断をご予約ください。実際のクロール状況を確認し、優先して着手できる改善箇所を具体的にお伝えします。
