sitemap lastmod记的是哪一刻？41万条实测

摘要：41万条地址的sitemap里，58.7%写了修改时间。把这批文件按2小时22分、7分钟、4秒三种间隔各重抓一遍，测出来的前移量分别是2小时18分、474秒和4秒——每次都正好等于间隔本身。同一批被声称刚刚改过的页面逐字比对，标题99.0%一字未动、H1零变化。另一头还有6个站的时间戳停在2到4年前。文中给出全量覆盖率、精度、年龄七档分布、索引层对账结果，一次把尺子量歪的完整复盘，以及一分钟就能在自己站上跑完的验证办法。

八月十九日有一条不大不小的消息：有人在后台看到排名波动，比官方宣布更新早了三到五天，于是问Google为什么不早点说。官方给出的答复是他们并没有提前推，只是尽量让公告贴近真正按下按钮的那一刻，时区有时候会让这件事变得麻烦。

这个答复里藏着一个更普遍的问题：一件事情发生的时刻，和这件事被写下来的时刻，中间隔着一道工序。那道工序由谁触发、什么时候触发，决定了写下来的那个时间到底可不可信。

网站上最典型的一个这种时间，就是sitemap里的修改时间。协议原文对这个字段的定义清清楚楚：这个地址对应的页面最后一次被修改的时间。它是个自我申报的字段，没有任何人来核验。

保哥把143个站声明出来的sitemap两层全拉了下来，435份文件、41万条地址，然后做了一件很朴素的事——隔一段时间原样再抓一遍，看这个数字会不会自己动。

把同一份地址清单隔两小时再抓一次，会发生什么？

这个实验的设计只有一句话：同一个地址、同一个请求身份、同一份文件，隔一段时间再取一次，把每条地址的修改时间前后对照。

百万级商品的站还要多考虑分片，分片、进出场与这个字段的诚实度是同一套工程。

时间戳在几种格式之间来回换很容易出错，从这个字段到结构化数据的日期换算有一份对照。

这份文件的写法讲究不少，2400个站踩出来的sitemap坑基本都在那份清单里。

如果这个字段真的记录内容变更，那么两次之间只有极少数地址会变——一个卖鞋的品牌站不可能在两小时里改掉几万个页面。

样本是怎么攒出来的

起点是157份能正常读取的robots.txt，其中143个站在里面声明了sitemap地址。顺着这些声明往下抓，第一层拿到157份可用文件，其中116份是索引文件、36份是直接的地址清单。索引文件里又声明了8573个子文件，按站抽取之后抓回第二层。

同一批文件上做过另一项实测，两条规则同时命中一个地址时谁说了算算出来是最长的那条。

两层结构的解析有现成办法，六种格式的解析与地址批量提取可以省掉自己写解析器。

起点那份文件本身就很容易写废，整站从谷歌搜索结果里消失的那类事故多半是从一行规则开始的。

两层合并、去掉抓失败和返回HTML伪装页的，最终得到435份可解析文件：313份是地址清单，122份是索引。地址一共410101条，覆盖116个站。

第一次抓取集中在晚上21点21分到21点33分之间。第二次原样重抓，集中在23点43分到23点55分。两次的中位间隔是2小时22分。

这次没算进去的几件事

有三类东西被排除在外，先交代清楚免得误读。

逐条查一百天不如按模板抽样半天，电商审计改成按页面模板抽样的做法更适合大站。

用别人的工具之前更该先校准口径，第三方数据到底准不准的六步校准法能挡掉大部分噪声。

抽样口径直接决定结论真假，孤岛页面检测的抽样口径怎么定是同一类方法论问题。

一是抓不到的站。20个站一份文件都没取回来，24次请求直接返回拒绝。这批站不在任何一个比例的分母里，所以文中所有百分比说的都是能读到的那部分。

二是图片和文档专用的清单。有些站给图片单独做了一份，那里面的时间语义跟页面不是一回事，统一剔掉了。

三是同一个地址在多份文件里重复出现的情况。这种重复本身也是个问题，但它属于另一个话题，这次只按文件为单位分别统计，不做跨文件去重。

376736条地址，16.9%的修改时间变了

能够两次都取到、且地址完全相同的条目一共376736条。其中63519条的修改时间发生了变化，占16.86%。

这份文件的作用常被夸大，提交网站地图到底能不能提升排名那篇把边界划得比较清楚。

单站也做过同类抽查，585条网址里48条是坏的而生成程序一次都没报错。

这个比例本身就不太对劲。两个多小时里，六万多个页面被改动过，这在任何一家电商公司都不是常态。但比比例更说明问题的是变化的方向和幅度。

中位前移2小时18分19秒，和间隔几乎一样

把每一条变化算成前后差值，结果是这样的：93.2%的变化是往前挪了不到2.5小时，5.6%挪了2.5小时到1天，1.0%挪了超过1天，还有135条是往回退的。

把日期改一改能不能骗过去，真更新与假刷新的副作用实测给了直接的答案。

新鲜度这件事本身是有机制的，哪些页面该更新、更新了会怎么被处理值得先弄明白再动手。

所有变化的中位前移量是2小时18分19秒，四分位区间只有2小时18分04秒到2小时18分25秒。而两次抓取的间隔是2小时22分。也就是说，这个字段没有停在原地，它跟着我的请求一起往前走了。

再换一个角度看同一件事：63519条变化里有58917条，也就是92.8%，新值落在第二次抓取时刻的前后1.5小时以内。它不是散落在过去的某个时间点上，它就贴在你请求的那一刻旁边。

站级分布：46个站一动不动，18个站整份全变

把它拆到站级会更清楚。115个有可比数据的站里，46个站的修改时间一条都没变，7个站变动不到5%，44个站在中间，18个站的变动比例在95%以上。

中间还夹着一层缓存，六层缓存与边缘路由对SEO的影响会改变你看到的东西。

地址规模失控会连带一堆问题，大量无用页面拖垮流量的诊断与处置有一张决策矩阵。

这个信号最终服务的目标是抓取预算，抓取预算优化的十二项实操按优先级排过一次序。

