做蜘蛛池和站点运营时，比較让人困惑的一種情况是：入口頁明明已经改好，新連結也放進去了，搜尋蜘蛛的日誌里也天天有訪問，但抓下来的目标 URL 始终是最早那一批。這时候先別急着怀疑蜘蛛“不認新連結”，很可能是它拿到的入口頁 HTML 本身就是舊版本。
搜尋蜘蛛看到的是服務器返回了什么，不是你改了什么
搜尋蜘蛛每次訪問入口頁，都是一次獨立的 HTTP 請求。它不關心後台編輯器里存的是哪一版，只關心這次請求返回的响應体里有没有那些連結。中間任何一层缓存把舊 HTML 交给了它，它看到的就是舊連結集合。所以“我改了”和“蜘蛛看到了”之間，隔着好几层缓存。
最容易造成版本不一致的三层缓存
- CDN 或邊缘节点缓存：入口頁通常訪問量不小，很容易被邊缘节点缓存住。TTL 设得長，或者节点没收到刷新指令，蜘蛛拿到的就是缓存副本。
- 服務器端頁面缓存：Nginx 的 proxy_cache、各類 CMS 的静態化、Redis 頁面缓存等，都會把入口頁的 HTML 存一份。發布新内容时如果没触發清理，源站自己返回的也是舊版。
- 静態托管或對象存储：入口頁放在對象存储、静態站点托管上时，覆盖上传和 CDN 刷新是两件事，漏掉任何一步都會留下舊版本。
浏览器缓存對搜尋蜘蛛影响很小，因為蜘蛛一般不會复用本地磁盘缓存，這一层可以放到最後再排查。
怎么確認蜘蛛拿到的是哪一版
- 用搜尋蜘蛛的 User-Agent 請求入口頁，看响應头里的 Age、X-Cache、CF-Cache-Status、X-Cache-Hits 這類字段，判断是否命中缓存以及缓存了多久。
- 把返回的 HTML 儲存下来，直接搜新增目标連結的那段字符串，看是否真的出現在响應体里。
- 對比日誌里入口頁的响應体大小：新舊版本連結數量差得多时，字节數通常會有明顯差別。
日誌里有訪問，只說明蜘蛛来過，不能說明它拿到了最新内容。
按這個顺序排查更省時間
- 绕過 CDN 直接請求源站（用源站 IP 加 Host 头），確認源站返回的是不是新版。這一步能把“源站問题”和“缓存問题”分開。
- 如果源站是新版、CDN 是舊版，去刷新缓存，而不是反复改頁面结构。
- 發布入口頁时养成發布即刷新缓存的习惯，或者把 HTML 類资源的 TTL 調短一些。
- 缓存確認干净後，再用 URL 提交或 sitemap 提醒一次，让蜘蛛重新取一遍入口頁。
顺序上建议先解决缓存再提交。反過来做，蜘蛛被叫来了，拿到的還是舊版本，提交就白費了一次。
几個容易踩的坑
- 只刷新了站点首頁，没刷新真正承载連結的入口頁。
- 把 404 或 301 的响應也一起缓存了，之後即使内容恢复，蜘蛛拿到的仍是错誤响應。
- 入口頁按訪問者随机分片或做 A/B 版本，蜘蛛每次拿到的版本都不同，新連結自然不稳定。
- 多节点 CDN 或自建多台邊缘机器，只清了其中一部分，剩下的节点還在發舊版。
小结
入口頁新連結迟迟不被發現，先分清是“連結没寫對”還是“蜘蛛没拿到新版”。缓存類問题的特征通常比較明顯：老連結抓得挺好、新連結一直不出現，同时日誌里入口頁訪問量並不低。按源站、CDN、頁面缓存的顺序逐层確認，再配合提交入口頁，比反复調整連結结构更有效率。整個過程不會立刻带来什么變化，但能避免在一個方向上反复空轉。