為什么蜘蛛看到的頁面和你看到的不一样
不少站点接入 CDN 之後會出現一種情况：浏览器訪問正常，但抓取日誌里同一批 URL 的响應碼、响應体大小反复跳動，甚至出現 404 與 200 交替。這通常不是源站本身出了問题，而是邊缘节点的缓存狀態和回源策略不一致造成的。抓取工具没有浏览器那样的本地缓存和 Cookie 环境，每次請求更接近冷啟動，因此它對缓存配置的差异比真人用戶敏感得多。
先分清三種响應来源
- 邊缘命中：节点直接返回缓存副本，响應头里通常能看到 Age 递增或命中标识。
- 回源获取：节点没有可用副本，向源站請求後再返回，同时决定是否缓存。
- 绕過缓存：命中某些規則（Cookie、查询串、特定 UA）时不缓存直接回源。
蜘蛛在不同時間、不同节点拿到的，可能是這三種中的任意一種。如果三者返回的内容不一致，比如缓存里存着舊版頁面而回源返回新版，就會出現抓取结果與线上不一致的現象。
常见配置坑
1. 缓存了不该缓存的狀態碼
部分 CDN 預設會缓存 404、410 甚至 301，並按配置的 TTL 保留。頁面恢复後，邊缘仍在返回舊的 404，蜘蛛會認為该 URL 已经失效。排查时看响應头里是否有較大的 Age 值，基本就能判断。
2. 缓存键包含 UA 或完整查询串
如果缓存規則按 User-Agent 区分，或者没有忽略营销參數，同一路径會被拆成多份副本，命中率骤降，回源压力上升。抓取频次稍高时，源站就容易出現响應變慢甚至超时。
3. Set-Cookie 導致 HTML 無法缓存
頁面响應带上 Set-Cookie，多數 CDN 會直接判定為不可缓存。结果是每個請求都回源，服務器负载和响應耗时的波動會更明顯。
4. TTL 過短或過長
過短等于没有缓存；過長則让更新内容迟迟無法被看到，蜘蛛反复抓到的都是舊版本，容易形成抓了但不更新的错觉。
一個可执行的排查顺序
- 固定同一 URL，用不同 UA（普通浏览器、蜘蛛 UA、空 UA）多次請求，對比响應碼、内容長度與 Age。
- 查看响應头中的缓存标识字段，確認這次是命中、回源還是绕過。
- 把 CDN 訪問日誌與源站日誌按時間對齐，看回源比例是否異常偏高。
- 检查缓存键規則：是否包含 UA、Cookie、全部查询串。
- 检查是否缓存了 4xx、5xx 與 301、302，以及這些規則的 TTL 設定。
- 確認源站在高峰时段的响應耗时是否稳定，排除带宽與连接數限制。
缓存的作用是降低回源压力，而不是改變頁面语义。任何让蜘蛛長期拿到與源站不一致内容的配置，都會给收錄判断增加額外成本。
配置上的几個稳妥做法
- HTML 使用較短的 TTL，配合過期後被動更新的策略，兼顾新鲜度與回源压力。
- 4xx 的缓存 TTL 設定得比 200 更短，避免错誤狀態被長期固化。
- 缓存键忽略與内容無關的查询參數，减少副本數量。
- 不要在 CDN 层對蜘蛛 UA 做單獨封禁或降級；确實需要限流时，優先按 IP 與並發维度控制。
- 改版或下线路径时，先確認邊缘缓存已刷新，再观察抓取日誌中的狀態碼變化。
观察效果时看什么
不必期待抓取量短期内有明顯變化，重点看三個指标的趋势：回源請求占比是否下降、响應耗时分布是否收窄、日誌中同一 URL 的狀態碼是否稳定。這三項稳定之後，抓取节奏通常也會更有規律。至于具体抓取频次和收錄结果，由搜尋引擎自行判断，站点能做的是让每次請求都拿到一致、可達的响應。