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