登录
侧边栏壁纸
博主头像
雷灵

  • 累计撰写 235 篇文章
  • 累计收到 2 条评论
技术教程

为了替代 User-Agent 给全站上了 Client Hints（客户端提示），搜索引擎收录与移动端快照却彻底错乱？排查 Vary: Sec-CH-UA 缺失致 CDN 缓存投毒、蜘蛛无 Client Hints 降级渲染空白、Nginx 响应式协商死循环与百度移动端权重暴跌我踩过的几个深坑

雷灵
2026-10-25 / 0 评论 / 8 阅读
AI 摘要由 AI 生成

文章揭示了实施User-Agent缩减计划后，因未考虑到搜索引擎爬虫无法识别Client Hints导致的问题，包括百度移动端权重暴跌、CDN缓存投毒等。文章强调在全面采用Client Hints时，必须考虑到搜索引擎爬虫的技术局限性，否则可能引发严重的搜索排名和用户体验问题。

上个月我们把全站的基础设施往前推了一大步：响应 Google 推进了快两年的 User-Agent 缩减计划（User-Agent Reduction），在全站边缘网关和 SSR 服务中全面接入了 User-Agent Client Hints（客户端提示，简称 UA-CH）。

按照官方的设计设想，传统的 User-Agent 字符串实在太臃肿，充斥着各种为了历史兼容堆砌的虚假标识，还很容易被黑产拿来做浏览器指纹追踪。换成 Client Hints 之后，浏览器默认只暴露极简的品牌和主版本，像详细的操作系统构建号、设备具体型号这类高熵信息，都需要服务端主动通过响应头发出 Accept-CH 声明，浏览器才会按需在后续请求里通过 Sec-CH-UA-Model、Sec-CH-UA-Platform-Version 等头部回传。

我们在网关与前端渲染服务里用一套全新的自适应组件替换掉了以前那套笨重的 ua-parser-js 正则库。不管是针对移动端与桌面端的排版切分、针对不同屏幕密度的高清 WebP/AVIF 图片分发，还是内部自建的风控防护，全依托这套优雅的 HTTP 标头协商机制跑了起来。

在本地开发环境以及用新版 Chrome、Edge 甚至 iPhone Safari（支持部分特性）多轮测试，表现堪称完美：桌面端渲染桌面组件，手机打开秒级切到移动版流式布局，Lighthouse 性能跑分甚至因为精简了前端正则探测代码涨了整整 4 分。

改动上线两周后，原本风平浪静的运维群突然被 SEO 同事连环艾特。

监控大盘里，全站移动端收录曲线如同坐上了滑滑梯：百度搜索资源平台里，“移动端体验”异常报告单日激增上千条，提示大量核心落地页“未适配移动设备”、“页面字体过小或排版溢出”；更致命的是，移动端核心搜索词库排名全线雪崩，很多排名前三的干货文章直接从百度移动搜索前五页消失。

紧接着，海外站的 Google Search Console 也亮起了刺眼的红灯：Googlebot 移动爬虫抓取到的页面渲染快照里，原本充实的正文区域大片留白，部分长文的收录快照甚至只剩下了一个孤零零的页头和一段“页面正在加载中”的骨架屏。

明明技术栈更加现代，代码执行效率更高，怎么一放到搜索引擎面前，全站的移动端权重就几乎被连根拔起？

带着团队把爬虫抓取记录、边缘 CDN 节点日志和 Nginx 抓包数据逐一复盘，我们才彻底看清：当这套专为现代浏览器量身定做的客户端提示协议，迎面撞上行为模式停留在传统 HTTP 时代的搜索引擎爬虫时，到底藏着多少让人吐血的致命暗礁。

坑一：把 Client Hints 当成全网标配，忽视爬虫“首访无头”与“国产蜘蛛零支持”的盲区

排查的第一步，我们直接在网关上抓取百度爬虫（Baiduspider）与谷歌爬虫（Googlebot）的真实 HTTP 请求头。

我们在生产网关机器上跑了这样一段监听：

tcpdump -i eth0 -A -s 0 'tcp port 80 or tcp port 443' | grep -B 2 -A 10 -E "User-Agent:.*(Baiduspider|Googlebot)"

把终端打印出来的请求头和普通 Chrome 浏览器的请求头放在一起对比，答案一目了然：

普通 Chrome 124 访问页面时的请求头：

