入口頁接入 CDN 是很常见的做法，能降低源站压力、加快响應。但不少运营者會遇到一種情况：明明已经在源站给入口頁加了新的目标 URL，搜尋蜘蛛却像没看到一样。這往往不是連結本身有問题，而是搜尋蜘蛛拿到的是 CDN 缓存的舊版 HTML。
搜尋蜘蛛只會看到它拿到的那份 HTML
搜尋蜘蛛本质上是普通的 HTTP 客戶端，它請求入口頁时，得到什么响應体就解析什么連結。如果請求命中了 CDN 邊缘节点缓存，节点會直接返回缓存副本而不回源，源站上新加的連結就不會出現在這次响應里。也就是说，URL 發現的起点是响應内容，而不是源站文件。
怎么判断是不是缓存導致的
- 用带搜尋蜘蛛 UA 的請求直接訪問入口頁 URL，查看返回的 HTML 里是否包含新連結。
- 观察响應头里的缓存标识，例如 Age、X-Cache: HIT/MISS、CF-Cache-Status 等，判断這次請求是否走了缓存。
- 對比 CDN 域名與源站直连返回的 HTML，如果两者不一致，基本可以確認是缓存版本陈舊。
- 在源站訪問日誌里篩選搜尋蜘蛛的 UA，如果長時間没有回源记錄，說明請求大多被邊缘节点消化了。
比較稳妥的處理方式
- 给入口頁 HTML 設定較短的缓存時間，例如几分钟到十几分钟；静態资源可以單獨設定較長缓存，两者分開配置。
- 更新入口頁後主動刷新 CDN 缓存，多节点部署时注意刷新范围，避免只刷新了個別节点。
- 如果入口頁内容更新频繁，可以考虑對 HTML 關閉缓存，或設定成需要回源校驗的模式。
- 連結變更後，把 URL 提交接口或 sitemap 作為补充渠道，让發現不只依赖入口頁這一次响應。
几個容易踩的坑
第一，為了绕過缓存给入口頁 URL 加随机參數，會制造出大量内容相同的地址，反而不利于抓取效率。第二，缓存副本里可能還留着已经刪除的連結，搜尋蜘蛛抓到後得到 404，白白消耗抓取配額。第三，多地 CDN 节点缓存刷新時間不一致，可能出現不同地区的搜尋蜘蛛看到不同版本入口頁的情况，排查时要多节点對比，不要只看一次請求的结果。
入口頁的更新能否被發現，取决于搜尋蜘蛛那次請求實际拿到的 HTML。缓存策略、刷新動作和日誌核對這三件事配合好，URL 發現的节奏才相對稳定。
日常检查清單
- 入口頁 HTML 的缓存时長是否與更新频率匹配
- 更新後是否执行了缓存刷新，並用带蜘蛛 UA 的請求复核過
- 响應头里的缓存狀態是否正常，是否長期 HIT 不回源
- 缓存副本中是否残留已经失效的連結
- 源站日誌里搜尋蜘蛛的回源是否規律