做蜘蛛池的人常说“让蜘蛛来”，但真正要先解决的問题其實是让蜘蛛知道有哪些 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 把清單交代清楚，最後拿推送接口补新增的關键頁面。把發現通道理顺之後，日誌里的蜘蛛来訪曲线通常會更连贯，也更容易看出問题出在哪一环。