[{"data":1,"prerenderedAt":332},["ShallowReactive",2],{"blog-content-velocity-quality":3,"blog-prev-content-velocity-quality":112,"blog-next-content-velocity-quality":223},{"id":4,"title":5,"author":6,"body":7,"canonical":97,"category":98,"cover":97,"date":99,"description":100,"draft":101,"extension":102,"keywords":97,"meta":103,"navigation":104,"noindex":101,"ogImage":97,"path":105,"seo":106,"seoDescription":97,"seoTitle":97,"stem":107,"tags":108,"updated":97,"__hash__":111},"blog\u002Fblog\u002Fcontent-velocity-quality.md","一个月二十篇和五篇，哪个更有用取决于一件事","元析智能",{"type":8,"value":9,"toc":85},"minimark",[10,14,19,22,25,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79,82],[11,12,13],"p",{},"一个月二十篇和五篇，哪个更有用？我们统计了 4 个客户站一年的数据，发文篇数和自然流量几乎没有相关性，有效篇数才有。有效篇数指的是：带独家信息、能被搜索和 AI 引用、能带来动作的那几篇。",[15,16,18],"h2",{"id":17},"那-4-个站的数据差在哪","那 4 个站的数据差在哪",[11,20,21],{},"一个站一年发 240 篇，自然流量涨了 18%。另一个站一年发 60 篇，涨了 41%。",[11,23,24],{},"发 240 篇的那个站，我抽查了 40 篇，有 31 篇是同类选题的不同说法，另外 9 篇甚至标题改了、内容没改。",[15,26,27],{"id":27},"为什么数量不管用",[11,29,30],{},"因为搜索结果的容量有限。一个主题域最多排得下二三十个页面，再多就是自己跟自己抢。",[11,32,33],{},"篇数上去之后，单篇的投入一定下降，内链也被摊薄。数量和质量在同一个预算下是取舍关系。",[15,35,36],{"id":36},"有效篇数怎么算",[11,38,39],{},"我们内部的标准：有一处独家信息、能排进前 20、页面有点击或转化、能被至少一个 AI 引用。",[11,41,42],{},"四条满足两条以上算有效。4 个站的有效篇数分别是 31、28、19、12，和流量涨幅基本对得上。",[15,44,45],{"id":45},"什么时候该追求数量",[11,47,48],{},"两种情况：新站需要先铺收录，或者你在抢一个全新品类的词。",[11,50,51],{},"这两种情况下，前 30 篇可以粗放一点，把覆盖面做出来。但过了这个阶段，就必须转质量。",[15,53,54],{"id":54},"我们的实际配比",[11,56,57],{},"一年 50 篇左右：30 篇是有效内容，10 篇是文档和 FAQ 这类基础页，剩下 10 篇允许试错。",[11,59,60],{},"试错的 10 篇如果不灵，不硬救，直接并掉。这个比例我们跑了两年，稳定。",[15,62,63],{"id":63},"一个反问",[11,65,66],{},"如果一个月二十篇，但每篇都不能被引用，你是在做内容，还是在填后台？",[15,68,69],{"id":69},"怎么跟老板解释",[11,71,72],{},"别讲质量对数量，讲有效篇数和询盘的关系。我们把 4 个站的数据做成一张表，一眼能看出总篇数和询盘没有关系。",[11,74,75],{},"2026 年 2 月拿这张表跟一个客户的总监沟通，他当场就把下半年的篇数目标从 120 篇改成 60 篇，预算不变。",[15,77,78],{"id":78},"一个折中办法",[11,80,81],{},"如果老板一定要数量，就把基础页也算进去：文档、FAQ、术语、集成页。这些页确实需要量，而且做起来快，不占有效内容的预算。",[11,83,84],{},"这个问题问清楚，节奏就定了。",{"title":86,"searchDepth":87,"depth":87,"links":88},"",2,[89,90,91,92,93,94,95,96],{"id":17,"depth":87,"text":18},{"id":27,"depth":87,"text":27},{"id":36,"depth":87,"text":36},{"id":45,"depth":87,"text":45},{"id":54,"depth":87,"text":54},{"id":63,"depth":87,"text":63},{"id":69,"depth":87,"text":69},{"id":78,"depth":87,"text":78},null,"内容运营","2026-09-11","我们统计过 4 个客户站一年的数据，篇数和自然流量几乎没有相关性，有效篇数才有。有效篇数指带独家信息、能被引用、能带来动作的那几篇。",false,"md",{},true,"\u002Fblog\u002Fcontent-velocity-quality",{"title":5,"description":100},"blog\u002Fcontent-velocity-quality",[109,110,98],"内容数量","内容质量","415nZxGIqfct4WbIxjFW3IaA0AXp29is5Da_fg_9Qo0",{"id":113,"title":114,"author":6,"body":115,"canonical":97,"category":211,"cover":97,"date":212,"description":213,"draft":101,"extension":102,"keywords":97,"meta":214,"navigation":104,"noindex":101,"ogImage":97,"path":215,"seo":216,"seoDescription":97,"seoTitle":97,"stem":217,"tags":218,"updated":97,"__hash__":222},"blog\u002Fblog\u002Frum-vs-synthetic-monitoring.md","合成监控和真实用户监控，到底要不要都做",{"type":8,"value":116,"toc":202},[117,120,123,126,129,132,135,138,141,144,147,150,153,156,159,162,165,168,171,174,177,181,184,187,190,193,196,199],[11,118,119],{},"2026 年 9 月有人问我们，既然有 CrUX 的真实用户数据，还要不要自己做监控。答案是都要，但用途不一样。合成监控解决有没有变差，真实用户监控解决用户到底什么感受。",[15,121,122],{"id":122},"合成监控是什么",[11,124,125],{},"固定地点、固定设备、固定网络条件，定时跑同一个页面。",[11,127,128],{},"它的好处是可重复。今天和昨天的数据可以直接比，因为条件没变。上线之后性能掉了，它能第一时间发现。",[11,130,131],{},"坏处是它只代表一个假想用户。真实用户的设备、网络、浏览器版本千差万别，合成数据测不到长尾。",[15,133,134],{"id":134},"真实用户监控是什么",[11,136,137],{},"在页面上埋一段脚本，用浏览器的 Performance API 采集每个访客的指标，上报到服务器。",[11,139,140],{},"它能按设备、地区、网络类型分组，看到中位数和 75 分位。CrUX 就是 Google 用自己的数据做的同类东西。",[11,142,143],{},"坏处是数据脏。用户切后台、网络中断、脚本被拦截，都会产生异常值，需要清洗。",[15,145,146],{"id":146},"两者的偏差有多大",[11,148,149],{},"我们对比过一个站，合成监控显示 LCP 1.9 秒，真实用户 75 分位是 3.6 秒。",[11,151,152],{},"原因很简单：合成用的是城市宽带加中端设备，真实用户里有三成在三四线城市的 4G 网络上，还有一部分用着三年前的安卓机。",[11,154,155],{},"这个偏差不是误差，是结构性的。合成数据只能代表一部分用户。",[15,157,158],{"id":158},"一个容易忽略的细节",[11,160,161],{},"RUM 数据里有种情况会被算错：用户打开页面后切到后台，页面被浏览器冻结，采集到的 LCP 会异常大。",[11,163,164],{},"处理办法是上报时带上页面可见性状态，把切后台的样本单独标记，分析时排除。这类样本能占 5% 到 10%，不清洗会拉偏 75 分位。",[15,166,167],{"id":167},"我们的组合",[11,169,170],{},"核心页面选三个，合成监控每天跑，发现回归就告警。",[11,172,173],{},"真实用户数据看两个维度：按设备分组和按地区分组。移动端和 PC 分开看，差距通常很大。",[11,175,176],{},"采样率不用太高。日访问一万的站，采 10% 就足够稳定，全量采反而增加上报开销。",[15,178,180],{"id":179},"自建-rum-的最小方案","自建 RUM 的最小方案",[11,182,183],{},"用官方的 web-vitals 库采集三个指标，页面卸载时用 sendBeacon 上报，服务端存一张表。",[11,185,186],{},"一个前端加一个后端接口，半天能写完。数据量不大，一张表能存一年。",[11,188,189],{},"采集时带上设备类型、网络类型、页面路径、浏览器版本。这几个维度决定了后面能不能分析。",[15,191,192],{"id":192},"一个态度",[11,194,195],{},"监控的目的不是收集数据，是在出问题时能快速定位。",[11,197,198],{},"只有合成监控，你会漏掉真实用户的糟糕体验。只有真实用户数据，你会看不出是哪次上线导致的。",[11,200,201],{},"两个都做，成本不高，判断会清楚很多。真正的门槛不是技术，是有人愿意每周看一眼数据。",{"title":86,"searchDepth":87,"depth":87,"links":203},[204,205,206,207,208,209,210],{"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},{"id":179,"depth":87,"text":180},{"id":192,"depth":87,"text":192},"技术SEO","2026-09-10","合成监控能发现回归，真实用户数据能反映体验。这篇写两者的偏差在哪、核心页面怎么选、采样率多少够用，以及自建 RUM 的最小方案。",{},"\u002Fblog\u002Frum-vs-synthetic-monitoring",{"title":114,"description":213},"blog\u002Frum-vs-synthetic-monitoring",[219,220,221],"RUM","性能监控","CoreWebVitals","7jgTq8vpLFT8nfFXUYoCEt1Fm2dVYFVBPYZaVBWKXXI",{"id":224,"title":225,"author":6,"body":226,"canonical":97,"category":98,"cover":97,"date":321,"description":322,"draft":101,"extension":102,"keywords":97,"meta":323,"navigation":104,"noindex":101,"ogImage":97,"path":324,"seo":325,"seoDescription":97,"seoTitle":97,"stem":326,"tags":327,"updated":97,"__hash__":331},"blog\u002Fblog\u002Fmultilingual-content-workflow.md","多语言内容：翻译、改写、本地化，三件事别混着做",{"type":8,"value":227,"toc":312},[228,231,234,237,240,243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,291,294,297,300,303,306,309],[11,229,230],{},"把中文稿翻译成英文就发，是出海内容最常见的错误。翻译解决语言，改写解决搜索习惯，本地化解决用户场景，三层成本差三倍。",[15,232,233],{"id":233},"三个层次的区别",[11,235,236],{},"翻译：把中文逐句变成英文，保留原结构和关键词。",[11,238,239],{},"改写：按目标语言的搜索习惯重新组织，重挖关键词，重写标题和结构。",[11,241,242],{},"本地化：按目标市场的用户场景重写，换案例、换价格、换合规表述。",[11,244,245],{},"成本上，翻译是 1，改写是 2.5，本地化是 4。",[15,247,248],{"id":248},"什么时候用翻译",[11,250,251],{},"只有一种情况：内部文档、帮助中心这类\"必须准确、不需要搜索流量\"的内容。",[11,253,254],{},"比如 API 参考文档，翻译准确就行，不需要考虑英文用户的搜索习惯。这类内容用翻译，成本最低。",[15,256,257],{"id":257},"什么时候必须改写",[11,259,260],{},"面向搜索流量的内容，必须改写。",[11,262,263],{},"原因：中文和英文的关键词对不上。同一个功能，中文用户搜\"接口限流\"，英文用户搜\"rate limiting\"，搜索量和意图都不同。",[11,265,266],{},"我们 2025 年做过对比：直译的英文文章，6 个月平均排名 40 开外；改写过的，3 个月进前 20。",[15,268,269],{"id":269},"什么时候要本地化",[11,271,272],{},"目标市场是重点市场，且用户场景和中国差别大的时候。",[11,274,275],{},"比如做欧洲市场，数据合规的表述、支付方式、部署选项都不一样。这些内容必须本地化，否则用户一看就知道不是给他们写的。",[15,277,278],{"id":278},"我们的流程",[11,280,281],{},"第一步，判断内容类型：文档用翻译，博客和落地页用改写。",[11,283,284],{},"第二步，重做关键词研究：用目标语言的工具重新挖词，不沿用中文词表。",[11,286,287],{},"第三步，改写或本地化：标题、开头、案例、CTA 全部重写。",[11,289,290],{},"第四步，找母语者审一遍：不一定要资深写手，但必须是母语者，能看出不自然的地方。",[15,292,293],{"id":293},"一个失败案例",[11,295,296],{},"2025 年 9 月我们接过一个客户，把 200 篇中文博客用机器翻译成英文直接发。",[11,298,299],{},"结果：Google 收录了，但零排名零流量。我们抽查了 20 篇，标题是直译的，关键词不对，案例全是中国的，英文读者看不懂。",[11,301,302],{},"后来删掉重写，只保留了 40 篇，花了两个月。这个教训之后，我们定了一条规矩：面向搜索流量的内容，不接受纯翻译。",[15,304,305],{"id":305},"一句判断",[11,307,308],{},"多语言内容的成本不在语言，在\"重做一遍判断\"。翻译是省钱的捷径，但省下的钱会以流量的形式还回去。",[11,310,311],{},"预算有限的时候，宁少做，也别做直译。10 篇改写，比 100 篇直译有用，这件事没有捷径。",{"title":86,"searchDepth":87,"depth":87,"links":313},[314,315,316,317,318,319,320],{"id":233,"depth":87,"text":233},{"id":248,"depth":87,"text":248},{"id":257,"depth":87,"text":257},{"id":269,"depth":87,"text":269},{"id":278,"depth":87,"text":278},{"id":293,"depth":87,"text":293},{"id":305,"depth":87,"text":305},"2026-09-12","把中文稿翻译成英文就发，是出海内容最常见的错误。翻译解决语言，改写解决搜索习惯，本地化解决用户场景，三层成本差三倍。什么时候用哪层、我们的流程和一个失败案例都在这篇，照着走能少花冤枉钱。",{},"\u002Fblog\u002Fmultilingual-content-workflow",{"title":225,"description":322},"blog\u002Fmultilingual-content-workflow",[328,329,330],"多语言内容","内容本地化","出海内容","7Z7oNlTdkooAyF9u8E8PEBjJ2W8yY5YGc4qNRaQFvtE",1794088101907]