[{"data":1,"prerenderedAt":298},["ShallowReactive",2],{"blog-prerender-baidu-indexing-test":3,"blog-prev-prerender-baidu-indexing-test":112,"blog-next-prerender-baidu-indexing-test":192},{"id":4,"title":5,"author":6,"body":7,"canonical":96,"category":97,"cover":96,"date":98,"description":99,"draft":100,"extension":101,"keywords":96,"meta":102,"navigation":103,"noindex":100,"ogImage":96,"path":104,"seo":105,"seoDescription":96,"seoTitle":96,"stem":106,"tags":107,"updated":96,"__hash__":111},"blog\u002Fblog\u002Fprerender-baidu-indexing-test.md","预渲染救不了百度收录？我们测了 4 个站","元析智能",{"type":8,"value":9,"toc":85},"minimark",[10,14,18,21,37,40,43,46,49,52,64,67,70,73,76,79,82],[11,12,13],"p",{},"预渲染对百度有效，但有前提：预渲染服务要快、快照要新、百度蜘蛛的 UA 要能命中规则。三条缺一条，效果就会打对折甚至归零。",[15,16,17],"h2",{"id":17},"四个站的三个月对照",[11,19,20],{},"2025 年 10 月，我们给四个客户站接入预渲染，方案是自建服务加缓存，观察三个月百度收录变化。",[22,23,24,28,31,34],"ul",{},[25,26,27],"li",{},"A 站，文档站 800 页：收录从 2100 涨到 1.9 万。",[25,29,30],{},"B 站，营销站 300 页：从 1400 涨到 9000。",[25,32,33],{},"C 站，产品站 600 页：从 3200 只涨到 3400。",[25,35,36],{},"D 站，博客 400 页：从 6000 涨到 7100。",[15,38,39],{"id":39},"有效的那两个做对了什么",[11,41,42],{},"预渲染服务响应都在 500 毫秒以内，快照缓存 24 小时内刷新，主站没有屏蔽预渲染服务的请求路径。A 站还额外做了两件事：把 sitemap 重新提交，并在正文里补了 300 字以上的说明文字。快照里只有标题和图片的页面，收进去也没用。",[15,44,45],{"id":45},"无效的那两个差在哪",[11,47,48],{},"C 站的预渲染服务平均响应 3.2 秒，百度蜘蛛超时后直接放弃，日志里能看到大量请求 499 中断。D 站的问题更简单：预渲染规则只匹配了 Googlebot 的 UA，百度 UA 没进白名单，一直拿到的是空壳 HTML。配置一行之差，白等了三个月。",[15,50,51],{"id":51},"三条可执行建议",[53,54,55,58,61],"ol",{},[25,56,57],{},"预渲染的 UA 白名单必须包含 Baiduspider，还要考虑百度移动蜘蛛。",[25,59,60],{},"服务响应压到 1 秒内，超时就等于没做。",[25,62,63],{},"快照定期刷新，价格、产品名这类内容别用一年前的缓存。",[15,65,66],{"id":66},"怎么验证有没有生效",[11,68,69],{},"用百度搜索资源平台的抓取诊断，看\"抓取到的 HTML\"里有没有正文。这是最直接的方法，比在浏览器里看源码可靠。Google 这边用网址检查的\"已呈现的 HTML\"。",[15,71,72],{"id":72},"成本和我们自己的做法",[11,74,75],{},"自建一套预渲染服务，按 1000 个页面算，服务器成本每月几百块，开发两天。第三方服务按请求量计费，抓取量大的站一个月要几千块，而且响应时间不受你控制，这是 C 站翻车的主要原因。",[11,77,78],{},"我们的默认做法是自建加 Redis 缓存，快照按内容类型设过期时间：产品页 6 小时，文档页 24 小时，营销页 7 天。监控加两个指标就够了——预渲染服务的 P95 响应时间和快照缓存命中率，命中率低于 80% 就要查缓存键。",[15,80,81],{"id":81},"立场",[11,83,84],{},"预渲染是止痛药，不是治疗方案。它解决的是\"现在就要收录\"，不解决\"三年后的结构问题\"。真要做长线，SSR 或者 SSG 早晚要上。预渲染只适合两类团队：排期排不出重构的，和页面数量不大、只想先拿流量的。",{"title":86,"searchDepth":87,"depth":87,"links":88},"",2,[89,90,91,92,93,94,95],{"id":17,"depth":87,"text":17},{"id":39,"depth":87,"text":39},{"id":45,"depth":87,"text":45},{"id":51,"depth":87,"text":51},{"id":66,"depth":87,"text":66},{"id":72,"depth":87,"text":72},{"id":81,"depth":87,"text":81},null,"技术SEO","2026-03-20","预渲染在 Google 上通常有效，在百度上不一定。我们用 4 个客户站做了 3 个月对照，2 个收录明显改善，2 个几乎没变化，差异出在三个可查的地方。",false,"md",{},true,"\u002Fblog\u002Fprerender-baidu-indexing-test",{"title":5,"description":99},"blog\u002Fprerender-baidu-indexing-test",[108,109,110],"预渲染","百度收录","SPA","rjyjKEfLsRqG6iabp6gXIRsF5HV9TjvgQ9bLo0Wbgjw",{"id":113,"title":114,"author":6,"body":115,"canonical":96,"category":97,"cover":96,"date":181,"description":182,"draft":100,"extension":101,"keywords":96,"meta":183,"navigation":103,"noindex":100,"ogImage":96,"path":184,"seo":185,"seoDescription":96,"seoTitle":96,"stem":186,"tags":187,"updated":96,"__hash__":191},"blog\u002Fblog\u002Fbulk-meta-rewrite-script.md","批量改标题和描述，脚本能做和不能做的事",{"type":8,"value":116,"toc":174},[117,120,123,126,129,132,135,138,141,144,147,150,153,156,159,162,165,168,171],[11,118,119],{},"2026 年 3 月我们给一个站批量改了 400 个产品文档页的标题和描述，用的是脚本。改完四周看数据，有 60 个页面的点击率反而降了，最后回滚了其中 40 个。批量改动这件事，脚本能做的比想象中少。",[15,121,122],{"id":122},"脚本能做的三件事",[11,124,125],{},"批量读。从站点地图或者 CMS 数据库把全部标题、描述、URL 拉出来，存成表。这一步人工做要一整天，脚本五分钟。",[11,127,128],{},"批量写。通过 CMS 的接口或者直接改数据库，把新标题写回去。写完立刻读一遍确认，不能写完就跑。",[11,130,131],{},"批量校验。标题长度、重复标题、描述长度、有没有漏填，这些规则让脚本查，比人眼靠谱。我们用的规则很简单：标题超过 30 个汉字截断，描述控制在 60 到 120 字，同站重复标题直接报错。",[15,133,134],{"id":134},"脚本做不了的事",[11,136,137],{},"判断哪个标题更好。这是内容判断，脚本没有数学依据。点击率受位置、搜索意图、竞品、季节影响，标题只是其中一个变量。",[11,139,140],{},"判断用户意图。产品页的标题是给已经知道产品的人看的，博客标题是给还在找答案的人看的，两种写法完全不一样，脚本分不出来。",[11,142,143],{},"判断品牌调性。有的公司要求标题里必须带产品名，有的要求口语化。这些约束得写进规则表，由人定。",[15,145,146],{"id":146},"我们的流程",[11,148,149],{},"先人工写 50 个标题，作为样本。这 50 个要覆盖不同类型页面，产品页、文档页、博客、案例。写完让团队投票选出最好的 10 个，总结出规律。",[11,151,152],{},"脚本按规律套模板生成剩下的 350 个，但每条都要人工扫一遍。我们抽了 10% 做详细复核，发现 7 条有语病。",[11,154,155],{},"上线后四周看数据，按页面类型分组对比点击率，下降超过 15% 的回滚。",[15,157,158],{"id":158},"那次失败的原因",[11,160,161],{},"我们把 400 个文档页的标题从“某功能官方文档”改成“某功能怎么用，完整步骤”。听起来更吸引人，但搜“某功能文档”的人是在找参考手册，加一句“怎么用”反而模糊。",[11,163,164],{},"导航型查询的页面，标题别乱改。它本来就不靠点击率吃饭，用户是直奔这个页面来的。",[15,166,167],{"id":167},"回滚机制",[11,169,170],{},"改之前把原值存一份带日期的表，按批次分组。一周内能一键回滚，超过两周就不好判断是不是标题造成的影响了。",[11,172,173],{},"还有一个规矩：别直接改生产库。先改测试环境，抽几个页面看渲染结果，确认没问题再上生产。我们见过脚本把 HTML 标签写进标题字段的事故，修复花了两天。",{"title":86,"searchDepth":87,"depth":87,"links":175},[176,177,178,179,180],{"id":122,"depth":87,"text":122},{"id":134,"depth":87,"text":134},{"id":146,"depth":87,"text":146},{"id":158,"depth":87,"text":158},{"id":167,"depth":87,"text":167},"2026-03-19","400 个页面批量改标题，60 个改完点击率反而降了。脚本能读、能写、能回滚，但判断哪个标题更好它做不了。这篇写我们的流程和那次回滚。",{},"\u002Fblog\u002Fbulk-meta-rewrite-script",{"title":114,"description":182},"blog\u002Fbulk-meta-rewrite-script",[188,189,190],"标题优化","批量处理","自动化","fTP_cDi4gMzNzOux0BWzteLMo5QXuS-hrfLSbxYQ65Q",{"id":193,"title":194,"author":6,"body":195,"canonical":96,"category":97,"cover":96,"date":287,"description":288,"draft":100,"extension":101,"keywords":96,"meta":289,"navigation":103,"noindex":100,"ogImage":96,"path":290,"seo":291,"seoDescription":96,"seoTitle":96,"stem":292,"tags":293,"updated":96,"__hash__":297},"blog\u002Fblog\u002Ffont-weight-bloat.md","一个官网用了 11 个字重，字体治理比压缩更省",{"type":8,"value":196,"toc":279},[197,200,203,206,218,221,224,227,230,233,236,239,253,256,259,262,265,272],[11,198,199],{},"一个官网用了 11 个字重，首屏要下 5 个字体文件。这不是夸张，是今年 1 月我们在一个开发者工具站上看到的。删到 3 个字重之后，首屏字体请求从 5 个降到 1 个，体积从 1.1MB 降到 310KB。",[15,201,202],{"id":202},"字体是怎么膨胀的",[11,204,205],{},"设计师给了 4 个字体家族，每个 3 到 4 个字重，前端按设计稿逐个引入，没人算过总量。页面里真正用到的只有 3 个字重，剩下的都是复制粘贴留下的。",[11,207,208,209,213,214,217],{},"查法：跑一遍页面，用 DevTools 的 Coverage 面板看字体文件使用率，再对照 CSS 里所有 ",[210,211,212],"code",{},"font-family"," 和 ",[210,215,216],{},"font-weight"," 声明。这个站有 40 多处声明，实际组合只有 9 种。",[15,219,220],{"id":220},"治理比压缩更省",[11,222,223],{},"很多团队一上来就想压缩字体，其实先做减法收益更大。这个站把 11 个字重砍到 3 个：正文 400、标题 600、强调 700。视觉上几乎没差别，因为设计稿本来只用这三档。",[11,225,226],{},"顺序是：先砍字重，再砍字族，最后才子集化。反过来做，等于给用不上的字重做子集，白费功夫。",[15,228,229],{"id":229},"可变字体值不值",[11,231,232],{},"可变字体一个文件包含多个字重，理论上更省。实测要看用几个：只用 2 到 3 个，普通字体子集更小；用 5 个以上，可变字体才有优势。",[11,234,235],{},"我们给这个站试过可变字体，单文件 340KB，比 3 个静态子集加起来还大，最后没用。这个结论有点反直觉，但数字摆在那儿。",[15,237,238],{"id":238},"四条判断清单",[53,240,241,244,247,250],{},[25,242,243],{},"页面实际用到几个字重？超过 3 个就要审",[25,245,246],{},"有没有引入图标字体？能换 SVG 就换",[25,248,249],{},"中文正文用系统字体行不行？行的话最省",[25,251,252],{},"首屏字体文件总大小控制在 300KB 以内",[11,254,255],{},"按这四条走一遍，多数站的字体体积能砍掉六成。这个站改完首屏 LCP 从 2.4 秒降到 2.1 秒，幅度不算惊人，但省下的 800KB 流量对移动端用户是实打实的。",[15,257,258],{"id":258},"顺带纠正一个误区",[11,260,261],{},"字体不是\"越少越好\"到极端。有客户问能不能只用一个字重，全部靠浏览器合成粗体。合成粗体在低分屏上边缘发虚，中文尤其明显，视觉代价比省下的 60KB 大。三个字重是多数 B2B 软件站的下限。",[15,263,264],{"id":264},"上线后的复查",[11,266,267,268,271],{},"改完字体不是一劳永逸。我们给每个站加了一个每月自动跑的检查：抓首页 HTML，列出所有 ",[210,269,270],{},"@font-face"," 和实际引用，对比总数。有一次产品团队上线新页面，又带回来两个没用上的字重，被这个检查抓到了。",[11,273,274,275,278],{},"字体文件还要设长缓存，文件名带 hash，",[210,276,277],{},"Cache-Control: max-age=31536000, immutable","。少了这条，回访用户每次还要重新协商，白等一轮往返。",{"title":86,"searchDepth":87,"depth":87,"links":280},[281,282,283,284,285,286],{"id":202,"depth":87,"text":202},{"id":220,"depth":87,"text":220},{"id":229,"depth":87,"text":229},{"id":238,"depth":87,"text":238},{"id":258,"depth":87,"text":258},{"id":264,"depth":87,"text":264},"2026-03-21","开发者工具站首屏要下 5 个字体文件，总体积 1.1MB。砍到 3 个字重加子集化之后，请求降到 1 个、体积 310KB。附四条判断清单，以及可变字体值不值的实测。",{},"\u002Fblog\u002Ffont-weight-bloat",{"title":194,"description":288},"blog\u002Ffont-weight-bloat",[294,295,296],"字体加载","字体治理","首屏优化","VwHYGFy9BxF9eKMtQHCWwlHAZuL3PZLuZnAPQ1w_2go",1794088107459]