最后那18个站的数字非常整齐：anker.com的4214条全变，eufy.com的11690条全变，soundcore.com的1975条全变，dji.com的354条全变，italic.com的96条全变。gymshark.com、tentree.com、aloyoga.com、everlane.com、marinelayer.com、fahertybrand.com、taylorstitch.com都是差一条全中。

这不是内容更新的分布形状。内容更新永远是长尾的——少数页面动、多数页面不动。整份文件同时全变只有一种解释：这个数字是在文件被生成的那一刻现算出来的。

另外那46个站呢

它们一条都没动。这看上去像是好消息，但先别急着下结论——后面会看到，它们里面有一批的问题比前面那18个还严重，只是方向相反。

这几年该查的层次比过去多，从AI爬虫到无障碍的42步实战是一份扩展清单。

资深团队反而更容易栽在结构性问题上，被忽略的那几类技术SEO失灵原因说的就是这种局面。

这类没人报错的欠账攒起来相当可观，技术债怎么排查和分批偿还给了一套可执行的顺序。

被声称刚刚改过的那些页面，正文真的动了吗？

到这里为止，能证明的只是这个数字在动。要证明它在说假话，还得反过来问一句：那些被声称刚刚改过的页面，正文究竟改了没有。

两次抓取拿到的东西不一样也可能另有原因，爬虫和用户看到的页面不一样怎么揪出来是另一条排查线。

做对照组这件事经常能救命，量出七成页面有差异、补上对照组后只剩两个点就是一次返工。

闭环怎么设计

做法是从那18个整份全变的站，加上6个从不变化的对照站，把之前抓过的页面原样再抓一遍。两次抓取的间隔和sitemap那边完全一样，都是两个多小时。

抓下来的东西还可能被截断，2MB抓取上限的八步优化是先要排除的干扰项。

抓下来的东西有没有正文得先确认，132个独立站首页有28个是空壳量的就是这件事。

做内容指纹要选对算法，从摘要算法到缓存键与完整性校验那份对照可以直接抄。

比对四样东西：页面标题、页面描述、H1、以及正文的词集相似度。前三样是逐字比对，改一个字符就算变；正文那一项是把可见文本切成词、剔掉哈希与随机串之后算重合比例。

选这四样是有讲究的。电商页面上有大量本来就每次都不同的东西——防重放令牌、灰度分桶标记、时间戳、埋点参数。这些东西如果不剔干净，任何两次抓取看上去都是不一样的。而标题、描述、H1不会因为你刷新一次就变。

102个页面，标题99.0%一字未动

那18个站里可比对的页面一共102个。结果是：

标题在别处还会被重写一遍，四大平台社交卡片的逐字段体检能看出差异。

有些字段其实是被平台锁死的，哪些页面元素能改、哪些改不了得先摸清楚。

标题这一栏怎么写也有讲究，八种模板与长度阈值背后的真相比工具给的建议实在。

sitemap说这102个页面在刚过去的两小时里全部被修改过，实际上它们一个字都没改。

对照组给出了同样的100%，这很重要

对照组那29个页面（来自prose、article、weber、philips、traeger、stokke这几个修改时间从不变化的站）标题一字未变的比例是100%，描述100%，H1也是100%，正文相似度中位同样是100%。

想知道某个动作到底有没有增量，别让本来就会买的人冒领功劳那套测法值得借鉴。

验证一条建议有没有效有个笨办法，给那条建议配一个注定无效的对照组比讲道理管用得多。

两组给出一样的结果，恰恰说明这把尺子是好的。两组页面在这两小时里都没动，唯一的差别在于它们的sitemap怎么说这件事。

这把尺子第一次量出来的是4.6%，而且是错的

这一节值得单独讲，因为它差点让整篇文章的结论反过来。

数据看着正常也未必真的正常，浏览器把yes改成forks而问卷看不出异常是同一种隐形污染。

口径不清的指标最容易误导判断，从指标体系到异常诊断的完整做法可以拿来搭自己的框架。

一个准确率数字先要问它的及格线谁划的，95%准确率是自己划的还是考出来的是同一类追问。

第一次跑闭环比对时，量出来的正文相似度中位数是4.6%，很多站甚至只有0.24%。按字面读，这意味着两小时里页面被换掉了99%以上——刚好可以拿来支持sitemap，可惜方向完全相反。

发现它有问题靠的是对照组：那6个从不变化的站也给出了同样极低的相似度。如果尺子是准的，两组不该长得一样。

根子在一行毫不起眼的映射代码。原先那批页面的存盘文件名里带一个序号，而这个序号来自任务队列的行号。我图省事，拿抓取结果文件里的出现顺序去重建这个序号——问题是那批抓取是八个进程并行跑的，结果文件的写入顺序跟队列顺序根本对不上。于是我一直在拿A页面的旧版跟B页面的新版做比较，比了一百多对，一次都没比对过同一个页面。

改成按队列文件里的序号列取值之后，相似度立刻从4.6%跳到100%。这类错误最坏的地方在于它不报错，输出的数字看起来还挺像那么回事。

教训写下来只有一句：并行写出来的结果文件，它的行序不携带任何信息，任何拿行序当键的做法都是错的。要拿也只能拿输入队列的行序。

间隔换成七分钟、再换成四秒，前移量还跟得上吗？

两小时那一次可以说明问题，但单独一次实验总归不够。如果这个字段真的等于请求时刻，那么换一个间隔，前移量应该跟着换成新的间隔。这是一个可以被证伪的预测，做起来也不贵。

能被机器批量验证的事就别靠人记，哪些SEO工作能交给工具、哪些不能划了一条边界。

在线上做实验要先想好收尾，怎么做A/B测试才不影响SEO里有官方表态和清理动作。

第二次自检：间隔七分钟

从那批文件里挑出变动最多的一份地址清单，每个站一份，在第二次抓取结束大约7分钟之后再抓第三次。

服务器上那一整套例行动作都能自动化，备份、清单导出、缓存与证书一条龙有现成脚本可抄。

