很多人排查收錄問题时，第一反應是“蜘蛛不来抓”。但更常见的情况其實是：這個 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 有没有被知道，日誌通常能给出答案；知道之後的事，才轮到抓取和索引去解决。