GET /tech/arch-optimization HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Mobile Safari/537.36
Sec-CH-UA: "Chromium";v="124", "Google Chrome";v="124", "Not-A.Brand";v="99"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

而百度移动爬虫发过来的请求头却是这样的：

GET /tech/arch-optimization HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Linux; Android 10; Redmi K30) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Mobile Safari/537.36 Baiduspider-render/2.0; +http://www.baidu.com/search/spider.html
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

百度爬虫发来的请求里，根本不存在任何 Sec-CH-UA、Sec-CH-UA-Mobile 或者 Sec-CH-UA-Platform 标头。不仅百度没有，搜狗、360 乃至必应蜘蛛（Bingbot），没有任何一家国内搜索引擎支持 Client Hints 规范。

更关键的是 Googlebot。即便 Google 是推进 UA 缩减的主导者，但负责全网抓取的 Googlebot 爬虫集群在发起第一次 HTTP 抓取握手时，请求头里同样不会主动携带高阶 Client Hints。只有在收到服务器明确返回的 Accept-CH 头之后，它的无头渲染器（Headless Chromium）才可能在后续特定的渲染周期里附带基础提示。

再看看当时后端工程师是怎么写设备识别逻辑的：

// 踩坑写法：过分迷信 Client Hints，缺失头直接默认为桌面或兜底降级
export function resolveDevice(req: Request): 'mobile' | 'desktop' {
  const chMobile = req.headers.get('sec-ch-ua-mobile');

  if (chMobile !== null) {
    return chMobile === '?1' ? 'mobile' : 'desktop';
  }

  // 坑点所在：开发者把传统 UA 解析当成已废弃逻辑，顺手直接返回了 desktop！
  return 'desktop';
}

这段逻辑在真实办公环境里很难测出漏洞，因为团队成员的手机浏览器清一色是较新的 Chrome 或 Safari，每次访问都带着标头。

可一遇到百度移动蜘蛛，sec-ch-ua-mobile 取出来是 null。服务直接判定这次请求来自一台“宽屏桌面电脑”，于是把整整 1440px 宽度的桌面端 HTML、多栏复杂表格和没做移动折叠的大图完完整整地吐给了百度。

百度移动索引算法拿到快照一跑，发现视口完全没有针对手机屏幕做响应式布局适配，立刻在站长后台打上“非移动友好”标签，移动端自然搜索权重随即遭到毁灭性降权。

针对这个问题，网关与服务端的设备判别必须建立起严格的“降级分层梯队”：将 Client Hints 视作现代浏览器的渐进增强属性，但必须把传统的 User-Agent 正则探测作为永远不可移除的保底网。

我们在 Node.js 中间件里把逻辑彻底重构：

