很多站点把内容放在 CDN 後面，搜尋蜘蛛拿到的其實是邊缘节点返回的副本。理解這一层，能解释不少「明明更新了，抓的却是舊内容」或者「源站日誌里根本没有蜘蛛记錄」的現象。
蜘蛛的請求先落在哪一层
搜尋蜘蛛的請求和普通用戶一样走 DNS 解析，命中离它較近的邊缘节点。如果该节点有可用缓存，就直接返回，源站不會留下訪問日誌。所以只看源站日誌时，很容易誤判蜘蛛没来過。要完整观察，需要把邊缘节点的訪問日誌也纳入統計，或者至少在 CDN 侧按 UA 做抽样记錄。
缓存头會間接影响重抓节奏
缓存策略本身不是排名因素，但它决定了蜘蛛每次来訪能拿到什么版本。
- Cache-Control 的 max-age 過長：邊缘持續返回舊副本，蜘蛛即使按时重抓也看不到新内容，長期看會压低重抓意愿。
- s-maxage 與 stale-while-revalidate：能减轻回源压力，但過期後的第一批請求可能仍然是舊版本。
- Vary 头設定不当：按 UA 或 Cookie 分缓存时，缓存颗粒度變细，命中率下降，回源次數上升。
robots.txt、Sitemap 與狀態碼的特殊處理
這几類资源通常不适合長期缓存。robots.txt 一旦在邊缘滞留數小时，規則變更後蜘蛛仍按舊規則抓取；Sitemap 被缓存過久，新 URL 的發現會被拖慢；而源站短暂故障时，如果邊缘把 5xx 也缓存下来並持續返回，蜘蛛可能连續多次收到错誤响應，對後續抓取安排並不有利。
建议對 robots.txt、Sitemap 和主要栏目頁設定較短的缓存時間，並明确禁止缓存 5xx 响應。
邊缘與源站不一致时的排查顺序
- 用蜘蛛 UA 直接請求目标 URL，看响應头里的 X-Cache、Age、CF-Cache-Status 一類字段，判断是命中還是回源。
- 對比邊缘返回的 HTML 與源站輸出，重点看首屏内容、正文和關键連結是否一致。
- 检查是否把蜘蛛 UA 誤拦在缓存或風控規則之外，導致 403、429 频繁出現。
- 刷新缓存後再次請求，確認版本已更新，再去抓取日誌里核對蜘蛛的再次訪問時間。
缓存和抓取是两條线：缓存解决的是「谁来拿、拿得多快」，抓取解决的是「蜘蛛愿不愿意再来」。两者都理顺，效果才會叠加。
内鏈與 URL 發現不依赖缓存层
無论請求走哪一层节点，頁面里的連結始终是蜘蛛發現新 URL 的主要路径。邊缘缓存只影响内容版本和响應速度，不會替站点补上缺失的内鏈。因此改版、上新栏目时，仍然要把入口連結、Sitemap 和分頁路径一起检查一遍，不要指望缓存层能替代结构梳理。
把邊缘日誌、响應头和内鏈结构放在一起看，比單獨盯任何一項都更容易定位問题。