PerplexityBotとGooglebotの違い
PerplexityBotとGooglebotの違いを、目的、robots.txtのルール、ログでの本物の確認、アクセス解析での扱いで比べます。ユーザーの依頼による取得を別に確認する方法も解説します。
Googlebotは、Googleの検索インデックスを作るために巡回するクローラーで、そのインデックスはAIによる概要（AI Overviews）に表示される条件にも関わります。PerplexityBotは、Perplexityの検索でサイトを表示し、リンクするために巡回します。Perplexityの説明では、基盤モデルの学習のためのコンテンツの収集には使われません。 Perplexity-Userは、ユーザーの依頼による取得のための別のクローラーです。そのアクセスは、2つの自動のクローラーとは分けて調べましょう。
それぞれのクローラーの役割
| 確認すること | Googlebot | PerplexityBot |
|---|---|---|
| 目的 | Google検索のインデックスのためのコンテンツの巡回 | Perplexityの検索でのサイトの表示とリンク |
| robots.txt | 自動の巡回には、Googlebotのトークンが使われる | 自動の巡回には、PerplexityBotのトークンが使われる |
| ユーザーの依頼による取得 | Googleは、ユーザーの依頼による取得を別に記載しており、Googlebotはその種類ではない | Perplexity-Userは、PerplexityBotとは別 |
| 拒否したときの効果 | 今後の巡回を制限する。インデックス済みのURLを確実に削除する方法ではない | そのクローラーのアクセスを制限する。すべての取得をサイト全体で禁止するものではない |
GoogleのAI機能の説明によると、AIによる概要の対象になるには、裏付けとなるページがインデックスされていて、検索のスニペットに表示できる状態である必要があります。対象になることは、選ばれる約束ではありません。そのため、Googlebotのアクセスは見つけてもらうためには大切ですが、そのページがAIの回答に表示されたことは示しません。
この表は、アクセスの役割の地図として使いましょう。クローラーの訪問、インデックスされたページ、引用元のリンク、人のクリックは、それぞれ別の観察です。確かめるには、それぞれ別の記録が必要です。
確認するrobots.txtのルール
ページを配信しているホスト名の、公開されたrobots.txtを開きます。名前を指定したクローラーのグループ、その許可と拒否の行、名前を指定したグループがないときに適用される広いグループを探します。トップページだけでなく、記事や製品のページのパスそのものを判定しましょう。
GooglebotとPerplexityBotの判断は分けておきます。一方を拒否しても、もう一方に同じ指示を出したことにはなりません。検索で見つけてもらうことが目的なら、拒否されているページに内容を足す前に、意図しない除外がないかを確認します。
robots.txtは、ルールに従うクローラーへのお願いで、HTTPのアクセスを強制するものではありません。設定の確認がうまくいっても、ファイアウォールが同じアクセスを拒否していないかは分かりません。反対に、ブラウザでページが開けても、自動のアクセスに同じ応答が返るとは言えません。設定の範囲はrobots.txtの書き方で解説しています。
リクエストのログでGooglebotを見分ける
まず、ユーザーエージェントの項目で、Googlebotのトークンを含む記録を選びます。日時、リクエストされたホスト名、パス、HTTPステータス、元のアクセス元のIPアドレスを表示したままにします。ユーザーエージェントはコピーできるので、本物か確かめるまでは「Googlebotを名乗るアクセス」として扱いましょう。
Googleの確認方法の説明に沿って、公開されている適切なクローラーのIPアドレスの範囲を使うか、逆引きのDNSのあとに正引きのDNSで確認します。説明にあるホスト名の形式を確かめ、正引きの結果が元のアドレスに戻ることを確認します。名前に「google」という言葉が含まれるだけでは不十分です。
プロキシを使っている場合は、元のアクセス元のアドレスを記録した、信頼できる記録を使います。プロキシのアドレスしかないサーバーのログでは、アクセス元を確かめられません。確かめられない記録は、本物のクローラーのアクセスとして数えず、「不明」として分けておきます。
ログでPerplexityのアクセスを見分ける
ユーザーエージェントの項目で、PerplexityBotとPerplexity-Userを別々に絞り込みます。信頼できるアクセス元のアドレスを、Perplexityのクローラーの説明からリンクされている、対応する最新のIPアドレスの一覧と比べます。文字列の先頭を比べるのではなく、必要に応じてIPv6も含めて、アドレスの範囲を正しく照合しましょう。
Perplexity-Userのアクセスは、人の質問がきっかけのことがありますが、自動の取得であることに変わりはありません。Perplexityの説明では、このクローラーはユーザーの依頼による取得なので、通常はrobots.txtに従いません。巡回についての希望を伝えるのではなく、HTTPのアクセスそのものを拒否したいなら、アクセス制御を使います。
どちらのトークンでも、応答の結果を確認します。拒否、リダイレクト、ページの取得の成功は、それぞれ違う出来事です。成功のステータスでも、確認画面（チャレンジ）や空のページが返っていることがあります。内容が読める状態だったと判断する前に、返された本文を確認しましょう。
役に立つクローラーのログの見直し方
期間を決めて、確認できたアクセス元、パス、ステータスでアクセスをまとめます。元の記録は残しておきます。アクセスのルールを変えたら、変えた日時を記録し、その後の同じパスへのアクセスと比べます。ログに記録がなくても、クローラーが拒否されたとは言えません。まだ来ていないだけかもしれません。
サーバーの応答と、CDNなどのエッジでの応答は分けて見ます。アプリケーションに届く前に拒否されたアクセスは、エッジのセキュリティのログにしか残らないことがあります。アプリケーションのログだけを見ると、調べている拒否を見落とすことがあります。
サイトの担当者に問題を伝えるときは、代表的なアクセスを1件、タイムゾーン、パス、応答、本物かどうかの確認の結果と一緒に渡します。関係のない訪問者の情報は伏せます。この記録があれば、担当者はどのクローラー、ホスト名、デプロイで問題が起きたかを推測せずに、対応するアクセスのルールを確認できます。その後に成功したアクセスは、結果が変わった根拠として別に残しましょう。
具体的な結果を記録します。「確認できたクローラーが、料金のページで拒否の応答を受けた」なら、対応できます。「AI可視性が下がった」では、どのアクセスが失敗したかが分かりません。確かめられたアクセスの問題を直し、次のアクセスを待つか、対応している診断ツールでアクセスできるかを確認しましょう。
アクセス解析での2つのクローラーの扱い
クローラーや取得のアクセスは、人の訪問の合計に含めません。通常のブラウザのタグでは、アクセス解析のタグを動かさないアクセスは、通常のページのイベントを作りません。サーバーサイドで計測している場合は動きが違うことがあるので、ログの合計とアクセス解析のセッションを比べる前に、自社の設定を確認します。
確認できる人の流入は、GA4などのアクセス解析に実際に記録された参照元を使って、別に数えます。人が引用元のリンクをたどるのと、AIがその引用元を取得するのは、別の出来事です。Perplexity-Userのアクセスを、すべて流入の訪問に置き換えてはいけません。
クリックが参照元なしで届き、「direct（直接）」として表示されることもあります。近くのクローラーのアクセスと照らし合わせても、どこから来たかは分かりません。SearchSealは、回答、ブランドの言及、返された引用元のURLを保存します。クローラーのアクセスはサーバーのログで、人の訪問はアクセス解析で確認しましょう。一方が他方を証明すると考えずに、記録を並べて比べます。
よくある質問
PerplexityBotは基盤モデルの学習に使われますか？
Perplexityの説明によると、PerplexityBotは検索結果でサイトを表示し、リンクするためのもので、AIの基盤モデルのためのコンテンツの収集には使われません。これは、この名前のクローラーの目的についての説明です。
Googlebotを拒否すると、AIによる概要だけに影響しますか？
いいえ。GooglebotはGoogle検索の巡回に使われます。拒否すると、通常の検索のための巡回も制限されます。また、robots.txtだけでは、インデックス済みのURLを確実に削除できません。
Perplexity-Userのアクセスは、人のセッションですか？
いいえ。ユーザーの操作を助けることがある、自動の取得です。人が実際にリンクをたどってサイトに来たときに、ブラウザの訪問として別に数えます。
ユーザーエージェントで、どのクローラーが来たか証明できますか？
いいえ。信頼できるアクセス元のIPアドレスを、公式の範囲や説明されている確認方法で確かめます。確認できないときは、名乗っているだけのアクセスとして分けておきます。