把入口頁挂在 CDN 後面之後，常會遇到一種別扭的情况：源站已经加了新的目标連結，本地浏览器打開也能看到，可搜尋蜘蛛抓到的還是几天前那一版 HTML。目标 URL 于是就卡在“没被發現”的狀態里。
這類問题多數不是蜘蛛不来，而是它来的那一刻，CDN 直接把缓存里的舊頁面返回了。要判断和處理，需要先把“蜘蛛拿到的是哪一份 HTML”這件事弄清楚。
缓存命中时，蜘蛛看到的是過期副本
CDN 的常規逻辑是：請求到達邊缘节点，如果缓存中有一份未過期的响應、且缓存键匹配，就直接返回，不回源站。搜尋蜘蛛的請求如果没有被特殊标记，通常和普通訪客一样命中這份缓存。
也就是说，源站更新了連結，不代表邊缘节点立刻更新。缓存没到期、也没被主動清除之前，蜘蛛每次来拿到的都可能還是舊 HTML，里面自然没有你新加的 URL。
容易造成新舊错位的几種設定
- 入口頁缓存時間设得太長：比如把 HTML 的邊缘缓存或浏览器缓存设成几天，連結改動後要等很久才會回源。
- 按 User-Agent 做了差异化缓存：给蜘蛛返回的是一個简化版或空壳頁，而這份版本本身又被缓存，之後就一直返回同一份。
- Vary: Cookie 之類的响應头：蜘蛛不带 Cookie，會被分到另一份缓存，有可能正好是不含新連結的那份。
- 缓存清除只清了主 URL：入口頁带 utm 或其它查询參數时會被当成不同的缓存键，舊副本仍然留在邊缘节点。
- 把 HTML 当成静態资源長期缓存：某些規則里 HTML 也被打上了長缓存，更新後頁面内容迟迟不換。
怎么確認蜘蛛拿到的是不是舊版
- 用搜尋蜘蛛的 User-Agent 請求入口頁，把返回的 HTML 抓下来，直接搜目标連結是否在里面。
- 观察响應头里的缓存狀態字段，例如 Age、X-Cache、CF-Cache-Status，判断這次是 HIT 還是 MISS。
- 對比同一时刻直连源站 IP 的返回内容，看看两邊是不是同一份 HTML。
- 核對 Last-Modified、ETag 是否随改動變化，長期不變往往意味着拿到的是缓存副本。
確認是缓存問题之後的處理
- 發布連結改動後，主動對入口頁 URL 做一次缓存刷新，缩短等待時間。
- 给 HTML 類型的响應設定更短的邊缘缓存時間，必要时用 stale-while-revalidate 之類的策略平衡回源压力。
- 检查是否存在按 UA 分流的規則，避免蜘蛛被分到一個内容不全的版本。
- 把带參數和不带參數的入口頁归到同一缓存键，或在參數變更後一並清除。
- 改動完成後重新观察搜尋蜘蛛的訪問记錄，確認它下次取到的是新 HTML。
缓存刷新解决的是“蜘蛛讀到的 HTML 是不是最新”這一环。至于它拿到新連結之後會不會去抓、什么时候抓，還受抓取预算、目标頁质量、robots.txt 等條件影响，不能把它当成结果上的保證。
小结
入口頁加了連結却迟迟没有動静时，先別急着怀疑蜘蛛池本身。用带蜘蛛 UA 的請求確認拿到的是源站 HTML 還是缓存副本，往往几分钟就能排除一大半可能性。真正需要長期维護的，是入口頁的缓存策略，以及更新内容後及时刷新的习惯。