这类定时对照最适合交给计划任务，把排名、清缓存和这类巡检挂上定时配置起来不算麻烦。

53842条可比对地址里，8539条的修改时间又变了，占15.86%——跟两小时那次的16.86%几乎一样。而这次的中位前移量是474秒，也就是7分54秒。

变动的站还是那18个，一个不多一个不少。

第三次自检：间隔四秒

最后一次间隔短得有点荒唐。第三次抓取里我给同一个地址连发了两个请求，只是请求身份不同，两个请求之间隔着几秒钟的串行时间。

抓取速率被调低时往往一条错误都没有，服务器日志里看不见的那种降速是同一类静默故障。

这类小脚本自己写最快，用对话式编程做SEO小工具的八步避坑讲的就是这种自养工具。

手头没有脚本的时候，用接口测试工具看清一个地址的状态码与响应头也够用了。

结果是121851条可比对地址里有32406条给出了不同的修改时间。把这些差值按绝对值分档：

差值的中位数是4秒。两个请求之间隔了几秒，答案就差了几秒。

三个量级全部对上，这个字段就是请求时刻

把三次实验并排放：

同一件事在日志里也能验一遍，5000个站的爬虫伪造与抓取预算实测可以互相印证。

数字与数字之间也会出问题，一条五年趋势线上有三处口径变更是最典型的一例。

一个指标要能被复算才敢拿来做决策，五大指标的单一事实来源怎么建是配套的治理办法。

三个数量级差着上千倍，每一次前移量都跟间隔本身对齐。这已经不是相关性了，这是同一个东西。

为什么中位前移量总比间隔略小一点？因为435份文件不是同时抓完的，每份的两次时刻各有各的偏差；另外有些站的这份文件挂在缓存后面，缓存的存活时间会让答案落后于真实的请求时刻几分钟。

一分钟就能在自己站上跑一遍

不需要写脚本，两条命令就够。取一条你站上的sitemap地址，抓下来存成第一份，喝口水，再抓一份，然后对比两份文件。如果两份文件里的时间字段整体前移了你喝水的那段时间，那么这个字段在你站上就是个装饰。

生成器说格式正确并不代表内容对，它说校验通过的时候其实只查了三件事值得看一眼。

不会写代码也有办法批量做，十二个表格公式把数据活自动化对小团队够用。

不花钱也能把基础检查做全，预算为零时真正好用的那批工具列过一份清单。

需要留意的是要用同样的请求身份抓两次，并且别用浏览器——浏览器会带缓存，你看到的可能是本地副本。

换一个身份去问，同一份文件会给出不同答案吗？

跨站抓取有一条铁规矩：任何一个数字报出去之前，都要先确认它测的是这个地址的状态，还是这台机器受到的待遇。同一个地址对不同来客给出不同答案，是这几年越来越常见的事。

模拟不同身份去测站有现成办法，用生成的标识去试探自己的站能复现大部分差别待遇。

要弄清对面到底是谁再谈待遇，120种爬虫标识的分类与真假验证是一份可以照做的清单。

为什么这一步不能省

更早一批实验里遇到过一次典型：63条抓取失败的地址，换成普通浏览器身份重抓，18条立刻变成正常，占28.6%。如果不做这一步，失败率会被虚报将近一半。

真要拦住某类程序得分层做，三层选型框架比只改一个文件靠得住。

想知道谁真的来过只能看日志，每5次Googlebot抓取就有1次IP不属于谷歌是同一批数据挖出来的。

拦截往往发生在你看不见的那一层，防火墙到底拦不拦得住AI爬虫答案没那么简单。

写了放行也未必等于对方进得来，说允许、仍有十个站把对方挡在门外是另一层错位。

所以这次也做了。第三次抓取的时候，每个地址用爬虫身份和浏览器身份各请求一次，两次挨着发。

表面数字：26.59%，涉及61个站

直接比对的结果是121851条可比对地址里32406条不同，占26.59%，涉及61个站。eufy.com差了7300条，anker.com差了1585条，iittala.com差了1550条。

一个判断值不值得做，样本先替你答一半，87个站的清单先替你答了一半是同一种取数思路。

一个数字好看不等于它有用，砍掉虚荣指标、只盯能驱动生意的信号是同一个取舍。

同一个数字各家算法不同这件事到处都是，关键词难度为什么各家工具差那么大是最典型的一例。

如果就这么写出去，标题大概会是“同一份地址清单，四分之一的时间戳会因为你是谁而改变”。这句话很有传播力，也很危险，因为它是错的。

把测量顺序从结果里扣掉

问题出在两个请求不是真的同时发出去的。脚本先发爬虫身份那一个，等它跑完再发浏览器身份那一个，中间隔了几秒。而前面刚证明过，这个字段每过一秒就往前走一秒。

做对照要先算清能不能测得出来，单因素隔离与最小可检测效应是绕不开的一步。

换个环境结论就变的建议要格外小心，四层架构分歧导致优化建议跨平台失灵是同一类陷阱。

所以要看差值有多大。89.1%的差异不超过60秒，中位数4秒；方向上也是压倒性的——32276条是后发的那次更新，只有130条反过来。这三条特征凑在一起只指向一个结论：这不是身份差异，这是我自己的测量顺序。

按站算也一样：61个站里有45个站的中位差值不超过60秒。

扣干净之后，真正的身份差异只剩3个站

把中位差值超过1天的站单独挑出来，只有三个：iittala.com有1550条，中位差1.8天；rituals.com有134条，中位差3.0天；otto.de只有1条，差6.3天。

爬虫拿到的可能压根不是页面，人机验证屏被当成正文索引是最难查的一种。

响应会不会因人而异也能量，说会变的3个站、真会变的17个站是同一种对照。

还有一个负结果值得记一笔：两种身份下114份文件的状态码全部是200，没有一份因为身份被拒。在别的实验里这个位置经常出现大批403，这次一次都没有——机器可读文件的待遇和普通页面确实不一样。

这条方法能搬到别的地方

判据可以固化成三问：第一，两次测量是不是真的同时发生的？第二，如果不是，被测的量在这段时间里会不会自己变？第三，观察到的差异，方向是不是压倒性地偏向后测的那一次？

