蜘蛛訪問的不一定是你的源站
很多站点在源站前面加了 CDN 或反向代理，搜尋蜘蛛請求时命中的往往是缓存层。如果缓存策略設定得不细，會出現两種典型情况：内容已经更新，但蜘蛛连續多天抓到舊副本；或者缓存把错誤頁、空列表頁甚至带登入態的頁面存了下来，再统一返回给所有訪客。這两種情况都谈不上被惩罚，但會让抓取结果與你的预期長期错位，靠感觉判断很难發現問题。
先把缓存层級列清楚
自查的第一步不是改配置，而是画出完整的請求鏈路。
- 浏览器本地缓存：主要影响回訪用戶，對蜘蛛影响有限，但會干扰你自己的測試结果。
- CDN 邊缘节点：蜘蛛最常命中的一层，需要重点看 TTL 與刷新机制。
- 反向代理或應用层缓存：例如 Nginx proxy_cache、Varnish、頁面静態化。
- 對象存储與静態资源：文件名带哈希的版本化资源，可以放心設定較長缓存。
- 資料库與接口层缓存：影响列表頁、聚合頁的内容新鲜度。
把每一层的生效條件、過期時間和清理方式寫下来，後面排查时才能定位到具体是哪一层在返回舊内容。
重点看這几個响應头
- Cache-Control：区分 max-age 與 s-maxage，前者面向浏览器，後者面向共享缓存；不确定的頁面可以用 private 或 no-store。
- Age：告诉你這份响應在缓存里放了多久，内容更新後如果 Age 依舊很大，說明刷新没有生效。
- Vary：多語言、多终端站点要確認是否按 UA、Accept-Language 区分，避免不同版本互相覆盖。
- ETag 與 Last-Modified：條件請求的基础，缺失时蜘蛛可能整頁重新下载。
- 自定义命中标识：部分 CDN 會返回 X-Cache 之類的头，便于快速判断命中還是回源。
内容更新後的缓存處理
建议在發布流程里固定三件事。
- 主動刷新：文章頁、栏目頁更新後調用 CDN 的刷新接口，按 URL 或目錄清理。
- 版本化资源：CSS、JS、图片改名带哈希，用新地址替代刷新舊地址。
- 發布後驗證：抽查若干 URL，確認返回的正文、标题、時間已经更新，Age 已归零或很小。
错誤頁面不要被長期缓存
5xx 通常是临时的，适合設定很短的 TTL 或不缓存，否則故障恢复之後，缓存层仍在返回错誤狀態。404 與 410 可以短時間缓存以减少源站压力，但不建议設定數月。同时注意缓存键是否忽略了無意义的追踪參數，否則同一篇内容會被拆成大量缓存副本，既浪費存储，也會让蜘蛛在不同時間拿到不同结果。
容易忽略的几個细节
- 不同地区、不同节点返回的内容是否一致，可以多地抽查同一個 URL。
- 带登入態或個性化推荐的頁面是否被共享缓存，检查是否誤返回 Set-Cookie。
- 分頁、篩選參數的缓存策略是否與正文頁相同，避免组合地址被缓存成大量重复頁面。
- 站点改版或模板調整之後，舊缓存是否已经清理干净。
- 缓存命中率、回源率是否有监控，出現異常时能否及时發現。
缓存的目标是让内容更快到達用戶和蜘蛛，而不是让舊版本停留更久。把刷新動作寫進發布流程，比事後逐一排查省事得多。
建议的检查节奏
小型站点可以在每次較大范围更新後抽查一次；内容更新频繁的站点，建议把缓存刷新與發布流程绑定，並每月做一次多地节点對比。记錄下每次異常的 URL、時間和處理方式，長期看比临时修改配置更有價值。