そのため、サイトには、/ blog / tag / tag_name /という形式のリンクを生成するタグクラウドがあります。 タグはユーザー定義であるため、ほとんどすべてのUTF-8文字を含めることができます。 さらに、そのようなページ(特定のタグによるトピックを含む)には、他のサイト/ソーシャルネットワーク/フォーラムからのリンクが定期的に配置されます。 多くの場合、URLエンコード方式の違いにより、これらのリンクは標準ではないページにつながります。
例を挙げましょう。 Harry Potterタグがあり、エンコードされた形式では、Harry + PotterまたはHarry%20 Potterのいずれかです。 サイトには、両方のオプションへのリンクがある場合があります。 しかし、サイトエンジンの場合、REQUEST_URIがデコードされると、これらのリンクは完全に同一になります。これは、重複するページがあり、検索エンジンが本当に嫌いだからです。 これらの重複に対処するために、ページを読み込むときにURLをデコードし、PHP関数urlencode()を使用してエンコードし直し、元の要求された文字列と比較します。 一致しない場合は、ブラウザに301番目のコードを指定し、正しいURLに送信します。 したがって、検索エンジンの目には重複したページが「密着」します。
すべてが非常に単純なようです。 Googlebotがこれらのリンクの一部にハングアップしたのはなぜですか? 幸い、GWTには特別な機能があります-「View as Googlebot」を使用すると、検索ボットの目を通してサイトを見ることができます。 さて、試してみてください。 この例では、「guns'n'roses」という別のタグを使用します。 そのため、ボットにページ/ブログ/タグ/ guns'n'roses /を読み込むように指示します。 ボットは、すべてが正常であると答え、答えを受け取ります。
HTTP/1.1 301 Moved Permanently ... Location: /blog/tag/guns%27n%27roses/
そうです、 RFC 3986による単一引用符は %27としてエンコードされます。 OK、ボットをURL /ブログ/タグ/ guns%27n%27roses /に誘導しようとしています(通常のブラウザのように)。 応答として、次のものを取得します。
HTTP/1.1 301 Moved Permanently ... Location: /blog/tag/guns%27n%27roses/
そして一見したところ絶対に公平な発言:「それ自体へのリダイレクトがページで見つかりました。 これにより、無限のリダイレクトサイクルが発生する可能性があります。」
しかし、サーバーのログでは、実際にリクエストが再度行われていることがわかります。明確に指定された「GET / blog / tag / guns%27n%27roses」ではなく、「GET / blog / tag / guns'n'roses / HTTP / 1.1」 / HTTP / 1.1。」 Googlebotは独自の方法でLocationディレクティブの意味を解釈し、RFCを吐き出し、それ自体と私のサイトを無意味なクエリで苦しめた。
さらにグーグルは、グーグル検索ボットが次の記号に対して特別な同情を持っていることを発見するのを助けました。
, @ ~ * ( ) ! $ '
それらを対応するコードに変換しません
%2C %40 %7E %2A %28 %29 %21 %24 %27
本当にあなたの神経を台無しにし、すでに拷問されたウェブマスターを時間を浪費することができるもの:)