一堆问题先修哪个得有依据，五百个站实测排出来的技术SEO优先级可以当排期底稿。

把审计交给自动化之前有三个前提，数据、方法与人工复核各要满足什么得先过一遍。

判断对面是哪一代程序只能看日志，AI爬虫到底有没有抓你的站那套挖法可以直接套用。

三个问题里只要有一个答不上来，报出去的差异里就掺着你自己的影子。这次的比例是89.1%——四分之一的差异里，九成是我造出来的。

41万条地址里，这个字段的整体面貌是什么样的？

前面几节都在拿动态说事，这一节回到静态口径，把这批数据完整摊开。

整站体检该查什么有现成框架，从抓取、内容到AI可见度的完整诊断清单可以照着排。

收录、排名、流量是三件事，没流量的时候先分清卡在哪一层能省掉一半无用功。

覆盖率58.7%，但站级分布是两头大中间小

410101条地址里有240643条带修改时间，占58.7%。

平台内置、通用工具与专属应用各有边界，三层框架怎么选能避免重复投入。

换成前后端分离之后这套基建要自己重搭，清单、重定向与规范网址集体失分是常见的第一课。

不装插件也能把这份清单做扎实，动态优先级、图片节点与分页缓存的写法是一份完整实现。

站级看是这样：116个站里12个站一条都不写，38个站条条都写，66个站部分写。部分写的那批多半是因为不同类型的地址由不同的模块生成——商品页有，专题页没有，博客有，落地页没有。

一条都不写的那12个站，反而是最省心的

这个说法听着别扭，但从信号质量的角度看确实成立。不写就是不表态，抓取方拿不到信息，会退回到自己的判断，代价是它得多花点力气。

每年清一次工具栈很有必要，12个站样本里的四维冗余与八步瘦身给了可执行的顺序。

装得越多越容易互相打架，应用栈精简、性能治理与冲突排查是同一个减法思路。

写了假的则不一样。它先给出一个明确的表态，抓取方按这个表态排一次序，事后发现不对再回来调整，中间浪费掉的抓取次数是实打实的。

这里有个容易被忽略的连带影响：这个字段还常常被拿去喂别的东西。有些站把它当成商品的更新日期渲染进页面，有些站的内部报表拿它统计维护频率。一旦源头是假的，下游几个地方会一起跟着假。

精度：12.7%只精确到日期

写了时间的那24万条里，30562条只写到年月日，没有时分秒，占12.7%。带时区标记的有210081条。两种写法都合规，时间格式规范里的完整日期与完整日期加时间两种形态都被允许。

结构化数据里的日期同样容易写错，把结构化数据调试这件事讲透那篇有逐字段的排查法。

几种日期写法各有各的场合，国际标准格式、清单与响应头之间的格式账算得很清楚。

还有一个数字为零：未来时间的条目一条都没有。这算是个好消息，说明至少没人把这个字段当成上架排期表用。

年龄分布：将近一半号称是当天改的

刚开始做数据分析先把工具理顺，三类工具与排名追踪的习惯是个不错的起点。

旧文章的处置有一套标准动作，更新、合并还是删除的四步判断可以直接搬。

新鲜度也能拿来换AI引用，内容新鲜度的五条实战法则说的是怎么做才算真更新。

老内容悄悄掉量是常态，内容衰退的识别与分级更新比盲目全量刷新划算得多。

整体中位年龄是1.12天。四分之一的地址号称是抓取前15分钟内改的。而最老的一条落在14.4年前，比很多做SEO的人入行还早。

把这张表跟前面的漂移实验放一起看就明白了：那48.4%里有相当大一块不是真的当天改过，只是它每次被读取的时候都会重新盖一个当天的戳。

为什么有些站的时间戳整整齐齐挤在同一秒？

翻这批文件的时候有个现象特别扎眼：不少文件里成百上千条地址共用同一个时间戳，一秒不差。

一个模板生成十份内容也是同样的机制，字符层看不出重复、信息层十份一模一样是它的另一面。

模板批量生成的东西撞车是常态，插件和主题各冒出一套规范网址怎么归一是同一类清理。

232份文件里，90份整份只有一个取值

把带修改时间不少于50条的文件挑出来一共232份，其中90份文件里所有条目的时间戳完全相同，占38.8%。

一次扒清页面上所有格式的字段缺漏，结构化数据审计工具怎么用那篇讲了操作细节。

结构化数据里也有大量批量填出来的字段，112个独立站里17个在犯的商家名称错误是一份对照。

几个具体的例子：bellroy.com的一份文件513条地址全部写着同一个日期；rapha.cc的93条全部是同一个毫秒；allbirds.com的291条共用同一秒。

aloyoga.com更整齐——三份文件分别是936条、986条、991条，前两份共用同一秒，第三份共用它的下一秒。2913个页面，两秒钟改完。

把这些时刻拉到同一个时区，它们落在同一分钟里

这才是真正有意思的地方。allbirds写的是06点16分18秒，aloyoga是06点16分19秒和20秒，avocadogreenmattress是06点16分23秒，baseus是06点16分30秒，beistravel是06点16分32秒。awaytravel和brooklinen写的是另一个时区的09点16分，换算过去也是06点16分26秒和55秒。

名单上那些名字有没有真来过也能量，266个爬虫令牌里只有23.3%真的来过是另一组实测。

这类没人维护的字段到处都是，响应头里248个死字段、多数不是你写的量的是同一种存量。

响应里冒出一个莫名其妙的日期，可能是运行环境替你写了一行1981年的时间就是这么来的。

七个互不相干的品牌，页面加起来好几千个，声称自己在同一分钟之内完成了修改。而那一分钟，恰好是我这台机器开始发请求的前后。

它们的共同点是跑在同一个电商平台上。平台在生成这份文件时把当前时刻填了进去，仅此而已。

这不是某一家平台的毛病

