検索エンジンがHTTPヘッダーフィールドContent-Locationを尊重するかどうか疑問に思いました。
これは、たとえば、URLからセッションID引数を削除する場合に役立ちます。
GET /foo/bar?sid=0123456789 HTTP/1.1
Host: example.com
…
HTTP/1.1 200 OK
Content-Location: http://example.com/foo/bar
…
明確化：
セッションIDを削除すると、リクエストが完全に異なり、応答も異なる可能性があるため、リクエストをリダイレクトしたくありません。同封の回答は、その「メインURL」でも利用できることを述べたいと思います。
たぶん私の例は私の質問の意図をうまく表していないでしょう。では、HTTPヘッダーフィールド「Content-Location」の目的は何ですか？をご覧ください。。
Google はちょうど私の質問に対する答えを発表したと思います: canonical URL を宣言するためのcanonicalリンク関係です。
Google のMaile Ohyeは次のように書いています。
MickeyC は言った...代わりに、次のように Content
-Location ヘッダーを使用する必要がありました
。@MikeyC: はい、理にかなっている理論的な観点から、私たちは確かにそれを検討しました. ただし、いくつかの点により、次のように選択しました。
私たちのデータは、多くの Web サイトで「Content-Location」ヘッダーが不適切に構成されていることを示しています。Web マスターは、重複していない長くて醜い URL を提供することがありますが、これはおそらく意図的ではありません。Web サーバーが Content-Location ヘッダーを送信していることに気付いていない可能性があります。
サイトの所有者に連絡して、Web 全体の Content-Location の問題を解決するには、非常に時間がかかります。白紙の状態から始めれば、より迅速に機能を提供できることに気付きました。Microsoft と Yahoo! この形式をサポートするためにオンボードで、ウェブマスターは 1 つの構文を学ぶだけで済みます。
多くの場合、Web マスターは Web サーバー ヘッダーの構成に苦労しますが、HTML はより簡単に変更できます。rel="canonical" はフレンドリーな属性のように見えました。
ほとんどのまともなクローラーは Content-Location に従います。したがって、はい、検索エンジンは Content-Location ヘッダーを尊重しますが、sid パラメーターを持つ URL が結果ページにないという保証はありません。
「Content-Location」ではなく「Location」を使用することに加えて、リダイレクトの理由に応じて、応答で適切なHTTPステータスコードを使用します。検索エンジンは、一時的な（302）ステータスよりも永続的なリダイレクト（301）ステータスを好む傾向があります。
代わりに「Location:」ヘッダーを試してください。