Sitemap 是什么，不是什么
Sitemap 解决的是广度问题：告诉搜索引擎站点里存在哪些规范 URL。它不解决权重和优先级问题，也不保证被收录。不少站点把 sitemap 当成唯一的发现渠道，内链却断得七零八落，最后 sitemap 里大量 URL 长期停留在已知但很少被访问的状态，提交动作本身没错，缺的是配套的入口结构。
文件结构上的几个硬约束
- 单个文件不超过 50000 条 URL，解压后不超过 50MB，超过就分片
- 分片之后要用 sitemap 索引文件串起来，索引里同样只放各个分片的地址
- 只放最终返回 200 的规范地址，不放重定向目标之外的旧地址、不放参数变体、不放已设 noindex 的页面
- 写绝对 URL，包含协议；统一用 UTF-8 编码；体量较大时用 gzip 压缩
这几条看着基础，但审核不严的站点常常在分片环节出错：文件生成了，索引里却漏掉某一个，等于这部分 URL 从未被提交过。
lastmod 为什么容易失真
很多站点的 lastmod 用的是构建时间，而不是内容实际变更时间。发一次版，全站 URL 的时间戳一起变成今天。第一次可能还会引起抓取系统的注意，几次之后这个信号就没有区分度了——所有页面都显示刚更新，等于所有页面都没有更新。
更麻烦的是时间戳回退。某篇文章的 lastmod 从 6 月变回 3 月，这种前后不自洽会让抓取系统降低对整个 sitemap 的信任。
lastmod 的价值在于区分，而不是新鲜。全站统一刷新，等于没有信号。
相对稳妥的做法
- 把 lastmod 绑定到内容实体：正文、标题、结构化数据、主要配图的实际修改时间
- 模板、导航、页脚的调整不要写进 lastmod
- 时间戳只前进不后退，时区统一，格式用带偏移的 ISO 8601
- 没有可靠时间来源的页面，宁可不写 lastmod，也不要随手填一个当前时间
分片与更新节奏
分片不要按字母顺序随便切。可以按内容类型或更新频率来分：高频更新的栏目一个文件，长期稳定的页面一个文件。这样你只需要重新生成变动的那个分片，不必每次重写全部。
更新频率上，sitemap 不需要每有一条内容变动就重新生成并推送，一天几次通常足够。频繁提交同一个文件，收益是递减的。
和 canonical、内链的分工
sitemap 只列规范版本。同一篇内容的其它地址通过 canonical 指向它，不要把几条地址都塞进 sitemap，那是自己制造重复抓取。
sitemap 负责让抓取系统知道地址存在，内链负责说明哪个页面更重要、从哪儿进入。只提交 sitemap、内链里却没有任何指向的页面，抓取间隔通常明显长于有内链支撑的页面。反过来，内链结构清晰、sitemap 写得粗糙的站点，抓取表现往往也不差——两者的权重并不对等。
怎么验证它有没有起作用
- 在服务端日志里筛出 sitemap 中的路径，看是否被访问、访问间隔多长
- 对比有内链入口和无内链入口的页面，抓取频次差异是否明显
- 查看搜索引擎后台的 sitemap 报告，关注已发现与已抓取之间的差距
- 抽查 lastmod 与内容实际修改时间是否一致
如果大量 URL 长期停在已发现未抓取，先别急着改 sitemap，回到内链和站点层级上看：这些页面本身是不是缺少入口，或者藏得太深。
几个常见坑
- sitemap 里包含 robots.txt 已屏蔽的目录，白提交
- 分片文件没有在索引里列出，等于没提交
- 把搜索结果页、筛选页塞进去，制造大量低质抓取
- 把 sitemap 当站点结构图用，放进去成千上万个几乎不更新的页面，反而稀释了真正的更新信号