容易把这件事读成某个建站平台不行，但数据不支持这个说法。那18个整份全变的站里，既有跑在主流托管电商上的服装品牌，也有自建站的消费电子品牌，还有欧洲的连锁零售。它们唯一的共同点是这份文件由程序在请求时现生成。

默认值被人悄悄改掉更难发现，第三方默认行为变更造成的静默漂移是同一种失控。

第一年最容易踩的都是默认配置，跨四种建站系统共有的12项隐性失分可以逐条对照。

选平台时就该问清楚默认行为，托管、自建还是纯代码怎么选把各自的代价摊开了。

反过来，同一个平台上也有大量站的时间戳老老实实待在原地。差别不在平台，在于导出这份清单的那段逻辑到底读了什么——读数据库里的内容更新时间，就是对的；读系统当前时间，就是错的。这两行代码长得很像，写的人往往不觉得有区别。

更值得留意的是，这类默认值一旦定下来，后面接手的人几乎没有机会发现它不对。生成的文件格式合法，校验工具全部通过，搜索后台也不会报错。要发现它，你必须主动去做一次前后对照——而这件事不在任何一份常规检查清单上。

只写到日期的那12.7%是同一种毛病的低配版

只精确到年月日的写法，效果等于把时间戳的分辨率砍到一天。bellroy那513条就属于这一类——它们全都写着抓取当天的日期。

工具漏改的地方往往在它的视野之外，它只看紧挨着的那一个字就是这类边界。

分页那一层也常被平台简化处理，集合页分页的索引判断与规范网址设置需要单独理一遍。

这种写法的问题不在于不精确，而在于它同样是生成时算的。第二天再抓，日期会跟着换成第二天。

怎么一眼认出这种文件

不需要抓两次也能看出苗头：打开一份地址清单，看时间戳的不同取值有几个。如果几千条地址只有一两个取值，或者所有取值都挤在几秒钟之内，那基本可以确定它记的是生成时刻。

想看一个页面过去长什么样，缓存快照退役后还能用的几个工具能帮上忙。

桌面爬虫跑一遍就能看出不少毛病，全站审计的十二类问题排查清单是配套的检查表。

清单里混着坏地址也很常见，死链批量检测、分类到提交的一条龙能顺手一起做掉。

真正跟着内容走的文件长得很不一样——时间戳会散布在过去几个月甚至几年里，密度随着时间往回走逐渐变稀。

那44个处在中间的站，才是这个字段正常工作的样子

115个站里有44个既不是全变也不是全不变。这批站的形态值得看一眼，因为它们提供了一个可以对照的正常值。

商品数据一变就牵动一堆页面，八类重复内容的成因地图与诊断清单可以对照排查。

真正难缠的是筛选组合产生的地址，分面导航产生的海量地址怎么治理单独拆过一遍。

同一商品的几十个地址该合还是该拆，产品变体的地址与索引策略需要先想清楚再动。

它们的变动比例散落在几个百分点到几十个百分点之间，且集中在特定几份子文件上——通常是商品清单那几份在动，帮助中心和法律条款那几份不动。这正是一个真实电商站该有的样子：库存和价格每天变，退货政策一年改一次。

要注意的是，两小时里动几个百分点仍然偏多。更可能的解释是这批站的时间戳跟的不是内容本身，而是数据库里那行记录的更新时间——库存数字变一下，记录的更新时间就跟着变，页面上肉眼看不出任何区别。这算是个中间状态：开关接上了，只是接得比应该接的位置更靠前。

另一头的毛病：四年没动过的时间戳算不算问题？

前面说过还有46个站一条都没变。它们里面藏着方向完全相反的另一种病。

自动化不是哪天突然坏的，它从第二周就开始走形而没人发现说的是同一种慢性失效。

变更没人记就等于没发生，13类信号、5档工具栈与22周落地是一套变更日志的做法。

6个站的时间戳停在半年到四年以前

把这46个站按各自时间戳的中位年龄排一下，有6个站的中位年龄超过180天：

长期没人管的东西还有别的形态，测试站被索引后的八步清除与四层防御是最典型的一例。

新鲜度和常青资产要一起平衡，媒体站为什么总在这两者之间崩有完整的机制拆解。

上千篇旧内容的处置需要一套判据，留、改、并、删、转的决策系统比拍脑袋靠谱。

这几个都不是小站。它们的商品页在这几年里必然改过价格、改过库存状态、改过文案、改过图片。而那份清单上的时间，还停在改版那天。

两种病的机制其实是同一个

第一种是把这个字段接到了生成程序上，第二种是压根没接。看上去南辕北辙，本质完全一样：没有任何一个事件会触发这个值的更新。

同一批样本上量过的另一件事是，给单个爬虫开组会丢掉通配组全部规则中招比例高得离谱。

写下去却没有接收方的指令不止这一处，有多少条规则压根没人在读比想象中高得多。

第一种的触发源是文件被请求，第二种的触发源是某次人工导入。真正应该当触发源的那件事——页面内容发生变更——两种都没接上。

哪一种更糟

要看搜索引擎怎么用它。如果它每次都说全都是新的，那么它对所有地址的区分度为零，等于什么都没说；如果它常年不动，同样区分度为零。两种都是废字段，但后一种至少不会给人一种在正常工作的错觉。

收录速度本身也能当指标看，三个平台、三百个站的收录速度实测对比给了参照值。

有些指标该退休了，2026年该淘汰的九个SEO指标与替代方案列得比较果断。

需要说清楚的是，这个字段不写并不会招来惩罚。规范里它是可选的。真正的代价在于：一个大站的抓取资源是有限的，你放弃了一个本来可以用来引导抓取顺序的信号。

判断自己属于哪一种，只要两步

第一步，隔十分钟抓两次，看数字动不动。全都在动就是第一种。

做这行容易把自己耗空，一套个人审计五步法顺手也留给自己用。

三个平台的后台告警要分级处理，分级诊断与90天监控闭环能把噪声压下去。

想批量核对收录状态有配额限制，2000条配额下的监控管线怎么搭是一套现成方案。

第二步，如果不动，随便挑五个你确定最近改过的页面，看它们的时间戳是不是跟着改了。没跟着改就是第二种。

