很多站点接入 CDN 之後，訪問速度上去了，但搜尋蜘蛛那邊却開始出現奇怪的抓取记錄：同一個 URL 有时返回 200，有时返回 404；頁面内容明明已经更新，蜘蛛拿到的還是几天前的版本；源站日誌里看不到蜘蛛，CDN 日誌里却有一堆 5xx。這類問题通常不是源站坏了，而是邊缘缓存和回源策略没有對齐。
CDN 缓存為什么會影响抓取
搜尋蜘蛛訪問站点时，走的路径和普通用戶基本一致，也會先到 CDN 节点。如果节点上有缓存，就直接返回缓存内容，不回源站。于是缓存什么、缓存多久、按什么维度区分缓存，都會直接影响蜘蛛看到的内容。
更麻烦的是，CDN 通常只按 URL 和少量請求头做缓存键。如果站点有移動端适配、多語言、登入態或 A/B 測試，缓存键没覆盖這些差异，蜘蛛可能拿到不匹配的版本。
常见的缓存與回源問题
- 错誤狀態碼被缓存：源站短暂 404、500 或 503，被 CDN 按普通頁面缓存下来，後續蜘蛛和用戶持續看到错誤頁。
- 重定向被長期缓存：临时跳轉或维護頁被缓存，源站已经恢复，邊缘节点還在返回 301、302。
- HTML 頁面缓存過久：列表頁、詳情頁内容更新频繁，但缓存 TTL 設定成几小时甚至几天，蜘蛛抓到的内容滞後。
- 回源失敗返回舊内容：源站超时或不可用，CDN 配置了 stale-while-revalidate 或類似策略，蜘蛛拿到過期缓存，無法判断頁面是否正常。
- 缓存键忽略關键维度：没有区分 Accept-Language、Cookie、设备類型，導致不同版本互相覆盖。
- 缓存刷新依赖人工：發布内容後忘记刷新，或者刷新只清了部分节点，蜘蛛從不同节点拿到不同结果。
自查清單：從缓存規則到日誌對照
1. 检查不同资源類型的 TTL
静態资源如图片、CSS、JS 可以用較長缓存，但 HTML、接口 JSON、RSS、sitemap 這類需要動態更新的资源，建议設定較短 TTL 或不缓存。至少让栏目頁、詳情頁的缓存時間與更新频率匹配，不要一套規則套全站。
2. 检查狀態碼是否進入缓存
在 CDN 配置里確認 404、410、500、503 是否被缓存，缓存多久。很多 CDN 預設會缓存 404 一段時間，源站修复後邊缘节点仍在返回舊狀態。建议對错誤狀態設定短缓存或不缓存，並保留主動刷新能力。
3. 检查缓存键與 Vary 头
如果站点存在多語言、移動端獨立 URL 或基于 Cookie 的内容差异，確認缓存键是否包含相應請求头。不要為了命中率把所有差异都忽略掉，否則蜘蛛可能抓到错誤語言或错誤设备版本。
4. 检查回源配置與源站健康
查看回源超时、重试次數、回源协议和回源 Host。回源超时太短會让源站稍慢就返回 5xx；回源 Host 配错可能拿到預設站点内容。有條件的话，在源站和 CDN 两侧都保留监控，区分是源站故障還是回源鏈路問题。
5. 對照 CDN 日誌與源站日誌
把同一時間段的 CDN 訪問日誌和源站日誌放在一起看。重点看搜尋蜘蛛的請求：CDN 返回了什么狀態碼、是否命中缓存、有没有回源、源站返回了什么。如果 CDN 日誌里蜘蛛狀態碼正常，源站却没有记錄，說明請求被缓存挡掉了；反過来，源站 200 但 CDN 5xx，則要查回源鏈路。
6. 检查 robots.txt、sitemap 和驗證文件
這些文件经常被 CDN 缓存。如果 robots.txt 更新後没有及时刷新，蜘蛛可能繼續按舊規則抓取。sitemap 和搜尋引擎驗證文件同理，建议單獨設定缓存策略，發布後主動刷新並抽查节点。
日常操作建议
- 把缓存規則按资源類型分层，不要全站一個 TTL。
- 發布内容後，除了刷新頁面，也检查 CDN 缓存是否同步清除。
- 對搜尋蜘蛛不要做特殊内容返回，保持與用戶一致，避免被判定為 cloaking。
- 监控缓存命中率、5xx 比例和回源失敗率，異常时先看邊缘再查源站。
- 保留一份缓存配置變更记錄，出問题时能快速回滚。
CDN 不是“设好就不用管”的组件。缓存策略、回源配置和日誌對照需要定期检查，尤其在改版、迁移、批量更新内容之後。把邊缘节点当成站点的一部分来运营，才能减少蜘蛛拿到舊版本或错誤狀態碼的概率。