为什么页面没有被收录？一份实用诊断清单

1. 记录准确 URL 与观察结果

复制预期被收录的完整地址，包括主机名、路径及有实际意义的参数。记录日期、触发调查的证据，以及这是新发布、已更新还是迁移后的页面。英文 URL 和对应中文 URL 应分别检查。

在 Search Console 中检查这一准确地址。区分 Google 保存的索引信息和对当前页面执行的实时测试；实时测试不能证明页面已经收录。记录可用的排除原因、上次抓取时间和所选规范页。Google 对这些检查字段有具体说明。

搜索某个 URL 可以提供观察线索，但不应代替诊断。如果报告还没有反映近期变更，应记录这种不确定性，而不是立即重写文章。

2. 检查响应与最终目标

请求页面并检查重定向。最终是否到达预期内容，还是登录界面、统一首页、验证页面、缺失提示或服务器错误？保存最终 URL 和状态码。即使状态为 200，如果正文是错误信息，仍然需要调查。

分别检查规范主机和真实语言路径。历史地址应当重定向时，既检查跳转，也检查目标。我们的域名重建报告说明，/?news/78.html 这类带字面查询段的地址为什么需要单独测试。

还要检查托管层控制。从自己的电脑请求成功，并不能证明真实搜索爬虫可以通过防火墙。条件允许时使用官方检查与服务商日志；仅更改 User-Agent 字符串不足以验证爬虫身份。

3. 区分抓取与索引许可

把真实规则放入Robots.txt 规则测试器。它只检查粘贴的输入，不读取响应头或线上配置。Google 需要访问页面才能看到其中的 noindex，因此禁止抓取不能替代索引控制。查看 noindex 文档。

4. 对照声明的偏好与 Google 的选择

分别记录页面声明的 canonical 和检查报告中的 Google 所选规范页。两者不一致时，应调查相似 URL 集合，而不是随机增加另一个标签。参数、其他主机、重定向和不一致的内链，都可能让意图变得不清楚。

Canonical 是偏好信号，不是保证被采用的命令。Google 将重定向、canonical 标注与站点地图列为不同强度的信号。核对规范化指引。

对于英中语言对，通常应从每个完整版本的自引用 canonical 和双向语言标注开始。可用Hreflang 生成器准备一致的映射，再检查部署后的 HTML。已生成标签并不能证明翻译等价或远程 canonical 正确。

5. 先看报告原因，再审查内容

页面索引报告区分多种排除原因，例如已发现但尚未编入索引、已抓取但尚未编入索引。这些代表不同阶段。应结合报告解释与单页检查，而不是把所有排除都归因于 robots。查看报告说明。

检查通向页面的站内路径。读者能否从相关主题或文章找到它？规范地址是否在站点地图中？它是否提供了超出近似重复页的说明？如果只是重复另一篇指南的答案，应先决定改善或合并，而不是增加 URL 数量。

内容需求生成器可以帮助明确尚缺的读者决策和证据。摘要预览工具适合在内容完善后编辑展示形式。它们都不能诊断 Google 的索引系统，也不会提供保证收录的办法。

6. 进行具体修改，并保存结果

写一份简短变更记录：观察到的问题、证据、选定修复、部署时间及后续检查方式。先解决明确限制，再考虑其他段落。上线后核对真实响应，并在适用情况下执行官方实时检查。

Google 在适用的检查流程中提供申请编入索引的操作，但申请不意味着保证纳入，也没有即时完成的承诺。不要把反复提交未改变的 URL，当作解决报告问题的替代品。

记录三个状态：技术变更已上线；搜索引擎已处理或重新抓取；预期 URL 已收录。其中一些状态可能暂时未知。这样比把部署成功直接报告成收录恢复更准确。

下载证据记录清单

下载 Markdown 诊断清单

这是空白工作材料，不是对你网站作出的报告。它要求记录准确 URL、报告日期、响应、robots 结果、指令、规范页、内链、修改和跟进。对外分享时，不要包含敏感账户或客户信息。

如果问题来自有意进行的迁移，请继续阅读历史 URL 案例。如果是规则匹配问题，请使用可复现的 robots 示例。