两步都过了才算这个字段是活的，而这批样本里能两步都过的站并不多。

索引文件那一层的时间，和子文件对得上吗？

大站的sitemap通常分两层：一个索引文件列出所有子文件，每个子文件再列具体地址。索引文件那一层也可以给每个子文件写一个修改时间，语义是这个子文件最后一次变动的时间。

两处说法不一致时该信谁是个老问题，工具说在头部、浏览器说在正文该信哪一边也是同一种分歧。

两层由不同团队维护是常态，后端工程师配合SEO的七个动作点是从22周账本里总结的。

1730条声明，只有70对能真正核对

索引文件里带修改时间的子文件声明一共1730条。能同时拿到子文件本体、可以做对账的有70对。

要批量订正历史数据得小心，怎么安全地批量改一批文章的SEO字段有可直接用的写法。

论坛程序也能自己拼出这份清单，免插件的导出改造与分页做法是个小而完整的例子。

对账办法很直接：索引里声明的那个时间，应该等于这份子文件里所有地址的最大修改时间。

只有32.9%对得上

70对里相差不超过60秒的只有23对，占32.9%。剩下47对的差值中位数是0.4天，最大的一对差了1374天，也就是将近3.8年。

两处说法不一致最后往往落到重复上，同域、跨域与参数变体六类全排查可以顺着查。

规范网址自相冲突也是常见故障，八种跨页场景与冲突诊断可以按图索骥。

两个声明同时出现该怎么判，九种场景下这两者能不能一起用有逐个场景的答案。

换句话说，同一个站的两层文件对同一批页面的最后修改时间给出了差着三年多的两个答案，而这两份文件是同一次导出生成的。

为什么会脱节

多数情况是两层由不同的代码路径生成：索引那一层由一个定时任务刷，子文件由另一段逻辑填。谁都没有义务去看对方写了什么。

把检查接进流水线才不会反复，自动化为什么不能放在最后一段做讲的正是这件事。

两段逻辑归两个团队就容易脱节，内容、技术、外链三类分工与团队配比是同一个协作问题。

还有一种更隐蔽：索引那一层写的是文件被重新导出的时间，子文件里写的是内容的时间。两个语义本来就不一样，但字段名是同一个。

这一层错了要紧吗

要紧程度取决于站的规模。子文件数量少的时候，抓取方会把每个子文件都读一遍，索引层写什么都无所谓；子文件成百上千的时候，索引层的时间会影响先读哪一份。

想知道抓取资源花在哪只能看日志，读懂抓取行为与预算浪费是配套的工具教程。

站的层级深浅直接影响能不能被找到，架构搭错了爬虫根本走不到商品页有对照实验。

没有交叉校验的余地，这件事严重在哪？

一个自我申报的数字要变得可信，通常靠两条路：要么有人核验，要么有另一个独立来源可以对照。这个字段两条都没有。

两处都能下同一道指令的时候容易搞反，这两个手段各管哪一段里分工写得很清楚。

响应头那一层能承载的信息比多数人以为的多，索引指令、缓存与协商字段各管什么有一份完整机制图。

694个页面响应里，只有13个带修改时间响应头

HTTP协议本身有一个字段专门用来说明资源的最后修改时间，位置在响应头里，协议规范里对这个字段的语义界定比清单那边严格得多。理论上它可以拿来跟sitemap里的声明对账。

有些地址连声明的地方都没有，接口和订阅源拿什么说自己不想被收录是同一类结构性缺口。

缓存这一整套字段配起来讲究不少，怎么让回头客秒开又不犯改了不更新的事故有逐项配置建议。

实测下来，694个页面的响应里只有13个带了这个字段，占1.9%。剩下98.1%的页面根本没有第二个时间可以拿来核对。

原因不难理解：现在的页面几乎都是动态生成的，服务端自己也说不清这个页面的内容是什么时候定稿的，索性就不写。

校验的最后一条路也堵着

还有一个办法是用内容指纹——如果两次抓取的页面字节完全一样，那就是没改。可惜页面上那些每次都不同的令牌和埋点参数让字节比对基本失效，必须先做归一化，而归一化的规则每个站都不一样。

正文藏在脚本里会让所有比对失效，三种渲染方式下的引用率差异实测给了量化的落差。

页面上哪些是内容、哪些是壳子并不好分，语义化标签到底影响不影响机器抓取拿样本页跑过一遍。

这就是为什么这个字段在实践中变成了一句没人查的话。

抓取方其实还有一条路，只是这条路上的站更少

HTTP协议里有一套条件请求机制：抓取方带上上次拿到的指纹再来问一次，服务端如果发现没变，就回一个不带正文的短响应。这个字段与条件请求怎么配合有一份写得很细的说明。这套机制既能省流量，又天然是一个诚实的变更信号，因为它由服务端在响应那一刻现算。

传输这一层还有别的浪费，出厂只压一种类型、其余字节全额计入抓取预算也值得顺手查。

没改过的页面被反复重发很浪费，服务器把同一个页面对爬虫重发几百遍是怎么发现的写在里面。

这套机制的普及度实测过，142个站只有52个回得出那个短响应就是那次的结论。

问题是能正确回应这套机制的站同样不多。更早一批实测里，142个站只有52个在没改的情况下回得出那个短响应，其余的每次都把整个页面重发一遍。

两条路都走不通的结果是：抓取方只能靠自己反复抓、反复比，用统计的办法猜哪些地址值得常来。你在清单里写的那个时间，在这套猜测里的权重，取决于它历史上有多准。

搜索引擎那边怎么处理

Google的公开说法是这个字段只有在一致且可信的时候才会被参考。这句话反过来读就是：它已经默认相当一部分站写的是假的，所以先看一致性再决定信不信。

手动提交能不能加快收录也被问烂了，真相与配套的排查清单那篇答得比较干脆。

一个信号在整条链路里的位置决定它的分量，召回到重排四个阶段各看什么有完整拆解。

声明与实际判定不一致是常态，规范网址选择的九条决策逻辑解释了它凭什么不听你的。

