[{"data":1,"prerenderedAt":293},["ShallowReactive",2],{"blog-js-rendering-google-baidu":3,"blog-prev-js-rendering-google-baidu":109,"blog-next-js-rendering-google-baidu":189},{"id":4,"title":5,"author":6,"body":7,"canonical":93,"category":94,"cover":93,"date":95,"description":96,"draft":97,"extension":98,"keywords":93,"meta":99,"navigation":100,"noindex":97,"ogImage":93,"path":101,"seo":102,"seoDescription":93,"seoTitle":93,"stem":103,"tags":104,"updated":93,"__hash__":108},"blog\u002Fblog\u002Fjs-rendering-google-baidu.md","百度和 Google 对 JS 渲染的支持，差得比想象中大","元析智能",{"type":8,"value":9,"toc":82},"minimark",[10,14,18,21,24,27,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79],[11,12,13],"p",{},"Google 能渲染大部分 JS，百度只渲染一部分，而且不稳定。今年 3 月我们测了 4 种前端架构在两边抓取里的表现，客户端渲染的站在百度上基本等于裸奔。",[15,16,17],"h2",{"id":17},"我们测的场景",[11,19,20],{},"4 个站，前端架构分别是：纯服务端渲染、Next.js 服务端渲染、Next.js 客户端渲染、Vue SPA。",[11,22,23],{},"每个站用百度抓取诊断和 Google 的 URL 检查工具各抓一次，对比抓到的 HTML 里有没有正文和链接。",[11,25,26],{},"结果：纯服务端渲染两边都正常；Next.js 服务端渲染两边正常；Next.js 客户端渲染 Google 能拿到正文，百度拿到的 HTML 基本是空的；Vue SPA 两边都只能拿到框架代码，正文和链接都缺。",[15,28,30],{"id":29},"google-的渲染","Google 的渲染",[11,32,33],{},"Google 有独立的渲染队列，页面抓下来之后排队渲染，再索引渲染后的内容。这个过程有延迟，但大部分页面最终能渲染出来。",[11,35,36],{},"代价是时间。我们观察到新页面从抓取到渲染完成，平均要 3 到 10 天，比纯 HTML 页面慢。",[15,38,39],{"id":39},"百度的渲染",[11,41,42],{},"百度也支持渲染，但覆盖面和稳定性差很多。我们的测试里，Next.js 客户端渲染的站，百度抓到的 HTML 只有标题和 meta，正文和链接都没有。",[11,44,45],{},"百度官方文档的说法是要保证\"重要内容在 HTML 里可读\"，实际测试下来，这句话应该理解成\"别指望渲染\"。",[15,47,48],{"id":48},"怎么判断你的站有没有问题",[11,50,51],{},"三个方法。抓取诊断里看百度拿到的 HTML，搜正文第一句话，搜不到就是没渲染；用 curl 直接请求页面，看返回的 HTML 有没有内容；看索引量，客户端渲染的站索引量通常远低于页面数。",[11,53,54],{},"我们一个客户 800 个页面，百度只收录了 60 个，查下来是纯客户端渲染，百度只能看到空壳。",[15,56,57],{"id":57},"怎么做",[11,59,60],{},"优先改服务端渲染或者静态生成，这是根本解法。",[11,62,63],{},"改造成本高的话，至少做两件事：关键内容（产品描述、文章正文、内链）放服务端输出；给不渲染的页面加 noscript 兜底内容，虽然效果有限，但比没有强。",[11,65,66],{},"我们给那个客户做的方案是：产品页和文章页改成静态生成，交互部分保留客户端渲染。改完两个月，百度收录从 60 页涨到 640 页。",[15,68,69],{"id":69},"一个被误判的细节",[11,71,72],{},"抓取诊断显示百度拿到了 HTML，不代表正文被索引。我们见过客户诊断里返回 200，但百度实际索引的是空白页，因为正文是后来异步加载的。",[11,74,75],{},"判断方法：在百度里搜页面的正文片段，搜得到才算真的索引了。抓取诊断只能看抓到时那一刻的内容，不能证明索引结果。",[15,77,78],{"id":78},"一句判断",[11,80,81],{},"前端架构选型的时候没人会想到百度，等收录出问题再改，成本是当初的 10 倍。做国内市场的软件公司，这一点要在技术选型阶段就定下来。",{"title":83,"searchDepth":84,"depth":84,"links":85},"",2,[86,87,88,89,90,91,92],{"id":17,"depth":84,"text":17},{"id":29,"depth":84,"text":30},{"id":39,"depth":84,"text":39},{"id":48,"depth":84,"text":48},{"id":57,"depth":84,"text":57},{"id":69,"depth":84,"text":69},{"id":78,"depth":84,"text":78},null,"技术SEO","2026-08-17","Google 能渲染大部分 JS，百度只渲染一部分，而且不稳定。今年 3 月我们测了 4 种前端架构在两边抓取里的表现，客户端渲染的站在百度上基本等于裸奔。判断方法、改法都写了，看完能判断自己的站有没有问题。",false,"md",{},true,"\u002Fblog\u002Fjs-rendering-google-baidu",{"title":5,"description":96},"blog\u002Fjs-rendering-google-baidu",[105,106,107],"JS渲染","抓取","百度与Google","OGHomc1L4Sr20cJbdB9He2gGPoMolNYKAUwp-9SHAV4",{"id":110,"title":111,"author":6,"body":112,"canonical":93,"category":177,"cover":93,"date":178,"description":179,"draft":97,"extension":98,"keywords":93,"meta":180,"navigation":100,"noindex":97,"ogImage":93,"path":181,"seo":182,"seoDescription":93,"seoTitle":93,"stem":183,"tags":184,"updated":93,"__hash__":188},"blog\u002Fblog\u002Fcloud-migration-guide-seo.md","迁移指南是云服务最接近成交的内容",{"type":8,"value":113,"toc":171},[114,117,120,123,126,129,132,135,138,141,144,147,150,156,159,162,165,168],[11,115,116],{},"云服务的内容里，迁移指南是离成交最近的一类。搜“从 AWS 迁移到 XX”“数据库迁移 不停机”的人，已经在评估方案了。2025 年 9 月到 2026 年 7 月，我们给一个云厂商写了 8 篇迁移指南，带来 470 条企业线索，成单 11 个。",[15,118,119],{"id":119},"迁移词的结构",[11,121,122],{},"分三种。按源平台：“从 AWS 迁出”“从阿里云迁出”。按组件：“MySQL 迁移”“对象存储迁移”“K8s 集群迁移”。按约束：“不停机迁移”“零数据丢失迁移”“迁移成本对比”。",[11,124,125],{},"三种组合起来就是页面矩阵。我们优先做源平台加组件，比如“从 AWS RDS 迁移到 XX 的 MySQL”，意图最明确。",[15,127,128],{"id":128},"一篇迁移指南的骨架",[11,130,131],{},"第一步，评估。给一张对照表：源端资源、目标端对应产品、注意事项。这张表决定用户能不能继续读。",[11,133,134],{},"第二步，方案。至少给两条路径：停机窗口迁移和不停机双写。写清各自的前置条件、耗时、风险。",[11,136,137],{},"第三步，操作步骤。分阶段，每阶段有验证点。验证点写具体命令或指标，别写“确认无误”。",[11,139,140],{},"第四步，回滚。这段最容易被省略，其实是企业客户最先问的。写清回滚窗口、数据一致性怎么保证。",[11,142,143],{},"第五步，成本。迁移本身的工时、迁移期间的双份费用、以及迁移后每月的账单变化。给区间，别给单个数字。",[15,145,146],{"id":146},"一个差异化做法",[11,148,149],{},"我们每篇指南都带一个“迁移前后实测”小节，给出真实迁移的数据量、耗时、遇到的两个问题。这部分是销售讲不出来的，只有交付团队有。写进去之后，页面的平均停留时间从 2 分钟到 4 分半。",[11,151,152],{},[153,154,155],"strong",{},"内容怎么和销售配合",[11,157,158],{},"迁移指南单独存在没用，要和销售流程接上。我们的做法是给每篇指南配一个内部版本：多一段“这个客户的情况适合哪条路径”，销售跟进前先读一遍。这样内容和成单之间的链条是通的。",[11,160,161],{},"另外，客户在沟通中提到的问题，回来补进指南的常见问题部分。三个月下来，指南的问答区会变成一份真实的异议清单，比市场部闭门写的强。",[15,163,164],{"id":164},"转化设计",[11,166,167],{},"迁移指南的 CTA 不是“免费试用”，是“预约迁移评估”。这类用户要的是方案，不是账号。我们给客户做的评估表单只有四个字段，提交后由解决方案工程师跟进，转化率比普通试用高很多。",[11,169,170],{},"内容要定期更新，云产品改价、改规格、改限制，指南跟着改。我们在页面顶部标了版本号和更新月份，用户会看这个。",{"title":83,"searchDepth":84,"depth":84,"links":172},[173,174,175,176],{"id":119,"depth":84,"text":119},{"id":128,"depth":84,"text":128},{"id":146,"depth":84,"text":146},{"id":164,"depth":84,"text":164},"SEO","2026-08-16","搜“从 AWS 迁移到 XX”的人已经在做决策，内容只要回答得够具体，线索质量就很高。我们写了 8 篇迁移指南，一年带来 470 条企业线索，成单 11 个。",{},"\u002Fblog\u002Fcloud-migration-guide-seo",{"title":111,"description":179},"blog\u002Fcloud-migration-guide-seo",[185,186,187],"云迁移","采购意图","内容运营","_oqYNXJIYIjRxWssy76kd_K-DIZFKYV8ovqTBx5kDNI",{"id":190,"title":191,"author":6,"body":192,"canonical":93,"category":281,"cover":93,"date":282,"description":283,"draft":97,"extension":98,"keywords":93,"meta":284,"navigation":100,"noindex":97,"ogImage":93,"path":285,"seo":286,"seoDescription":93,"seoTitle":93,"stem":287,"tags":288,"updated":93,"__hash__":292},"blog\u002Fblog\u002Fproject-delay-communication.md","项目延期不可怕，可怕的是最后一天才说",{"type":8,"value":193,"toc":273},[194,197,200,203,206,209,212,215,218,221,224,228,231,234,237,240,243,246,249,252,255,258,261,264,267,270],[11,195,196],{},"2026 年 8 月我们一个项目延期了三周，发现当天就告诉了客户，比原定交付日早了十天。客户没有生气，反而说这样他能安排别的事。延期本身不致命，致命的是最后一天才说。",[15,198,199],{"id":199},"延期的三种原因",[11,201,202],{},"第一种，等客户。产品文档没给、后台权限没开、案例没确认。这类最常见，也最容易说清。",[11,204,205],{},"第二种，我们自己产能不够。稿子排太满、审稿人请假、技术排查比预估的久。",[11,207,208],{},"第三种，外部变化。算法更新打乱了优先级，第三方工具接口变了要重做。",[11,210,211],{},"三种原因的处理方式不一样，但第一件事都一样：当天说。",[15,213,214],{"id":214},"为什么当天就要说",[11,216,217],{},"因为客户需要时间调整。他的发布会、投放计划、内部汇报都挂在你的交付日上。你晚说一天，他就少一天余量。",[11,219,220],{},"还有个原因是信任。延期被发现和主动说，性质完全不同。被发现一次，后面每次交付他都会怀疑。",[11,222,223],{},"我们的规矩是：只要判断可能延期超过三天，当天发消息，不等确认。",[15,225,227],{"id":226},"怎么说四句话","怎么说：四句话",[11,229,230],{},"第一句，事实。原定几号交付，现在预计几号，延期多久。",[11,232,233],{},"第二句，影响。哪些交付物受影响，哪些不受影响。",[11,235,236],{},"第三句，原因，一句话，不辩解。",[11,238,239],{},"第四句，方案。接下来怎么补，需要客户配合什么。",[11,241,242],{},"四句话能说完的事，别写一页。写得越长，越像在找理由。",[15,244,245],{"id":245},"三种不该出现的解释",[11,247,248],{},"第一种，怪客户。“因为你们文档给晚了”，哪怕是真的，也要换成“我们在等文档，预计 X 号能拿到”。",[11,250,251],{},"第二种，过度道歉。连着说五次抱歉，客户会觉得你心里没底。",[11,253,254],{},"第三种，承诺一个明显做不到的新时间。为了安抚客户把交付日再提前一周，下次延期时更难看。",[15,256,257],{"id":257},"延期之后怎么补信任",[11,259,260],{},"延期之后的三周，我们每周多给客户一次口头同步，十分钟，说清进展和风险。成本不高，但客户能感觉到事情在被推进。",[11,262,263],{},"交付完成之后，把延期原因写进复盘，下个项目排期时把同类风险标出来。客户看到你真的在改，比说十次抱歉有用。",[15,265,266],{"id":266},"延期之后要补什么",[11,268,269],{},"补两件事：一是把延期原因写进复盘，看是流程问题还是估算问题；二是下一个交付节点提前两天给客户看一眼进度，别让他等到交付日。",[11,271,272],{},"我们现在的项目周报里有固定一行：本周有风险的任务。写这一行的时候没人爱写，但它让延期变成了可讨论的事，而不是突然的坏消息。",{"title":83,"searchDepth":84,"depth":84,"links":274},[275,276,277,278,279,280],{"id":199,"depth":84,"text":199},{"id":214,"depth":84,"text":214},{"id":226,"depth":84,"text":227},{"id":245,"depth":84,"text":245},{"id":257,"depth":84,"text":257},{"id":266,"depth":84,"text":266},"行业观察","2026-08-18","延期三周，提前十天告知，客户反而更信任我们。这篇写发现延期当天要做的四件事、跟客户说的四句话模板，以及三种不该出现的解释。",{},"\u002Fblog\u002Fproject-delay-communication",{"title":191,"description":283},"blog\u002Fproject-delay-communication",[289,290,291],"项目延期","客户沟通","交付管理","Sbw78FJ0033IzZ--fXyKrsEsNHO99MFeIQYPSUNIfFk",1794088102729]