已发现但未编入索引：该检查什么，怎样推进修复
从 Search Console 状态出发，核实 URL、分组排查访问与发现路径，把未收录问题变成有证据、负责人和复查方法的任务。
这个状态告诉了我们什么
“已发现 — 尚未编入索引”表示 Google 已经知道这个 URL，但尚未抓取。它与“已抓取 — 尚未编入索引”不同，后者已经发生过抓取。把状态当成排查起点，不要直接当成某一种原因的证明。Google 页面索引报告说明。
先判断这是不是你希望出现在搜索中的页面。核心产品页与筛选产生的重复 URL，不应该直接进入同一份修复清单。下面是 Meridian 的实际排查方法，结合所引 Google 文档整理，资料核对日期为 2026 年 9 月 11 日。文中的场景是演示，不是客户实测结果。
先核实 URL 和当前证据
在 Search Console 的 URL 检查工具中输入完整地址，记录资源、URL、报告状态、检查日期和已有的最后抓取信息。将索引中的记录与实时测试分开：两者回答不同问题。实时测试通过，不等于页面已经被收录。URL 检查工具说明。
为一个页面先建立一条记录：
- 受影响的完整 URL，以及预期的最终 URL。
- 页面用途：产品、服务、文章、类目，还是重复或工具性页面。
- 发布时间，以及最近一次实质性修改时间。
- 报告状态、观察日期和证据链接或截图。
- 已做过哪些检查，还缺什么权限。
最后抓取时间为空，就如实记录为空。页面存在重定向时，同时记录请求地址和最终地址。如果同事看到不同结果，先核对地址、时间和检查类型，再讨论原因。
先分组，再决定怎么修
按模板和发布时间选取少量代表性样本；条件允许时，从相同页型中各选一个异常页面和已收录页面。抽样用于诊断，不能直接当成全站问题比例的统计估计。
| 页面组 | 有用的对照 | 要回答的问题 |
|---|---|---|
| 新发布的商业页面 | 相同模板的旧页面 | 新的发布路径发生了什么变化？ |
| 整个语言目录 | 其他语言的对应页面 | 链接、URL 规则与语言信号是否一致？ |
| 生成页面或参数 URL | 预期的规范页面 | 是否值得作为独立搜索入口存在？ |
| 单篇文章 | 相近且已收录的文章 | 问题只出在这一页，还是整个模板？ |
优先看能回答真实客户需求、且有明确下一步动作的页面。未收录 URL 数量更多，不自动代表情况更差；先看这些 URL 到底是什么。
检查访问、发现路径和目标页面
预期页面能否正常访问？
检查响应及重定向链。与主机或开发团队调查错误、超时和可用性问题。访问不稳定时，将观察时间与日志、Search Console 抓取信息对照；浏览器成功打开一次，只是一条观察。Google 抓取问题排查指南。
分别检查 robots 规则与索引指令。robots.txt 用于控制抓取，不能代替 noindex；Google 必须能够获取页面，才能看到其 noindex 指令。不要为了减少报告中的异常数量，随意解除私有页面、测试环境或工具性页面的有意限制。Google noindex 说明。
首选 URL 的信号是否一致？
把最终地址、声明的 canonical、内部链接和站点地图放在一起检查。canonical 是一种信号，Google 不一定按声明选择。重复页面应先确定哪一个版本代表这份内容。规范 URL 指南。
是否存在合理的发现路径？
从导航、主题页或相关内容中找到一条可抓取的相关链接，检查实际落点。站点地图可以帮助发现，但列入其中不保证被抓取或收录。站点地图说明。
大型生成式网站还应结合 URL 清单的规模、价值和服务器承载情况检查。不能仅凭这个状态就断定抓取预算不足。在证据能够连接起来之前，分别记录抓取信息、服务器证据和内容判断。
把排查结果变成一项任务
**演示场景：**一个新服务页已进入站点地图，但站内唯一入口仍指向旧 URL，而旧 URL 又跳转到别处。其他服务页使用了统一的导航路径。
这支持一次内部链接修正，但不能证明它是 Google 尚未抓取页面的唯一原因。一条有用的任务记录可以这样写：
| 字段 | 示例记录 |
|---|---|
| 观察 | 服务导航指向过时的目标地址 |
| 证据 | 请求 URL、重定向落点，以及链接实际 href |
| 建议动作 | 将相关导航链接更新为预期服务 URL |
| 负责人 | 网站开发或 CMS 编辑 |
| 技术验收 | 链接直达目标页面，响应、canonical 与站点地图一致 |
| 搜索跟进 | 后续重新检查并记录 Google 是否抓取或收录 |
| 遗留不确定性 | 尚未排除其他抓取、质量或网站级因素 |
可以下载索引排查工作表，为自己的页面建立记录。若想看我们实际做过的 URL 一致性工作，可以查看 Meridian 审计发现与复查示例。该示例证明技术调整的过程，没有声称解决了这一特定 Search Console 状态。
先验证改动，再跟踪搜索结果
实施后重复最初发现问题时的检查，把修改前证据、修改日期、负责人和复查结果放在一起。技术验收通过，代表这项任务完成，不代表所有未收录原因都已排除。
需要时，对重要的已修改页面申请索引，或为更大的一组页面提交更新的站点地图。Google 说明，抓取可能需要数天到数周；反复申请不会加快抓取，申请本身也不保证进入搜索结果。重新抓取说明。
与团队约定下一次观察日期，到时记录新状态：仍为已发现、已抓取但未收录，还是已收录。不要预设一定改善；状态改变时，下一步调查方向也可能需要调整。
什么时候适合做技术审计
当问题跨越多个模板、影响重要商业页面、原因仍不明确，或可能的修改分别由不同团队负责时，可以考虑有明确范围的技术 SEO 审计。带上 URL 样本、已完成的检查，以及可用的 Search Console 或日志权限。
如果已经知道怎么修，只是需要持续协调开发和检查发布，可以了解持续技术 SEO 支持。下一步取决于你需要的是诊断、已知问题的实施支持，还是持续复核。
常见问题
每个 URL 都应该被收录吗？
不是。先明确哪些规范、面向客户的页面应该成为搜索入口。重复或有意排除的页面，与重要页面意外未收录，需要不同的处理决定。
实时测试成功，就代表问题解决了吗？
它只说明当时检查到的项目。要与 Google 保存的索引状态、页面是否获得有效搜索访问分别记录。
要不要不停重复提交同一个 URL？
反复提交没有变化的地址不是诊断。应记录状态、调查证据、完成有依据的改动，再跟进观察。
