大多数 sitemap 生成一次、提交一次,然后被遗忘。站点只有几百条 URL 时这样做没问题。超过几千条之后,sitemap 不再是走形式,而是一套清单管理系统——Google 会把这份清单的质量当作一个信号来读。
按"变化节奏"分区
一个装着 80,000 条 URL 的 sitemap 在覆盖率下滑时什么都告诉不了你。分区的全部意义在于让 sitemap 文件本身成为诊断单元:
- 按栏目:
/blog、/products、/docs各一个 sitemap。某个栏目的覆盖率劣化时,边界清晰可见。 - 按变化频率:天天变的页面(列表、库存)与永不变化的页面(文档、法务)分开。它们的新鲜度预期不同,混在一起会让
lastmod失去意义。 - 按语言/地区(如果你跑 hreflang):覆盖率问题常常按语言分布,按语言分区的 sitemap 能把"国际覆盖率下滑"具体成"
de这个 sitemap 下滑了"。
indexsubmit 按计划同步 sitemap 并按 sitemap 栏目跟踪覆盖,正是这个原因——sitemap 索引是诊断最自然的轴。
lastmod:诚实本身就是策略
lastmod 是协议里被滥用最多的字段。每一个给所有 URL 盖构建时间戳的 sitemap 生成器,都在教爬虫不信任它。Google 在 lastmod 准确时用它做抓取 prioritization 的证据很充分;在它闻起来像机器生成时忽略它的证据同样充分。
让 lastmod 保持可信的规则:
lastmod= 最后一次内容修改,不是最后一次构建、部署或清缓存。- 如果你的 CMS 产不出真实的内容版本,干脆省略
lastmod。没有lastmod的 sitemap,胜过说谎的 sitemap。 - 修正之后,预期效果是渐进的——对该字段的信任是按站点积累、随时间重建的。
sitemap 是什么、不是什么
sitemap 是一个发现辅助——一份"这些 URL 存在且重要"的声明。它不是提交协议,不是保证,也治不好薄弱的内链。只存在于 sitemap 里、没有任何上下文内链的页面,会得到最弱的待遇:很少被抓取,信任更低。
实际推论:用 sitemap 定义清单,用内链为清单里的页面争取地位。如果一个页面重要,应该有某个真实页面在上下文中链接到它。
上线之后监控什么
sitemap 是你整个覆盖率故事的分母。四个随时间跟踪的数字几乎能说明一切:
- 每栏目的已同步 vs 已收录——每个分区的覆盖率。
- 每栏目的已发现未收录——Google 对这类 URL 的质量判定。
- 404 与重定向——指向死链或迁移 URL 的 sitemap 条目是信任漏损。
- 新 URL 的首次收录耗时——新条目进入索引要多久;这个数字上升是全站信任的早期预警。
如果你在用电子表格手动跟踪这些,这正是 indexsubmit 自动化的工作:sitemap 按计划同步、每条 URL 的判定每天记录、每个栏目独立评分并保留 30 天趋势、栏目覆盖率劣化时告警。
先像 Google 的爬虫那样看你的 sitemap 索引——把它当作相互竞争的清单——并把它分区成你能据此行动的样子。
未完成的同步与套餐上限
同步触及套餐的 URL 清单上限时，会保持“未完成”状态。没有读到的页面不会因此被认定为已移除。提高上限后，indexsubmit 会重新获取完整 sitemap；缓存的“未修改”响应不能把上一次的部分清单变成完整清单。