做站点运营时，URL 结构、内鏈、Sitemap 這些环节通常會被反复检查，但 CDN 與缓存這一层常常被跳過。蜘蛛請求頁面时，拿到的往往不是源站刚刚生成的 HTML，而是邊缘节点上的一份副本。缓存策略如果和内容更新节奏對不上，就會出現源站已经改完、蜘蛛看到的還是舊版本的情况。
缓存為什么會改變蜘蛛看到的内容
搜尋引擎抓取的是一個 URL 的 HTTP 响應，而這份响應可能来自源站，也可能来自 CDN 节点或反向代理的缓存。這带来三個直接後果：
- 内容更新後，如果 HTML 缓存未過期，蜘蛛抓到的仍是舊正文、舊标题或舊連結；
- 狀態碼同样會被缓存，被缓存的 404 或 301 會在缓存周期内持續返回给蜘蛛；
- 缓存键設定不合理时，不同參數的頁面可能互相覆盖，返回同一份内容。
所以缓存不只是运维话题，它直接决定了蜘蛛實际讀到什么。
發布前值得確認的几項策略
HTML 文档的缓存时長
動態生成的 HTML 一般不建议做長時間缓存。常见做法是给 HTML 設定較短的 s-maxage，或者使用 must-revalidate，让节点在内容更新後能較快回源。把 HTML 缓存一整天，虽然能减轻源站压力，但当天所有改動對蜘蛛来说都是不可见的。
静態资源用長缓存加版本指纹
CSS、JS、图片這類文件可以放心使用長缓存，前提是文件名或查询串带版本号。更新时改文件名，蜘蛛和浏览器自然會拿到新文件，不需要专门去刷新缓存。
狀態碼不要被長期缓存
需要特別检查 404、410、301、302 的缓存头。一個临时下线的頁面如果被缓存成 404，在缓存過期前蜘蛛每次来都會得到同样的结果；被缓存的跳轉也一样，即使你後来改回了正常頁面，节点仍會繼續跳。
缓存键與查询參數
確認缓存键是否包含查询參數。如果忽略參數，分頁、篩選、排序這些带參數的 URL 會共用一份缓存，蜘蛛抓到的内容與 URL 不對應，容易被判定為重复或空壳。反過来，如果參數過度參與缓存键，又會造成大量回源。
robots.txt 與 sitemap.xml
這两個文件通常放在根目錄，也很容易被 CDN 一起缓存。它們的缓存時間建议短一些，避免新規則或新地址迟迟不生效。
内容更新後的刷新動作
- 發布完成後，主動刷新首頁、栏目頁、被改動的詳情頁，以及 sitemap.xml；
- 涉及 URL 變更的，先確認 301 已生效，再刷新對應地址；
- 把「刷新關键 URL」寫進發布流程，而不是等發現問题再补；
- 大范围改版时，考虑整站刷新一次，並观察回源量是否會给源站带来压力。
怎么驗證节点返回的是最新内容
- 用 curl -I 或浏览器開發者工具查看响應头，關注 Age、X-Cache、CF-Cache-Status 這類字段，判断是否命中缓存、缓存了多久；
- 带上搜尋引擎的 UA 再請求一次，確認没有针對 UA 的差异化缓存；
- 從不同地区或不同节点請求同一個 URL，對比正文與狀態碼是否一致；
- 在 CDN 後台看命中率與回源量，異常升高往往意味着缓存键被频繁绕過。
缓存的目标是减少回源，而不是让内容停留在過去。判断标准很简單：發布十分钟後再抓一次，蜘蛛看到的是不是你現在看到的這一版。
几個常见的坑
- 為了提高命中率，把 HTML 缓存设得很長，更新只能靠手動刷新；
- 測試环境與生产环境共用一套缓存規則，測試頁被节点缓存後影响线上；
- 只刷新首頁，忘了列表頁和 sitemap；
- 對 404 做長缓存，把後来重新上线的頁面挡在门外；
- 忽略 Vary 头，導致压缩版與未压缩版、移動版與桌面版互相污染。
小结
CDN 與缓存不需要复杂配置，但需要和發布流程绑在一起：HTML 短缓存、静態资源長缓存加指纹、異常狀態碼不長期缓存、關键 URL 發布後主動刷新。把這四件事固定下来，蜘蛛讀到的内容基本就能和源站保持一致。