很多人排查收录问题时，第一反应是“蜘蛛不来抓”。但更常见的情况其实是：这个 URL 压根没有进入待抓取队列。搜索引擎要先从某个入口知道 URL 存在，才会安排抓取，抓取之后才谈得上是否进索引。“发现”是最靠前的一层，也最容易被忽略。
发现、抓取、索引：三个阶段分开看
- 发现：URL 从某处被知道，比如站内链接、sitemap、外部链接、重定向链、站长平台的提交入口。
- 抓取：调度器派爬虫来请求，服务器返回可用的响应（通常是 200）才有内容可解析。
- 索引：抓到的内容经过解析、去重、质量判断，才决定是否入库、以哪个 URL 入库。
这三步是串联的，但排查时必须分开。日志里没有抓取记录，可能是没被发现，也可能只是排期还没到；日志里已经有抓取记录，说明发现这一步完成了，问题在后面。
URL 通常从哪几个入口被发现
站内链接
这是最稳定也最容易被低估的入口。一个页面只要从首页或栏目页经过少量点击能到达，通常在几轮抓取内就会被发现。反过来，如果页面只藏在很深的列表里，或者链接是 JS 渲染后插入、被属性拦住，发现就会慢很多甚至不会发生。检查方式很简单：在站内用鼠标点，能不能点到它。
sitemap
sitemap 适合批量提交新 URL，尤其是内链结构里位置很深的页面。它的作用是“告知存在”，不是“要求立刻抓取”，也不保证收录。写得干净、URL 规范、状态码正常才有参考价值；如果里面塞了大量 404、重定向或参数变体，反而会分散抓取资源。
外部链接与提交入口
来自站外的链接，尤其是被频繁抓取的页面链接过去，往往能加快发现速度。站长平台的提交入口有类似作用，适合少量、确需尽快让搜索引擎知道的新 URL，不适合当作日常批量手段。
重定向链与 JS 生成的链接
301 指向的目标 URL 可以被发现，但链条越长，传递越慢。JS 里拼接出来的链接，如果不在 HTML 里出现，发现可能延迟，直到渲染环节跑完才被看到。
用服务器日志看“发现”这一步
访问日志里能直接看到爬虫的请求记录：请求路径、User-Agent、状态码、时间、Referer。几个判断要点：
- 日志里出现对该 URL 的请求，说明至少被发现过，接着看返回码和抓到的内容是否正常。
- 日志里始终没有该 URL 的请求，先回到站内链接和 sitemap 检查，而不是急着改服务器配置。
- 看 Referer 或抓取路径，能判断它从哪里找到的页面，帮助定位内链断点。
- 留意状态码：对爬虫返回 403、429 或 5xx，会把抓取卡住，表现上很像“没被发现”。
补充一点：日志不完整是常态。CDN、反向代理、日志轮转都可能丢记录，不要因为某一天没看到记录就下结论，至少观察一到两周。
一个可落地的自查顺序
- 在站内手动找到这个页面，确认链接可点、不是 JS 拼接、没有被属性拦截。
- 检查 robots.txt 是否误挡，页面是否写了 noindex。
- 核对 sitemap 里的 URL 与实际地址是否完全一致，包括大小写、末尾斜杠、参数。
- 用工具或直接请求，确认对爬虫 User-Agent 返回 200，且内容是完整正文。
- 通过站长平台提交该 URL，然后按周观察日志与索引状态，不要每天反复提交。
- 如果日志已有抓取但长期未收录，问题就不在发现层，应转去检查内容质量与重复度。
看起来像“没被发现”，实为别的问题
常见的有：页面返回软 404、正文靠 JS 异步加载而渲染失败、服务器对爬虫做了拦截、同一内容有多个 URL 互相竞争。这些情况下 URL 其实已经被发现，甚至被抓取过，只是结果不理想，改抓取配置没有用。
把“发现”和“抓取”分开排查，能省掉很多无效动作。URL 有没有被知道，日志通常能给出答案；知道之后的事，才轮到抓取和索引去解决。