在抓取日志里经常能看到一种情况：页面内容明明改过，蜘蛛却隔了很久才回来，或者只反复抓首页和几个列表页。很多人第一反应是「权重不够」，但更常见的原因是：站点没有把「这里变了」这个信号清楚地传出去。
蜘蛛判断要不要再来时，会看哪些信号
重新抓取不是凭感觉，它大致依赖几类可观测的信息：
- HTTP 缓存头：Last-Modified、ETag 决定蜘蛛再次请求时，服务器能否直接回答「没变」。
- Sitemap 里的 lastmod：这是站点主动声明的时间戳，可信度完全取决于它是否与实际改动一致。
- 站内链接的变化：首页、栏目页、列表页出现新链接，往往比 Sitemap 更能提示「有新内容」。
- 历史抓取表现：同一个 URL 过去多次返回 304，或抓回去发现内容几乎不动，重访间隔自然会被拉长。
这几类信号不是各自独立的。Sitemap 说「变了」，服务器却回 304；或者内容真变了，列表页却一年没动过，蜘蛛都会倾向于按更保守的那一方来判断。
lastmod 写错的三种典型情况
lastmod 是最容易被写坏的字段，常见的有三类：
- 全站同一个时间戳。每次生成 Sitemap 都把当前时间写进所有 URL，结果是每次提交都像全站刚更新过。蜘蛛第一次可能信，几次之后就会把这个字段当噪音。
- 从不更新。页面内容改了半年，lastmod 还停在建站那天。蜘蛛会认为这个字段没有参考价值，重新抓取只能靠内链和外部链接推着走。
- 格式或时区不一致。同一份文件里混用不同格式、缺时区、日期比实际抓取时间还晚，解析异常会让字段直接失效。
比较稳妥的做法是：只在正文出现实质修改时更新 lastmod，模板调整、广告位替换、样式改动不必动它。宁可少更新，也不要乱更新。
内容改了，但信号没改
还有一类情况是内容确实变了，但周边环境一动不动：列表页排序没变，没有任何新链接出现，内链指向的文字还是旧的，发布时间字段也没更新。蜘蛛的抓取路径大多是从枢纽页顺着链接铺开的，如果这些入口没有任何变化，它就没有理由优先回到这条路径上。
相对有效的做法是让「变了」这件事在链接层面也能被看见：更新文章时顺手把它推回栏目页或相关推荐位；对长期维护的页面，在正文里补一条指向新内容的链接。这类改动不需要频繁，但要真实发生。
怎么验证蜘蛛有没有收到更新信号
不要凭感觉判断，日志里能看出不少东西：
- 看目标 URL 的抓取间隔有没有缩短。修改后一周内的访问次数，是比「有没有收录」更直接的反馈。
- 看 304 与 200 的比例。如果蜘蛛反复来访却一直拿到 304，说明它认为内容没变，需要回头检查 Last-Modified 或 ETag 的生成逻辑。
- 看首次返回的状态码。改版期间如果频繁出现 5xx、超时或 429，蜘蛛的抓取路径会在入口处断掉，后面的信号都传不进去。
服务器端别拖后腿
服务器稳定性会直接影响抓取意愿。首字节时间明显偏慢、响应时好时坏、同一台机器上抓取和用户访问互相挤占资源，都会让蜘蛛降低抓取频次。缓存头如果配置得当，既能让蜘蛛快速拿到「未修改」的答案，也能减轻源站压力，这两件事是互相成全的。需要注意的是，有些 CDN 或防火墙会对高频请求做限流，如果限流误伤了搜索蜘蛛，抓取路径会在最前面就被截断，站内做再多优化也传不出去。
一份可以照着做的检查顺序
- 确认页面是否真的改了实质内容，改动幅度值不值得触发重抓。
- 检查 Last-Modified、ETag 是否随内容变化而更新，而不是每次请求都变。
- 核对 Sitemap 中 lastmod 的格式、时区与实际改动时间是否对得上。
- 看首页、栏目页、列表页有没有出现指向该页面的新链接。
- 翻近期日志，统计目标 URL 的抓取间隔与 304 比例。
- 最后再看服务器响应时间与限流情况，确认抓取请求有没有被中途拦下。
把「变了」这件事同时交给缓存头、Sitemap 和内链去表达，比反复重推同一份文件更有效。蜘蛛不需要被说服，它只需要拿到一致、可验证的信息。