robots.txt、noindex 与 canonical：分别解决什么问题？

从期望结果开始

此表用于开始调查，不是可直接套用的通用发布配置。先明确准确 URL、预期访问者和目标搜索系统。用于归档或筛选页的策略，不应意外覆盖希望读者找到的文章。

修改前，保存当前 HTTP 响应、相关 HTML 和观察到的索引状态，再写出可检查的目标。例如：“此公开确认页应继续允许访客访问，但不进入 Google 索引。”这比“优化 robots”更具体，也更容易判断工作是否完成。

robots.txt：关于抓取的约定

Robots 规则告诉遵守协议的爬虫，哪些路径可以抓取。它不会验证访客身份，而且文件本身可公开读取。如果 Google 通过链接知道某个 URL，即使没有抓取正文，也可能展示该地址。Google 的 robots 介绍说明了这些限制。

说明性场景：出版网站希望减少无帮助筛选模式的抓取，同时保留文章。先列出应该允许和禁止的示例 URL，明确目标爬虫，再把规则粘贴到Robots.txt 规则测试器。工具不会检查真实防火墙，也不能证明搜索结果已移除。

规则组选取、通配符和匹配行的具体操作，请阅读可复现的 robots 测试教程。这里需要先决定的是：真正目标是否为限制抓取？如果内容敏感，应使用访问保护，而不是在公开 robots 文件里列出其位置。

noindex：必须能被读取的索引指令

如果 HTML 页面应继续可访问，但不希望进入 Google 索引，可以在 head 中配置相关指令：

<meta name="robots" content="noindex">

也可以通过 HTTP 响应头配置，包括非 HTML 资源：

X-Robots-Tag: noindex

这里是正文中的转义代码示例，不是对本指南生效的指令。Google 必须取得 URL，才能看到 noindex。如果 robots.txt 禁止抓取，它可能始终读不到该指令。核对 noindex 的前提。

说明性场景：公开活动确认页不适合作为搜索落地页。先确认爬虫能够请求页面，再检查实际 meta 或响应头并记录发布时间。后续通过相应官方报告观察处理。发布成功不代表立即移除，也不要因此给整个网站添加 noindex 响应头。

canonical：相似 URL 之间的首选信号

Canonical 声明为重复或高度相似内容指定首选代表。它是信号，而不是保证 Google 采用该 URL 的命令。重定向、规范标签和站点地图等配置保持一致时，可以共同表达偏好。查看 Google 的规范化指引。

说明性场景：同一文章可以通过干净地址和带营销参数的地址访问。比较正文及预期行为，再让规范声明、内部链接和站点地图与选定地址一致。不再需要的重复页可以调查是否适合重定向。不要把回答不同问题的页面随意指定为 canonical。

英语和中文是另一种关系。本站完整译文通常各自声明 canonical，再提供双向语言标签。英语是主要语言，并不会使中文自动变为英文重复页。请使用完整 hreflang 示例和映射生成器核对语言对。

把组合配置作为整体检查

没有必要对每个 URL 叠加所有可用指令。每次变更都应解释预期行为，以及它与现有模板如何共同生效。如果托管响应头和 HTML 分属不同团队，应检查最终组合响应，再判断各自配置是否正确。

先核对变更，再观察处理

1. 在简短变更记录中填写准确 URL 和期望行为。
2. 保存当前响应、指令与相关官方检查结果。
3. 执行范围明确的修改，核查共享模板的其他页面。
4. 发布后请求最终地址，检查真实返回的响应。
5. 将爬虫处理与索引状态作为后续独立观察记录。

如果症状是页面未出现，请使用收录诊断清单。撰写技术指南前，可以通过内容需求生成器明确读者决策与尚缺证据。这两个工具都不会修改远程网站，也不能代替服务商检查报告。

一份小型带日期日志就能提高可核查性：已选择策略、变更已上线、已观察处理、预期索引状态已确认或仍未知。不要把未知项隐藏，也不要把每一次成功 HTTP 请求都理解成已经收录或已经排除。