很多站点排查抓取問题，习惯先看 robots、Sitemap 和内鏈，却忽略了一個前置环节：蜘蛛請求的那個 URL，最终是由谁返回内容的。如果站点前面挂了 CDN 或反向代理，蜘蛛拿到的可能不是源站目前版本，而是邊缘节点上的某一份缓存副本。抓取路径没變，看到的内容却對不上，問题就會顯得很“玄”。
缓存命中时，蜘蛛看到的是哪一份内容
CDN 的預設行為是尽量提高命中率，這對普通訪客是好事，對蜘蛛却可能带来偏差：
- 源站刚更新了标题和價格，邊缘缓存還没過期，蜘蛛抓到的仍是舊版本，内容新鲜度信号被“冻结”。
- 頁面缓存了带登入態或带地区差异的版本，蜘蛛拿到的頁面里出現本不属于它的内容。
- 不同节点返回的 HTML 不一致，蜘蛛在不同時間看到不同结果。
這些情况本身不會直接導致降權，但會让“抓到的内容”和“站点真實内容”之間产生漂移。判断方法很简單：用蜘蛛的 UA 從一個普通網絡出口請求頁面，與源站直连的輸出做對比（先去掉時間戳、随机 token 之類的動態部分）。如果差异明顯，優先查缓存策略，而不是先改内鏈。
缓存键與 URL 參數：同一頁面被拆成几份
缓存键决定了“什么算同一個资源”。如果缓存键把全部查询參數都算進去，带 utm、带會话參數、带排序參數的 URL 都會各自生成一份缓存，蜘蛛顺着這些 URL 走一圈，抓到的是一堆内容相同、地址不同的頁面。反過来，如果缓存键忽略了有意义的參數（比如分頁的 page、篩選條件的 id），蜘蛛請求第 2 頁时可能被塞回第 1 頁的内容，抓取深度看起来走了，實际没走。
比較稳妥的做法是：明确哪些參數參與缓存键，哪些不參與；在缓存层把無意义參數剥离或统一跳轉；确保分頁、篩選這類真正改變内容的參數不被忽略。這部分配置通常由运维或前端架构决定，但内容运营需要知道它存在，否則容易誤判成“蜘蛛不抓列表頁”。
Vary、Cookie 與多版本頁面
同一個 URL 因為有 Vary 头或 Cookie 差异，可能對應多種缓存版本。需要確認的是：
- 蜘蛛請求时通常不带 Cookie，邊缘节点會把哪一份缓存给它，這一份是否就是希望被索引的版本。
- 如果 Vary 里包含 User-Agent，移動版和桌面版會分開缓存，這时要確認返回给蜘蛛的，是與頁面 canonical 一致的那一份。
- 地区重定向、語言切換如果在缓存层完成，要確認蜘蛛不會被反复送到某個临时的預設版本。
缓存层是最容易把“一個頁面”變成“多個頁面”的地方，也是最容易把“多個頁面”压成“一個頁面”的地方，两头都會影响蜘蛛對站点的理解。
別把错誤狀態一起缓存
源站偶尔出現的 5xx、502、超时頁，如果被邊缘缓存按預設 TTL 存下来，蜘蛛在接下来的一段時間里會持續拿到错誤响應。它看到的不是一個偶發抖動，而是一個持續不可用的地址，回訪节奏自然會調整。建议在缓存規則里明确：4xx、5xx 不缓存，或只做极短時間的缓存；同时留意源站的超时頁是否被当成 200 返回。
缓存头與蜘蛛的回訪
Cache-Control、Expires、ETag、Last-Modified 這些头，不只是给浏览器看的，蜘蛛在决定是否重新拉取内容时也會參考。如果邊缘节点把源站的 ETag 抹掉或重新生成，條件請求就可能失效，每次回訪都要拉完整内容；如果 TTL 被设得极長，蜘蛛可能長時間看不到更新後的頁面。合理的方向是让缓存头真實反映内容更新节奏：詳情頁和列表頁区分開，不要用“一周不變”這種一刀切策略。
怎么驗證蜘蛛拿到的是源站内容
不需要复杂工具，按下面的顺序排查基本够用：
- 用與蜘蛛相同的 UA 請求目标 URL，儲存响應头和正文。
- 绕過 CDN，直接請求源站上的同一路径，做對比。
- 检查响應头里的缓存命中标识（如 X-Cache、Age、CF-Cache-Status 之類，不同厂商命名不同）。
- 如果命中缓存，看该 URL 的 TTL 與實际内容更新時間是否匹配。
- 對比訪問日誌中“源站收到的請求”與“邊缘收到的請求”，確認蜘蛛的請求有没有真正到達源站。
如果發現蜘蛛長期只命中缓存、几乎不回源，說明缓存策略對抓取過于“友好”，把更新信号挡在了外面，這时需要單獨為搜尋引擎的 UA 配置回源或更短的 TTL。把“蜘蛛看到什么”先確認清楚，再谈抓取频率和發現效率，判断會准确得多。
寫在最後
抓取問题不總是出在連結结构上。CDN 和缓存层處在蜘蛛與源站之間，决定了蜘蛛實际上看到了什么。把這一层核對清楚，再去調整 Sitemap、内鏈和更新信号，才不會把時間花在错誤的方向上。