先给结论：缓存决定“看到哪一版”，不决定“能不能發現”

入口頁的 HTML 被 CDN 或反向代理缓存，本身並不會让搜尋蜘蛛失去發現目标 URL 的能力。蜘蛛請求入口頁时拿到的就是缓存节点返回的那份 HTML，它只會解析這份 HTML 里的 a 标簽和可识別連結。所以真正的問题不是“頁面被缓存了”，而是“被缓存的那一版里有没有連結”。

換句话说，缓存影响的是一條時間线：你什么时候往入口頁加了新目标 URL，蜘蛛什么时候才能從缓存节点上看到它。

三種常见情况

• 缓存版本里有連結：這是最常见的情况。入口頁更新完成、缓存刷新後，蜘蛛拿到的缓存 HTML 里包含目标連結，URL 發現流程照常走。
• 缓存還是舊快照：你刚加了一批目标連結，但 CDN 上仍是最早那一版 HTML，蜘蛛自然看不到新增連結，表現就是“加了但一直没動静”，通常等缓存過期或手動刷新後就恢复正常。
• 缓存层直接拦住了請求：CDN 開了爬虫 UA 黑名單、人机驗證或频繁訪問限制，蜘蛛拿到的可能是 403、驗證頁或一個没有連結的简化頁面。這種情况下，蜘蛛根本没有机會解析到目标 URL。

容易被忽略的几個缓存相關設定

• CDN 規則里對“無 UA、無 Cookie”的請求返回精简版頁面，而蜘蛛請求恰好命中這條規則。
• 按地域或按 UA 差异化返回 HTML，蜘蛛 UA 命中的那一版里没有放連結。
• HTML 缓存 TTL 设得過長，例如一周以上，入口頁更新後要等很久才會回源。
• 用了“僅缓存、不回源”的邊缘逻辑，源站入口頁改了，邊缘节点長期不更新。
• CDN 與源站之間的压缩、编碼差异一般不影响解析，不必為此過度担心。

怎么自查

1. 用命令行請求入口頁，並指定蜘蛛 UA，看返回的 HTML 里到底有没有目标連結。
2. 加一個随机查询參數再請求一次，绕過缓存直连源站，對比两份 HTML 的連結部分是否一致。
3. 看响應头里的缓存命中标识，確認這次請求命中的是邊缘缓存還是回源结果。
4. 對照 CDN 訪問日誌和源站日誌，看蜘蛛 UA 的請求有没有回源、回源後源站返回了什么狀態碼。
5. 如果日誌里只有 CDN 节点 IP、看不到蜘蛛 UA，說明請求在邊缘就被處理掉了，需要检查 CDN 的 UA 轉發設定。

运营上的處理建议

• 入口頁這類需要经常更新的頁面，缓存 TTL 不要设太長，几小时到一天之間比較灵活。
• 更新入口頁連結後，顺手做一次缓存刷新，让新版本尽快對蜘蛛可见。
• 不要给入口頁開啟爬虫拦截、人机驗證或訪問频率封鎖，這些功能對正常抓取的伤害遠大于防護收益。
• 如果确實做了 UA 差异化，務必保證蜘蛛 UA 走的是包含完整連結的版本。
• 入口頁不必追求极致缓存命中率，稳定、可解析比“快”更重要。

提示：刷新缓存只是让新版本更快被看到，能不能被抓取還要看抓取预算、目标 URL 自身质量和站点整体情况，不要把刷新缓存当成提升抓取的手段。

小结

CDN 缓存不是搜尋蜘蛛發現目标 URL 的障碍，障碍是缓存版本里没有連結、或者缓存层把蜘蛛挡在门外。排查顺序建议是：先確認蜘蛛能否正常拿到入口頁 HTML，再確認拿到的那份 HTML 里有連結，最後才去考虑抓取和被收錄的問题。把這三步分開看，很多“加了連結没反應”的情况就能定位清楚。