[{"data":1,"prerenderedAt":350},["ShallowReactive",2],{"blog-multilingual-market-priority":3,"blog-prev-multilingual-market-priority":119,"blog-next-multilingual-market-priority":233},{"id":4,"title":5,"author":6,"body":7,"canonical":103,"category":104,"cover":103,"date":105,"description":106,"draft":107,"extension":108,"keywords":103,"meta":109,"navigation":110,"noindex":107,"ogImage":103,"path":111,"seo":112,"seoDescription":103,"seoTitle":103,"stem":113,"tags":114,"updated":103,"__hash__":118},"blog\u002Fblog\u002Fmultilingual-market-priority.md","多语言先做哪个市场，我们用四个分数排顺序","元析智能",{"type":8,"value":9,"toc":91},"minimark",[10,14,19,22,25,29,32,35,39,42,45,49,52,55,58,61,64,67,70,73,76,79,82,85,88],[11,12,13],"p",{},"多语言内容最贵的错误，是同时开三个市场。我们的做法是先算分，选一个市场做完再开第二个。四项打分，10 分制，谁高做谁。2026 年上半年我们帮两个客户用这套方法排过，都只开了一个新市场。",[15,16,18],"h2",{"id":17},"第一项现有询盘从哪来","第一项：现有询盘从哪来",[11,20,21],{},"翻最近 12 个月的询盘和成交记录，按国家或地区分组。已经有海外询盘的，那个市场就是第一优先级。",[11,23,24],{},"如果一个海外询盘都没有，说明产品还没验证这个市场，先别写内容。",[15,26,28],{"id":27},"第二项搜索需求","第二项：搜索需求",[11,30,31],{},"用目标语言在 Google 里搜你的核心词，看有没有相关的搜索建议、有没有竞品在投广告、有没有第三方评测站。",[11,33,34],{},"需求存在但供给很差的市场，是最好的机会。",[15,36,38],{"id":37},"第三项竞品覆盖程度","第三项：竞品覆盖程度",[11,40,41],{},"你的竞品在目标市场有没有本地语言站。有，说明这个市场有人在打；没有，可能是没需求，也可能是没人做。",[11,43,44],{},"两种情况要分开：如果是同类产品的大厂都没做，谨慎；如果是区域小厂在做，可以进。",[15,46,48],{"id":47},"第四项支持能力","第四项：支持能力",[11,50,51],{},"这是最容易忽略的一项。客户来了，谁用当地语言回复？谁处理时区差异？谁做发票和合规？",[11,53,54],{},"没有支持能力的市场，内容做得再好也接不住，流量只会拉高跳出率。",[15,56,57],{"id":57},"怎么算总分",[11,59,60],{},"四项各 10 分，加权：询盘 40%、搜索需求 25%、竞品 20%、支持能力 15%。",[11,62,63],{},"低于 6 分的市场先不做。6 到 7.5 分可以先做一个试点，写 5 篇内容看三个月。",[15,65,66],{"id":66},"一个实例",[11,68,69],{},"一个做 API 网关的客户，英文市场询盘占 35%，搜索需求 8 分，竞品覆盖 6 分，支持能力 4 分，总分 6.4。",[11,71,72],{},"我们的建议是先补英文售前支持，再做英文内容。先做内容的话，询盘来了没人跟，等于白做。",[15,74,75],{"id":75},"做完一个再开下一个",[11,77,78],{},"一个市场的内容体系，从词表到支柱页到案例，至少要六个月才能跑顺。同时开两个，等于两个都做不深。",[15,80,81],{"id":81},"开新市场前先做的事",[11,83,84],{},"先跑三个月的英文询盘，看有没有真实成交。没有成交就先别写内容。",[11,86,87],{},"2025 年 12 月我们劝住过一个客户，他想做日文站，但三年里只接过两个日本询盘，且都没成交。第二年他先找了日本代理，再回来做内容，顺序对了。",[11,89,90],{},"我们见过一个客户同时做英文、日文、德文三个站，一年后三个站加起来不到 200 个自然访问。",{"title":92,"searchDepth":93,"depth":93,"links":94},"",2,[95,96,97,98,99,100,101,102],{"id":17,"depth":93,"text":18},{"id":27,"depth":93,"text":28},{"id":37,"depth":93,"text":38},{"id":47,"depth":93,"text":48},{"id":57,"depth":93,"text":57},{"id":66,"depth":93,"text":66},{"id":75,"depth":93,"text":75},{"id":81,"depth":93,"text":81},null,"内容运营","2026-07-23","不是所有市场都值得做多语言。我们按询盘来源、搜索需求、竞品覆盖、支持能力四项打 10 分制，先做分数最高的一个市场，做完再考虑第二个。",false,"md",{},true,"\u002Fblog\u002Fmultilingual-market-priority",{"title":5,"description":106},"blog\u002Fmultilingual-market-priority",[115,116,117],"多语言","出海","市场选择","ZSuOs23cgSOpvno6MLCRbiK35DFWSBNnQ9wmNDQWfiI",{"id":120,"title":121,"author":6,"body":122,"canonical":103,"category":221,"cover":103,"date":222,"description":223,"draft":107,"extension":108,"keywords":103,"meta":224,"navigation":110,"noindex":107,"ogImage":103,"path":225,"seo":226,"seoDescription":103,"seoTitle":103,"stem":227,"tags":228,"updated":103,"__hash__":232},"blog\u002Fblog\u002Fpreload-preconnect-misuse.md","preload 用错反而更慢，先看这三个判断",{"type":8,"value":123,"toc":212},[124,127,130,133,136,139,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191,194,197,200,203,206,209],[11,125,126],{},"2026 年 8 月我们接手一个站，head 里写了九条 preload，测完发现只有三条真正被首屏用到。剩下的不但没帮忙，还抢了 LCP 图片的带宽，首屏反而慢了 200 毫秒。资源提示不是越多越好。",[15,128,129],{"id":129},"三种提示各管什么",[11,131,132],{},"dns-prefetch 只做 DNS 解析，最轻，适合那些一定会请求、但不急的第三方域。",[11,134,135],{},"preconnect 多做一步，把 TCP 连接和 TLS 握手也提前完成，成本高一点，适合关键第三方域，比如字体、CDN、支付。",[11,137,138],{},"preload 直接下载指定资源，优先级最高，会和其他关键资源抢带宽，所以只该给首屏必需的东西。",[15,140,142],{"id":141},"什么该-preload","什么该 preload",[11,144,145],{},"LCP 那张图。它是首屏最大的元素，提前下载能直接改善指标。",[11,147,148],{},"关键字体。字体藏在 CSS 里发现得晚，preload 能省一个来回，但要带 crossorigin。",[11,150,151],{},"关键 CSS，如果它放在外部文件里，可以 preload 之后切换成样式表。",[11,153,154],{},"我们通常控制在三个以内。超过三个，就要问一句：这些真的都是首屏必需的吗。",[15,156,157],{"id":157},"用错的三种情况",[11,159,160],{},"第一种，preload 了没用上的资源。Chrome 会在控制台警告“资源被预加载但未在几秒内使用”，看到这条警告就该删。",[11,162,163],{},"第二种，crossorigin 不匹配。字体 preload 不带 crossorigin，浏览器会当成另一个请求，等于下载两次，比不 preload 还慢。",[11,165,166],{},"第三种，给非首屏图片做 preload。用户在首屏根本看不到，提前下载纯属浪费。",[15,168,169],{"id":169},"怎么验证",[11,171,172],{},"DevTools 网络面板有一列优先级，看 preload 的资源是不是真的排在前面，有没有把 LCP 图挤下去。",[11,174,175],{},"再看瀑布图。preload 生效的话，关键资源的请求起点会提前到和 HTML 解析并行；没生效的话，它还是排在一堆请求后面。",[11,177,178],{},"最后对比改前改后两次的 LCP。没有改善就说明用错了，别留着。",[15,180,181],{"id":181},"一次真实的清理",[11,183,184],{},"2026 年 6 月我们查另一个站的 preload，九条里有六条是产品经理要求加的，理由是重要。",[11,186,187],{},"逐条看：两张大图不在首屏、一个统计脚本、一个客服组件、一个字体子集其实没用到、一个视频预加载了八兆。",[11,189,190],{},"删掉六条、保留三条之后，首屏 LCP 从 2.9 秒降到 2.4 秒。加的时候每个人都说重要，删的时候没人反对。",[15,192,193],{"id":193},"怎么跟团队解释",[11,195,196],{},"资源提示的效果很难用业务语言描述。我们的说法是：它只影响首屏的等待时间，不影响功能。",[11,198,199],{},"所以争议最小，改起来也安全。上线前测一次，有改善就留，没改善就删，不需要开会讨论。",[15,201,202],{"id":202},"一个判断",[11,204,205],{},"资源提示是微调工具，不是万能药。它能省一两百毫秒，前提是用对地方。",[11,207,208],{},"网络优化的顺序应该是：先砍掉不必要的资源，再优化关键路径，最后才用提示做微调。",[11,210,211],{},"顺序反过来，先加一堆 preload，只会让本来就拥挤的首屏更乱。",{"title":92,"searchDepth":93,"depth":93,"links":213},[214,215,216,217,218,219,220],{"id":129,"depth":93,"text":129},{"id":141,"depth":93,"text":142},{"id":157,"depth":93,"text":157},{"id":169,"depth":93,"text":169},{"id":181,"depth":93,"text":181},{"id":193,"depth":93,"text":193},{"id":202,"depth":93,"text":202},"技术SEO","2026-07-22","一个站 preload 了九个资源，只有三个真用上，首屏反而慢了两百毫秒。这篇写 preload、preconnect、dns-prefetch 各管什么，什么时候不该用。",{},"\u002Fblog\u002Fpreload-preconnect-misuse",{"title":121,"description":223},"blog\u002Fpreload-preconnect-misuse",[229,230,231],"preload","资源提示","首屏","FYfSwZ9RKnp5r0UiOJqEfvsEYM57zqA9y25fjjoFO5Q",{"id":234,"title":235,"author":6,"body":236,"canonical":103,"category":104,"cover":103,"date":339,"description":340,"draft":107,"extension":108,"keywords":103,"meta":341,"navigation":110,"noindex":107,"ogImage":103,"path":342,"seo":343,"seoDescription":103,"seoTitle":103,"stem":344,"tags":345,"updated":103,"__hash__":349},"blog\u002Fblog\u002Fproduct-launch-content-plan.md","新产品上线前 8 周的内容排期：预热、教育、发布、跟进",{"type":8,"value":237,"toc":329},[238,241,244,247,250,254,257,260,263,267,270,273,276,280,283,286,289,293,296,299,302,305,308,311,314,317,320,323,326],[11,239,240],{},"软件产品发布当周才开始写内容，已经晚了。我们把内容排期提前 8 周：预热期讲问题、教育期讲方案、发布期讲产品、跟进期讲案例。",[15,242,243],{"id":243},"为什么内容要早于产品",[11,245,246],{},"发布当周才开始写，有三个问题：搜索需要时间收录和排名；用户需要时间理解问题；销售需要素材去接触客户。",[11,248,249],{},"我们 2025 年做过对比：提前 8 周做内容的发布，首月自然流量是发布当天才开始写的 3 倍。",[15,251,253],{"id":252},"第-8-到-6-周预热期讲问题","第 8 到 6 周：预热期讲问题",[11,255,256],{},"这个阶段不讲产品，讲\"你正在遇到什么问题\"。",[11,258,259],{},"三类内容：行业问题分析、用户痛点盘点、旧方案的局限。目标是让目标用户认领问题。",[11,261,262],{},"写法上，别急着提产品名。文章里提一次\"我们正在做一个新方案\"，结尾留个订阅入口就行。",[15,264,266],{"id":265},"第-5-到-3-周教育期讲方案","第 5 到 3 周：教育期讲方案",[11,268,269],{},"讲\"这类问题通常怎么解\"，可以对比不同思路，但不急着讲自家产品。",[11,271,272],{},"三类内容：解决方案对比、选型标准、实施注意事项。",[11,274,275],{},"这个阶段可以开始埋产品线索：在对比里提一句\"我们采用了 XX 方案\"，但不展开。",[15,277,279],{"id":278},"第-2-到-0-周发布期讲产品","第 2 到 0 周：发布期讲产品",[11,281,282],{},"发布前两周，开始写产品相关的内容：功能解读、使用场景、和竞品的差异。",[11,284,285],{},"发布当天发三篇：产品介绍（给新用户）、功能深潜（给技术读者）、发布公告（给现有客户和媒体）。",[11,287,288],{},"发布后第一周发两篇：客户案例（如果有）、常见问题。",[15,290,292],{"id":291},"发布后-4-周跟进期讲案例","发布后 4 周：跟进期讲案例",[11,294,295],{},"产品上线后，用户会有真实反馈。这个阶段写：第一批用户怎么用、遇到什么问题、我们怎么解决。",[11,297,298],{},"这类内容最容易被引用，因为有一手信息。我们一般要求产品团队在发布后两周内提供 3 个真实使用场景。",[15,300,301],{"id":301},"一个例子",[11,303,304],{},"2026 年 3 月，一个客户发布日志分析模块。我们提前 8 周排期：",[11,306,307],{},"第 8 周发\"日志成本失控的三个原因\"，第 5 周发\"日志方案怎么选\"，第 2 周发功能解读，发布当天发三篇，第一周发 FAQ，第四周发两个客户的真实使用记录。",[11,309,310],{},"结果：发布首月自然流量 1.8 万，注册 240 个，其中 60% 来自预热期和发布期的内容。",[15,312,313],{"id":313},"一个提醒",[11,315,316],{},"预热期的内容不要写得太\"营销\"。用户能看出来你在铺垫，效果会打折。",[11,318,319],{},"写法上以\"我们观察到\"开头，讲问题、讲数据，别讲产品有多好。",[15,321,322],{"id":322},"一句判断",[11,324,325],{},"产品发布的内容效果，80% 取决于发布前有没有铺垫。提前 8 周不是夸张，是按搜索收录和用户决策周期算出来的。",[11,327,328],{},"如果产品下周就发，那至少把\"问题类内容\"补上，别只发一篇产品介绍。",{"title":92,"searchDepth":93,"depth":93,"links":330},[331,332,333,334,335,336,337,338],{"id":243,"depth":93,"text":243},{"id":252,"depth":93,"text":253},{"id":265,"depth":93,"text":266},{"id":278,"depth":93,"text":279},{"id":291,"depth":93,"text":292},{"id":301,"depth":93,"text":301},{"id":313,"depth":93,"text":313},{"id":322,"depth":93,"text":322},"2026-07-24","软件产品发布当周才开始写内容，已经晚了。我们把内容排期提前 8 周：预热期讲问题、教育期讲方案、发布期讲产品、跟进期讲案例。四个阶段各写什么、什么时间发，都在这篇，附一个发布首月的数据，都是我们自己跟的案例。",{},"\u002Fblog\u002Fproduct-launch-content-plan",{"title":235,"description":340},"blog\u002Fproduct-launch-content-plan",[346,347,348],"产品发布","内容排期","内容策略","mFuSY1ydWZRWGZJsnPyKspwDfYpOGRSEt_r1RXEEyCs",1794088103545]