搜索引擎读 sitemap 的时候，会看每条地址后面的那个日期：lastmod。它用这个日期判断"这页值不值得再来一趟"。
如果全站 498 条地址的日期都是同一天，等于每天告诉它：我们全站重写了一遍。头一次它可能还信，第二次就开始打折，等到真有内容更新那天，它反而不来了。
我们站原来的情况就是这样：498 条，全部是构建当天。
背景：498 条日期全是构建当天
上面两段就是背景。下面的过程，是我们把它改掉的两周里踩到的两个坑。
过程：坑一——以为改一个函数就够了
站上的页面不是一种方式生成的，是四种：
- 大多数内页走主模板，在同一个函数里拼出来；
- 首页是自己一份独立模板，不经过那个函数；
- 三百多页第三方目录，是另一个脚本直接写盘的；
- 早期文章是从旧站整页搬过来的，只换页头页脚，正文一个字节不动。
初版我们只在主模板那个函数里加了日期逻辑。跑完自测：首页没有，目录页查不到，老文章没有。498 条里只有一百来条被改到，其余照旧。
过程：坑二——补丁打早了会被后面的步骤盖回去
把三类漏掉的页补上之后，再跑一遍，还有一页反复漏。查下去发现：那一页在我们流程的后段还会被整体重建一次。我们先前注入的内容，连同一整段结构化描述，被新生成的版本覆盖了。
麻烦的地方在于日志：它还写着"已注入 1 页"。补丁确实执行了，只是执行完就被推平。这种错最难查，因为每一步单看都是成功的。
改法只有一句：所有"给全站打补丁"的动作，全部挪到最后一步，统一扫一遍。前面谁重建都不怕，最后一步跑在所有人后面。
技术路线：给每页存一份内容指纹
日期不能靠"今天构建过"来写，只能靠"内容真的变过"来写。我们给每页算一个指纹：标题、描述、正文三样拼起来取哈希，存成一份台账。
下次构建时逐页比对：
- 指纹一样 → 内容没动 → 沿用台账里的旧日期；
- 指纹不一样 → 内容动过 → 写今天，并且更新台账。
于是同一天里，只有真被改过的页面日期会跳，其余保持原样。目录页也被单独做了指纹，不再一锅端。
结果：怎么证明这不是摆设
只跑一次"全站都是今天"，是看不出真假的——全站一个日期和全站真日期，读数长得一样。
我们做了一次反证：把某一页的日期手工改成 9 月 1 日，正文一个字不动，重新构建。如果机制是真的，这页必须还是 9 月 1 日。
结果它保留了。再把那段正文改一句，重跑，它才跳到当天。到这一步才算把机制验住。
结果：顺带补的两件事
一是优先级。498 条里，三百多页是第三方目录，对读者价值低但对检索有用；我们没把它们屏蔽掉，而是把优先级压到 0.2，另外单出一份"只含 111 条真内容页"的核心清单，两份都声明在 robots 里。
二是结构化描述。全站 497 页都补上了层级导航（面包屑）和更新日期，82 篇文章补了作者和发布时间。这些不直接影响排名，但决定了机器能不能准确判断"这页是谁写的、什么时候改的"。
沉淀：一句结论
给机器看的元数据，贵的不是"写全"，是"写准"。宁可少写一条，不要写一条假的——写假的那条，会把你真实的那条一起废掉。
关于本文：内容由 AI 辅助整理、发布前经人工复核（依《人工智能生成合成内容标识办法》明示）。
首发：zby.info/blog/sitema… （站内同源，改稿以站内为准）
出品：伯阳AI（BoyangAI）｜深度优化国产算力上的 AI 能力交付，运行于国家超算互联网。能力、验证、账单全公开。
主体：海口龙华熵憬信息咨询工作室（统一社会信用代码 92460000MADJ50056L，可在国家企业信用信息公示系统按码查验）
可核验记录：zby.info/verificatio…
