你的网站用了Brotli压缩，百度真的能识别吗？

你刚配好Brotli，首页打开快了一截，心里却打鼓：百度蜘蛛来爬的时候，它真能“看懂”这个压缩包吗？要是它解不开，你优化的页面速度，对SEO来说就等于没发生。

Brotli压缩到底比Gzip强在哪？

Brotli是谷歌推出来的压缩新选手，不是噱头。它对HTML、CSS、JS这类文本文件的“瘦身”效果，确实比Gzip更实在。

文件小了，用户下载的数据就少，页面自然亮得更快。不少资讯站、博客、电商后台都悄悄切过去了——不是为了炫技，是真觉得省事又省流量。

我们帮一个做行业报告的网站做过对比：同样一份JS文件，Brotli压出来比Gzip轻了一大截。虽然没法说具体数字，但传输时带宽占用明显下降，CDN回源次数也少了。

百度蜘蛛抓取时，支持哪些压缩格式？

百度没发过公告说“全面支持Brotli”，也没在文档里写明兼容列表。但我们盯了两年多的抓取日志，跑过几十个不同配置的站点，结论很实在：

Gzip是百度蜘蛛的“母语”。不管哪个版本、从哪个机房来，它都能稳稳接住，解压、解析、建索引，一气呵成。

Brotli呢？偶尔能通，但不稳。有的爬虫实例能解，有的直接跳过；同一台服务器，今天行明天不行；换个UA再试，结果又变了。它不是“不支持”，而是“不承诺支持”。

如果蜘蛛遇到Brotli压缩，会发生什么？

最怕的是：你的Nginx或CDN只给br，不给gzip，而百度蜘蛛偏偏撞上那个不认Brotli的实例。

结果就是——它拿到一堆二进制乱码，或者干脆返回406（Not Acceptable）。页面内容进不了百度数据库，标题、摘要、关键词全白搭。你更新了10篇干货，百度可能只当它们不存在。

有个技术博主就踩过这坑：他用Cloudflare自动开启Brotli，但没设User-Agent分流。百度收录的页面摘要里全是“ ”，排名掉得悄无声息。等他加了一行规则，让百度爬虫进来时强制走gzip，三天后收录就恢复正常了。

如何安全地为网站启用Brotli压缩？

别一刀切开Brotli，要“看人下菜碟”。

核心就一条：服务器必须同时支持gzip和br，然后靠请求头里的 Accept-Encoding 做判断。

现代浏览器（Chrome/Firefox/Edge）发请求时会写明：Accept-Encoding: br, gzip → 你回br。
百度蜘蛛的请求头通常是：Accept-Encoding: gzip → 你老老实实回gzip。

不需要额外装插件，也不用改业务代码。Nginx加几行配置，Apache开个模块，CDN控制台勾个选项，就能让Brotli和Gzip各司其职。

除了压缩格式，还有哪些速度优化百度更看重？

百度不查你用了什么算法，它看的是用户点开后——等不等、卡不卡、关不关。

比如首屏图片加载慢，哪怕你JS用Brotli压得再狠，用户第一眼还是卡在空白页。这时候把轮播图换成WebP+懒加载，比换压缩算法管用得多。

再比如一个企业官网，把几个阻塞渲染的第三方统计脚本挪到<body>底部，首屏可交互时间缩短了不少。后来他们发现，百度搜索结果页里“阅读时长”指标涨了，几个核心词的点击率也跟着上去了。

技术是工具，体验才是答案。

今天就能执行的具体操作步骤

现在就打开 Chrome，按 F12 调出开发者工具，切到「网络」标签页，刷新你的首页。
随便点一个 .js 或 .css 文件，在右侧「标头」里找 Content-Encoding 字段——确认它显示的是 gzip 还是 br。

接着，装一个免费的 User-Agent 切换插件（比如 Chrome 商店搜 “User-Agent Switcher”），选中 Baiduspider 模拟百度爬虫，再刷一次。
这次看同一个文件的 Content-Encoding：如果还是 br，或者压根没这个字段，说明你的服务器没对百度做区分。

今天就去你的 Nginx 配置文件（通常是 /etc/nginx/conf.d/your-site.conf）里，在 server 块里加这一段：

if ($http_user_agent ~* "Baiduspider") {
    set $gzip_for_spider "on";
}
gzip_vary on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

然后执行 sudo nginx -t && sudo systemctl reload nginx。
两分钟，Brotli照用，百度照抓。