sitemap lastmod 值多少：24 个站里 13 个写了等于没写

实测 · 2026-08-17 · 30 个站 · 单次快照

样本与口径：与我们 2026-08-15 那次 robots.txt 与 llms.txt 调查完全相同的 30 个站。每个站只读一个 sitemap，2026-08-17 用匿名 HTTPS 请求取回。下面所有数字都出自那一个文件，不代表整站。

做出海独立站的人多半没自己写过 sitemap —— 它是 Next.js、Vercel、Framer、Webflow、Shopify 这些工具生成的。问题在于生成器往往把构建时间当成 sitemap lastmod 填进去。我们读了 30 个站，24 个拿到可解析的文件：10 个一条 lastmod 都没有，3 个把全部 URL 盖成同一天。24 个里有 13 个，这个字段等于没写。

24 个能读到的文件，长这样

按引擎拿到之后能做什么来分。中间那一档最值得看：文件里日期是满的，但每一条都一样。

还有 6 个站不在这 24 个里面。5 个直接不让匿名请求读 sitemap，1 个返回了 200 但内容不是 sitemap。这两种情况另开一节说，因为「门关着」和「字段是空的」不是一个问题。

怎么测的

判定规则在发第一个请求之前就写死了，跑完一条没改。这一步在这类调查里是必要的：先看结果再定阈值，标题会更好看，结论会更不可信。

1. 取 /robots.txt，用里面第一条 Sitemap: 行；没有就试 /sitemap.xml。
2. 如果拿到的是 sitemap index，跟进它的第一个子文件去读。
3. 数 URL 条数、数带 lastmod 的条数、数这些值一共覆盖多少个不同的日历日。
4. 分档：一条 lastmod 都没有算「没有」；10 条以上 URL 却只有 1 个日期算「一个戳」；2 个以上日期算「有分布」。

每个文件一次请求，普通桌面浏览器的 User-Agent，不带 cookie、不登录，每站最多 3 个请求。

出海独立站常用的那几个平台，正好都在样本里

这一节是这篇对中文读者最有用的部分。样本里有 7 个站用的正是国内做出海的人天天在用的建站与托管工具，它们生成的 sitemap 是什么样，基本就是你的站是什么样。

Vercel 与 Next.js 官网这两个是反例，说明用同一套技术栈完全做得出真实分布 —— 它们的 lastmod 接的是页面自己的内容历史，不是这次部署的时间。

10 个站的 sitemap 里，一条 lastmod 都没有

这些文件只列 URL，到此为止。文件越大，这个缺口越贵：引擎要在几万条里自己猜哪一条值得重新抓。

3 个站把整个文件盖成同一天

这个形态在校验工具里是全绿的，对引擎却什么都没说。每条 URL 都有日期，每个日期都一样，因为写进去的是构建时间，不是页面变更的时间。

Cloudflare 那份还多写了两个字段：首页条目上带着 <changefreq>daily</changefreq> 和 <priority>1.0</priority>。Google 文档白纸黑字写着这两个它都不看（原文 Google ignores <priority> and <changefreq> values）。也就是说这条 URL 上的四个提示字段，三个要么按政策被忽略、要么整份文件里长得一模一样。

有真实分布的长什么样，以及我们自己的口径在哪儿翻了车

11 个站的日期是散开的。文档站是最硬的例子：MDN 抽到的那个文件里 14,576 条带 lastmod，覆盖 751 个不同日期 —— 时间戳接在页面上、而不是接在部署上，出来就是这个样子。

这 11 个里有 3 个是我们自己那条「取 index 第一个子文件」规则的副作用。它们照写出来，不悄悄丢掉。

• arstechnica.com —— 抽到的子文件里只有 1 条 URL，说「有分布」毫无意义。
• medium.com —— index 里列了 27,755 个子文件，第一个是 2019 年的归档，读到的日期全在 2019 年。
• bbc.com —— 一样的形状，50,000 条 URL 的日期落在 2008 到 2009 年。

这件事本身也是个结论，不只是脚本的毛病：任何按文件顺序去走 sitemap index 的程序，第一脚都会踩进归档里。

5 个站的 sitemap 匿名根本读不到

这跟「没写 lastmod」是两回事，我们也不把它算成站方的问题 —— 引擎的身份和一次普通 curl 请求不一样。

Stack Overflow 连 robots.txt 本身都返回 418，那是一道机器人挑战，不是一条策略声明。第 6 个站是 Canva：/sitemap.xml 返回 200，内容不是 sitemap。

你该拿 sitemap lastmod 怎么办

把它当成一句需要兑现的承诺，而不是一个需要填满的字段。Google 的 sitemap 文档说这个值应当反映页面上一次实质性更新的时间，并且专门举例说改个版权年份不算实质性。构建时间戳属于同一类不算数的变化。

• 把 lastmod 接到页面自己的内容历史上：改内容它就动，重新部署它不动。
• 用我们上面那个办法查一遍自己的文件：数一数它一共覆盖几个不同日期。
• 别因为生成器顺手给了今天的日期，就把整份文件盖成今天。
• 别在 changefreq 和 priority 上花时间，Google 明写这两个不看。

如果你的生成器只能给出构建时间，那么不写 lastmod 反而更诚实，而且你并没有因此失去任何本来就有的东西。接下来把变更直接告诉引擎：IndexNow 怎么用讲的是这条路，页面改完之后怎么推送收录讲 Google 那一侧。如果你想看的不是一个字段、而是整条被抓取与被引用的链路，那正是 QueryWin 在做的事。

这次快照说不了的事

我们不知道任何一个「整批同一天」到底是不是错的。一个每天重建全部页面的站，从技术上讲确实每个文件都变了。站在外面，一次请求、没有页面历史，我们分不开真实修改和部署产物 —— 而这恰恰就是 Google 说它在信这个字段之前会做的那个判断。

还有两条边界。每个站只读了一个文件，所以某个站完全可能在我们没打开的那份 sitemap 里写着漂亮的日期。以及这是单日快照，它说不了这些值随时间怎么变。重抓行为我们这次一点都没测。

常见问题

Google 到底看不看 sitemap lastmod？

看，但有条件。Search Central 文档的原话是：如果这个值是「consistently and verifiably accurate」（一贯且可核验地准确，例如拿它和页面的最后修改时间对比），Google 就会用它。这句话里真正吃劲的是 accurate。

写不准的话，是不是干脆别写？

按 Google 自己的措辞，核验不过的值就不再被采用。核验不过之后会怎样我们没测，所以说不准是整份文件受影响，还是仅仅这个字段被跳过。

怎么一次性查完自己的 sitemap？

把文件取下来，抓出全部 lastmod，每个只留前 10 个字符，然后数不同值有几个。几百条 URL 只数出一个值，答案就已经在那儿了。

这 30 个站是怎么来的？

就是我们 2026-08-15 做谁在挡 AI 爬虫那次用的同一批，故意一个没换，好让两次测量能横着对照。

出处核对于 2026-08-17：Google Search Central，Build and submit a sitemap。