// 修正后的稳健逻辑：双轨并行，爬虫优先回退至标准 UA 正则
export function resolveDevice(req: Request): 'mobile' | 'desktop' {
  // 1. 如果存在标准 Sec-CH-UA-Mobile 头，说明是支持 Client Hints 的现代浏览器
  const chMobile = req.headers.get('sec-ch-ua-mobile');
  if (chMobile === '?1') return 'mobile';
  if (chMobile === '?0') return 'desktop';

  // 2. 爬虫或老旧客户端无 Client Hints，强制启用传统 User-Agent 匹配
  const ua = req.headers.get('user-agent') || '';
  const mobileRegex = /(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(xi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino/i;

  if (mobileRegex.test(ua)) {
    return 'mobile';
  }

  return 'desktop';
}

无论是国产爬虫还是无头测试脚本，只要带有 Android 或 iPhone 标识，都能稳稳拿到移动版语义化结构。

坑二：响应头漏配 Vary: Sec-CH-UA-Mobile, User-Agent，CDN 边缘缓存遭遇跨端投毒

修复了设备识别代码之后，我们以为万事大吉，立马把代码推到了预发和线上。

谁知道过了两天，更诡异的现象出现了：用手机访问同一个文章链接，有时候展示的是移动版排版，刷新几次之后又突然变成了字小如蚁的桌面版；而在办公室用电脑浏览器访问，偶尔也会刷出移动端的抽屉菜单。

抓出 CDN 边缘节点的缓存记录后，我们发现静态 HTML 的缓存完全失控了。

我们的全站架构在源站前面挂了一层七牛/腾讯云 CDN。为了降低服务端 SSR 的计算压力，技术博客落地页都配置了边缘缓存策略：

# 源站 Nginx 对博客落地页的缓存控制
location /article/ {
    proxy_pass http://upstream_node;
    add_header Cache-Control "public, max-age=3600, s-maxage=86400";
    # 踩坑点：只声明了需要的客户端提示，却漏掉了 Vary 缓存分片指令！
    add_header Accept-CH "Sec-CH-UA-Mobile, Sec-CH-UA-Platform";
}

CDN 节点缓存网页的核心依据默认只有 URL（即 Host + URI）。如果源站针对同一个 URL，根据请求头里的不同参数（例如手机还是电脑）返回了截然不同的 HTML，就必须通过 HTTP 响应头里的 Vary 字段告知 CDN 代理服务器：“这份缓存不仅取决于 URL，还取决于请求头里的指定字段”。

一旦缺少了 Vary 声明，整个缓存链条就会演变成谁先访问就以谁为准的“掷骰子游戏”：

  1. 凌晨 3:10，Googlebot 桌面蜘蛛爬取了 /article/108.html；
  2. 源站收到没有移动标识的请求，生成了一份桌面端 HTML；
  3. CDN 边缘节点把这份桌面端 HTML 缓存了下来，有效时间 24 小时；
  4. 早上 7:30，百度移动蜘蛛来到同一个节点抓取 /article/108.html；
  5. CDN 发现该 URL 命中缓存，连源站都没碰，直接把几个小时前存下的桌面端 HTML 吐给了百度移动蜘蛛；
  6. 接着一位真实手机用户访问，同样拿到了这份桌面端缓存。

这就构成了典型的 CDN 缓存跨端投毒（Cache Poisoning）。爬虫在不同时间段抓到的内容在移动与桌面之间反复横跳，甚至出现百度移动端快照收录了桌面版、谷歌桌面端快照收录了移动版汉堡菜单的荒唐局面。

不仅如此，由于百度蜘蛛不发 Sec-CH-UA-Mobile 而普通手机发，光配 Vary: Sec-CH-UA-Mobile 依然不够。

如果只声明 Vary: Sec-CH-UA-Mobile，CDN 会把“无该头部”的请求统一归为一个缓存池。当没有该标头的百度移动爬虫访问时，它依然会命中同属“无该标头”池子里的桌面版缓存！

最终在 Nginx 源站与 CDN 规则中，必须把这几个关键 Vary 维度补齐：

# 稳妥的 CDN 缓存隔离配置
location /article/ {
    proxy_pass http://upstream_node;

    # 声明服务器支持的客户端提示
    add_header Accept-CH "Sec-CH-UA-Mobile, Sec-CH-UA-Platform" always;

    # 关键修复：告诉 CDN 针对这几个头部建立独立的缓存分片副本
    add_header Vary "Sec-CH-UA-Mobile, User-Agent, Accept-Encoding" always;

    # 移动设备与桌面设备由后端识别后注入内网自定义头，用于 CDN 辅助分片
    proxy_set_header X-Device-Type $device_type;
}

有了明确的 Vary 标头，CDN 边缘才会为带着 Sec-CH-UA-Mobile: ?1 的手机端、带着 User-Agent: ...Android... 的百度移动爬虫，以及标准的桌面客户端分别建立独立的缓存空间，彻底杜绝快照混淆。

坑三：滥用 Critical-CH 协商协议，导致传统搜索引擎蜘蛛遭遇网络抓取截断

在解决缓存问题的过程中，团队里有位同学查阅了 W3C Client Hints 规范文档，发现了一个叫 Critical-CH 的机制。

按照规范定义，浏览器首次发起请求时往往不知道服务端需要哪些客户端提示。如果服务端认为某些提示信息是页面首屏渲染不可或缺的关键依赖（例如首屏需要根据 Sec-CH-UA-Model 针对折叠屏做针对性布局），就可以在响应中加上：

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model

规范要求：当支持该特性的现代浏览器发现服务器响应了 Critical-CH，且自己刚才发出的请求里正好缺了其中某项提示时，浏览器必须立即丢弃刚才收到的初步响应，自动重启握手流程，带上完整的提示标头重新发起 GET 请求。

这位同学觉得这个机制能彻底解决新访客首跳缺少提示的问题，于是在全站全局加上了 Critical-CH。

然而这个改动上线不到 48 小时，服务器错误日志里的抓取异常直接爆表。

在 Nginx access.log 里，大量搜索引擎爬虫的访问记录呈现出异常的零字节截断（bytes_sent: 0）与 499 Client Closed Request 状态码：

123.125.71.56 - - [14/Oct/2026:14:22:01 +0800] "GET /article/205.html HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Linux; Android 10; Redmi K30)...Baiduspider-render/2.0"
66.249.66.89 - - [14/Oct/2026:14:22:05 +0800] "GET /article/205.html HTTP/1.1" 200 452 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X...Googlebot/2.1)"

问题恰恰出在爬虫底层 HTTP 客户端的实现上：
绝大多数搜索引擎爬虫为了保证全网数以百亿计页面的抓取通吞吐量，其网络引擎基于轻量级的标准 HTTP 协议栈打造，根本没有实现针对 Critical-CH 的连接中断重试机制！

当爬虫发来普通的 GET 请求，突然收到一个带有 Critical-CH 的响应头时：

  1. 部分对规范敏感的解析器（如特定版本的无头抓取探针）认为协议未达成一致，直接中止连接，在服务端留下 499 错误；
  2. 百度与搜狗蜘蛛甚至直接把这当作服务端连接不稳定的信号。多次抓取遭遇连接重置后，搜索引擎的反作弊与健康度模型判定该站点服务器极不稳定，迅速下调抓取配额（Crawl Budget）。
  3. 抓取配额一旦下跌，新发布的技术文章几天都见不到蜘蛛的身影，旧文章的死链和更新也得不到同步。

我们得出了一个沉痛的结论：在面向公开网络搜索收录的博客、文档和内容型落地页上，严禁在全局链路启用 Critical-CH。

Critical-CH 只适合内网系统或需要高精度设备鉴权的应用型后台。对于公网内容，必须永远坚持“能给就给，不给就拿标准 UA 凑合解析，首次请求务必一次性给全完整 HTML 内容”的原则。

坑四：双域名架构下的重定向逻辑冲突，将爬虫踹进 302 死循环

我们博客早期的架构是主站用 www.example.com，移动端用单独的 m.example.com，后来虽然做了自适应，但为了兼容老用户的书签，依然保留了 m. 域名的二级解析，并在 Nginx 层做了相互重定向。

在引入 Client Hints 之前，这套跳转用的是老资格的 Nginx if 语句：

# 老版主站 Nginx 跳转规则
if ($http_user_agent ~* "(android|iphone|mobile)") {
    return 302 https://m.example.com$request_uri;
}

改版时，网关同事把主站的判定依据换成了新的 Client Hints：

# 踩坑示范：两套域名使用的判定依据断层
# 1. 主站 www.example.com 上的配置：
set $is_mobile 0;
if ($http_sec_ch_ua_mobile = "?1") {
    set $is_mobile 1;
}
if ($http_user_agent ~* "(android|iphone|mobile)") {
    set $is_mobile 1;
}
if ($is_mobile = 1) {
    return 302 https://m.example.com$request_uri;
}

# 2. 移动站 m.example.com 上的回跳配置：
# 如果不是手机，就跳回桌面版主站
if ($http_sec_ch_ua_mobile = "?0") {
    return 302 https://www.example.com$request_uri;
}
# 致命盲区：工程师在移动站上把传统 UA 兜底给漏掉了！

看仔细这段看似周全的规则：
当百度移动蜘蛛（携带 Android User-Agent，但不带 Sec-CH-UA-Mobile）访问主站 https://www.example.com/article/50.html 时：

  1. 主站读取到 User-Agent 包含 android，判定为手机端，返回 302 跳转到 https://m.example.com/article/50.html；
  2. 蜘蛛顺着 302 来到了移动站 m.example.com；
  3. 移动站的 Nginx 检测请求头：$http_sec_ch_ua_mobile 根本不存在，值为空，不等于 ?1；
  4. 移动站的后端服务（采用上文坑一的早期逻辑）由于没拿到客户端提示，判定此访客为桌面端，又抛出一个 302 把它甩回 https://www.example.com/article/50.html！

两台服务器像打乒乓球一样，把百度移动爬虫在 www. 和 m. 之间来回踢皮球。

# 用 curl 模拟百度移动爬虫测试，惨不忍睹的 302 循环
curl -I -A "Mozilla/5.0 (Linux; Android 10; Redmi K30) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Mobile Safari/537.36 Baiduspider-render/2.0" https://www.example.com/article/50.html

终端一跑，连续重定向超过 10 次直接报 ERR_TOO_MANY_REDIRECTS。

搜索引擎爬虫对重定向循环有着极其严厉的惩罚机制。一旦发现页面陷入 302 循环，爬虫会立刻掐断抓取并给该 URL 贴上“死链”标签，一周内全站从该路径衍生出的收录全部被剔除。

为了解决双端重定向断层，我们在 Nginx 中使用统一的 map 状态机接管判定，并保证两套域名的逻辑彻底同构：

# 在 nginx.conf 的 http 块内统一声明双重映射
map $http_sec_ch_ua_mobile $client_hint_is_mobile {
    "?1"        1;
    "?0"        0;
    default     -1; # 代表客户端未发送该标头
}

map $http_user_agent $ua_is_mobile {
    default     0;
    "~*android" 1;
    "~*iphone"  1;
    "~*mobile"  1;
}

# 最终决策矩阵
map "$client_hint_is_mobile:$ua_is_mobile" $final_is_mobile {
    "1:0"       1; # Client Hints 声明为移动端
    "1:1"       1; # 两者皆声明为移动端
    "0:1"       0; # Client Hints 优先（如桌面浏览器开启移动模拟器）
    "0:0"       0; # 明确为桌面端
    "-1:1"      1; # 无 Client Hints 时，坚决继承传统 UA 判定
    "-1:0"      0; # 默认兜底为桌面端
}

通过这种明确的四态组合映射，即便任何一边缺失标头，也不会出现互相对立的判决结果。

坑五：前端水合（Hydration）双端状态不一致，触发 DOM 树崩溃导致爬虫快照留白

最后一个深坑埋在前端渲染工程内部。

解决了服务端的重定向和响应头之后，为什么 Googlebot 抓到的移动页面快照依然会出现正文空白的情况？

我们用无头浏览器抓出 Googlebot 在无头渲染沙箱里的控制台报错日志，发现了一串醒目的红字：

Uncaught Error: Hydration failed because the initial UI does not match what was rendered on the server.
Expected server HTML to contain a matching <div> in <main>.
See https://react.dev/link/hydration-mismatch for more information.

问题出在前端代码对 navigator.userAgentData 的无条件信赖上。

在 React/Next.js 的自适应正文组件里，前端工程师为了追求极致交互，写了这样一段自执行逻辑：

// 踩坑前端组件：盲目使用客户端 navigator.userAgentData 进行状态推断
export default function ResponsiveArticleBody({ serverHtml, mobileHtml }: Props) {
  const [isMobile, setIsMobile] = useState(false);

  useEffect(() => {
    // 坑点：客户端运行环境拥有真实客户端提示，但在服务端该提示并未注入
    if (typeof navigator !== 'undefined' && (navigator as any).userAgentData) {
      setIsMobile((navigator as any).userAgentData.mobile);
    } else {
      setIsMobile(window.innerWidth < 768);
    }
  }, []);

  return (
    <article className="content-body">
      {isMobile ? <div dangerouslySetInnerHTML={{ __html: mobileHtml }} /> : <div dangerouslySetInnerHTML={{ __html: serverHtml }} />}
    </article>
  );
}

当 Googlebot 的渲染沙箱运行这段代码时：

  1. 服务端因为前述原因，给 Googlebot 吐出的初始 HTML 结构是基于标准流式布局的 DOM 树；
  2. 当 Googlebot 的无头 Chromium 启动客户端脚本执行水合时，它的 navigator.userAgentData.mobile 返回了特定值；
  3. React 发现客户端计算出的初次挂载结构与服务端传送过来的静态 HTML 标签类型完全不吻合，直接触发了硬性水合崩溃（Hydration Error）；
  4. 在现代前端框架中，水合报错往往会导致组件卸载并尝试退回客户端纯渲染，但在爬虫短暂的渲染超时窗口（通常只有 3-5 秒）内，异步内容还没来得及拉取，渲染线程就结束了；
  5. 最终搜索引擎保存下来的快照就是一片空白或残缺不全的代码骨架。

针对 SEO 敏感的内容型页面，响应式排版应当尽可能依赖纯 CSS 的媒体查询（Media Queries）与 Container Queries，而不是在 JavaScript 运行时动态切换两套截然不同的 DOM 节点。

对于必须做服务端切分的极重度差异模块，必须确保服务端渲染使用的判断标记（由请求头提取出来的布尔值），通过序列化直接透传给客户端作为初次渲染状态，彻底杜绝水合阶段的前后端分歧：

// 修复方案：服务端明确注入初始设备标识，保证前后端水合基准完全统一
interface PageProps {
  initialDevice: 'mobile' | 'desktop';
  content: string;
}

export default function ArticlePage({ initialDevice, content }: PageProps) {
  // 水合基准完全以服务端为准，后续交互通过 CSS 处理适配
  return (
    <main className={`article-layout ${initialDevice}`}>
      <article className="prose" dangerouslySetInnerHTML={{ __html: content }} />
    </main>
  );
}

避坑总结：Client Hints 时代的 SEO 兼容自检表

经过整整一周的排查、发版与回滚，我们把全站的抓取逻辑重新理顺。

两周后，百度与谷歌的爬虫重新回归正常抓取轨道，站长平台的移动友好度报错清零，关键词排名也逐步恢复到了改版前的水平。

如果你的站点也正准备拥抱现代 Web 规范、接入 Client Hints 或正在遭遇莫名其妙的移动端收录暴跌，不妨用下面这条 curl 指令快速检验你的边缘节点：

# 模拟百度移动蜘蛛，验证响应头是否包含完整 Vary，且内容不返回 302 循环与桌面端代码
curl -i -H "Accept: text/html" \
     -A "Mozilla/5.0 (Linux; Android 10; Redmi K30) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Mobile Safari/537.36 Baiduspider-render/2.0" \
     https://www.example.com/article/your-test-slug.html

检查返回结果时，重点看准这四个硬核指标：

  • 响应头是否包含 Vary: Sec-CH-UA-Mobile, User-Agent，保证 CDN 不会把桌面内容串味给移动爬虫；
  • 是否严禁在全网公共页面滥用 Critical-CH，防止爬虫因协议不支持而直接断开连接；
  • 在无任何 Client Hints 标头的情况下，系统能否准确降级使用传统 User-Agent 正则探测，保证移动爬虫拿到标准的移动友好 HTML；
  • 双域名（www 与 m）跳转判定逻辑是否保持强一致状态机，绝不出现相互踢皮球的 302 循环。

新技术规范很美好，但在搜索引擎的世界里，永远要记住：并不是所有造访你站点的访客，都是一台崭新的 Chrome 浏览器。

版权所有：雷灵模板
文章标题：为了替代 User-Agent 给全站上了 Client Hints（客户端提示），搜索引擎收录与移动端快照却彻底错乱？排查 Vary: Sec-CH-UA 缺失致 CDN 缓存投毒、蜘蛛无 Client Hints 降级渲染空白、Nginx 响应式协商死循环与百度移动端权重暴跌我踩过的几个深坑
文章链接：https://www.llbbs.cn/jishujaocheng/295.html
本站文章均为原创，未经授权请勿用于任何商业用途
0
SEO优化 移动端适配 Nginx配置 Baiduspider Googlebot CDN缓存 ClientHints UserAgent
版权属于： 雷灵
本文链接： https://www.llbbs.cn/jishujaocheng/295.html
文章声明： 本文版权内容属于《雷灵模板》转载请标明出处
相关推荐
苹果CMS V10采集后无法播放？五大核心排查与修复实战指南
苹果CMS V10采集后无法播放？五大核心排查与修复实战指南
 网站开启 HTTP/2 甚至 HTTP/3 百度收录却断崖暴跌？排查 Baiduspider 协议兼容、Nginx ALPN 降级协商与连接重置 (RST) 我踩过的几个坑
网站开启 HTTP/2 甚至 HTTP/3 百度收录却断崖暴跌？排查 Baiduspider 协议兼容、Nginx ALPN 降级协商与连接重置 (RST) 我踩过的几个坑
 Linux 内存 buff/cache 占满、free 见底？排查内存假耗尽、swappiness 调优与 drop_caches 我踩过的几个坑
Linux 内存 buff/cache 占满、free 见底？排查内存假耗尽、swappiness 调优与 drop_caches 我踩过的几个坑
 后端开发小白必学：Node.js + Express 5分钟搭个人博客API后台，避免数据库连接泄露的3个新手雷区
后端开发小白必学：Node.js + Express 5分钟搭个人博客API后台，避免数据库连接泄露的3个新手雷区

评论一下？

OωO
取消