robots.txt是搜索引擎爬虫访问网站时读取的第一个文件，它的作用相当于一份抓取许可清单，明确告诉爬虫哪些路径可以抓、哪些路径禁止进入。这个文件本身非常简单，就是一个纯文本，但在接入CDN之后，情况就变复杂了：缓存会导致规则更新延迟，回源策略可能让不同节点返回不同的robots.txt，甚至源站配置错误会让整个网站被搜索引擎误判为禁止抓取。本文从robots.txt的规范讲起，逐步分析CDN场景下的配置要点和常见坑。
robots.txt的核心语法与规范要点
robots.txt必须放置在域名根目录下，即https://ipipp.com/robots.txt（示例中域名以你的实际域名为准），并且只能有一个。它对大小写敏感的部分是路径，而指令名不区分大小写。文件编码必须是UTF-8，且通过HTTP状态码200返回。如果返回404，爬虫会认为网站没有限制，可以抓取全部内容；但如果返回5xx错误，部分搜索引擎会暂时停止抓取整个站点，这就是CDN场景下最危险的情况。
基本语法由若干组规则构成，每组以User-agent开头，后跟Disallow或Allow指令。下面是一个典型示例：
User-agent: * Disallow: /admin/ Disallow: /search? Allow: /search/special-page Disallow: /*.pdf$ User-agent: Googlebot Disallow: /tmp/ Sitemap: https://www.ipipp.com/sitemap.xml
几个细节需要注意：通配符*匹配任意字符序列，$表示路径结尾匹配；Allow的优先级高于Disallow（在Google的实现中，更具体、更长的规则优先）；Crawl-delay指令目前只有少数搜索引擎支持，Google已经明确忽略它。最关键的一点：robots.txt控制的是“抓取”，而不是“收录”。如果一个页面被外部链接指向，即使被Disallow了，它仍可能出现在搜索结果中，只是没有摘要内容。想要彻底不被收录，应该使用noindex的meta标签或HTTP响应头。
CDN缓存机制对robots.txt的影响与配置策略
robots.txt的特点是更新频率低但时效性要求高。当你临时屏蔽某个目录时，如果CDN还缓存着旧版本，爬虫在接下来的缓存周期内仍会按旧规则抓取。更糟的是，搜索引擎对robots.txt的缓存时间最长可达24小时甚至更久，两层缓存叠加会让规则变更迟迟不能生效。
正确的CDN配置思路是：对robots.txt设置短缓存或不缓存。以Nginx源站为例，可以直接在响应头中声明：
location = /robots.txt {
root /data/site;
# 关键：robots.txt不缓存或缓存时间极短
add_header Cache-Control "no-cache, must-revalidate";
add_header CDN-Cache "BYPASS";
expires -1;
}如果使用云厂商CDN控制台，一般在缓存规则配置中新增一条文件路径规则，将/robots.txt的缓存时间设置为0或者几秒，并确保源站返回的Cache-Control头不被CDN覆盖。此外，务必保证所有CDN边缘节点回源时拿到的是同一份robots.txt。有些站点在多源站负载均衡场景下，不同源站部署了不同版本的文件，会导致爬虫在不同时间抓到相互矛盾的规则，搜索引擎可能选择最严格的那条执行，造成大范围误屏蔽。
还有一个容易被忽视的问题：CDN的WAF或安全防护可能把爬虫请求拦截，返回403或验证页面。爬虫拿不到robots.txt时会反复重试，浪费抓取配额。建议在CDN的安全策略中把主流搜索引擎的爬虫UA加入白名单，但要注意伪造UA的风险，条件允许时可以反向DNS验证爬虫IP的真伪。
多环境与动态robots.txt的实践方案
很多网站存在测试环境、预发布环境和生产环境，robots.txt的需求截然不同：测试站应该整站禁止抓取，避免重复内容稀释生产站的权重。常见做法是通过源站程序动态输出robots.txt：
package main
import (
"net/http"
"os"
)
func robotsHandler(w http.ResponseWriter, r *http.Request) {
env := os.Getenv("APP_ENV")
w.Header().Set("Content-Type", "text/plain; charset=utf-8")
w.Header().Set("Cache-Control", "no-cache")
if env != "production" {
// 非生产环境整站禁止抓取
w.Write([]byte("User-agent: *\nDisallow: /\n"))
return
}
w.Write([]byte("User-agent: *\nDisallow: /admin/\nDisallow: /api/internal/\n\nSitemap: https://www.ipipp.com/sitemap.xml\n"))
}
func main() {
http.HandleFunc("/robots.txt", robotsHandler)
http.ListenAndServe(":8080", nil)
}动态输出robots.txt的好处是规则和部署环境绑定，不会因为人为疏忽把测试配置带到线上。但要注意，动态接口必须轻量，响应速度要快，否则在CDN回源时会造成延迟。同时，任何Disallow: /上线的操作都应该有审核流程，这条规则一旦生效，整个站点将从搜索结果中逐步消失，恢复期可能长达数周。
配置后如何验证规则是否生效
配置完成不代表万事大吉，验证环节不可省略。第一步用curl直接请求CDN域名下的robots.txt，确认返回内容和HTTP头：
curl -I https://www.ipipp.com/robots.txt # 关注返回的状态码是否为200，X-Cache或CDN-Cache头是否显示BYPASS或MISS curl -s https://www.ipipp.com/robots.txt | head -20
第二步借助搜索引擎提供的在线工具，例如Google的robots测试工具，输入具体URL可以查看是否被规则拦截，同时能看到Google实际缓存的robots.txt版本是否为最新。第三步定期检查CDN日志中爬虫对robots.txt的请求，如果发现大量非200响应，说明回源或防护环节出了问题。
最后建议把robots.txt纳入版本管理，每次变更留下记录。爬虫友好不是一个配置完就结束的动作，而是持续维护的过程：新增页面目录时要同步评估是否需要更新规则，CDN调整缓存架构时要重新验证robots.txt的实时性。只有源站、CDN、搜索引擎三方视角都验证通过，你的robots.txt才真正做到了既保护敏感内容，又不阻碍正常收录。
CDNrobots.txt爬虫优化修改时间：2026-09-16 19:02:43