做站点运营的时候，很少有人會把“時間”当成一個需要检查的配置項。但蜘蛛判断一個頁面要不要重新抓取，除了看内容變化，也很依赖服務器给出的時間信息：Date、Last-Modified，以及 Sitemap 里的 lastmod。這些時間只要互相矛盾，蜘蛛拿到的就是一套混乱的信号。
先统一服務器的“表”
服務器时区没统一，是最常见也最容易被忽略的問题。同一台机器上，系統时区、應用執行时（PHP、Node、Java）时区、資料库时区可能各不相同，于是寫進頁面的時間和寫進日誌的時間能差好几個小时。
- 系統层面固定一個时区（UTC 或固定的東八区），不要依赖服務器所在地的預設值；
- 應用執行时單獨設定时区，避免系統改了、代碼還在用舊預設值；
- 資料库连接时区與寫入时区保持一致，防止存進去的是 UTC、讀出来当成本地時間；
- 多台服務器或容器节点之間開啟 NTP 對时，否則各节点時間漂移，集群里同一次抓取的時間戳都對不上。
日誌時間和頁面時間對不上，结论就會错
日誌里记錄的是服務器時間，而你分析时看的是自己电脑的時間。如果两者差 8 小时，很容易得出错誤结论：以為蜘蛛凌晨三点最活跃，實际那是晚上十一点；以為某個栏目一整天没被抓，其實只是統計窗口错位了。
做日誌分析前，先把日誌時間換算到统一基准，並在结论里标明用的是哪個时区。如果日誌格式里没有时区标识，建议在格式中加入偏移量，省得以後每次都要靠猜。
Last-Modified 與 Sitemap 的 lastmod 要對得上
Last-Modified 只精确到秒，而且應该是真實的修改時間。常见的几種错誤寫法：
- 模板改動或部署上线时批量刷新了全站頁面的 Last-Modified，让蜘蛛誤以為所有内容都更新了；
- 時間戳被寫成了未来時間，蜘蛛可能直接忽略這個值，甚至把頁面当作異常；
- 頁面正文里顯示的更新時間和 HTTP 头里的時間不一致，用戶看到“今天更新”，头里却是半年前。
Sitemap 里的 lastmod 同理。用 W3C 格式（YYYY-MM-DD 或带时区偏移的完整時間）就够了，不建议為了顯得新鲜而每天整站改成当天。如果所有 URL 共用同一個時間戳，基本等于告诉蜘蛛這份時間表没有參考價值。
定时發布與缓存過期
定时發布功能如果时区設定错了，會出現两種尴尬情况：内容提前可见，或者蜘蛛按时来抓却只拿到空頁面和 404。發布前可以確認這几点：
- 發布任務的調度时区與站点展示时区一致；
- 草稿、预览地址不被蜘蛛訪問，避免抓到未完成内容；
- Expires 與 Cache-Control 的 max-age 和内容更新频率匹配，別让頁面改動後還要等很久才生效。
一份可以照着做的自查清單
- 记錄系統、應用、資料库、CDN 四個环节各自的时区，確認它們一致；
- 抽查几個頁面的响應头，检查 Date 與 Last-Modified 是否合理、是否晚于目前時間；
- 從 Sitemap 里取若干 URL，與頁面實际更新時間逐條比對；
- 把日誌時間換算到统一时区，再看一遍抓取时段分布；
- 检查定时發布、缓存刷新任務是否按时区正确执行。
蜘蛛不會因為你把 lastmod 改成今天就更频繁地来，但會因為時間戳前後矛盾，而降低對你站点時間信息的信任。
時間戳不是一個装饰字段，它是蜘蛛判断“要不要再来一次”的依據之一。把时区统一、把時間寫真實，比反复提交 URL 更省事。