把入口頁挂在 CDN 後面是常见做法，一来能挡掉一部分無效請求，二来响應更快、更稳。但上线之後不少人會發現：自己在源站明明改了連結，搜尋蜘蛛的抓取日誌里却還是老样子。這多半和“蜘蛛到底抓到了哪一层”有關。
搜尋蜘蛛拿到的是邊缘节点的响應
從搜尋蜘蛛的视角看，它請求的是入口頁的域名，DNS 解析到哪個 IP、中間经過几层缓存，它並不關心。只要 CDN 對 HTML 開了缓存，邊缘节点上有副本时就會直接返回副本，源站根本不會收到這次請求。
也就是说，蜘蛛看到的内容大体等于邊缘节点的缓存副本，而不是你刚改完的源站文件。缓存没到期之前，連結、正文、响應头都以副本為准。
几種容易被忽略的具体影响
1. 連結更新有延迟
你在源站新增或刪除了目标連結，蜘蛛拿到的仍是舊副本里的連結集合。抓取量看起来“没反應”，不一定是蜘蛛的問题，而是它压根没看到新連結。
2. 响應头被一起缓存下来
如果源站曾经返回過 X-Robots-Tag、Set-Cookie 之類的头部，部分 CDN 會连同响應头一起缓存。蜘蛛拿到的是一份上下不完全一致的响應，判断依據可能和你目前源站的配置對不上。
3. 狀態碼也可能是缓存的
源站短暂返回過 5xx 或 404，如果被缓存下来，蜘蛛在缓存有效期内會持續看到這個狀態碼。反過来，源站已经修好了，蜘蛛那邊可能還没“解冻”。
4. 不同节点内容不一致
多节点回源時間不同，可能出現 A 节点是舊版本、B 节点是新版本的情况。蜘蛛這次和下次請求命中不同节点，看到的連結就不一样，表現得很“随机”。
排查顺序可以按這個来
- 先看响應头。用蜘蛛的 UA 請求入口頁，重点看 Age、X-Cache、CF-Cache-Status 這類字段，判断這次是命中缓存還是回源。
- 再對比内容。同一 URL 分別带缓存參數和不带參數請求一次，比較正文長度和連結數量是否一致。
- 然後看源站日誌。如果源站訪問日誌里几乎看不到蜘蛛 IP，說明請求基本被邊缘节点吃掉了。
- 最後確認刷新策略。是等 TTL 自然過期，還是每次更新都主動刷新，這决定了蜘蛛多快能看到新内容。
几個實操上的建议
- 入口頁這類“連結随时會變”的頁面，缓存時間不适合设得太長，几分钟到十几分钟級別通常就够用。
- 更新連結後主動刷新對應 URL 的缓存，比干等 TTL 更可控。
- 不要把入口頁和图片、样式這類静態资源用同一套缓存規則，两者的更新频率完全不是一個量級。
- 如果入口頁需要按 UA 返回不同内容，先確認 CDN 的缓存键里有没有带上 UA，否則很容易互相串味。
CDN 本身不是問题，問题往往出在“被缓存的東西”和“你正在改的東西”不是同一份。把這一层理清楚，很多“蜘蛛不抓新連結”的困惑會自然消解。
最後提醒一句：無论缓存怎么配，蜘蛛是否抓取、何时抓取，仍然由搜尋引擎自己决定。我們能做的，是让它每次来看到的内容都准确、可预期。