未收录页面：包含链接检查的决策树
搜索控制台提供两个相似但成因不同的标签。请按顺序浏览各个分支，并在匹配的第一个分支处停止。
ArchiLinks 研究团队 ·
“已发现，当前未收录”意味着 Google 知道该 URL 但尚未抓取它。“已抓取，当前未收录”意味着它已抓取该页面但决定不收录。前者主要关乎优先级和发现机制，后者则关乎页面本身的质量。
为什么链接是诊断的关键
团队通常将收录问题视为纯粹的技术问题，这往往没错。然而，有一个信号很容易被忽视。
当你发现指向未收录 URL 的外部链接时，你可以了解外部站点是否为其背书。如果一个页面既没有内部链接也没有外部链接，Google 几乎没有理由在其抓取时间或收录空间中分配资源给它。
拥有几十个薄页面且站点地图扁平的站点很常见，应作为首要检查对象。
完整的链接调用请参阅 API 脚本；对于即将迁移的部分，迁移检查清单 将收录检查安排在 T+1 周。Bing 和 Yahoo 的表现可能与 Google 不同，因此请单独测试它们，并考虑自 2021 年推出以来 Bing 的 IndexNow 服务。
决策树
1. 页面是否被屏蔽或设置了 noindex？
在搜索控制台中检查 URL。查看渲染后的 HTML、HTTP 标头和 robots.txt。遗留自测试环境的 noindex 通常是罪魁祸首。如果是，请移除它并请求收录。
2. Google 是否选择了不同的规范链接？
将用户声明的规范链接与 Google 选择的规范链接进行比较。如果它们不同，在 Google 看来该页面是重复或近重复页面。合并、差异化处理或接受它。
3. 页面是否可从实际栏目访问？
统计来自已收录页面的内部链接。如果少于两个，或仅来自站点地图，则意味着发现机制薄弱。从中心页面添加链接。
4. 该页面是否有外部链接？
检查该 URL 的 toppages 和 backlinks。如果有其他域链接到它，请先修复内部链接，并预期收录速度会加快。如果没有，该页面必须通过内容来赢得收录机会。
5. 该页面值得保留吗？
薄页面、模板化页面或基于参数的页面通常是有目的被排除的。合并、设置 noindex 或删除。不要在抓取预算上浪费精力争论。
每个分支通常指向什么
| 发现 | 典型原因 | 操作 | 见效时间 |
|---|---|---|---|
| noindex 或 robots 屏蔽 | 测试环境规则发布到生产环境 | 移除并请求收录 | 几天到几周 |
| Google 选择的规范链接不同 | 重复页面、参数、薄变体 | 合并或重写 | 几周 |
| 内部链接少 | 孤立页面或深层页面 | 来自中心页面和站点地图的链接 | 几周 |
| 存在链接但未收录 | 内容被判定为低价值 | 改进内容，保持重定向或规范链接的准确性 | 一到两个月 |
| 大量页面受影响 | 全站质量或结构信号 | 在提交更多内容之前进行修剪和合并 | 几个月 |
当收录数量急剧下降时
收录量从数万骤降至几十是一个事件，而非趋势。首先查看日期。将其与你自己的发布记录进行比较，因为模板更改或共享组件上的 noindex 标志通常能解释大多数突然下降。
然后进行抽样。从下降前取五十个 URL，从下降后取五十个 URL，查看每组的收录状态、规范链接和内部链接。模式通常会在总数显示之前就在样本中显现。
已收录但被 robots.txt 屏蔽
URL 可能显示为已收录，但 robots.txt 屏蔽了抓取。Google 可以通过链接知道该地址并将其列出，但不会读取内容，因此该列表很单薄，通常没有描述。如果你希望页面根据内容进行评估，请取消屏蔽该路径；或者保持屏蔽并接受该裸条目。
检查匹配该 URL 的规则。为测试路径编写的宽泛模式可能会意外捕获实时产品文件夹，修复方法是使用更窄的行，而不是第二个文件。
为什么站点地图条目会等待，而手动请求不会
手动请求的 URL 可能在几天内被收录，而仅列在站点地图中的相同 URL 则保持未收录。这种差距通常反映的是抓取优先级而非页面质量。请求会将页面移到队列前面，而站点地图条目则在队列中等待。
持久的修复方法是一样的。从已被抓取的页面链接到该页面，并保持站点地图中没有过时条目，这样两条路径都指向同一个 URL。
在请求收录 URL 之前
- URL 返回 200 状态码并显示真实内容，而不是外壳或加载指示器。
- HTML 或响应标头中没有 noindex。
- 规范链接指向 URL 本身，或指向你有意选择的版本。
- 至少有一个内部链接来自已收录的页面。
- URL 列在站点地图中，且站点地图中没有过时条目。
- 你有一条简短的说明，解释为什么该页面应该被收录。
阅读 site: 结果和实时测试
site: 查询显示运行查询时 Google 索引中的内容。它是一个快照。在页面报告中可见但 site: 查询结果为空，是再次检查的理由，而非最终结论。
URL 检查及其实时测试回答了一个更狭窄的问题：Google 现在能为一个地址抓取和渲染什么。用它来区分抓取或渲染问题与质量问题。
运行 site: 查询而不自欺欺人
使用确切地址运行 site:，然后使用页面中的唯一短语再次运行。对于实时页面，两个空结果通常意味着 URL 未收录，或者它已在其他规范链接下收录。在假设其他情况之前，先检查规范链接。
没有摘要的结果与完全没有结果是不同的状态。注意你看到的是哪一种，因为每种情况的修复方法不同。
比较声明的规范链接和选定的规范链接
在已收录页面上打开 URL 检查，并将你声明的规范链接与 Google 选择的规范链接进行比较。不匹配意味着 Google 选择了另一个页面作为此内容的代表。这个选择对你来说可能是正确的也可能是错误的，所以在做任何更改之前决定它是哪一种。
如果渲染版本为空，则问题出在构建过程中，而不是索引中。JavaScript 链接审计 涵盖了这种情况。
大规模运行检查
手动检查几百个 URL 只能做一次。定期检查需要来自脚本的状态、规范链接和链接数据，以及一个记录每次运行历史的文件。
从已经吸引外部链接的 URL 开始。在主机上运行 toppages，以便找到值得检查的外部链接指向的网站部分，然后将该列表与“未收录”导出进行比较。重叠部分是首先修复的组。外部站点已经指向这里。
每个 URL 应记录什么
为每个 URL 存储一行数据，包括其状态码、声明的规范链接、Google 选择的规范链接、来自已收录页面的内部链接数量以及链接域的数量。五列足以将列表分类为需要不同工作的组。
在行动之前对组进行排序。具有外部链接、错误规范链接且无内部路径的 URL 需要不同的修复方法，而仅仅新创建的 URL 则不同，将两者混合会在错误的问题上浪费一个冲刺周期。
保留每次运行的文件。两次运行之间的变化显示修复是否有效，而单个快照无法告诉你这一点。
保持请求队列简短
将手动收录请求限制在具有外部链接且规范链接清晰的组。这些页面最有可能快速收录，如果它们保持未收录状态，则价值最大。
具有冲突规范链接或薄内容的页面应列入单独的合并列表。反复请求它们只会增加队列中的噪音，且不会提供新信息。
收录问题
- 新页面需要多长时间才能出现在索引中？
- 从几小时到几周不等。拥有强大内部链接的成熟站点可以在几天内看到新 URL。新站点通常等待时间更长。如果四周内没有出现问题信号，则不必惊慌。
- noindex 会影响抓取预算吗？
- 带有 noindex 的页面仍会被抓取以查看标签，尽管 Google 往往会减少抓取频率。对于 URL 数量低于数万的大多数站点，抓取预算不是你应该担心的限制。
- 外部链接有助于页面收录吗？
- 它们有助于发现并显示页面受到外部关注。但它们不能强制收录。薄页面或重复页面仍可能被排除。
- 在搜索控制台中请求收录是修复方法吗？
- 这是一个提示，而非治愈。如果根本原因是规范链接冲突、内容薄弱或缺乏内部链接，页面往往会再次掉出索引。
