在索引报告里，“已发现，但尚未编入索引”是一个很容易引起误判的状态。看到“已发现”三个字，很多人会理解成“马上要收录了，等几天就行”。实际上它只说明一件事：蜘蛛已经知道这个 URL 存在。知道在哪里，和去不去抓、抓了收不收，是后面两步的事。
先把两种状态分开看
已发现，尚未编入索引
URL 被蜘蛛登记在待抓取队列里，但还没有真正请求页面。常见来源是 sitemap、站内链接、外链，或者历史抓取记录。这类页面的问题通常不在内容质量，而在抓取调度：站点的抓取配额被分给了别的页面，或者这个 URL 的优先级排得太靠后。
已抓取，尚未编入索引
蜘蛛已经访问过页面，拿到了内容，但判断它不值得进索引。这时候再等下去意义不大，问题多半在页面本身：内容太薄、和站内其他页面高度重复、正文依赖脚本渲染但渲染不出来，或者页面自己通过 noindex、canonical 把自己排除掉了。
分不清这两类，处理方向就会完全跑偏。前者要调抓取优先级，后者要动页面。
“已发现”之后为什么迟迟不抓
- 抓取配额有限。站点能承受的抓取量不是无限的，蜘蛛会按页面重要性分配。低优先级页面排队很久是正常的。
- 一次性上线太多新 URL。比如批量生成几万个标签页或筛选页，队列瞬间被撑满，真正想收录的页面也被挤在后面。
- 内链太浅或根本没有内链。页面只出现在 sitemap 里，站内没有任何入口，蜘蛛自然把它当次要目标。
- 服务器响应慢或错误率高。大量超时、5xx 会让蜘蛛降低抓取频率，整个站点的抓取节奏都会被拖慢。
“抓了却不编入”通常卡在哪
- 正文只有几句话，或者大段是模板、导航、推荐位，实际信息量很低。
- 与站内其他页面内容高度重合，比如同一批商品的不同排序结果。
- 主要依靠前端脚本渲染，蜘蛛执行脚本后拿到的仍是空壳。
- 页面上的 canonical 指向了另一个 URL，等于主动声明“别收我”。
建议的排查顺序
- 先确认状态属于哪一类，不要混在一起处理。
- 抽几个典型 URL，看蜘蛛实际抓到的内容和你看到的页面是否一致。
- 检查这些 URL 有没有站内入口，入口在几层之内。
- 盘点近期新增的 URL 类型，把明显没有检索价值的形态先控制住。
- 看服务器日志，确认蜘蛛实际抓的是哪些页面，而不是只看报告数字。
- 做完结构调整后，给它一段时间观察，不要每天改动页面期待立刻变化。
把“被发现”当成“会被收录”，是收录类问题里最常见的误判。发现只是排队，收录是一次判断。
几个常见做法上的偏差
频繁提交 sitemap、反复修改标题、每天手动请求抓取，这些动作本身不会提升页面价值。如果页面所处的层级、内容质量和站内结构没有变化，状态也不会变化。反过来，把低价值 URL 的产出减下来，把内链集中到真正希望被收录的页面上，往往比反复催促更有效。
收录不是开关，而是站点资源分配的结果。蜘蛛愿意抓、抓了之后愿意留，取决于页面值不值得。与其盯着状态数字，不如先确认每一类 URL 的存在理由是否站得住。