Sitemap里的网页lastmod，应该反映这张网页最后一次重大更新。地图今天重新生成，旧文章没有变化，就不该把全部旧页都标成今天更新。日期没有可靠来源时，这个可选字段可以先不填。
实际维护时，要顺着“正文改了什么→系统记录什么日期→生成器输出什么→访客看到什么”检查。只看地图里日期够不够新，容易修错地方。
lastmod记录哪一次更新
lastmod可以理解为“这个地址对应的内容，最后一次有实质变化是什么时候”。它帮助搜索引擎理解更新情况，但不等于要求Google当天抓取，也不是提高排名的按钮。
先看日期旁边是什么地址
在XML中找到loc，它给出条目指向的对象。下面是一个教学网页条目：
<url>
<loc>https://example.com/selection-guide/</loc>
<lastmod>2026-10-06</lastmod>
</url>
这里的日期属于选型指南。如果你看到的外层文件列的是post-sitemap.xml等子地图，那个条目的lastmod描述子地图文件，不能拿它代替每篇文章的更新日期。
比如今天新增一篇文章，子地图内容变了，外层索引可以反映文件更新；子地图中另一篇没改的旧文，不会因此得到新的内容日期。这两个层级在Sitemaps协议中有不同对象。
哪些变化值得反映到日期里
新页首次发布后，还没有后续修改，可以使用有依据的初始日期。旧页以后补充关键适用范围、更正影响判断的参数、调整重要结构化事实或重要链接，应按实际重大更新记录。
以选型指南为例，原文只写“适合户外”，后来核实并补充使用温度与不适用环境，这会改变读者的选择。页脚版权年份变了，或某个标点改了，通常不属于同一程度的变化。
Google强调准确、可验证和重大更新，范围包括主要内容、结构化数据及重要链接，见Google的地图说明。这里没有一个通用“改满多少字”的门槛。AI多写两段重复内容，也不能自动成为重大更新。
日期可以只写年月日，也可以写带时区的完整时间。只要准确并符合格式，不必为了显得精细，给没有时间记录的旧文章编出几点几分。
WordPress里的日期，从哪里来
WordPress后台保存的修改时间，与公开地图里的lastmod，中间还有一层生成逻辑。理解这条关系，才能知道应该查文章、插件还是缓存。
先确认谁在输出当前地图
站点可能使用WordPress核心地图、SEO插件地图或自建脚本。常见入口如/wp-sitemap.xml、/sitemap_index.xml，只是寻找线索，不能保证每个站都使用这些地址。
先打开当前GSC已提交的地图入口，确认它能正常访问，再进入列出目标文章的子地图。还可以查看站点已有的地图配置和robots.txt中的Sitemap声明。重点是找到正在使用的输出，避免修改一份已经停用的文件。
没找到入口时，先按XML Sitemap生成与排错定位。不要为了补lastmod再装第二个SEO插件；多个生成器会增加“改的是谁、Google读的是谁”的混乱。
CMS修改时间不理解内容的重要性
WordPress修改时间字段记录系统认为这条内容何时被修改。它不会阅读文章，判断新加一句话是否改变读者决策。自动化任务、批量保存或页面构建流程，也可能影响系统记录；实际行为要检查当前实现。
地图生成器可能读取该字段，也可能使用其他日期来源。插件配置、开发者过滤器和自建脚本，都可能改变输出。不能看到后台保存时间正常，就直接断定地图一定正确。
一条清楚的检查链是：编辑先说明改了什么，维护者确认系统记录，再检查生成器选了哪个字段，最后读公开XML。某一层不同步，就沿那一层定位，别同时改日期、换插件、清全站缓存。
如果使用Yoast，官方说明地图会随内容变动自动维护，通常无需每天手工重建；缓存和自定义过滤可能影响更新，见Yoast地图不更新的排查。其他插件也应按各自说明查实际来源，不能照搬同一个菜单或代码片段。
用三张页面，走完一次检查
选一篇这次确实要更新的指南，再挑一篇旧文和一张产品页作对照。后两张本次不改，这样才能看出日期是不是被全站一起刷了。
以下是教学安排：选型指南补充已核实的适用限制；安装旧文和P31产品页没有变化。
修改之前，保存这三个条目
打开真正列出它们的子地图，用浏览器查找完整URL，记下各自lastmod。保存URL和原值即可，不需要抄整份地图，也不要只截外层索引的日期。
同时记下计划修改的内容。比如“选型指南补充高温环境不适用的条件”，这能在事后核对正文与日期是否对应。仅记录“更新文章”，维护者看不出更新是否已经公开。
发布之后，先看正文再看XML
以未登录访客打开指南，确认新增信息确实可见。若公开页还是旧版，先解决发布或页面缓存；这个时候反复刷新地图，不会让读者看到新内容。
正文确认后，再查指南的子地图条目，以及另外两页。预期结果如下：
| 页面 | 修改后应看到什么 |
|---|---|
| 选型指南 | 新信息已公开，日期反映本次重大更新 |
| 安装旧文 | 内容未改，保留原日期 |
| P31产品页 | 内容未改，不随地图重建刷新日期 |
指南变化、其他两页不变，说明本次输出与三个对象的实际状态相符。这是一次有边界的验证，不能由三张样本推断所有历史页面都没有问题。
如果三张一起变成今天，查日期来源是否统一用了生成时间。如果指南正文已新、地图日期仍旧，查生成与缓存。如果只有外层索引变化，先分清对象，不急着判错。
最后把“改动说明、公开时间、目标URL、原日期、新日期和两张对照页结果”放进同一份维护记录，下次就能按同样方式复查。
发现日期不对，修真正出错的一层
全站日期每天都变
先在没有发布内容的两个日期各保存一次地图，比对同一批URL。某天打开看到全是当天日期，只能说明当天的现象，还没有证明“每天都刷新”。
确认规律后，让维护者查生成器是否填了请求时间、脚本运行时间或文件构建时间。如果是，应改成有依据的页面更新时间。没有可靠来源的字段可以暂时省略，别反过来给每篇旧文随便加一句话，配合错误日期。
正文已更新，地图仍是旧日期
先分两种结果：公开正文旧，查发布和页面缓存；公开正文新、XML旧，查地图生成器及地图响应缓存。缓存可能来自插件、服务器或CDN，后台只清一个页面缓存按钮，未必清到了地图。
给维护者的记录可以写成：
指南已公开新增适用限制，当前子地图仍显示旧日期；安装旧文与P31未改，日期正常。请检查指南的日期来源和该子地图缓存，修后复核同三个URL。
按当前插件和主机说明处理相关缓存，不必为一个地图日期问题直接关闭全站缓存。也不要先批量重存所有文章，让原来能用于定位的差异消失。
时间差正好8小时
检查完整时间戳是否使用UTC或其他时区。UTC与北京时间相差8小时，同一时刻会有两种写法；先换算，再判断是不是更新延迟。只有日期的条目，不提供具体时刻，也不能据此排出小时级发布先后。
地图没有lastmod
它是可选字段，缺少不等于整份地图失效。先看URL是否正确、文件是否可访问、内容是否能够抓取；确定有可靠更新时间来源后，再安排生成器补充。别给所有旧页默认填今天。
修好之后，可以在GSC查看地图是否被正常读取，并针对重要URL检查实际抓取与索引。这些检查分别回答“地图读到了吗”和“网页处理得怎样”，日期正确不保证当天收录。
把这套记录纳入文章生产与维护流程，重要旧文每次真正更新时再核对。若有多套脚本、插件或缓存，带地图入口和三个样本URL联系跨境YOUNG，能更快确定该查哪一层。更多方法见Google SEO学习中心。
常见问题
改一个错别字，就必须把lastmod改成今天吗？
普通文字修正通常不必专门刷新。关键参数纠错可能改变实际判断，应结合影响处理。系统自动记录了一次保存，也不等于这次保存都是重大更新。
子地图今天重建，外层索引日期变了，是错的吗？
不一定。外层索引日期描述子地图文件，网页条目日期描述网页。先看loc指向什么，再判断是否把文件时间误填给全部旧文。
文章很久没改，会不会因为日期旧就掉排名？
不能只凭日期判断。先看内容是否仍准确、需求是否变化、页面是否有其他问题。需要更新就补真实信息，不为让日期变新而重复扩写。