發現入口不止一條
Sitemap 提交的是站点主動声明的入口，内鏈反映的是編輯已经建立的联系。两者之外還有一批頁面：編輯忘了加内鏈的、由程序按模板生成但没進 Sitemap 的、只有订阅者或站内检索才能触達的。這些 URL 並非不可發現，只是發現路径依赖另外几類入口。核對时不妨先問一句：這個地址除了直接訪問，還有哪些地方寫着它。
RSS 與 Atom 订阅源
订阅源本身就是一份天然的新 URL 列表，通常只放最近若干條，结构简單，解析成本低。它不是 Sitemap 的替代品，但在内容频繁更新的站点上，订阅源的刷新往往比 Sitemap 更及时，蜘蛛顺着它走一圈就能碰到最新頁面。
核對要点
- 輸出绝對地址，不要依赖相對路径和頁面上下文来补全。
- 只保留正文頁面，避免把标簽頁、作者頁、分頁混進條目。
- 更新节奏與發布节奏一致，長期空置的订阅源會逐渐失去發現價值。
- 確認订阅源本身没有被 robots.txt 誤屏蔽，否則连這條路径也一起断掉。
站内搜尋與聚合列表頁
标簽聚合、专题列表、搜尋结果的固定组合頁面，都能承载大量連結，是补充發現路径的常见做法。風險在于參數组合爆炸：一旦蜘蛛開始抓取带 query 的搜尋地址，容易生成大量内容重复、價值偏低的頁面，占用抓取资源，也會让日誌變得难以阅讀。
處理思路
- 對動態搜尋參數頁做 noindex，但不必一律在 robots.txt 中屏蔽——屏蔽之後頁面上的連結也一並不可见，可能把正常的發現路径一起切断。
- 把稳定的聚合入口（固定标簽頁、专题頁）與動態搜尋頁分開處理，前者可以当作正式入口，後者只做 noindex。
- 分頁列表保留可抓取的下一頁連結，不要只依赖点击後异步加载。
接口與 JSON 輸出的連結
前端通過接口取數再渲染連結时，HTML 里可能根本没有 a 标簽。蜘蛛不會主動去請求這些接口，自然也就看不到其中的地址。如果希望這批内容被發現，需要服務端渲染出可解析的連結，或者把它們寫進 Sitemap 與订阅源。
判断标准很简單：查看頁面源代碼时能不能看到完整的 href。看不到，就不要指望蜘蛛顺着它走。
核對這些入口是否真的生效
- 在服務器日誌中篩選订阅源地址與聚合頁地址的請求记錄，看蜘蛛是否定期来訪。
- 對比订阅源條目與 Sitemap 條目，找出只出現在其中一邊的地址，判断是否有意為之。
- 利用抓取日誌里的 referer 字段，反推蜘蛛是從哪個頁面到達目标地址的。
- 抽查接口渲染的頁面，確認源代碼中存在可解析的連結。
- 记錄新内容發布後各類入口的更新時間和被抓取的時間差，找出延迟最大的那一环。
容易踩的坑
- 把订阅源当成萬能提交工具，只堆地址不看内容质量，效果通常有限。
- 站内搜尋頁全量開放，導致大量參數地址進入抓取队列。
- 聚合頁内容由前端异步加载，頁面源碼里只剩一個空容器。
- 多個入口輸出的地址寫法不一致，带不带尾斜杠、大小寫不同，把同一個頁面拆成几個入口。
這些补充入口的作用是让發現路径更均匀，而不是替代基础建设。真正决定抓取效率的，仍然是站点结构的清晰程度、内鏈的可靠性和服務器响應的稳定性。入口核對做完之後，還是要回到日誌里看實际發生了什么。