做蜘蛛池或入口頁运营时，经常會遇到一種尴尬情况：明明在入口頁里加了新的目标連結，日誌里却迟迟看不到搜尋蜘蛛来抓。排查半天，服務器正常、頁面能打開、連結也没寫错——這时候要找的方向可能不是“頁面能不能訪問”，而是“搜尋蜘蛛到底有没有拿到最新版本的内容”。
304 和 CDN 缓存是两件事
304 Not Modified 是源站對條件請求的回應。搜尋蜘蛛再次抓取同一個 URL 时，通常會在請求头里带上 If-Modified-Since 或 If-None-Match，相当于問一句“這個頁面從上次抓取之後變過吗”。如果服務器判断没變，就回 304，蜘蛛沿用上一次抓到的内容，不再重新下载。
CDN 缓存則發生在更前面一层。請求還没到源站，邊缘节点就把自己存的那份副本直接返回了。這时候蜘蛛拿到的可能是几小时甚至几天前的 HTML。
两者共同的结果是：蜘蛛看到的不是你現在這份頁面，里面新加的連結自然也不會被發現。
返回 304 时，搜尋蜘蛛看到的是什么
正常配置下，304 是省流量的好做法。問题出在配置出错：有人為了“加快响應”，把入口頁寫死成永遠返回 304，或者 Last-Modified 不随内容更新而變化。這種情况下，即使你改了入口頁，蜘蛛問“變了吗”，服務器答“没變”，新連結就一直躺在源站里没人看。
還有更隐蔽的情况：動態生成的入口頁没有輸出正确的 Last-Modified，或者反向代理把 ETag 设成了一個固定值。表面上頁面能打開、内容也對，但對搜尋蜘蛛来说它始终處于“未更新”狀態。
CDN 缓存會让新連結延迟上线
入口頁如果挂在 CDN 後面，預設 TTL 常常是几十分钟到几小时，長的按天算。源站一改，邊缘节点並不會立刻同步。
- 蜘蛛第一次抓取，拿到缓存版本 A，里面還没有新連結；
- TTL 到期前再次抓取，返回的仍然是 A；
- 直到缓存過期或被主動刷新，才有机會拿到新版本 B。
如果入口頁是唯一的新 URL 来源，這段時間就是纯粹的發現延迟。你以為的“蜘蛛不抓新連結”，其實是它還没看见。
怎么確認自己遇到的是哪一種
- 用 curl -I 直接請求入口頁，看返回狀態碼是 200 還是 304，以及 Last-Modified、ETag、Age、X-Cache 這類响應头；
- 带上 If-Modified-Since 再請求一次，看源站是否會错誤地一直回 304；
- 拿源站 IP 直连抓一次，再走 CDN 域名抓一次做對比，看内容是否一致；
- 在服務器日誌里找搜尋蜘蛛的請求，看同一 URL 的返回碼分布，是不是長期只有 304 或只有缓存命中。
更新入口頁时的几個稳妥做法
- 更新内容後主動刷新 CDN 缓存，尤其入口頁這類承担 URL 發現职责的頁面；
- 检查 Last-Modified 是否随内容變化，避免服務器無差別返回 304；
- 不要為了绕開缓存，每次更新都換一個新 URL。入口頁地址频繁變動，等于丢掉之前积累的抓取记錄，還容易产生一批重复頁面；
- 如果入口頁改動很频繁，可以适当降低节奏，把新增連結攒到一次更新里，减少“频繁變動但無實质變化”的情况；
- 给新連結留出观察時間。缓存過期加上蜘蛛重新抓取，本来就不是即时過程。
入口頁能不能被重新解析，取决于搜尋蜘蛛是否真的下载到了最新版本。缓存和错誤的 304，都會让“已经更新過了”停留在源站上。
最後提醒一句：入口頁的作用是让 URL 被看见，不是保證被收錄。即使連結被重新解析到，後續能否抓取和收錄，仍然取决于目标頁自身的狀態。把缓存和狀態碼這一层排查清楚，至少能排除掉一部分“明明改了却没動静”的疑惑。