站点跑了一段時間，收錄數量却卡在一個數字上，新頁面迟迟不见動静。這时候最容易犯的错，是直接去改 meta、堆内鏈，却不知道蜘蛛到底走到哪儿停了。抓取路径巡检的意义，就是先把“没走到”這件事定位清楚，再動手。
第一步：区分“没發現”和“發現了没抓”
打開服務器日誌，按蜘蛛 UA 過滤，把最近 7 到 30 天的记錄按 URL 归類。结果通常分三類：
- 日誌里完全没出現過的 URL——蜘蛛根本没走到，或者走到了但請求被挡在门外（比如被 robots 規則拦住）；
- 出現過但狀態碼異常——404、500、301 循环，這類是路径断了；
- 出現了、返回 200，但内容不是你想让它看到的——比如渲染前是空壳、被登入墙挡住、被模板里的 canonical 指向別處。
這三類問题的修法完全不同。第一類要查入口和内鏈，第二類要查服務器和跳轉配置，第三類多半和前端渲染或模板有關。混在一起改，往往白費力气。
第二步：把三份清單對齐
准备三份名單：日誌里蜘蛛實际抓過的 URL、Sitemap 里提交的 URL、站内連結能到達的 URL（可以從首頁出發爬一遍，或者用站長工具的内鏈报告）。三份名單叠在一起，缺口就出来了：
- Sitemap 有、日誌没有：提交了但蜘蛛没来，通常是優先級或抓取预算的問题；
- 日誌有、内鏈没有：蜘蛛是從別處（外鏈、Sitemap、歷史记錄）進来的，頁面在站内其實是孤岛；
- 三份都没有：這個地址在系統里根本没被当成一個可訪問頁面，检查一下它是不是只在 JS 里拼出来的。
提示：日誌里同一路径带不同參數、大小寫、末尾斜杠的记錄，先归並再統計，否則缺口看起来會比實际大很多。
第三步：沿着路径往回找断点
確認某個重要頁面没被抓之後，往回倒推：谁應该連結到它？
- 找到它應该出現的列表頁、栏目頁或詳情頁；
- 看那個頁面的源碼里是否真的有可点击的 a 連結——注意是渲染前的 HTML，不是浏览器里看到的最终效果；
- 確認這條連結没有被 nofollow、没有被 JS 事件拦截、不依赖用戶点击才出現；
- 再看那個上級頁面本身有没有進過日誌。如果上級都没被抓過，問题在更上一层。
這样一层层往回走，通常能在三到四层内找到断点。很多“深层頁面不被抓”的案例，根因其實是中間某個栏目頁返回了 302，或者被 robots.txt 里一條過宽的規則挡住了。
容易被忽略的两個断点
- 入口頁本身：首頁、频道頁如果响應慢或经常返回 5xx，蜘蛛會降低来訪频率，整條路径的抓取都會跟着變慢。
- 列表分頁的尾頁：分頁連結如果只保留“下一頁”，蜘蛛很难走到後面几頁，靠後的條目自然長期不被發現。
第四步：修复要有先後顺序
断点找到之後，不要一次改几十處。按影响面排序更有效：
- 先修服務器和狀態碼問题，返回 200 是路径能走通的前提；
- 再修枢纽頁的内鏈，让連結出現在渲染前的 HTML 里；
- 然後處理孤岛頁面，把它們接進現有的導航或列表；
- 最後才考虑 Sitemap 的补充和調整。
Sitemap 是辅助發現的手段，不是替代内鏈的。一個頁面如果在站内完全無法通過連結到達，僅靠 Sitemap 提交，被蜘蛛稳定抓到的概率會打折扣。
巡检的节奏
不用天天看日誌。新目錄上线、改版、迁移域名這類動作之後做一次全面對齐，平时保持每两到四周看一次關键目錄的抓取覆盖即可。重点盯两類數字：重要頁面的抓取命中率，以及抓取總量里被浪費在參數頁、重复頁上的比例。前者偏低說明路径不通，後者偏高說明蜘蛛在绕圈。
把這些记錄留下来，下次改版时會比任何猜测都有用。