很多站長遇到過一個看着很矛盾的現象：源站入口頁里明明已经加上了新的目标 URL，用浏览器打開也能看到，但搜尋蜘蛛就是不跟進。查日誌會發現蜘蛛确實来過，只是抓到的 HTML 和現在源站的内容不一样。這種情况大概率不是蜘蛛的問题，而是 CDN 缓存层返回了舊版本頁面。
為什么 CDN 會让搜尋蜘蛛看到舊 HTML
CDN 的預設缓存键通常只有 URL，不看訪問者是谁。只要邊缘节点的缓存還没過期，請求就不會回源，节点上存的是什么，蜘蛛拿到的就是什么。源站更新連結之後，如果没触發刷新，蜘蛛在接下来的缓存周期里看到的仍然是舊頁面，新連結自然不會被發現。
几種比較常见的情形：
- 入口頁属于“常驻缓存”，TTL 設定得很長，連結更新後没有主動刷新或预热。
- 缓存規則里對爬虫 UA 做了單獨分流，部分节点返回源站内容，部分节点返回缓存内容，表現為抓取结果忽新忽舊。
- 入口頁配置了 Vary: User-Agent 或 Vary: Cookie，搜尋蜘蛛拿到的可能是精简版、甚至不含連結的版本。
- CDN 的 Bot 防護或频率限制把搜尋蜘蛛誤判為普通爬虫，返回驗證頁或 429，頁面里没有可解析的連結。
哪些情况影响最大
如果入口頁的角色就是“把連結暴露给蜘蛛”，那么缓存带来的偏差會被直接放大：源站更新得再勤，蜘蛛看到的始终是上一版。尤其是下面两類站点要特別注意。
- 入口頁連結是程序按時間動態生成的，頁面内容變化频繁，但缓存 TTL 仍按静態资源設定。
- 入口頁承担了反爬與限流职责，CDN 規則對非浏览器 UA 返回简化頁面，蜘蛛能進来但拿不到完整 HTML。
排查顺序
- 用搜尋蜘蛛的 UA 直接請求入口頁，观察响應头里的 X-Cache、Age、CF-Cache-Status 一類字段，判断這次是命中缓存還是回源。
- 把同一 URL 的源站直连结果與 CDN 返回结果做文本對比，看連結有没有缺失、是否被替換、HTML 是否被截断。
- 检查 CDN 的缓存規則與 UA 黑白名單：入口頁是否被長 TTL 缓存，搜尋蜘蛛是否被施加了 JS 挑战、驗證碼或限速。
- 翻 CDN 日誌里搜尋蜘蛛的請求记錄，重点看命中率、狀態碼分布，以及是否出現 403、429、503。
- 確認压缩與编碼正常，gzip、br 在邊缘节点上没有把 HTML 截断。
調整思路
- 入口頁連結發生增删後，主動調用 CDN 的刷新或预热接口，不要等 TTL 自然過期。
- 入口頁 TTL 设短一些，几分钟到一小时即可；它本身不是内容頁，没必要長時間缓存。
- 對已確認的搜尋蜘蛛 UA 關閉 JS 挑战與频率限制，避免它們拿到不含連結的頁面。
- 入口頁尽量不做 Vary: User-Agent 或按 Cookie 分流，保持同一 URL 對所有訪問者返回同一份 HTML。
- 同时把入口頁放進 sitemap，给連結發現留一條不依赖缓存的路径。
缓存問题最典型的表現是“部分节点能抓到新連結、部分节点還是舊的”。如果只看單次抓取结果，很容易誤判成蜘蛛不跟進或目标站有問题。
需要說明的是，修好缓存一致性只是让入口頁的連結能被稳定看到，並不等于目标 URL 一定會被收錄。抓取和收錄由搜尋引擎自行决定，這里能做的只是把發現环节的障碍清掉，剩下的交给正常的抓取节奏去驗證。