发现入口不止一条
Sitemap 提交的是站点主动声明的入口，内链反映的是编辑已经建立的联系。两者之外还有一批页面：编辑忘了加内链的、由程序按模板生成但没进 Sitemap 的、只有订阅者或站内检索才能触达的。这些 URL 并非不可发现，只是发现路径依赖另外几类入口。核对时不妨先问一句：这个地址除了直接访问，还有哪些地方写着它。
RSS 与 Atom 订阅源
订阅源本身就是一份天然的新 URL 列表，通常只放最近若干条，结构简单，解析成本低。它不是 Sitemap 的替代品，但在内容频繁更新的站点上，订阅源的刷新往往比 Sitemap 更及时，蜘蛛顺着它走一圈就能碰到最新页面。
核对要点
- 输出绝对地址，不要依赖相对路径和页面上下文来补全。
- 只保留正文页面，避免把标签页、作者页、分页混进条目。
- 更新节奏与发布节奏一致，长期空置的订阅源会逐渐失去发现价值。
- 确认订阅源本身没有被 robots.txt 误屏蔽，否则连这条路径也一起断掉。
站内搜索与聚合列表页
标签聚合、专题列表、搜索结果的固定组合页面，都能承载大量链接，是补充发现路径的常见做法。风险在于参数组合爆炸：一旦蜘蛛开始抓取带 query 的搜索地址，容易生成大量内容重复、价值偏低的页面，占用抓取资源，也会让日志变得难以阅读。
处理思路
- 对动态搜索参数页做 noindex，但不必一律在 robots.txt 中屏蔽——屏蔽之后页面上的链接也一并不可见，可能把正常的发现路径一起切断。
- 把稳定的聚合入口（固定标签页、专题页）与动态搜索页分开处理，前者可以当作正式入口，后者只做 noindex。
- 分页列表保留可抓取的下一页链接，不要只依赖点击后异步加载。
接口与 JSON 输出的链接
前端通过接口取数再渲染链接时，HTML 里可能根本没有 a 标签。蜘蛛不会主动去请求这些接口，自然也就看不到其中的地址。如果希望这批内容被发现，需要服务端渲染出可解析的链接，或者把它们写进 Sitemap 与订阅源。
判断标准很简单：查看页面源代码时能不能看到完整的 href。看不到，就不要指望蜘蛛顺着它走。
核对这些入口是否真的生效
- 在服务器日志中筛选订阅源地址与聚合页地址的请求记录，看蜘蛛是否定期来访。
- 对比订阅源条目与 Sitemap 条目，找出只出现在其中一边的地址，判断是否有意为之。
- 利用抓取日志里的 referer 字段，反推蜘蛛是从哪个页面到达目标地址的。
- 抽查接口渲染的页面，确认源代码中存在可解析的链接。
- 记录新内容发布后各类入口的更新时间和被抓取的时间差，找出延迟最大的那一环。
容易踩的坑
- 把订阅源当成万能提交工具，只堆地址不看内容质量，效果通常有限。
- 站内搜索页全量开放，导致大量参数地址进入抓取队列。
- 聚合页内容由前端异步加载，页面源码里只剩一个空容器。
- 多个入口输出的地址写法不一致，带不带尾斜杠、大小写不同，把同一个页面拆成几个入口。
这些补充入口的作用是让发现路径更均匀，而不是替代基础建设。真正决定抓取效率的，仍然是站点结构的清晰程度、内链的可靠性和服务器响应的稳定性。入口核对做完之后，还是要回到日志里看实际发生了什么。