发送 canonical 链接标头，而不是 noindex 标头。
发送 canonical 标头可能与发送 noindex 标头在爬网预算方面具有相同的优势——而不会因排除可能通过 noindex 拥有反向链接的网址而产生 SEO 影响。
如果您可以配置服务器，则可以使用 rel=“canonical” HTTP 标头（而不是 HTML 标签）来指示文档的规范 URL，该文档由 Search 支持，包括 PDF 文件等非 HTML 文档。
我们可以配置我们的服务器。使用 rel="canonical" HTTP 标头而不是 HTML 标签 是否强调了对 HTTP 标头解决方案的偏好？来自 #11553
Googlebot 对 no-index 标头处理得非常优雅。它建议尽可能多地保持路由开放，并使用标头进行关于索引的高保真规则。
也许 Google 对 canonical 链接标头的处理与对 no-index 标头的处理同样优雅。
我在这方面遇到困难，阅读谷歌的建议，似乎它并不特别在意。
rel="canonical"HTTP 标头的建议与rel="canonical"link标签的建议相同。
我猜没什么可失去的，而且 noindex 和 rel canonical 的组合可能是谷歌的正确做法。但我不太确定。
@Falco ？
这将把最近引入的站点设置回滚到基本上无操作（将我们发送的内容移到报头中的 head 标签，没有语义更改）。
我不希望进行此项更改。
对于新的默认设置 SiteSetting.allow_indexing_non_canonical_urls = false，目前的实现方式如下，并且将保持不变：
noindexcanonical (可能会被忽略)没有补丁且 SiteSetting.allow_indexing_non_canonical_urls = true 时：
canonical有补丁且 SiteSetting.allow_indexing_non_canonical_urls = true 时：
Link: <https://forum.example.com/t/test-example/1234>; rel="canonical"canonical (可能会被忽略 - 但无论如何与 header 相同)这样做的整个想法是：
将 canonical 设置为 http-header，以获得与 noindex http-header 相同的优势——即更快的抓取。
这样可能会使 noindex 及其不确定的含义变得过时。
关于 noindex 与 canonical 的另一点：
noindex 是一个非常强烈的信号，表示不将页面放入搜索索引。noindex 时，页面内容仍会被 Google Bot 处理以提取链接（有一个额外的选项 nofollow 可以禁用此功能）。canonical 是一个强烈的信号，表明要抓取的内容位于某个其他规范 URL 上。这是一个*‘思想实验’*。它没有在任何地方实现——我从不建议实现它：
noindexnoindex (代替：html link-tag canonical)– 或者 –
noindex为什么或者为什么不这样实现？
此更改并非“无操作”：
Google 可能会在其处理队列的不同阶段处理标头和 HTML 内容。通过发送标头，我们可能会跳过进一步的处理队列（例如渲染队列），从而为更重要的页面节省抓取预算。
（我找到的处理队列的唯一图表：Understand JavaScript SEO Basics | Google Search Central | Documentation | Google for Developers
noindex 更改最近已回滚：
请重新审视此 PR：
虽然不是强烈反对，但这感觉太小了。谷歌现在总是下载内容，我怀疑保存 HTML 解析是否真的能带来实质性差异。
还有很多其他领域需要关注，微数据可能是最需要关注的地方。
