Googleのウェブマスターガイドラインは
検索ボットが、サイト内のパスを追跡するセッションIDや引数なしでサイトをクロールできるようにします。これらの手法は、個々のユーザーの行動を追跡するのに役立ちますが、ボットのアクセスパターンはまったく異なります。ボットは、見た目は異なるが実際には同じページを指しているURLを削除できない可能性があるため、これらの手法を使用すると、サイトのインデックス作成が不完全になる可能性があります。
私のASP.NET1.1サイトは、カスタム認証/承認を使用しており、セッションGUIDにかなり依存しています（このアプローチと同様）。セッション以外の追跡トラフィックを許可すると、既存のコードが破損するか、セキュリティの脆弱性が発生するのではないかと心配しています。
非セッション追跡ボットが通常のセッション追跡サイトをクロールできるようにするためのベストプラクティスは何ですか？また、ユーザーエージェントを検査する以外に、検索ボットを検出する方法はありますか（セッション追跡を回避するために、ユーザーがgooglebotになりすましてほしくない）。
ボットを検出する正しい方法は、ホストエントリ（Dns.GetHostEntry）によるものです。一部のラメロボットではIPアドレスで追跡する必要がありますが、一般的なロボットでは一般的に追跡できません。Googlebotのリクエストは*.googlebot.comから送信されます。ホストエントリを取得したら、にチェックインしてIPHostEntry.AddressList、元のIPアドレスが含まれていることを確認する必要があります。
ロボットを検証するときは、ユーザーエージェントを見ないでください。
http://googlewebmastercentral.blogspot.com/2006/09/how-to-verify-googlebot.htmlも参照してください
まず第一に：既知の検索エンジンへの応答からJSESSIONIDを単純に取り除くことに関していくつかの問題がありました。最も注目すべきは、リクエストごとに新しいセッションを作成するとOutOfMemoryErrorsが発生したことです（Javaを使用していない場合、数千のアクティブなセッションの状態を維持することは、ほとんどまたはすべてのサーバー/フレームワークにとって確かに問題です）。これは、セッションタイムアウトを減らすことで解決できる可能性があります（ボットセッションの場合のみ-可能であれば）。したがって、この道を進みたい場合は、注意が必要です。その場合、DNSルックアップを実行する必要はありません。ここでは価値のあるものを保護していません（たとえば、 GoogleのFirst Click Freeと比較して）。誰かがボットのふりをして、通常は問題ないはずです。
代わりに、セッションの追跡を継続し（URLパラメーターをCookieのフォールバックとして使用）、各ページに正規リンクタグ（<link rel="canonical" href="..." />明らかにセッションID自体なし）を追加することをお勧めします。議論については、「 GoogleにJSESSIONIDを無視させる」またはMattCuttsを特集した広範なビデオを参照してください。このタグを追加することはそれほど煩わしいことではなく、とにかく良い習慣と見なされる可能性があります。したがって、基本的には、検索エンジンスパイダーの専用の処理なしで終了します。これは確かにGood Thing（tm）です。
問題に対するあなたのアプローチは完全には正しくないと思います。アクセス権の決定、悪意のあるユーザーのログ記録、ボットの検出などにセッション追跡メカニズムに依存するべきではありません。
任意のユーザーが特定のページにアクセスすることを望まない場合は、認証と承認を使用する必要があります。任意のユーザーがページへのアクセスを許可されている場合は、セッションIDなしでアクセスできるようにする必要があります（最初にアクセスしたページであるかのように）。したがって、ボットはこれらのページを問題なく閲覧できます。 。
悪意のあるユーザーは、Cookie、リファラー、URLパラメーターなどを使用（または微調整）しないことで、セッショントラッキングを回避する可能性があります。したがって、ここではセッショントラッキングを確実に使用できず、元のIPを使用してリクエストを単純にログに記録します。後で、収集したデータを分析して疑わしいアクティビティを検出したり、複数のIPを持つユーザーを見つけたりすることができます。これらの分析は複雑であり、実行時に実行しないでください。
ボットを検出するには、収集されたIPに対してDNSの逆引き参照を実行できます。繰り返しますが、これはオフラインで実行できるため、パフォーマンスが低下することはありません。一般に、提供されるページのコンテンツは、訪問者がボットであるか、または理解されていない人間のユーザーであるかによって決まるべきではありません（検索エンジンはそのような行動を不正行為として正当に扱います）。
なりすましが主な懸念事項である場合は、セキュリティが間違っています。ロボットにユーザーよりも多くの権限を与えるべきではありません。まったく逆です（したがって、ユーザーがログインを取得し、ロボットが取得するのはなぜですかrobots.txt）。
認証なしで誰かに特別な特権を与える場合、それは本質的になりすましに対して開かれています。IPはなりすましの可能性があります。サーバーとクライアントの通信はスプーフィングされる可能性があります。等々。
悪意のある動作を分析するためにCookieの追跡に依存している場合は、それを修正する必要があります。悪意のあるユーザーに本人確認を要求することなく、十分に理解できるようにするのは簡単なはずです。
IPは認証の代わりにはなりませんが、Cookieが利用できない場合にグループ化するには十分です。その上、そもそも、より信頼性の高い手段（つまり、要素の組み合わせ）を使用する必要があります。