怎么判断一致？最省事的办法就是隔一段时间抓两次，看这个值是不是跟着请求走——跟我做的实验一模一样，而且他们抓的次数比我多得多。

AI那边的抓取器读不读这个字段？

这个问题现在还没有可靠答案，能说的只有几条负结果，但负结果也是结果。

第一，各家AI抓取器都没有公开承诺过会参考这份清单里的时间。它们的公开文档里通常只写遵守哪些抓取规则，不写按什么顺序抓。

第二，从行为上看，这类抓取器更依赖从页面链接出发的遍历，以及用户当场提问触发的实时取回。后一种模式压根用不上任何预先排序——用户问了，它现在就去取，不管这个地址上次什么时候改过。

第三，同一批样本里给AI准备的那份纯文本清单，规范新增的两种链接关系在631个页面里采用数为零。这说明这一层的基建还很早期，谈不上谁在读谁的时间戳。

所以务实的判断是：修这个字段的收益目前只落在传统抓取那一侧。如果你的动机是让AI更快看到新内容，力气花在别处更划算——比如让页面在不执行脚本的情况下就能读出正文。

回到开头那条新闻

官方说尽量让公告贴近按下按钮的那一刻，为什么这件事需要专门解释？因为“发生”和“被记录”之间那道工序，永远存在。区别只在于有没有人认真去缩短它。

核心更新来了先别慌，六步落地的应对动作比到处打听消息管用。

算法更新的时间线值得留一份，完整盘点、评估体系与应对策略可以当索引用。

sitemap里那个字段的问题不是有人存心撒谎，而是写它的那段代码，只在文件被生成的那一刻运行过一次，此后它再也没有机会知道页面发生了什么。

自己站上怎么查，查完该改哪里？

前面全是别人家的数据，这一节说自己怎么办。整套检查一个人半天能做完，不需要额外工具。

技术项全绿也可能不涨，问题多半出在搜索意图没对齐是另一条要并行看的线。

同样的问题在不同规模的站上优先级不同，三类站点的高投入产出比修复顺序可以直接套。

五步自查顺序

第一步，抓两次隔十分钟的同一份地址清单，比对时间字段。全变说明接在生成程序上，全不变进第二步。

两个来源给的收录数不一样时，六种场景下该信谁与三源校准给了判据。

用命令查收录有它的适用边界，这个命令什么场景能用、什么时候会误判说得比较细。

后台那份抓取报告要会读，五类问题地址的占比与排查顺序能帮你分清是谁的问题。

第二步，挑五个最近确实改过的页面，看它们的时间戳有没有跟着变。没变说明这个字段是死的。

第三步，看一份文件里时间戳的不同取值有几个。几千条只有几个取值，就是批量盖章。

第四步，如果是两层结构，拿索引层声明的时间跟子文件里的最大时间对一下。

第五步，看看页面响应头里有没有修改时间字段。有的话跟清单里的值对一下，两边差得离谱说明至少有一边是编的。

三条判据，问的是同一件事

把上面五步压缩成三个问题：这个值是谁写进去的？世界上发生什么事它才应该改？那件事发生的时候，有没有任何东西会去通知写它的那段代码？

服务器上那些数值型配置也该逐条问一遍，二十项配置对SEO的实际影响可以照着核对。

配置每次都通过不代表没事，每八次抓取就有一次撞在跳转上是同一类隐形代价。

第三问答不上来，前两问答得再漂亮也没用。一个字段能不能长期保持正确，靠的不是当初写得多用心，而是它背后有没有一个“什么时候该改我”的开关。

要修的话改哪一层

最正确的做法是在内容层埋一个更新时间，页面每次保存时写一次，导出清单时直接读它。这需要后台配合，多数团队卡在这一步。

导出之后还要把新地址推出去，实时推送与异步队列的做法是配套的一环。

批量订正历史数据免不了直接动库，分批更新与时间字段同步的写法有可复用的语句。

老程序里改一次内容就冲掉发布时间，怎么改文章又保留原发布时间是同一个字段该由谁写的问题。

退而求其次，可以在导出程序里加一层缓存：把上一次导出的地址与时间存下来，这次导出时只有内容指纹变了的地址才更新时间，其余沿用旧值。这个方案不需要动业务代码，成本主要在存那份快照。

再退一步，如果两条路都走不通，那就别写。空着比乱写强，理由前面说过——一个对所有地址都给同样答案的信号，等于没有信号。

把检查接进流程，别做成一次性巡检

这件事最容易的失败方式是：这次查出来了，改好了，三个月后原样回来。原因很简单，改的是数据，没改产生数据的那段逻辑。

重复劳动该交出去就交出去，六类耗时任务的自动化方案按投入产出排过序。

这类脚本现在写得比过去快，怎么搭一条SEO自动化工作流有完整实测。

把巡检串成工作流并不难，四个场景闭环把内耗变成产线有现成的编排思路。

可以接的地方有两处。一是在导出流程的末尾加一道断言：如果这次导出的时间戳里，取值数量少于地址数量的某个比例，就让流程报错而不是安静地发布。这条断言写起来不到十行，能挡住批量盖章那一整类问题。

二是留一份上次导出的快照，每次导出后对比两次的时间戳分布，变动比例超过阈值就发一封邮件。这条能挡住的是另一类：某次上线之后生成逻辑被人改了，而没有人注意到。

两道都加上，这个字段才算真正有人管着。只做一次巡检，得到的只是一张三个月后就过期的快照。

什么情况下干脆不必管它

地址少于几千条的站，抓取方大概率会把全部地址都读一遍，这个字段影响很小，花力气去修性价比不高。

小站的力气该花在别处，把计算器和生成器做成链接磁铁可能回报更高。

任何改动都要给它时间，收录、爬坡到起量的真实时间线能帮你管理预期。

地址上万、页面更新频率差异很大的站才值得认真做——比如商品页天天变、帮助中心一年不动的那种，这个字段能实实在在改变抓取的先后顺序。

修好之后能拿回什么，可以粗算一笔

