做蜘蛛池的人常说“让蜘蛛来”，但真正要先解决的问题其实是让蜘蛛知道有哪些 URL 存在。入口页建得再多，如果地址没有被发现，蜘蛛也只能从已有的外链里慢慢爬过来。于是问题就变成了：sitemap 和主动推送这两条路，在蜘蛛池里各自扮演什么角色，又该怎么用。
蜘蛛发现 URL 的几条常见路径
搜索引擎发现新 URL 的方式并不是单一的，通常有几条并行：
- 顺着链接爬：从已收录页面出发，沿着 a 标签找到新地址，这是最传统也最慢的一条路；
- 读取 sitemap：站点主动声明自己有哪些页面，蜘蛛按文件批量发现；
- 资源平台提交：手动提交或通过 API 推送单个或批量 URL；
- 域名层面的历史数据：老域名曾经的结构、外链记录，也会影响发现的起点。
这几条路不是互斥的，实际运行中往往是叠加的。很多蜘蛛池效果不稳定，原因不在于蜘蛛不来，而在于URL 的发现通道太单一——只靠入口页互链，一旦某一环断掉，后面的页面就集体沉底。
sitemap 在蜘蛛池里的正确姿势
sitemap 的本质是“一份 URL 清单”，它不能保证抓取，更不能保证收录，但它能显著降低发现成本。用得好不好，差别主要在这几点。
只放值得被抓的 URL
常见的做法是把所有入口页一股脑塞进去，包括重定向页、带一堆查询参数的重复页、内容空白的占位页。这类 URL 出现在 sitemap 里，等于主动告诉蜘蛛“我这里有大量低质地址”，对整体信任没有好处。
- 只保留返回 200 状态、内容可读的页面；
- 不要放需要 JS 才能渲染出主要内容的页面，除非确认蜘蛛能执行；
- 不要把设置了 noindex 的页面写进去，两边的信号会互相打架；
- 同一内容只留一个规范 URL，参数、大小写、结尾斜杠的变体先做好归一。
分片与更新
入口页数量过千之后，建议用 sitemap 索引文件来管理。行业里常被引用的惯例是：单个 sitemap 文件不超过 5 万条 URL、未压缩体积不超过 50MB，索引文件最多引用 5 万个 sitemap——不同搜索引擎的具体限制可能略有差异，按最小的那个来准备比较稳妥。
更新频率也要贴近实际。入口页是批量生成还是缓慢新增，决定了 sitemap 该多久刷新一次。lastmod 写真实时间比每天全量刷一遍更有意义，后者容易被当成无差别更新。
主动推送值不值得做
推送接口的好处是快：URL 直接进入待抓队列，不用等外链传导。但它有两个现实限制——配额和不保证。配额通常按天计算，量级有限；推送成功只代表“收到了”，不代表会抓、更不代表会收录。
- 适合用于新增的重点入口页，量小、质优、时效要求高；
- 不适合用来冲量。把配额一次性打满，推的又多是同质页面，收益基本等于零；
- 推送前先确认页面能正常访问，否则等于把 404 推给蜘蛛；
- 推送记录最好留档，方便和日志里的实际来访做对照。
几个常见的误区
- 把 sitemap 当收录开关：它只是发现通道，抓不抓、收不收，取决于页面质量和站点整体表现；
- 清单越长越好：数量堆上去但质量跟不上，只会稀释清单的可信度；
- 只推不爬：推送通道顺畅，站内互链却是一团乱麻，蜘蛛进来后照样走不动；
- sitemap 和实际页面脱节：文件里有、线上已经删了，反复出现会拉低判断。
不同规模下的搭配建议
- 入口页几十到几百：一份 sitemap 加 robots 里声明即可，配合正常互链，不需要折腾推送；
- 入口页上千：改用 sitemap 索引加分片，按目录或主题拆分，更新按周或按新增节奏；
- 更大规模：先保证每个分片里的 URL 都能独立打开、内容不重复，再考虑推送接口覆盖新增部分，入口页的互链结构同步理清。
sitemap 和主动推送做的事只有一件：告诉蜘蛛“这里有哪些 URL”。它们解决的是发现问题，不解决质量问题。发现通道再顺，页面本身站不住，抓取量也留不下来。
回到蜘蛛池的日常操作，比较稳的顺序是：先把入口页的可访问性和去重做好，再用 sitemap 把清单交代清楚，最后拿推送接口补新增的关键页面。把发现通道理顺之后，日志里的蜘蛛来访曲线通常会更连贯，也更容易看出问题出在哪一环。