先把 Sitemap 的定位摆正
不少站点把 Sitemap 当成主要的 URL 发现渠道，结果站内互链做得一片稀疏。实际上蜘蛛发现页面的顺序通常是：先访问首页和高频更新的频道页，再顺着站内链接逐层跟进，Sitemap 更多是补充遗漏。它的价值在于覆盖那些内链薄弱、层级较深，或者刚上线还没被链到的 URL。如果站内链接本身断得厉害，单靠 Sitemap 也补不回来。
所以讨论字段怎么写之前，先明确一点：这些字段影响的是判断依据，不是抓取结果的开关。
lastmod 写准，才有可能被参考
lastmod 表示这个 URL 内容的最后修改时间。它被参考的前提是准确。常见的问题是：改一次模板、批量发布、CMS 自动保存，全站 lastmod 就变成同一个时间戳。这种「所有页面同时更新」的信号没有区分度，蜘蛛很难据此判断哪些页面真的变了，久而久之这类字段就更容易被忽略。
- 只在正文内容发生实质变化时更新，导航、样式调整不要触发
- 时间格式保持统一，带时区，避免同一份文件里混用多种写法
- 如果维护成本太高，宁可不写，也不要批量刷一个假时间
对于更新频繁的资讯类页面，准确的 lastmod 相对更有用；对于长期不动的说明页，写不写差别不大。
changefreq 与 priority：参考价值已经有限
changefreq 描述预期更新频率，priority 表示页面在站点内的相对重要度。这两个字段的实际影响这些年被大幅稀释，多数情况下不再作为主要依据。写的时候保持内部逻辑一致就够了：首页 priority 高一些，更新频繁的栏目 changefreq 偏 daily，但不要指望靠调高数值换来更多抓取。
更常见的坑是自相矛盾：一个 priority 写 1.0 的页面，lastmod 却是两年前。这种不一致反而削弱整份文件的可信度。
分片与索引文件：大站要留意边界
单个 Sitemap 有 URL 条数上限，超过就要拆成多个子文件，再用一个索引文件把子文件列出来。这里容易出现几类问题：
- 新增了子文件，但索引文件没同步更新，蜘蛛根本找不到
- 子文件里混着已经 404 或已经重定向的旧 URL
- 多个分片内容重叠，同一批 URL 被反复提交
分片本身并不复杂，麻烦在长期维护。每次改版、下线栏目、调整 URL 规则，都要回头确认清单和线上是否还一致。过期条目越多，整份文件的参考价值越低。
抓取路径稳不稳，最后还是要看服务器
Sitemap 提交之后，蜘蛛会挑时间去读取。如果站点响应慢、频繁超时，读取这个文件本身就会占用抓取配额，反而挤掉正文页面的抓取机会。同样的道理，Sitemap 文件也要能快速返回，不要走复杂查询，也不要经过多层重定向。
把 Sitemap 做成静态文件，通常比做成实时生成的动态接口更稳。
一份日常检查清单
- Sitemap 地址已在 robots.txt 中声明，且可以正常访问
- 清单里只保留返回 200、可被索引的页面
- lastmod 与内容实际更新时间对得上
- 分片与索引文件同步更新，没有死链和重复
- 内链结构不依赖 Sitemap 兜底，重要页面都有站内入口
- 定期从服务器日志里确认清单中的 URL 是否真的被抓过
这些动作不保证任何结果，但能减少「蜘蛛拿到的信息本身就是错的」这一类问题。URL 发现和重抓判断本来就是多个信号叠加的过程，Sitemap 只是其中一环，把它做干净、做准确，剩下的交给链接结构和站点稳定性。