Sitemap 常被当成一次生成、长期不管的静态文件。实际上它更像一份对外承诺的清单：你在告诉蜘蛛「这些地址值得来抓」。清单里混进失效地址、重复地址或者根本不该收录的页面，浪费的不只是带宽，还有整站被合理抓取的机会。

一、先确认地图里的地址都能打开、也都该收

生成逻辑往往直接读数据库里所有文章，标题、状态、权限一概不过滤。建议在生成环节加一道筛选，把下面这些类型剔出去：

• 返回 301、302 的跳转地址，应该写最终地址而不是中间地址；
• 已删除或已下线的 404、410 页面，尤其是内容下线后模板没同步的情况；
• 被 robots.txt 的 Disallow 挡住的目录，写了也抓不到，只会制造矛盾信号；
• 页面上带 noindex 的地址，除非你确实希望它被看到但不想被收录；
• 带筛选参数、排序参数、会话参数的列表页，这类地址容易成倍膨胀。

一个简单的判断标准：这个地址如果被蜘蛛抓走，你希望它看到什么？答不上来的，就不该出现在 sitemap 里。

二、lastmod 别写成全站同一个时间

不少站点每次跑生成脚本，就把所有地址的 lastmod 刷成当前时间。短期看不出问题，时间一长，蜘蛛会逐渐降低对这个字段的信任度，等真的有新内容时，反而得不到优先抓取。

比较稳妥的做法是：只有正文、标题或关键结构发生实质变化时才更新，模板调整、广告位替换、页脚年份自动更新这类改动不算。

lastmod 回答的问题是「哪些内容真的变了」，而不是「站点又跑了一遍生成脚本」。

三、分段与体积要提前规划

• 单个 sitemap 文件的地址数建议控制在 50000 条以内，未压缩体积不超过 50MB；
• 内容量较大的站点，用 sitemap index 按栏目或内容类型拆成多个子文件，便于单独排查和单独更新；
• 新闻、图片、视频有各自的扩展格式，不要和普通页面混在一个文件里；
• 体积偏大时启用 gzip 压缩，多数蜘蛛都支持。

拆分的另一个好处是定位问题更快：某个子文件的抓取异常，能直接对应到具体栏目，而不是在整个大文件里翻找。

四、哪些地址原则上不该进 sitemap

• 站内搜索结果页，这类地址数量近乎无限；
• 用户中心、登录后页面、表单提交后的结果页；
• 只做跳转用的短地址和追踪参数地址；
• 尚未通过自查的标签页与聚合页，等确认有实质内容再考虑加入。

分页后续页是否需要收录，取决于栏目本身的策略，但至少不要让每页都带一串参数地址混进来。

五、提交之后怎么验证

1. 在 robots.txt 里用绝对地址声明 Sitemap 位置，方便蜘蛛自动发现；
2. 到站长平台提交，观察抓取统计与覆盖率变化，而不是提交完就当结束；
3. 翻访问日志，看蜘蛛对 sitemap 文件的抓取频次和返回码，确认没有被限流或被 404；
4. 把 sitemap 地址数与实际被抓取、被索引的数量做对比，差距大的部分单独找原因；
5. 随机抽样若干条地址，手动检查状态码、canonical 指向和页面内容是否一致。

这套动作做下来，通常能发现几类反复出现的问题：老地址没清理、栏目改版后路径没同步、参数页批量进入地图。每次改版或栏目调整后重跑一遍，比事后从日志里反推要省力得多。

六、把它当成一份需要维护的清单

Sitemap 的价值不在于文件本身多大，而在于里面每一条都立得住。建议把生成逻辑写进日常流程：内容上线、下线、改路径时自动同步，每月抽一次时间做人工抽查。地图画得准，蜘蛛走的路才会顺。