做站点运营的时候，很少有人会把“时间”当成一个需要检查的配置项。但蜘蛛判断一个页面要不要重新抓取，除了看内容变化，也很依赖服务器给出的时间信息：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 更省事。