[{"data":1,"prerenderedAt":356},["ShallowReactive",2],{"blog-deploy-speed-regression":3,"blog-prev-deploy-speed-regression":133,"blog-next-deploy-speed-regression":242},{"id":4,"title":5,"author":6,"body":7,"canonical":117,"category":118,"cover":117,"date":119,"description":120,"draft":121,"extension":122,"keywords":117,"meta":123,"navigation":124,"noindex":121,"ogImage":117,"path":125,"seo":126,"seoDescription":117,"seoTitle":117,"stem":127,"tags":128,"updated":117,"__hash__":132},"blog\u002Fblog\u002Fdeploy-speed-regression.md","上线之后变慢，半小时内怎么定位到原因","元析智能",{"type":8,"value":9,"toc":106},"minimark",[10,14,19,22,25,28,32,35,38,41,45,48,51,54,58,61,64,67,70,73,76,79,82,85,88,91,94,97,100,103],[11,12,13],"p",{},"2026 年 9 月一个客户周五下午发版，晚上收到告警，移动端 LCP 从 2.3 秒涨到 4.1 秒。我们用半小时定位到原因，是先回滚再查，不是边查边等。",[15,16,18],"h2",{"id":17},"第一步先确认是真变慢","第一步：先确认是真变慢",[11,20,21],{},"排除网络波动和测试误差。同一时间用同一个工具测两次，看是否稳定。",[11,23,24],{},"看监控曲线。如果所有页面一起变慢，可能是 CDN 或者服务器的问题；如果只有某类页面，大概率是这次发版的内容。",[11,26,27],{},"再看真实用户数据。CrUX 有延迟，RUM 更及时，有自建监控的这时候才能看出影响面。",[15,29,31],{"id":30},"第二步先回滚","第二步：先回滚",[11,33,34],{},"确认是发版导致的，第一动作是回滚，不是查原因。",[11,36,37],{},"回滚之后用户先恢复正常，然后你在本地慢慢查。这个顺序很多人搞反，结果线上慢了两小时。",[11,39,40],{},"回滚前把版本号和变更记录存好，查的时候要用。",[15,42,44],{"id":43},"第三步看变更清单","第三步：看变更清单",[11,46,47],{},"对比发布前后的资源清单：新增了哪些 JS、图片、字体、第三方脚本，哪些文件体积变大了。",[11,49,50],{},"打包产物通常有 manifest，前后一对比，涨了多少一目了然。",[11,52,53],{},"第三方脚本尤其要查。这次的问题就是一个营销团队加的 A\u002FB 测试脚本，体积 260KB，还在 head 里同步加载。",[15,55,57],{"id":56},"第四步对比瀑布图","第四步：对比瀑布图",[11,59,60],{},"发布前后各抓一份 HAR，放在一起对比。",[11,62,63],{},"看关键资源的请求时间、顺序、优先级。我们这次看到 LCP 图片的请求被一个新脚本挤到了后面，开始时间晚了 1.2 秒。",[11,65,66],{},"这种问题不看瀑布图根本发现不了，因为文件本身没变。",[15,68,69],{"id":69},"我们遇到最多的四种回归",[11,71,72],{},"第一种，新加的第三方脚本。占了大概一半。",[11,74,75],{},"第二种，图片没压缩就上传。设计师给的原图直接传上去，一张三兆。",[11,77,78],{},"第三种，CSS 体积变大。组件库升级，样式文件翻倍。",[11,80,81],{},"第四种，缓存策略被改。发版时改了缓存头，所有静态资源重新下载。",[15,83,84],{"id":84},"回滚之外的补救",[11,86,87],{},"回滚之后要做两件事：把这次的回归写进复盘，说明是哪个提交、为什么没被发现；再补一条监控，让同类问题下次能被提前拦住。",[11,89,90],{},"如果一时修不好，还有临时方案：把新脚本改成异步加载、图片先压缩替换、给关键资源加 preload。",[11,92,93],{},"临时方案只能顶几天，别当长期解。我们见过一个站用临时方案撑了半年，最后谁也说不清当初为什么那么改。",[15,95,96],{"id":96},"一个预防措施",[11,98,99],{},"发版前跑一次性能对比，把核心页面的三个指标和上一个版本比，超过 10% 就不发。",[11,101,102],{},"这个检查放进 CI，几分钟能跑完。比上线后救火便宜太多。",[11,104,105],{},"发版窗口也有讲究。别在周五下午发大改动，出问题没人加班查。这条是我们用两次事故换来的。",{"title":107,"searchDepth":108,"depth":108,"links":109},"",2,[110,111,112,113,114,115,116],{"id":17,"depth":108,"text":18},{"id":30,"depth":108,"text":31},{"id":43,"depth":108,"text":44},{"id":56,"depth":108,"text":57},{"id":69,"depth":108,"text":69},{"id":84,"depth":108,"text":84},{"id":96,"depth":108,"text":96},null,"技术SEO","2026-09-29","发布后性能掉下去，先回滚还是先查。这篇写确认、对比、回滚的半小时流程，以及我们遇到最多的四种回归原因，和发版前的一次对比检查。",false,"md",{},true,"\u002Fblog\u002Fdeploy-speed-regression",{"title":5,"description":120},"blog\u002Fdeploy-speed-regression",[129,130,131],"性能回归","排查","上线流程","H5Wk8VoF_ka-uLIKxfSIglkX4ws6Vzgi6B9CNkWDip4",{"id":134,"title":135,"author":6,"body":136,"canonical":117,"category":118,"cover":117,"date":231,"description":232,"draft":121,"extension":122,"keywords":117,"meta":233,"navigation":124,"noindex":121,"ogImage":117,"path":234,"seo":235,"seoDescription":117,"seoTitle":117,"stem":236,"tags":237,"updated":117,"__hash__":241},"blog\u002Fblog\u002Fsite-search-pages-indexed.md","站内搜索页被收录 8 万条：怎么清、怎么防",{"type":8,"value":137,"toc":222},[138,141,144,152,155,158,161,164,167,170,173,176,179,182,186,189,192,195,198,201,204,207,210,213,216,219],[11,139,140],{},"站内搜索结果页被搜索引擎大量收录，是软件站最常见的索引事故之一。我们处理过一个 8 万条站内搜索页被收录的站：清理用了 8 周，索引量降了 76%。",[15,142,143],{"id":143},"一次真实的索引事故",[11,145,146,147,151],{},"2026 年 1 月，一个 SaaS 客户的站内搜索页被收录了 8 万多条。用户搜任何词都会生成一个 ",[148,149,150],"code",{},"\u002Fsearch?q=xxx"," 的页面，这些页面没有 noindex，sitemap 也没排除。",[11,153,154],{},"后果：索引里一大半是站内搜索页，核心产品页的抓取频次被压到每周一次，收录也慢。",[15,156,157],{"id":157},"为什么会被收录",[11,159,160],{},"三个原因，通常会同时出现：",[11,162,163],{},"站内搜索页没有 noindex；站内搜索页被大量内链指向（比如热门搜索词、相关搜索）；sitemap 自动包含了所有 URL。",[11,165,166],{},"搜索引擎顺着链接爬，发现页面有内容、能访问，就收了。",[15,168,169],{"id":169},"清理顺序",[11,171,172],{},"第一步，先挡发现路径。站内搜索链接加 nofollow（这里可以用，它只影响发现路径，不影响页面本身），热门搜索词改成提交表单而不是链接。",[11,174,175],{},"第二步，给站内搜索页加 noindex。页面保留给用户用，但告诉搜索引擎别收录。",[11,177,178],{},"第三步，sitemap 里排除搜索页。这是最容易被忘的一步。",[11,180,181],{},"第四步，已经收录的页面，靠 noindex 慢慢退出索引。8 万条的量，退出要 6 到 10 周，别急。",[15,183,185],{"id":184},"为什么不直接-robots-屏蔽","为什么不直接 robots 屏蔽",[11,187,188],{},"robots 屏蔽后，搜索引擎读不到页面上的 noindex，已收录的页面会一直留在索引里，只是不再更新。要清理已收录的页面，必须让它能抓到 noindex。",[11,190,191],{},"所以顺序是：先加 noindex，等索引退出后再考虑 robots。",[15,193,194],{"id":194},"预防的三道闸",[11,196,197],{},"第一道，上线检查：新功能上线时确认有没有生成可索引的搜索结果页。这是流程问题，不是技术问题。",[11,199,200],{},"第二道，sitemap 白名单：sitemap 只包含白名单里的目录，别自动扫描全站。",[11,202,203],{},"第三道，每周看索引报告：GSC 和百度后台的索引量按目录看，搜索页占比超过 5% 就查。我们把这套检查写进了上线清单，每个新功能上线前过一遍。",[15,205,206],{"id":206},"清理后的数据",[11,208,209],{},"8 万条站内搜索页，清理 8 周后索引量从 11 万降到 2.6 万，核心产品页平均抓取间隔从 7 天降到 2 天。",[11,211,212],{},"流量没掉，因为搜索页本来就不带来搜索流量。这件事的技术成本不高，难在流程上有没有人负责。",[15,214,215],{"id":215},"判断",[11,217,218],{},"站内搜索页是给用户用的，不是给搜索引擎看的。这个定位想清楚，就不会出错。",[11,220,221],{},"如果你的索引里已经有一堆搜索页，别慌，先加 noindex，等它慢慢退出，别用 robots 硬挡。",{"title":107,"searchDepth":108,"depth":108,"links":223},[224,225,226,227,228,229,230],{"id":143,"depth":108,"text":143},{"id":157,"depth":108,"text":157},{"id":169,"depth":108,"text":169},{"id":184,"depth":108,"text":185},{"id":194,"depth":108,"text":194},{"id":206,"depth":108,"text":206},{"id":215,"depth":108,"text":215},"2026-09-28","站内搜索结果页被搜索引擎大量收录，是软件站最常见的索引事故之一。我们处理过一个 8 万条站内搜索页被收录的站：清理用了 8 周，索引量降了 76%，核心页抓取翻倍。清理顺序和预防的三道闸都在这篇，照着做能少踩坑。",{},"\u002Fblog\u002Fsite-search-pages-indexed",{"title":135,"description":232},"blog\u002Fsite-search-pages-indexed",[238,239,240],"站内搜索","索引控制","抓取","wdA5K9X1ONvc4f6CuB6KRHRJmn9s6XxXAj-KaE5_Ndc",{"id":243,"title":244,"author":6,"body":245,"canonical":117,"category":344,"cover":117,"date":345,"description":346,"draft":121,"extension":122,"keywords":117,"meta":347,"navigation":124,"noindex":121,"ogImage":117,"path":348,"seo":349,"seoDescription":117,"seoTitle":117,"stem":350,"tags":351,"updated":117,"__hash__":355},"blog\u002Fblog\u002Fcontent-attribution.md","内容效果归因：注册到底算哪篇文章的功劳",{"type":8,"value":246,"toc":334},[247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301,304,307,310,313,316,319,322,325,328,331],[11,248,249],{},"一篇文章带来 10 个注册，另一篇带来 3 个，不代表第一篇更好。内容归因难在路径长、触点杂。我们用三层归因：直接来源、辅助触点、品牌搜索。",[15,251,252],{"id":252},"归因为什么难",[11,254,255],{},"用户从第一次看到文章，到注册，可能经过：搜索、读文章、看文档、看定价、搜品牌词、再回来注册。",[11,257,258],{},"如果只按\"最后一次点击\"算，功劳全给了定价页，内容一文不值。如果按\"第一次点击\"算，功劳全给了第一篇科普文，也不对。",[15,260,261],{"id":261},"我们的三层归因",[11,263,264],{},"第一层，直接来源。用户注册时，来源是某篇文章的 URL，直接算这篇文章的。",[11,266,267],{},"第二层，辅助触点。用户注册前 30 天内，看过哪些内容。这些内容算\"辅助\"，按触点数分配权重。",[11,269,270],{},"第三层，品牌搜索。用户搜品牌词进来的，功劳分给\"之前让他记住品牌的内容\"。",[15,272,273],{"id":273},"一个例子",[11,275,276],{},"2026 年 3 月，一个客户的数据：A 文章直接带来 10 个注册，B 文章直接带来 3 个。",[11,278,279],{},"但辅助触点看：B 文章在 60 个注册的路径里出现过，A 文章只在 15 个里出现。",[11,281,282],{},"结论：B 文章的价值被低估了。它是一篇\"种草\"内容，不直接转化，但影响决策。",[15,284,285],{"id":285},"怎么落地",[11,287,288],{},"工具层面：GA4 里配置内容分组，把文章、文档、落地页分开。",[11,290,291],{},"数据层面：每周导一次\"注册前 30 天内容触点\"，按内容分组统计。",[11,293,294],{},"报告层面：每月出一次\"直接贡献 + 辅助贡献\"两张表，别只报直接贡献。",[15,296,297],{"id":297},"两个误区",[11,299,300],{},"第一个误区，只看直接转化。纯内容团队会因此被低估，然后被迫写\"硬广\"，长期伤害内容质量。",[11,302,303],{},"第二个误区，把辅助触点算成\"平均分配\"。60 个注册路径里出现过，不等于贡献均等。我们一般按触点位置加权：越靠近注册，权重越高。",[15,305,306],{"id":306},"一个提醒",[11,308,309],{},"归因没有完美方案。三层归因也只是一个\"更接近真相\"的模型，不是真理。",[11,311,312],{},"关键是：全公司用同一套口径，并且知道这套口径的偏差在哪。",[15,314,315],{"id":315},"一个容易吵起来的问题",[11,317,318],{},"内容团队和增长团队经常为归因口径吵架。增长团队看最后一次点击，内容团队看辅助触点。",[11,320,321],{},"我们的解法是：两个口径都报，但决策用\"辅助触点 + 品牌搜索\"的合并口径。因为内容的作用本来就是影响决策，不是直接收单。",[11,323,324],{},"这个口径需要老板认可，否则内容团队永远说不清自己的价值。",[15,326,327],{"id":327},"一句判断",[11,329,330],{},"内容的价值，一半在直接转化，一半在影响决策。只算直接转化，内容团队永远会被当成成本中心。",[11,332,333],{},"把辅助贡献讲清楚，是内容负责人最重要的工作之一。",{"title":107,"searchDepth":108,"depth":108,"links":335},[336,337,338,339,340,341,342,343],{"id":252,"depth":108,"text":252},{"id":261,"depth":108,"text":261},{"id":273,"depth":108,"text":273},{"id":285,"depth":108,"text":285},{"id":297,"depth":108,"text":297},{"id":306,"depth":108,"text":306},{"id":315,"depth":108,"text":315},{"id":327,"depth":108,"text":327},"内容运营","2026-09-30","一篇文章带来 10 个注册，另一篇带来 3 个，不代表第一篇更好。内容归因难在路径长、触点杂。我们用三层归因：直接来源、辅助触点、品牌搜索。算法、例子和两个误区都在这篇，两张表的做法也写了，每月出一次。",{},"\u002Fblog\u002Fcontent-attribution",{"title":244,"description":346},"blog\u002Fcontent-attribution",[352,353,354],"内容归因","数据分析","内容评估","PicTA__fjjFq9y7DNAUZ1weg3_5yQPywcrS7Itp8VJ0",1794088101324]