这笔账算法不复杂。假设一个站有5万个地址，抓取方每天大约来看几千次，那么把全站过一遍需要十几天到几十天不等。

如果这份清单里的时间是可信的，抓取方可以把力气优先放在真正改过的那几百个地址上，剩下的按更低频率轮转。你新上的商品从上架到被发现的时间，可以从以周计缩短到以天计。

如果这份清单里的时间对所有地址都一样，这个优先级就无从谈起，抓取方只能按自己的历史统计去猜。猜的结果通常是：过去经常变的那类地址多来几趟，其余的慢慢排队。对一个刚上线新品类的站来说，这个默认策略相当不友好，因为新品类没有历史。

换句话说，这个字段的价值在改版和上新的时候最大，平时看不出来。这也解释了为什么它长期没人管——它不出问题的时候完全隐形，出问题的时候你又很难把掉量归因到它头上。

顺手说说旁边那两个字段

这份清单里还有两个常被一起写上的字段：更新频率和优先级。它们和修改时间是同一类东西——自我申报、没人核验，区别只在于它们连一个可以被证伪的事实都没有。

修改时间至少还对应着一件客观发生过的事，你可以拿页面去核对。更新频率写的是你打算多久改一次，优先级写的是你觉得这个页面在自己站内有多重要。这两件事只存在于你脑子里，外部无从验证，所以抓取方早就宣布不再参考它们。

实践中的建议很简单：这两个字段直接删掉。留着它们唯一的作用是让文件变大，以及让下一个接手的人以为它们还在起作用。样本里仍然有相当一批站在认真维护这两栏，那些力气基本是白花的。

一张判断表

推不动改动往往不是技术问题，重写汇报方式的八个步骤比反复解释有效。

把口头约定写成文字永远划算，达标定义、违约责任与四类经典纠纷是另一个场景的同一道理。

顺带一个和内容策略有关的提醒

有人会想：既然这个字段这么容易写，那把它全刷成今天是不是能让页面显得更新鲜？这条路走不通，而且代价不小。抓取方会拿它跟页面实际变化对账，对不上的站会被降低这个信号的权重——一旦被降权，你以后真的更新了它也不认。

结构化数据也常被当成灵丹妙药，它对AI搜索到底有没有用有官方说法加实测。

旧文章翻新是有章法的，十二步把旧版改成可被引用的来源比改日期实在得多。

批量生成的东西容易长得一样，五步差异化的实战办法能救回一部分。

换句话说，这个字段最大的价值来自它的诚实度，而诚实度是一次性的信用。攒起来要很久，花掉只要一次批量刷新。

真要让页面显得更新鲜，办法还是那个笨办法：把内容改到真的值得被重新看一遍，然后让这个字段如实记下改动那一刻。它不是一个可以单独优化的开关，它只是一个记录仪——记录仪本身没有价值，它记的东西才有。

常见问题解答

sitemap里的修改时间到底会不会影响排名？

不直接影响排名，它影响的是抓取的先后顺序。抓取方拿它决定先去看哪些地址，这个决定间接影响你的更新多久能被发现。规范里这个字段是可选的，写不写都不算错。但如果写了却写得不诚实，被识破之后这个信号在你站上就作废了，等于自己把一个免费的引导工具关掉了。

怎么判断我站上的这个字段是不是假的？

最快的办法是隔十分钟把同一份地址清单抓两次，比对每条地址的时间。如果绝大多数条目都往前挪了十分钟，那它记的就是你请求的那一刻。实测样本里115个站有18个是这种情况，占15.7%。要用同样的请求身份抓两次，并且避开浏览器缓存，否则第二次可能拿的是本地副本。

整份文件几千条地址共用同一个时间戳，一定有问题吗？

基本可以确定有问题。样本里带时间戳不少于50条的232份文件中，90份整份只有一个取值，占38.8%。真实的内容更新不可能这么整齐——它一定是长尾的，少数页面动、多数不动，时间戳会散布在过去几个月里。唯一的例外是那份文件本来就只装同一批同时上线的页面，比如一次性导入的活动页，这种情况在实践中很少见。

这个字段常年不动，比每次都刷新更好还是更差？

两种都是废字段，区别只在观感。常年不动至少不会误导人，而每次都刷新会让维护的人以为它在正常工作。样本里有6个站的时间戳中位年龄超过180天，最久的停在4.3年前。判断自己属于哪一类只要两步：先看抓两次动不动，再看确实改过的页面有没有跟着动。两步都通过才算这个字段是活的。

只写年月日不写时分秒，可以吗？

格式上完全合规，规范允许只写日期。但要注意它常常是同一个毛病的低配版——把分辨率砍到一天之后，仍然可能是每次生成时填当天日期。样本里12.7%的条目只精确到日期，其中不少属于这种情况。判断办法一样：隔一天抓两次，如果日期跟着换了而页面没改，那它记的还是生成时刻。

索引文件那一层的时间要不要写？

可以不写。真要写就得保证它等于对应子文件里的最大修改时间，否则不如空着。实测70对可对账的声明里只有23对对得上，占32.9%，最离谱的一对差了1374天。脱节的原因通常是两层由不同的代码路径生成，谁也不看谁写了什么。子文件数量少的时候这一层无所谓；子文件成百上千时它会影响抓取方先读哪一份。

响应头里的修改时间和sitemap里的，哪个更可信？

理论上响应头更接近服务端的真实状态，实践中它基本不存在——694个页面里只有13个带了这个字段，占1.9%。动态生成的页面服务端自己也说不清内容什么时候定稿，所以干脆不写。这就是为什么sitemap里的声明缺少一个独立来源可以对照，也是它长期以来没人查的根本原因。

修这件事需要后端配合到什么程度？

最彻底的做法要动内容层：页面每次保存时写一个更新时间，导出清单时读它，这需要后台改字段。如果推不动，可以只在导出程序里做——把上一次导出的地址与时间存成快照，这次只有内容指纹变了的地址才更新时间，其余沿用旧值。后一种方案完全不碰业务代码，成本在于要存一份快照，适合作为第一步先落地。

权威参考资料