很多站点上线後會把流量交给 CDN 處理，缓存配置通常是照着預設模板点几下就完事。日常訪問看不出問题，但搜尋引擎蜘蛛抓到的可能是几個小时前的頁面，甚至是一張被缓存下来的错誤頁。這類情况不會在後台报警，只能靠定期自查發現。
先確認蜘蛛看到的是哪一份内容
自查的第一步不是改配置，而是先取一份样本。可以用 curl -I 带上常见的蜘蛛 UA 請求几個 URL，观察返回头里的 Age、X-Cache、Cache-Control 等字段，再和浏览器直接訪問的结果對比。如果带蜘蛛 UA 时命中了缓存，返回的時間和正文却和源站對不上，說明缓存規則對爬虫同样生效，需要留意。
缓存时長與内容更新频率是否匹配
- 首頁、栏目頁這類變化频繁的位置，缓存時間不宜過長，否則新發布的文章會延迟出現在列表里。
- 文章詳情頁更新較少，可以設定較長的缓存時間，但編輯修改後要有主動刷新机制。
- CSS、JS、图片等静態资源可以設定長缓存，但要配合文件名版本号，避免改完之後用戶和蜘蛛還拿到舊文件。
需要注意的是，缓存時間不是越長越省事。内容更新和缓存刷新之間的時間差，就是蜘蛛可能抓到舊内容的窗口。
回源失敗时返回了什么
源站短時間不可用时，如果 CDN 返回的是 200 狀態碼加一個「服務繁忙」頁面，蜘蛛會把這張頁面当成正常内容處理，反复几次之後可能影响對该地址的判断。更稳妥的做法是让源站故障以 5xx 狀態返回，或者在配置允许时透传狀態碼。這一点可以在抓取日誌里核對：如果某個地址長期返回 200，但正文内容和平时明顯不同，往往就是缓存兜底頁。
更新内容後的刷新動作
- 文章發布或修改後，對對應 URL 触發一次缓存刷新，不要只刷首頁。
- 栏目頁、标簽頁如果依赖列表缓存，同样需要刷新，否則新文章的内鏈迟迟拿不到。
- 批量更新（比如改模板、改導航）後，按目錄或按文件類型批量刷新，並记錄刷新時間，方便和日誌對照。
抓取與缓存的几處常见冲突
- CDN 對未知 UA 做了拦截或驗證碼，蜘蛛請求被挡在门外，日誌里只剩 403。
- 缓存規則按目錄匹配，把 sitemap、robots.txt 也缓存了，修改後長時間不生效。
- 移動端和桌面端走不同缓存，两邊内容不一致，容易造成判断混乱。
- 多地节点回源策略不同，同一地址在不同地区返回的正文存在细微差异。
自查的目的不是追求配置完美，而是让「源站内容」和「蜘蛛拿到的内容」尽量一致，出現差异时能快速定位在哪一层。
一份可执行的自查清單
- 用蜘蛛 UA 抽样請求首頁、栏目頁、詳情頁各若干條，记錄狀態碼與 Age 值。
- 核對 robots.txt 與 sitemap 是否被缓存，修改後能否即时生效。
- 確認源站故障时返回的狀態碼，避免把兜底頁当成正常内容。
- 检查内容更新後是否有刷新流程，刷新记錄能否和爬虫日誌對上時間。
- 確認缓存規則没有誤伤静態资源的版本更新。
把這些检查放進固定的运维节奏，比如每次改版或調整缓存策略後跑一遍，比等到流量波動再回头排查要省事得多。