我想知道搜索引擎是否尊重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”的用途是什么？.
我认为谷歌刚刚宣布了我的问题的答案：声明规范 URL的canonical链接关系。
来自 Google 的Maile Ohye写道：
MickeyC 说...
您应该使用 Content-Location 标头，根据：
http
://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html “14.14 Content-Location”@MikeyC：是的，从理论上讲是有道理的，我们当然考虑过。然而，有几点让我们选择了：
我们的数据显示，许多网站上的“Content-Location”标头配置不正确。有时，网站管理员会提供长而丑陋的 URL，甚至不会重复——这可能是无意的。他们可能不知道他们的网络服务器甚至正在发送 Content-Location 标头。
联系网站所有者以清理整个网络的内容位置问题将非常耗时。我们意识到，如果我们从头开始，我们可以更快地提供功能。与微软和雅虎！板载支持这种格式，网站管理员只需要学习一种语法。
网站管理员通常难以配置其 Web 服务器标头，但可以更轻松地更改其 HTML。rel="canonical" 似乎是一个友好的属性。
大多数体面的爬虫确实遵循 Content-Location。所以，是的，搜索引擎尊重 Content-Location 标头，尽管这不能保证具有 sid 参数的 URL 不会出现在结果页面上。
2009 年，Google 开始研究rel=canonical响应正文中的 URI。
看起来自 2011 年以来，按照 RFC5988 格式化的链接也从 header field 解析Link:。网站管理员工具常见问题解答中也明确提到它是一个有效的选项。
猜猜这是为搜索引擎提供一些额外的超媒体面包屑以遵循的最新方式 - 因此当您实际上不需要将其作为内容提供时，可以让您将它们排除在响应正文之外。
除了使用“位置”而不是“内容位置”之外，根据您的重定向原因，在您的响应中使用正确的 HTTP 状态代码。搜索引擎倾向于支持永久重定向 (301) 状态与临时 (302) 状态。
请尝试使用“位置：”标题。