先说结论：XML Sitemap 中的 priority 字段不会影响排名，Google 已公开表示不会读取它；changefreq 也是如此。真正仍会被读取、并直接影响 AI 爬虫抓取效率的字段，只有 lastmod。如果每次生成 Sitemap 时，都把所有 URL 的 lastmod 改成当天日期，这不是在帮助爬虫，而是在让它逐渐不再信任这份清单。本文将说明如何把 XML Sitemap 做成一份可信的变更记录，让 GPTBot、ClaudeBot 和 PerplexityBot 用尽可能少的抓取次数发现你的最新页面。
Sitemap 的作用不是提升排名，而是提高抓取和索引效率
Sitemap 不会把任何页面推到更高的排名位置。它本质上是一份清单，告诉爬虫“这些 URL 存在，其中一些最近发生了变化”。对于页面不到几百个、内部链接清晰的小型网站，有没有 Sitemap 的差别其实不大，Google 一轮抓取通常就能找到全部页面。Sitemap 真正有价值的场景主要包括：网站规模较大，存在链接难以触达的深层页面或孤立页面，内容更新频繁，或者希望爬虫尽快发现某项变更。AI 爬虫尤其依赖这份清单，因为它们的抓取预算比 Google 更少，又没有 Search Console 这样的后台可供提交，因此可用的发现线索比你想象中更有限。
lastmod：唯一仍会被读取，也最容易被填错的字段
Google 在这一点上的态度一直很明确：它会参考 lastmod，但前提是这个值真实可信。一旦系统发现，每次重新生成 Sitemap 时，整个网站的 lastmod 都被改成当天日期，就会直接把该字段的可信度降至零。此后即使重要内容真的发生变化，这个信号也很难再有效传递。因此，lastmod 应反映内容发生实质性变更的时间，而不是模板调整时间，也不是全站重新部署的时间戳。就这一点而言，大多数 CMS 的默认设置都是错误的。
- 使用带时区的 W3C Datetime 格式，例如 2026-07-02T14:30:00+08:00，不要只填写日期。
- 只有内容发生实质性变更时才更新：修正错别字、更换装饰性图片或微调 CSS 都不算。
- 不要直接把网站构建时间或数据库中的 updated_at 当作 lastmod，否则每次部署都会错误地报告全站更新。
- Sitemap 索引中的每个子文件也必须有自己的 lastmod，指向该组内容最近一次真实变更的时间。
- 如果技术上无法生成真实可信的 lastmod，宁可完全留空，也不要每天把全站都报告为“今天更新”。
priority 和 changefreq：填了也没人看
Google 工程师已经公开说得非常清楚：priority 完全不会被纳入考虑，changefreq 也是如此。Bing 的态度也类似。如果 CMS 会自动填写这两个字段，保留并无妨；但不要让工程师花时间判断某个页面应该填 0.8 还是 0.6，这个数字不会改变任何抓取或排名结果。priority 唯一还算有用的地方，是迫使团队梳理哪些页面最重要——但这是给人看的，不是给算法看的。
AI 爬虫如何发现并使用你的 Sitemap？
GPTBot、ClaudeBot、PerplexityBot、CCBot 和 Google-Extended 等 AI 爬虫，没有可供提交 URL 的 Search Console。它们最稳定的发现渠道只有一个：robots.txt 中的 Sitemap 指令。缺少这一行时，你只能等它们沿着链接逐步爬进网站。声明 Sitemap 后，准确的 lastmod 能帮助它们跳过未发生变化的页面，把有限的抓取次数用在新内容上。这正是你需要的结果，因为 GEO 的目标是让内容被引用，而不是单纯让爬虫访问服务器。
大型网站如何拆分 Sitemap，最大限度提升索引效率
单个 Sitemap 文件有明确上限：最多包含 50,000 个 URL，或未压缩文件不超过 50MB，以先达到的限制为准。超过上限后必须拆分，再通过 Sitemap 索引统一管理；索引本身最多可容纳 50,000 个子 Sitemap。实际操作中，更好的做法不是等文件超限后再拆，而是从一开始就按内容类型分组。这样便能在 Search Console 中分别查看各组的索引覆盖情况，哪一类内容存在索引问题，一眼就能看出来。
- 按内容类型分组，例如 sitemap-blog.xml、sitemap-docs.xml、sitemap-product.xml，并分别查看各组的覆盖情况。
- 每个文件最多包含 50,000 个 URL，或保持在未压缩 50MB 以内。超过限制时继续拆分，再通过 Sitemap 索引汇总。
- 使用 gzip 将大文件压缩为 sitemap.xml.gz；协议允许这种做法，也能节省带宽。
- 重点维护最可能被 AI 引用的高价值页面，例如定价、对比、常见问题和案例页面；确保这些高频更新页面拥有最准确的 lastmod。
- 不要纳入设置了 noindex、canonical 指向其他页面或返回 4xx/5xx 的 URL，否则会削弱整份清单的可信度。
停止 ping：2023 年之后如何发送变更通知
Google 已在 2023 年停用 Sitemap 的 ping 端点，Bing 随后也采取了同样做法。现在再向 /ping?sitemap= 发起请求已经没有作用。替代方案分为三个层次：第一，维护准确的 lastmod，让爬虫按自身节奏回访时判断是否需要重新抓取；第二，只需在 Search Console 中提交一次 Sitemap，不必反复发送；第三，针对 Bing 和 Yandex，使用 IndexNow 实时推送 URL 级别的变更通知。需要注意的是，Google 不支持 IndexNow，多数 AI 爬虫也只依赖自身的回访计划和你的 lastmod。因此，想同时影响所有爬虫，真正有效的杠杆仍是严格、如实地维护 lastmod。
上线前的 Sitemap 检查清单
- robots.txt 中包含 Sitemap 指令，并指向可公开访问的 Sitemap URL。
- lastmod 反映真实的内容变更，格式包含时区，且不存在全站日期完全相同的情况。
- Sitemap 只收录返回 200 且可被索引的页面，排除 noindex 页面和 canonical 指向其他地址的 URL。
- 单个文件不超过 50,000 个 URL 或 50MB；大型网站使用 Sitemap 索引，并按内容类型分组。
- 在 Search Console 中提交一次，并检查“已发现”的数量是否与实际页面数量一致。
把这些关键点做好，你的 Sitemap 就能从一份没人信任的例行文件，变成爬虫和 AI 引擎愿意采纳的内容变更来源。多数团队的问题并不是漏掉了某个页面，而是全站的 lastmod 都在提供错误信息，同时 Sitemap 中还混入了大量不可索引的 URL。通过外部工具扫描，这些问题都会暴露出来。如果你想知道自己的 Sitemap 和整体技术 AEO 设置还缺什么，可以预约一次 30 分钟的 GEO 诊断（/contact），我们会直接指出最应该优先修复的问题。
