缓存為什么也是站点运营的事
缓存本身不改變内容质量，但它决定了蜘蛛和用戶在不同時間、不同节点上看到的是哪一版頁面。常见的情况是：編輯在後台改好了标题和正文，本地刷新也對，但搜尋引擎抓到的仍是几小时前的舊版本；或者反過来，一個临时的错誤頁面被缓存住，長時間挂在搜尋结果里。這些問题往往不是内容問题，而是缓存規則没理清。
做缓存自查的目标很简單：新内容尽快可见，舊内容按预期登出，不该缓存的頁面绝不缓存。
先分清三层缓存
浏览器缓存
由 Cache-Control、Expires、ETag 等响應头控制，影响回訪用戶和部分爬虫的重复抓取行為。HTML 通常建议短缓存或协商缓存，静態资源可以長缓存。
CDN / 反向代理缓存
缓存的是节点上的副本，通常關注 缓存键（URL、查询參數、Host、Accept-Encoding、UA 等）和 TTL。缓存键設定過粗，會把不同版本的頁面混在一起；設定過细，命中率又會掉下来。
源站應用层缓存
頁面片段、資料库查询、對象缓存等。這层出問题时的表現是：CDN 已经刷新了，但回源拿到的還是舊内容。
常见配置思路
- HTML 頁面：設定較短的 TTL，或使用协商缓存，让内容變更後能較快生效；首頁、栏目頁、詳情頁可以按更新频率区別對待。
- CSS、JS、字体、图片：文件名带指纹（hash 或版本号）时可以設定長缓存，改版时靠文件名變化自動失效。
- 接口與動態請求：明确标注不可缓存，避免把用戶相關資料缓存到公共节点。
- 错誤狀態碼：404、5xx 頁面不要長缓存，否則一次抖動會持續影响抓取。
- robots.txt 與 sitemap：建议短缓存甚至不缓存，避免規則更新後蜘蛛仍在讀舊文件。
發布新内容後的自查動作
- 確認發布流程里包含缓存刷新（purge）這一步，而不是靠等 TTL 自然過期。
- 用 curl -I 或浏览器開發者工具查看响應头，重点看 Cache-Control、Age、X-Cache 等字段，判断命中的是节点副本還是回源结果。
- 換几個不同地区的解析节点抽查同一 URL，確認各节点返回内容一致。
- 检查首頁、栏目頁、sitemap 是否同步更新，避免只剩詳情頁是新的。
- 记錄一次刷新到生效的大致耗时，作為後續运营的參考。
几個容易踩的坑
- 移動端與桌面端共用一份缓存：如果站点按 UA 輸出不同模板，缓存键里必须体現這一点，否則會串版。
- 带登入態的頁面被缓存：公共节点缓存了個人中心之類的頁面，既有安全問题，也會让蜘蛛抓到不该抓的内容。
- 301 和 404 被長期缓存：URL 迁移或頁面恢复後，节点仍返回舊狀態，看起来像“改了没用”。
- 回滚时只回滚代碼，忘了刷新缓存：结果新舊版本混在一起，排查起来很費時間。
- CDN 與源站压缩不一致：開啟压缩後要確認缓存键包含编碼维度，避免返回乱碼或解压失敗。
缓存自查不需要一次做到完美，先把首頁、栏目頁、sitemap、robots.txt 這几個關键位置的規則寫清楚，收益通常最直接。
一份可执行的检查清單
- 列出站点主要頁面類型，逐類标注期望的缓存时長與刷新方式。
- 核對静態资源是否带指纹、是否長缓存。
- 確認發布流程中缓存刷新是固定動作。
- 抽查三類 URL：刚發布的詳情頁、刚修改的栏目頁、近期下线的舊頁。
- 记錄一次異常情况的處理過程，形成文档。
把缓存当成内容發布流程的一部分来管，蜘蛛看到的版本和用戶看到的版本才不會長期打架。