在抓取统计和索引报告里，“已发现，尚未编入索引”是一个常被误读的状态。它字面上只是说：系统已经知道这个 URL 存在，但还没有把它抓下来，或者抓取动作被排在了很后面。它本身不是惩罚标记，也不代表页面被判了死刑，更多时候反映的是队列顺序和优先级问题。
不过，这个状态和“已抓取，尚未编入索引”是两件事。前者通常卡在抓取之前，后者是抓取已经完成、但内容判断没有通过。处理思路不同，先看清自己面对的是哪一种，后面才不会白忙。
第一步：确认 URL 没有被挡在门外
“被发现”和“可被抓取”是两条独立的线路。一个 URL 可能通过外链或站点地图被记录，但抓取入口被规则挡住，于是长期停在待抓取状态。
- robots.txt：Disallow 会阻止抓取，但不阻止 URL 被发现，所以很容易出现“有记录、没抓取”的组合。
- 返回状态：确认是 200，而不是多跳重定向、403、503 或间歇性超时。
- noindex 信号：检查 meta robots 和 X-Robots-Tag，尤其注意是否有旧配置残留在响应头里。
- 访问门槛：登录、验证码、地区限制、必须依赖 Cookie 才能出内容的页面，抓取端往往拿不到正文。
第二步：看发现路径是否有效
站点地图是最常见的发现来源，但它的作用被高估了。如果 sitemap 里混入大量筛选参数页、重复 URL、低价值分页，抓取队列会被这些地址稀释，真正想收录的页面反而排在后面。
站内链接同样关键。只靠 sitemap 暴露、站内没有任何入口的页面，优先级通常低于从首页几跳之内可达的页面。可以检查这些地址是否真的出现在导航、列表或相关推荐里，链接是否可抓取、有没有被 nofollow 或 JS 事件代替。
第三步：判断抓取预算被什么占用
抓取预算不是一个固定额度，它受站点规模、更新频率、响应速度、页面质量共同影响。新站或权重有限的站点，队列推进慢是常见现象，未必是配置出错。
- 服务器响应慢，或大量请求返回 5xx，会直接拖慢整体抓取节奏。
- 成千上万个低价值 URL 长期存在，会挤占本应留给重要页面的份额。
- 站点长期不更新，抓取端缺少回访理由，队列推进会变慢。
第四步：确认页面是否值得被索引
抓取和索引是两个决策。即使轮到了抓取，内容单薄、与站内其他页面高度相似、缺少独立价值的页面，也可能抓完后再被搁置。这时要处理的是内容本身，而不是继续催抓取。
反复提交站点地图、频繁使用抓取请求，并不会改变索引决策。决定队列顺序的是页面价值和站点整体表现，不是提交次数。
建议的处理顺序
- 抽样几个卡住的 URL，核对状态码、robots.txt、noindex 信号和访问门槛。
- 确认站内是否真的有可抓取入口，别只依赖 sitemap。
- 收敛站点地图，只保留规范 URL 和确实希望被收录的页面。
- 合并高度重复的页面，给内容单薄的页面补充信息或做整合。
- 对少数关键 URL 使用抓取请求，然后到日志里确认是否真的来过。
- 给队列留出几周时间再回看，不要每天改动规则。
大多数“已发现，尚未编入索引”会随着站点整体状况改善而自行推进。真正需要动手的，通常是被规则挡住、发现路径无效、站点地图泛滥这三类问题；把这几项理清，剩下的交给时间。