网站刚更新了 robots.txt，搜索引擎却仍按旧规则抓取；sitemap.xml 已经恢复，站长平台仍提示 403、404 或内容无法读取。遇到这类情况，不要只盯着源站文件。只要域名前面接入了 CDN，爬虫拿到的响应就可能来自边缘节点，而不是刚刚修改过的服务器。
排查时要回答三个问题：当前响应由谁返回、缓存的是哪一个版本、为什么刷新后仍会命中旧内容。确认这三点，再处理 TTL、缓存规则和刷新范围，通常比反复改文件更快。
一、哪些现象说明 CDN 可能缓存了旧文件
常见表现包括：
浏览器访问正常，但不同地区或不同网络看到的 robots.txt 内容不一致；
源站上的文件已经更新，公网请求仍返回旧规则；
sitemap.xml 在服务器本地能返回 200，经过 CDN 后却变成 403、404 或 5xx；
刷新页面偶尔恢复，几分钟后又出现旧内容；
响应头中的
Age持续增加，或能看到HIT、Via、X-Cache、CF-Cache-Status等缓存痕迹；Google Search Console 或其他站长平台提示无法抓取，但人工检查源站没有发现文件缺失。
这些现象不能单独证明 CDN 配置错误。搜索引擎自身可能缓存 robots.txt，DNS、WAF、回源规则和多源站部署也会造成相似结果。正确做法是同时对比 CDN 地址和源站地址的完整响应。
二、先确认爬虫拿到的是 CDN 响应还是源站响应
先请求公网域名并保存响应头：
curl -sS -D - -o /tmp/robots.txt https://example.com/robots.txt curl -sS -D - -o /tmp/sitemap.xml https://example.com/sitemap.xml
重点检查以下字段：
HTTP 状态码：是否稳定返回预期的 200；
Age：对象已在共享缓存中停留的时间；Cache-Control：源站和 CDN 对缓存时长的约定；ETag、Last-Modified：内容版本及条件请求依据；Via、X-Cache以及 CDN 厂商提供的缓存状态头；Content-Type：robots.txt 通常应为纯文本，sitemap.xml 应返回合适的 XML 类型；Content-Encoding和Content-Length：用于发现压缩或内容截断问题。
然后绕过 CDN 请求源站。若源站允许直接访问，可以把域名解析到源站 IP，同时保留正确的 Host 和 TLS SNI：
curl --resolve example.com:443:203.0.113.10 \ -sS -D - https://example.com/robots.txt curl --resolve example.com:443:203.0.113.10 \ -sS -D - https://example.com/sitemap.xml
把两组结果按状态码、响应头和正文内容逐项对比。源站内容正确、CDN 内容错误，问题多半在缓存对象、路径规则或边缘安全策略。两边都错，则应先修复源站文件、应用路由或生成任务。
如果源站只允许 CDN 回源，不要临时开放整个服务器。可以在安全组中限定管理 IP，或在内部网络执行测试，完成后恢复原有访问控制。
三、分别理解 robots.txt 和 sitemap.xml 的故障影响
robots.txt 位于站点根目录，爬虫会根据它判断哪些路径允许抓取。Google 的文档说明，Google 通常会缓存 robots.txt 最多约 24 小时；遇到网络或服务器错误时，缓存时间可能延长。因此，CDN 清理成功并不代表搜索引擎马上放弃自己保存的副本。
状态码也会影响处理结果。2xx 表示文件可正常读取；4xx 中的大部分状态通常会被视为不存在 robots.txt，但 429 属于服务器错误类处理；5xx 或网络错误可能让爬虫暂时停止抓取，并继续尝试获取文件。不要为了“禁止抓取”故意返回 403 或 5xx，应该在可正常访问的 robots.txt 中写清楚规则。
sitemap.xml 的目标更直接：稳定返回 200，XML 结构有效，URL 与站点规范一致。若 sitemap 被缓存成登录页、WAF 验证页或 HTML 错误页，即使 URL 后缀是 .xml，搜索引擎仍可能判定文件无效。检查正文开头、XML 声明、编码和 Content-Type，比只看状态码更可靠。
四、检查 CDN 规则时容易漏掉的几个位置
1. 路径匹配规则
查看 /robots.txt、/sitemap.xml、/sitemap*.xml 是否命中了特殊缓存行为。部分配置会把所有静态后缀或根目录小文件统一设置成长 TTL，结果让这两个文件跟图片、脚本一起缓存数天。
规则有优先级时，还要确认更具体的路径没有被后面的通配规则覆盖。多级 CDN 场景则要逐层检查，上游已刷新、下游仍保留旧对象的情况并不少见。
2. 缓存键
确认缓存键是否包含 Host、协议、查询参数和必要的请求头。若多个站点共用同一分发配置，而缓存键没有区分 Host，可能出现 A 站点请求命中 B 站点文件的严重问题。
带查询参数的刷新也要谨慎。/sitemap.xml?v=2 与 /sitemap.xml 可能是两个缓存对象；搜索引擎访问的通常仍是无参数地址，给后台预览链接加版本号并不能替代刷新正式 URL。
3. WAF 与机器人策略
CDN 的机器人管理、频率限制或自定义 WAF 规则可能只拦截特定 User-Agent、地区或 IP 段。人工浏览正常，不代表搜索引擎爬虫一定能访问。
可以用自定义 User-Agent 做初步对比，但不要把它当成真实搜索引擎验证。若策略只允许经过反向 DNS 验证的爬虫，应检查验证流程和规则日志，避免仅凭 User-Agent 白名单放行伪造请求。
4. 回源 Host、重写和重定向
错误的回源 Host 可能把请求送到默认虚拟主机；路径重写则可能让 /sitemap.xml 实际访问另一个应用路由。还要检查 HTTP 到 HTTPS、裸域到 www 域的跳转链，避免循环、跨域跳转或把 XML 重定向到首页。
五、如何安全刷新缓存并修复配置
优先执行按 URL 定向刷新：
https://example.com/robots.txt https://example.com/sitemap.xml
如果站点使用 sitemap 索引，还要刷新索引中本次变更涉及的子文件。除非缓存系统无法按 URL 操作，或者确认存在大范围污染，否则不建议直接清空全站缓存。全量清理会增加回源压力，也会让热门内容同时失去缓存保护。
刷新后连续请求两到三次，观察第一次 MISS 或重新验证后是否转为新对象，并核对正文哈希：
curl -sS https://example.com/robots.txt | sha256sum curl -sS https://example.com/sitemap.xml | sha256sum
随后调整长期策略：
为 robots.txt 和 sitemap.xml 设置较短、可控的共享缓存 TTL；
发布或生成文件后，通过部署钩子定向刷新对应 URL；
不缓存 403、429 和 5xx，或把错误缓存时间压到很短；
确认源站发送的
Cache-Control与 CDN 页面规则没有冲突；sitemap 更新频繁时，避免无意义的超长边缘缓存；
为状态码、内容类型、文件大小和内容哈希建立监控。
具体 TTL 没有统一答案。更新频率低的网站可以使用较长时间，频繁发布的网站则应缩短，并让刷新动作跟发布流程绑定。比“永不缓存”更稳妥的方案，是短 TTL 加定向刷新，同时保留 CDN 对突发访问的缓冲能力。
六、修复后怎样验证已经恢复
不要只在自己的电脑上刷新一次。建议按下面的顺序复核：
对比源站与 CDN 正文，确认内容和哈希一致；
从至少两个不同网络或边缘地区请求，排除单节点残留；
检查状态码、缓存状态、
Age、内容类型和重定向链；确认 robots.txt 中没有误封 CSS、JavaScript 或需要索引的目录；
验证 sitemap XML 格式、URL 数量、规范域名和最近更新时间；
在 Google Search Console 中重新检查 robots.txt 或提交 sitemap，等待搜索引擎重新抓取。
如果 CDN 已返回新内容，而站长平台仍显示旧结果，应给搜索引擎自身的缓存和重新抓取留出时间。此时继续反复全站清缓存通常没有帮助，反而会增加源站负载。
七、把这类问题挡在发布流程里
最省事的做法，是让 robots.txt 和 sitemap.xml 的生成、部署、刷新、验证形成一个闭环。发布任务完成后，自动请求正式域名，检查状态码、内容类型和哈希；若与源站不一致，立即告警并停止后续发布步骤。
同时保留最近几次文件版本和 CDN 刷新记录。出现抓取量异常时，可以快速判断是内容改动、边缘缓存、安全策略，还是搜索引擎尚未重新获取。这样处理，排查不再依赖临时猜测，也能避免同样的问题在下一次发布中重复出现。
