时间戳不只是给访客看的
很多站点对页面时间的处理很随意：模板里塞一个日期，更新时随手改一下，列表页按某个字段排序，谁也没去核对这几处是不是同一个值。等到内容开始变多、栏目开始堆积，问题就显出来了：有的页面明明改过，列表里却沉在很后面；有的页面几年没动，列表里却排在最前面。
时间戳至少同时服务三件事：访客判断内容是否还有效，站内列表和检索的排序依据，以及蜘蛛重抓时对页面新鲜度的参考。这三个用途对时间的要求是一致的：真实、统一、可解析。
常见的几类时间戳问题
显示时间与源码里的时间不一致
页面正文上方写着 2023 年 5 月，HTML 里的发布日字段写的却是另一个日期，结构化数据里又是第三个值。访客看到的是一个答案，机器读到的是另一个。这种不一致往往来自两套系统：编辑在后台填了发布日期，模板渲染时又取了一次创建时间。
批量操作把全站时间刷成同一天
改一次模板、跑一次批量替换、调整一次内链，如果脚本里带了更新时间字段的写入逻辑，全站页面的时间可能一起变成当天。结果是列表页里几百篇文章挤在同一天，排序失去意义，访客也会觉得这个站点的时间信息不可信。做批量操作前，先确认脚本会不会写入时间字段。
只有发布日，没有更新日
有些站点只展示一个日期，更新时直接把它覆盖成新日期。访客无法判断这是新文章还是老文章翻新，历史记录也丢掉了。更常见的反例是另一个极端：更新日长期不动，页面内容已经改了三版，时间还停在三年前。
列表页和详情页对不上
列表页按创建时间排序，详情页显示的是编辑手动填的日期，两边不一致时，访客点进去会觉得错位。这类问题的根源通常是排序字段和展示字段取了不同的数据源。
时间格式难解析
“三天前”“上个月”“2024 年年初”这类表达对访客友好，对解析不友好。相对时间还会随访问时间变化，缓存之后更容易出现偏差。机器可读的时间建议使用带时区的标准格式，展示层再转换成友好文案。
草稿和定时发布提前暴露
定时发布的文章如果提前生成静态页面并开放访问，会出现发布时间还没到、页面已经能被抓到的尴尬情况。草稿、预览链接同样要注意是否被外部访问到。
一份可执行的自查清单
- 抽取 20 个有代表性的页面，逐个对比页面显示时间、HTML 中的时间字段、结构化数据中的时间，确认三者一致。
- 回顾最近一次批量操作的时间，检查有多少页面的更新时间被集中改动过。
- 确认列表页的排序字段来源，和详情页展示字段是否同一个值。
- 检查时间格式是否统一，机器可读部分是否带时区。
- 抽查定时发布和草稿链路，确认未到时间的页面不会被访问到。
- 翻一遍旧文章，看看有多少页面的更新日与内容实际修改情况明显不符。
更新时该怎么处理
- 有实质修改才动更新时间。改个错别字、换个标点，不必刷新日期；补充了数据、修订了结论、调整了结构，才值得更新。
- 保留发布日，另起更新日。两个值都留着，访客能看到这篇文章的生命周期，列表排序也有据可依。
- 在文末写一句更新说明。比单纯换个日期更有信息量，也方便日后回溯改了什么。
- 别为了“显得新”而改日期。时间信息一旦失去可信度，再想让访客相信就难了。
时间戳是页面上最容易被忽略的字段之一，也是最容易在批量操作里被顺手改坏的地方。把它当成需要维护的数据，而不是模板里的一行装饰。
定期花半小时抽查一批页面的时间信息，成本不高，但能避免列表排序失真、访客误判和内容生命周期混乱这几类麻烦。站点越大，这件事越值得做成固定动作。