[{"data":1,"prerenderedAt":320},["ShallowReactive",2],{"blog-baidu-js-rendering-test":3,"blog-prev-baidu-js-rendering-test":118,"blog-next-baidu-js-rendering-test":220},{"id":4,"title":5,"author":6,"body":7,"canonical":102,"category":103,"cover":102,"date":104,"description":105,"draft":106,"extension":107,"keywords":102,"meta":108,"navigation":109,"noindex":106,"ogImage":102,"path":110,"seo":111,"seoDescription":102,"seoTitle":102,"stem":112,"tags":113,"updated":102,"__hash__":117},"blog\u002Fblog\u002Fbaidu-js-rendering-test.md","百度对 JS 渲染支持到什么程度，我们测了 6 个页面","元析智能",{"type":8,"value":9,"toc":91},"minimark",[10,14,18,21,24,31,37,43,49,55,61,64,67,70,73,76,79,82,85,88],[11,12,13],"p",{},"百度能渲染一部分 JS，但对异步数据、懒加载内容、动态注入的元信息支持不稳定。2026 年 3 月我们搭了一个独立测试域，用 6 个页面把这件事测了一遍。",[15,16,17],"h2",{"id":17},"怎么测的",[11,19,20],{},"6 个页面分别只测一个变量：纯 React 渲染标题和正文、正文通过接口异步加载、内链由 JS 动态插入、图片懒加载、Web Component 渲染正文、JSON-LD 由 JS 注入。观察方法用百度搜索资源平台的抓取诊断，看\"抓取到的 HTML\"里到底有什么。",[15,22,23],{"id":23},"结果",[11,25,26,30],{},[27,28,29],"strong",{},"纯 React 渲染","：标题和首屏正文被渲染出来，折叠面板里的内容没有渲染。",[11,32,33,36],{},[27,34,35],{},"接口异步加载的正文","：大部分没抓到，只有个别几次拿到了部分。",[11,38,39,42],{},[27,40,41],{},"JS 动态插入的内链","：没有被推理到，蜘蛛没有顺着这些链接去抓新页面。",[11,44,45,48],{},[27,46,47],{},"懒加载图片","：未被识别，图片没有进索引。",[11,50,51,54],{},[27,52,53],{},"Web Component 渲染的正文","：部分失败，不同页面结果不一致。",[11,56,57,60],{},[27,58,59],{},"JS 注入的 JSON-LD","：完全没被识别。",[15,62,63],{"id":63},"结论怎么用",[11,65,66],{},"首屏静态内容可靠。异步接口、懒加载、动态注入这三类不可靠。所以：标题、正文、内链、结构化数据，必须出现在服务端返回的 HTML 里。图片如果要参与索引，首屏别用懒加载。",[15,68,69],{"id":69},"我们还顺手测了抓取节奏",[11,71,72],{},"同样的 6 个页面，静态版和 JS 版各一份，观察百度蜘蛛的抓取次数。30 天里静态版平均被抓 4 次，JS 版平均 2 次，而且 JS 版的抓取集中在页面刚上线那几天，之后明显减少。这说明百度对渲染成本高的页面会降低抓取频率，这个结论比单个页面的收录结果更值得注意。",[15,74,75],{"id":75},"给前端的三个要求",[11,77,78],{},"标题和正文在服务端返回；内链用真实 a 标签，别用 onclick 跳转；结构化数据写在模板里，别在组件挂载后插入。三条做到，百度的收录表现会稳定很多，Google 那边也不会更差。",[15,80,81],{"id":81},"一个现实的做法",[11,83,84],{},"如果前端改不动，至少把关键内容预渲染一层，让蜘蛛拿到静态 HTML。用户走原 SPA，两边并行一段时间，等前端排期再做真正的 SSR。这条路我们走过几次，可行，但要接受维护成本。",[15,86,87],{"id":87},"立场",[11,89,90],{},"百度不是不能渲染，是别把 SEO 的关键内容压在渲染上。赌蜘蛛的行为，收益不确定，成本却是确定的——每次改版都要重新赌一次。",{"title":92,"searchDepth":93,"depth":93,"links":94},"",2,[95,96,97,98,99,100,101],{"id":17,"depth":93,"text":17},{"id":23,"depth":93,"text":23},{"id":63,"depth":93,"text":63},{"id":69,"depth":93,"text":69},{"id":75,"depth":93,"text":75},{"id":81,"depth":93,"text":81},{"id":87,"depth":93,"text":87},null,"技术SEO","2026-06-12","百度能执行 JS，但能力有限。我们设计 6 个测试页面，分别测 React 渲染、接口异步数据、动态内链、懒加载、Web Component、JSON-LD 注入，记录百度的实际抓取结果。",false,"md",{},true,"\u002Fblog\u002Fbaidu-js-rendering-test",{"title":5,"description":105},"blog\u002Fbaidu-js-rendering-test",[114,115,116],"JS渲染","百度收录","SPA","HYlisdd4OJXU-B0mgc-w9gjgjZ9pgcYrpptfcwc8WpI",{"id":119,"title":120,"author":6,"body":121,"canonical":102,"category":103,"cover":102,"date":209,"description":210,"draft":106,"extension":107,"keywords":102,"meta":211,"navigation":109,"noindex":106,"ogImage":102,"path":212,"seo":213,"seoDescription":102,"seoTitle":102,"stem":214,"tags":215,"updated":102,"__hash__":219},"blog\u002Fblog\u002Fbaidu-index-volume-drop.md","百度索引量掉了 40%，我们从哪查起",{"type":8,"value":122,"toc":200},[123,126,130,133,136,139,143,146,149,152,156,159,162,165,169,172,175,179,182,185,188,191,194,197],[11,124,125],{},"百度索引量一周掉 40%，先别改内容。我们按\"先看抓取、再看站点、最后看内容\"的顺序查，过去 6 次里有 4 次问题出在技术层。这篇把排查步骤和每一步看什么数据写清楚。",[15,127,129],{"id":128},"第一步确认掉的是索引量还是抓取量","第一步：确认掉的是索引量还是抓取量",[11,131,132],{},"这两个数经常被混着看。索引量掉、抓取量正常，说明搜索引擎来了但把页面从索引里移除了；索引量掉、抓取量也掉，说明它不来了。",[11,134,135],{},"在搜索资源平台里，索引量和抓取频次是两个入口，要分开看。我们见过客户说\"索引掉了\"，实际是抓取频次掉了，页面还在索引里，只是不再更新。",[11,137,138],{},"如果是抓取量先掉，跳到第三步查服务器。",[15,140,142],{"id":141},"第二步看掉的是哪类页面","第二步：看掉的是哪类页面",[11,144,145],{},"把索引量按目录拆开看。文档、博客、产品、标签页，哪一类掉得最多。",[11,147,148],{},"我们 2026 年 2 月遇到一个站，索引量从 2.4 万掉到 1.4 万，拆开看掉的全是标签页和分页。这类页面本来价值就低，掉索引不算坏事。",[11,150,151],{},"如果掉的是产品页和文档页，那才是问题。",[15,153,155],{"id":154},"第三步看服务器和抓取","第三步：看服务器和抓取",[11,157,158],{},"三个数：5xx 错误率、平均响应时间、robots 是否被改过。",[11,160,161],{},"我们遇到最多的原因是服务器在索引变化前一两天出过问题：CDN 配置改错、证书过期、源站 502。抓取诊断里能看到具体状态码。",[11,163,164],{},"还有一个隐蔽的：改版时把 sitemap 或 robots 的路径改了，搜索引擎拿到 404，抓取停摆。",[15,166,168],{"id":167},"第四步看页面本身有没有被改","第四步：看页面本身有没有被改",[11,170,171],{},"索引量掉之前两周内上线的改动，重点查：模板调整、URL 变更、canonical 配置、noindex 误加。",[11,173,174],{},"我们见过一个客户在模板里加了全局 noindex，测试环境忘了删，上线后整站索引掉了 90%。这种问题查页面源代码十分钟能发现。",[15,176,178],{"id":177},"第五步看内容质量","第五步：看内容质量",[11,180,181],{},"前面四步都正常，再看内容。是不是最近批量发了低质内容，或者被判定重复。",[11,183,184],{},"内容问题导致的索引下降通常是渐进的，不会一周掉 40%。一周暴跌，优先查技术。",[15,186,187],{"id":187},"我们的修复顺序",[11,189,190],{},"先修技术问题，再等 2 到 3 周观察。索引恢复比抓取恢复慢，抓取频次回来之后，索引量一般还要 2 周才回升。",[11,192,193],{},"内容问题最后处理，因为它见效最慢。如果技术没问题、内容也没大改，别乱动，观察一个月再说。百度索引量的波动比很多人想的频繁，一周的波动不代表趋势。",[15,195,196],{"id":196},"一句判断",[11,198,199],{},"索引量是结果，不是原因。掉的时候先找上游：抓取、服务器、配置。大多数时候，答案不在内容团队手里。",{"title":92,"searchDepth":93,"depth":93,"links":201},[202,203,204,205,206,207,208],{"id":128,"depth":93,"text":129},{"id":141,"depth":93,"text":142},{"id":154,"depth":93,"text":155},{"id":167,"depth":93,"text":168},{"id":177,"depth":93,"text":178},{"id":187,"depth":93,"text":187},{"id":196,"depth":93,"text":196},"2026-06-11","百度索引量一周掉 40%，先别改内容。我们按“先看抓取、再看站点、最后看内容”的顺序查，6 次里有 4 次问题出在技术层。排查步骤、每一步看什么数据、修复顺序都在这篇。6 次里有 4 次是技术问题，这个比例值得记住。",{},"\u002Fblog\u002Fbaidu-index-volume-drop",{"title":120,"description":210},"blog\u002Fbaidu-index-volume-drop",[216,217,218],"百度索引","收录诊断","站点健康","P_JsDHhE9RzVFPmjahM0RCRksRAp9B5EWysUe7Ad7uY",{"id":221,"title":222,"author":6,"body":223,"canonical":102,"category":103,"cover":102,"date":309,"description":310,"draft":106,"extension":107,"keywords":102,"meta":311,"navigation":109,"noindex":106,"ogImage":102,"path":312,"seo":313,"seoDescription":102,"seoTitle":102,"stem":314,"tags":315,"updated":102,"__hash__":319},"blog\u002Fblog\u002Ffont-loading-chinese.md","中文字体加载慢，问题不在字体文件大小",{"type":8,"value":224,"toc":301},[225,228,231,234,237,240,243,246,249,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298],[11,226,227],{},"2026 年 7 月我们给一个站查首屏，字体请求花了 1.9 秒，字体包 8 兆。中文字体确实大，但把它变慢的往往不是体积，而是加载时机和切换方式。改完之后同一个包首屏基本感觉不到等待。",[15,229,230],{"id":230},"中文字体为什么这么大",[11,232,233],{},"一个完整的思源黑体，包含两万多个字形，压缩后也有五到八兆。网页上真正用到常用字大概三千五，剩下九成多是浪费。",[11,235,236],{},"所以中文字体优化的第一件事不是压缩，是子集化：把你实际用到的字挑出来，生成一个只有几百 KB 的字体文件。",[15,238,239],{"id":239},"子集化怎么做",[11,241,242],{},"第一种，按页面用字生成。统计页面里出现的所有字符，生成对应子集。缺点是页面内容一改就要重新生成，适合内容稳定的官网。",[11,244,245],{},"第二种，按 unicode-range 分片。把字体切成多个小文件，浏览器按需加载。首屏常用字在第一个分片里，加载很快。",[11,247,248],{},"第三种，用在线字体服务，它们默认做分片。代价是多一个外部依赖，国内访问还要考虑稳定性。",[15,250,252],{"id":251},"font-display-三种取值","font-display 三种取值",[11,254,255],{},"block，字体没加载完文字不显示，最多等三秒。体验最差，用户看到一片空白。",[11,257,258],{},"swap，先用系统字体显示，加载完再换。文字马上可见，但切换时会有位移，字号大的时候很明显。",[11,260,261],{},"optional，如果字体没在很短的时间内加载好，这次就用系统字体，不切换。最不影响体验，但品牌字体可能经常不显示。",[11,263,264],{},"我们的选择是标题用 swap 加尺寸校正，正文直接用系统字体。",[15,266,267],{"id":267},"预加载和预连接",[11,269,270],{},"字体文件藏在 CSS 里，浏览器要等 CSS 解析完才发现它。用 preload 提前告诉浏览器，能省掉一个来回。",[11,272,273],{},"preload 要带 crossorigin，否则会因为请求类型不匹配被下载两次。这个坑我们踩过，字体反而更慢了。",[11,275,276],{},"字体放在第三方域名上，再加一条 preconnect，把 TLS 握手提前做掉。",[15,278,279],{"id":279},"什么时候干脆别用",[11,281,282],{},"一个官网只用了两种英文字体、没有中文需求，完全可以不加载自定义字体，用系统字体栈。",[11,284,285],{},"系统字体在 macOS、Windows、安卓上都不一样，但都好看，且零加载时间。首屏速度能提升几百毫秒。",[11,287,288],{},"品牌必须用特定字体，那就只用在标题和 logo 上，正文用系统字体。我们的默认建议就是这条。",[15,290,291],{"id":291},"一个验证方法",[11,293,294],{},"改完别只看 Lighthouse 的分数。把网络降到 3G，清缓存刷新，观察文字什么时候出现、什么时候变形。",[11,296,297],{},"再看真实用户数据。CrUX 里没有字体指标，但 LCP 如果卡在文字上，说明字体拖了后腿。",[11,299,300],{},"字体优化的收益常常被低估，因为它不像图片那么显眼。但首屏里最大的那块如果是标题文字，字体就是 LCP 的直接原因。",{"title":92,"searchDepth":93,"depth":93,"links":302},[303,304,305,306,307,308],{"id":230,"depth":93,"text":230},{"id":239,"depth":93,"text":239},{"id":251,"depth":93,"text":252},{"id":267,"depth":93,"text":267},{"id":279,"depth":93,"text":279},{"id":291,"depth":93,"text":291},"2026-06-13","一个中文字体包动辄八兆，但真正拖慢首屏的是加载时机和字形切换。这篇写子集化怎么做、font-display 三种取值怎么选、什么时候干脆别用自定义字体。",{},"\u002Fblog\u002Ffont-loading-chinese",{"title":222,"description":310},"blog\u002Ffont-loading-chinese",[316,317,318],"字体加载","页面体验","首屏","Sj3AIAaQl9sp9T_6h0hDGKZlWOxFU1oPgRu62eF9Nog",1794088104806]