時間戳不只是给訪客看的
很多站点對頁面時間的處理很随意：模板里塞一個日期，更新时随手改一下，列表頁按某個字段排序，谁也没去核對這几處是不是同一個值。等到内容開始變多、栏目開始堆积，問题就顯出来了：有的頁面明明改過，列表里却沉在很後面；有的頁面几年没動，列表里却排在最前面。
時間戳至少同时服務三件事：訪客判断内容是否還有效，站内列表和检索的排序依據，以及蜘蛛重抓时對頁面新鲜度的參考。這三個用途對時間的要求是一致的：真實、统一、可解析。
常见的几類時間戳問题
顯示時間與源碼里的時間不一致
頁面正文上方寫着 2023 年 5 月，HTML 里的發布日字段寫的却是另一個日期，结构化資料里又是第三個值。訪客看到的是一個答案，机器讀到的是另一個。這種不一致往往来自两套系統：編輯在後台填了發布日期，模板渲染时又取了一次建立時間。
批量操作把全站時間刷成同一天
改一次模板、跑一次批量替換、調整一次内鏈，如果脚本里带了更新時間字段的寫入逻辑，全站頁面的時間可能一起變成当天。结果是列表頁里几百篇文章挤在同一天，排序失去意义，訪客也會觉得這個站点的時間信息不可信。做批量操作前，先確認脚本會不會寫入時間字段。
只有發布日，没有更新日
有些站点只展示一個日期，更新时直接把它覆盖成新日期。訪客無法判断這是新文章還是老文章翻新，歷史记錄也丢掉了。更常见的反例是另一個极端：更新日長期不動，頁面内容已经改了三版，時間還停在三年前。
列表頁和詳情頁對不上
列表頁按建立時間排序，詳情頁顯示的是編輯手動填的日期，两邊不一致时，訪客点進去會觉得错位。這類問题的根源通常是排序字段和展示字段取了不同的資料源。
時間格式难解析
“三天前”“上個月”“2024 年年初”這類表達對訪客友好，對解析不友好。相對時間還會随訪問時間變化，缓存之後更容易出現偏差。机器可讀的時間建议使用带时区的标准格式，展示层再轉換成友好文案。
草稿和定时發布提前暴露
定时發布的文章如果提前生成静態頁面並開放訪問，會出現發布時間還没到、頁面已经能被抓到的尴尬情况。草稿、预览連結同样要注意是否被外部訪問到。
一份可执行的自查清單
- 抽取 20 個有代表性的頁面，逐個對比頁面顯示時間、HTML 中的時間字段、结构化資料中的時間，確認三者一致。
- 回顾最近一次批量操作的時間，检查有多少頁面的更新時間被集中改動過。
- 確認列表頁的排序字段来源，和詳情頁展示字段是否同一個值。
- 检查時間格式是否统一，机器可讀部分是否带时区。
- 抽查定时發布和草稿鏈路，確認未到時間的頁面不會被訪問到。
- 翻一遍舊文章，看看有多少頁面的更新日與内容實际修改情况明顯不符。
更新时该怎么處理
- 有實质修改才動更新時間。改個错別字、換個标点，不必刷新日期；补充了資料、修订了结论、調整了结构，才值得更新。
- 保留發布日，另起更新日。两個值都留着，訪客能看到這篇文章的生命周期，列表排序也有據可依。
- 在文末寫一句更新說明。比單纯換個日期更有信息量，也方便日後回溯改了什么。
- 別為了“顯得新”而改日期。時間信息一旦失去可信度，再想让訪客相信就难了。
時間戳是頁面上最容易被忽略的字段之一，也是最容易在批量操作里被顺手改坏的地方。把它当成需要维護的資料，而不是模板里的一行装饰。
定期花半小时抽查一批頁面的時間信息，成本不高，但能避免列表排序失真、訪客誤判和内容生命周期混乱這几類麻烦。站点越大，這件事越值得做成固定動作。