站群系统 sitemap 自动生成实战：生成时机、分站隔离与抓取反馈全解析

玩站群的朋友大概都碰过这种局面：几百个站点内容天天更，搜索引擎那边却像没看见一样。内容本身通常没毛病，症结在于蜘蛛根本不知道你动了哪里。站群系统里的 sitemap 自动生成，往小了说是个地图文件，往大了说它牵动着整条收录链路。我拿手上这套程序跑了半年多，从早期手动提交一路折腾到全自动推送，中间踩的坑攒了不少，下面就把生成逻辑和实操细节摊开说说。

生成时机卡不准，地图文件就是摆设

不少同行把 sitemap 自动生成当成“定时任务一开就完事”，真跑起来才发现，生成频率和内容更新节奏根本对不上，地图里要么清一色旧链接，要么新文章上线两天了还没被写进去。我这套方案现在走双轨触发：文章入库时先打标记，队列里攒够一批就触发一次增量生成；每天凌晨两点再跑一次全量重建，把删掉的、改过名的链接清理出去。增量生成只写入新增和修改的 URL，文件体积涨得慢，蜘蛛来抓的时候不用对着一份几兆的 XML 慢慢啃。

有个细节值得单独拎出来说——生成任务别跟内容发布挤在同一个进程里。之前图省事，发布完直接同步写地图，结果高峰期文章一多，生成任务把数据库连接占满，后台发稿直接卡死。后来拆成独立的 worker 进程，用消息队列传任务，这个问题才算彻底解决。

分站地图隔离是站群系统的命门

站群和单站最大的区别在于，每个子站都得有一份自己的 sitemap，而且必须挂在各自域名下。见过有人图省事，所有子站的地图全指向主站目录，蜘蛛爬到一半发现 URL 和域名对不上，直接判定地图无效。这套程序的做法是：每个站点根目录下自动生成 sitemap.xml，主地图文件只做索引，按站点 ID 分片。分片大小我卡在 50000 条上限以内，实际跑下来单站内容量很难到那个量级，但分片结构留着，以后扩站不用返工。

域名规则这块有硬性要求——生成的地图里所有 URL 必须带完整协议头和域名，不能写相对路径。之前有个子站换了域名，地图里还留着老域名的绝对路径，提交上去搜索引擎报了一堆 404。后来在系统配置里加了一道校验，生成时比对当前站点绑定的域名，不一致的直接跳过并记日志。这个校验逻辑不复杂，但省下的排查时间不止一星半点。

抓取日志反推地图质量

地图生成完只是第一步，蜘蛛来不来、抓多少，得看服务器日志。我习惯每周拉一次 access log，筛出抓取 sitemap.xml 的记录，盯两个指标：抓取频次和状态码分布。如果某个子站的地图连续几天都是 304，说明内容更新频率太低，得回头检查那个站的发稿计划；要是出现 500，多半是生成任务把内存吃满了，得去看 worker 的日志。

还有个容易被忽略的点——地图文件本身的响应头。现在这套方案给 sitemap.xml 单独配了缓存策略，Cache-Control 设成 max-age=3600，蜘蛛一小时内重复来抓直接走缓存，减轻后端压力。同时确保 Content-Type 是 application/xml，有些服务器默认返回 text/plain，虽然不影响解析，但部分抓取工具会报警告。这些参数在部署成本里几乎为零，效果却是实打实的。

推送通道别只盯着地图文件

sitemap 自动生成解决的是“蜘蛛能找到”的问题，但光靠它不够。这套系统在生成地图的同时，会把新增 URL 推一份到搜索引擎的主动推送接口，两套通道并行。实测下来，推送接口的收录触发速度比单纯等蜘蛛爬地图快 6 到 12 小时，对于有时效性的内容差别很明显。推送失败的 URL 会落到重试队列，最多重试三次，三次都失败就标记出来人工看，避免无效请求一直占着队列。

整套流程跑顺之后，日常维护的工作量主要落在日志巡检上。生成逻辑本身不需要天天盯着，但配置参数得根据站点规模调——分片阈值、重试次数、缓存时间这几个值，每个站群的使用场景不一样，照搬默认配置多半要出问题。我现在的习惯是每接一批新站，先拿三五个站跑一周观察日志，确认生成任务不堆积、地图抓取正常，再全量铺开。这行做久了就明白，自动化省的是重复劳动，该盯的指标一个都省不掉。