[{"data":1,"prerenderedAt":261},["ShallowReactive",2],{"blog-post-update-first-three-things":3,"blog-prev-post-update-first-three-things":94,"blog-next-post-update-first-three-things":159},{"id":4,"title":5,"author":6,"body":7,"canonical":78,"category":79,"cover":78,"date":80,"description":81,"draft":82,"extension":83,"keywords":78,"meta":84,"navigation":85,"noindex":82,"ogImage":78,"path":86,"seo":87,"seoDescription":78,"seoTitle":78,"stem":88,"tags":89,"updated":78,"__hash__":93},"blog\u002Fblog\u002Fpost-update-first-three-things.md","算法更新后别急着改站，先做这三件事","元析智能",{"type":8,"value":9,"toc":69},"minimark",[10,14,19,22,25,28,32,35,38,41,45,48,51,54,57,60,63,66],[11,12,13],"p",{},"算法更新后第一件事不是改站，是确认三件事：是不是真的更新、掉的是哪类页面、竞品有没有同样掉。这三件事没做完就动手，大概率改错方向。我们踩过这个坑，现在有固定顺序，也把判断标准写成了表。顺序错了，改得越多错得越多。",[15,16,18],"h2",{"id":17},"第一步确认是不是算法","第一步：确认是不是算法",[11,20,21],{},"看两个东西。一是同期其他站有没有波动，我们监测的同类站如果 80% 都在掉，基本可以确认是算法；只有一个站在掉，先怀疑自己。",[11,23,24],{},"二是看时间分布。算法更新通常在一两天内影响一批站，曲线是断崖式的；技术问题或改版是缓慢扩散的。",[11,26,27],{},"去年 11 月一次波动，客户坚持说是算法，我们查了 6 个同类站，只有他一个掉。最后查出来是 CDN 节点故障，服务器返回了 3 天 503。",[15,29,31],{"id":30},"第二步看掉的是哪类页面","第二步：看掉的是哪类页面",[11,33,34],{},"把掉量最大的 20 个页面拉出来，看它们的共同点：是同一个栏目？同一种内容类型？还是同一批发布时间？",[11,36,37],{},"这个分类决定后面怎么改。如果掉的是信息型文章，可能是内容质量或站点评级问题；如果掉的是产品页，可能是转化率或页面结构问题；如果掉的是新页面，可能是抓取或收录问题。",[11,39,40],{},"我们的做法是建一张表：URL、原排名、现排名、页面类型、发布时间、上次修改时间。这张表一拉，规律通常很明显。",[15,42,44],{"id":43},"第三步看竞品有没有同样掉","第三步：看竞品有没有同样掉",[11,46,47],{},"如果竞品也掉，说明是整个品类的需求或算法调整，你的站没问题，别乱改。如果竞品没掉甚至涨了，去看他们涨的是哪些页面，和你的差在哪。",[11,49,50],{},"这一步最容易被跳过，但它能省掉很多无用功。我们见过客户在竞品也掉的情况下大改站点，改完排名没回来，还把原来稳定的页面搞乱了。",[15,52,53],{"id":53},"三件事之后才动手",[11,55,56],{},"三件事做完，通常能得出一个方向：改内容、改结构、或者什么都不改只等恢复。",[11,58,59],{},"如果是内容问题，改最掉的那批页面，一次改 20%，观察两周。如果是结构问题，先修技术项，别碰内容。如果判断不了，什么都别改，观察一个月再说。",[15,61,62],{"id":62},"一个反例",[11,64,65],{},"2025 年 3 月核心更新后，一个客户第二天就把所有页面标题重写了。两周后流量又掉了 12%，因为新标题丢掉了原有的关键词。等我们介入时，已经改不回去了，只能重新做关键词映射。",[11,67,68],{},"算法更新不是考试，没有标准答案。先诊断，再动手，是我们用两年时间换来的顺序。",{"title":70,"searchDepth":71,"depth":71,"links":72},"",2,[73,74,75,76,77],{"id":17,"depth":71,"text":18},{"id":30,"depth":71,"text":31},{"id":43,"depth":71,"text":44},{"id":53,"depth":71,"text":53},{"id":62,"depth":71,"text":62},null,"SEO","2026-03-26","算法更新后第一件事不是改站，是确认三件事：是不是真的更新、掉的是哪类页面、竞品有没有同样掉。这三件事没做完就动手，大概率改错方向。我们踩过这个坑，写了份排查顺序，现在团队按这套顺序走，返工少了很多。",false,"md",{},true,"\u002Fblog\u002Fpost-update-first-three-things",{"title":5,"description":81},"blog\u002Fpost-update-first-three-things",[90,91,92],"算法更新","排查流程","流量恢复","gGL-ueD8pi23VkaUlyRozGQuuvt9zdYNzI8VW3zJTMc",{"id":95,"title":96,"author":6,"body":97,"canonical":78,"category":147,"cover":78,"date":148,"description":149,"draft":82,"extension":83,"keywords":78,"meta":150,"navigation":85,"noindex":82,"ogImage":78,"path":151,"seo":152,"seoDescription":78,"seoTitle":78,"stem":153,"tags":154,"updated":78,"__hash__":158},"blog\u002Fblog\u002Fdesign-system-docs-seo.md","设计系统文档公开，能带来开发者流量",{"type":8,"value":98,"toc":141},[99,102,105,108,111,114,117,120,123,126,129,132,135,138],[11,100,101],{},"设计系统文档该不该公开，很多团队在纠结，怕被抄。我的判断是公开，而且这是设计工具最便宜的一批自然流量。2025 年 12 月我们建议一个设计系统工具把组件文档从内网搬到公开域名下，四个月自然访问从每月 900 到 6900。",[15,103,104],{"id":104},"谁会搜组件文档",[11,106,107],{},"三类人：用这套系统的产品团队、想搭自己设计系统的公司、以及写代码时忘了某个组件怎么用的工程师。第三类最值钱，因为他每天都在用。",[11,109,110],{},"搜的词很具体：“按钮组件 禁用态 规范”“表单校验 提示文案 长度”“空状态 插画 尺寸”。这些词单月搜索量几十到几百，但页面数量可以很多，聚起来就是流量。",[15,112,113],{"id":113},"哪几类页面该公开",[11,115,116],{},"组件页、模式页、内容规范页，这三类公开价值最高。组件页写 API、状态、用法；模式页写“什么时候用抽屉什么时候用弹窗”这种判断；内容规范页写文案长度、语气、错误提示写法。",[11,118,119],{},"设计 token 页最难做好。它天然是表格，一屏几百行，搜索引擎能读但用户看不下去。我们给一个客户的做法是按用途拆成 6 页：颜色、间距、字号、圆角、阴影、动效，每页配一段为什么这么定的说明。拆完这 6 页的月访问加起来 1800。",[15,121,122],{"id":122},"一个反常识的发现",[11,124,125],{},"组件文档页的转化路径不是注册，是回访。用户第一次来查一个组件，不会注册。但一个月来五次之后，他会去看这个系统背后的产品是什么。所以我们在这类页面底部放的不是注册按钮，是“这套系统的设计原则”和“背后的工具”。",[11,127,128],{},"我们追踪过一个客户的数据：从组件文档进入、30 天内产生注册的用户，平均访问了 6.2 个文档页。普通博客读者是 1.4 个。",[11,130,131],{},"关键词怎么定也有讲究。组件文档不需要打“设计系统”这种大词，要打组件名加状态名。我们给一个客户的按钮页标题写成“按钮组件：尺寸、状态与禁用规范”，比原来的“Button 组件”多覆盖了三个搜索词。",[15,133,134],{"id":134},"别做的事",[11,136,137],{},"别把文档放在需要登录的地方，那等于没有。别用截图代替可复制的代码，设计师和工程师都要复制。别在文档里放产品广告位，破坏阅读节奏，代价比收益大。",[11,139,140],{},"公开文档的风险是竞品参考，但设计系统本身不是壁垒，执行速度才是。这个账我们算过很多次，结论一致。",{"title":70,"searchDepth":71,"depth":71,"links":142},[143,144,145,146],{"id":104,"depth":71,"text":104},{"id":113,"depth":71,"text":113},{"id":122,"depth":71,"text":122},{"id":134,"depth":71,"text":134},"技术SEO","2026-03-25","把组件库文档从内网搬到公开域名后，一个设计系统工具每月多 6000 次自然访问。哪些页面值得公开、怎么组织，以及 token 页为什么最难做好。",{},"\u002Fblog\u002Fdesign-system-docs-seo",{"title":96,"description":149},"blog\u002Fdesign-system-docs-seo",[155,156,157],"设计系统","组件库","文档SEO","BSgXwt3LLTUZi1oI2vD_ECOsE9H9y8grGaOG9xSjFlQ",{"id":160,"title":161,"author":6,"body":162,"canonical":78,"category":79,"cover":78,"date":250,"description":251,"draft":82,"extension":83,"keywords":78,"meta":252,"navigation":85,"noindex":82,"ogImage":78,"path":253,"seo":254,"seoDescription":78,"seoTitle":78,"stem":255,"tags":256,"updated":78,"__hash__":260},"blog\u002Fblog\u002Fseo-scripts-maintenance.md","SEO 脚本没人维护，三个月后一定会崩",{"type":8,"value":163,"toc":242},[164,167,170,173,176,179,182,185,188,191,194,197,200,203,206,209,212,215,218,221,224,227,230,233,236,239],[11,165,166],{},"2026 年 4 月我们从 git 里翻出 11 个自建脚本，4 个已经跑不通了。没人删，也没人修，就那么挂着定时任务，每天往日志里写报错。自建脚本的成本大头不在写，在养。",[15,168,169],{"id":169},"崩的五种原因",[11,171,172],{},"站点改版。选择器、API 路径、字段名一变，脚本立刻失效，这是最常见的。",[11,174,175],{},"第三方接口变更。GSC API 的字段调整、CMS 升级、webhook 格式变化，都会让脚本读不到数据。",[11,177,178],{},"磁盘和权限。日志写满、token 过期、服务账号被移出权限组，这些运维层面的问题最容易被忽略。",[11,180,181],{},"写脚本的人走了。没文档、没注释，接手的人看不懂也不敢改。",[11,183,184],{},"需求变了。当初要的报表没人看了，脚本还在跑。",[15,186,187],{"id":187},"三种崩法",[11,189,190],{},"静默出错最危险。脚本正常退出，但结果是空的或者错的，报表照发，数字全是零。",[11,192,193],{},"部分出错次之，比如只抓到一半页面，报表看着正常但少了一块。",[11,195,196],{},"彻底不跑反而安全，因为很快会有人发现数据没了。",[11,198,199],{},"我们现在的做法是每天校验输出行数，低于阈值直接报错退出，不生成报表。",[15,201,202],{"id":202},"三条维护规矩",[11,204,205],{},"每个脚本一个说明文件，写清用途、输入、输出、依赖、负责人。五分钟能写完，省后面的十次沟通。",[11,207,208],{},"依赖版本锁定。Python 包不锁版本，半年后换个环境跑不起来。",[11,210,211],{},"每季度跑一次全量验证，对着已知结果比一遍。这条最容易被跳过，但只有它能发现静默错误。",[15,213,214],{"id":214},"交接怎么做",[11,216,217],{},"录一段五分钟的屏，把脚本跑一遍，讲清每一步在做什么。视频比文档有效，因为能看到报错长什么样。",[11,219,220],{},"注释只写“为什么”，不写“是什么”。代码本身能看出是什么，看不出的是当初为什么这么写。",[11,222,223],{},"别留只有一个人能跑的脚本。这个人休假，任务就停。",[15,225,226],{"id":226},"哪些活别自己写",[11,228,229],{},"能买就买。日志分析、排名监控、死链检测都有成熟工具，自己写等于浪费三个月。",[15,231,232],{"id":232},"一个反面例子",[11,234,235],{},"2025 年我们写过一个自动提交站点地图的脚本，六行，跑了一年没坏。后来站点从 800 个 URL 涨到 3 万，站点地图超过 5 万条的上限被截断，脚本不知道，一直提交半份地图，导致新页面收录拖了一个月。",[11,237,238],{},"修起来十分钟，发现花了半个月。原因是没人校验过输出的条数。",[11,240,241],{},"只在两种情况下自建：市面上的工具满足不了具体规则，或者用量大到工具费用不合理。我们自建的脚本都落在“排序”和“拼数据”这两类事上，现成工具确实做不到。",{"title":70,"searchDepth":71,"depth":71,"links":243},[244,245,246,247,248,249],{"id":169,"depth":71,"text":169},{"id":187,"depth":71,"text":187},{"id":202,"depth":71,"text":202},{"id":214,"depth":71,"text":214},{"id":226,"depth":71,"text":226},{"id":232,"depth":71,"text":232},"2026-03-27","我们盘过 11 个自建脚本，4 个已经跑不动。崩的方式有静默出错、部分出错和彻底不跑三种。这篇写维护规矩、交接办法，以及哪些活干脆别自己写。",{},"\u002Fblog\u002Fseo-scripts-maintenance",{"title":161,"description":251},"blog\u002Fseo-scripts-maintenance",[257,258,259],"自动化脚本","维护","工作流","yJYKpIH-VUaGrRXtE65UDEuAoLVpu4vsR7jLk7DHgIE",1794088107295]