把蜘蛛池入口頁放在 CDN 後面是常见做法，能扛並發、减少源站压力。但 CDN 上的缓存副本和源站内容並不是时刻一致的，搜尋蜘蛛抓到的那份頁面，有可能是几小时甚至几天前的舊版本。里面的連結列表、锚文本、跳轉目标都會跟着一起被“冻住”，于是你在源站改了半天，蜘蛛那邊看不到變化。
缓存命中时，蜘蛛拿到的到底是谁的版本
搜尋蜘蛛發起請求後，請求會先落到 CDN 邊缘节点。如果该 URL 在节点上還在缓存有效期内，节点會直接把缓存副本返回，請求根本到不了源站。整個過程對蜘蛛来说和正常訪問没有区別：狀態碼 200、頁面有内容、連結也在，只是這份内容是舊的。
所以判断這類問题，不能只看“源站更新了没有”，還要看“邊缘节点什么时候回源”。
几個比較典型的表現
- 日誌里蜘蛛請求频率正常，但抓走的 URL 列表和源站目前的不一致。
- 源站訪問日誌里看不到蜘蛛 IP，只有 CDN 回源节点的记錄。
- 同一時間不同地区节点的抓取结果不同，有的還返回舊連結。
- 手動刷新缓存後短時間内内容更新，過一阵又回到舊版本。
排查顺序建议
- 用同一個 URL 請求一次，看响應头里的缓存标识（如 Age、X-Cache、CF-Cache-Status 等），確認是否命中缓存。
- 對照 CDN 控制台的缓存規則，看入口頁路径是不是被套用了較長的 TTL。
- 检查源站日誌里有没有 CDN 回源請求，以及回源的間隔。
- 把蜘蛛日誌和 CDN 日誌按時間對齐，找出内容“切換”的時間点。
- 確認這次改的是連結结构還是僅僅锚文本，改連結结构的影响更大，值得單獨處理。
處理思路
比較稳妥的做法是让入口頁的缓存時間短一些，或者對入口頁這類需要经常變化的頁面單獨设規則，不和静態资源共用同一套 TTL。
- 改連結结构前，先刷新對應路径的 CDN 缓存，再等蜘蛛下一次抓取。
- 入口頁的 HTML 不建议设“一年過期”這類長缓存，图片、脚本可以長，頁面本身短一些。
- 如果入口頁是動態生成的，检查 CDN 是否忽略了某些查询參數，避免不同參數被合並成同一條缓存。
- 多节点部署时，注意缓存刷新是否覆盖全部节点，部分服務商的刷新是按区域生效的。
缓存問题不一定让蜘蛛抓取失敗，更常见的後果是“抓到了，但抓到的是舊連結”，從現象上看和抓取正常几乎一样，容易被忽略。
容易混淆的几種情况
並不是所有“蜘蛛拿到的連結不對”都出在 CDN 上。也可能是源站本身有頁面級缓存（反向代理、框架缓存）；或是入口頁的生成逻辑里讀了會過期的資料；再或者蜘蛛抓的是一條早被替換掉的舊 URL，而那條 URL 在节点上還有缓存副本。
把這几层分開看，先確認請求鏈路上究竟哪一层返回了舊内容，再决定是刷缓存、調 TTL，還是改生成逻辑。
處理顺序上，先定位再動手會省很多時間。建议在改動入口頁结构之前，先留一份简單對照记錄：源站版本、缓存狀態、蜘蛛最近一次抓取時間。後面再出問题时，不用重新推一遍。