[{"data":1,"prerenderedAt":339},["ShallowReactive",2],{"blog-keyword-research-without-tools":3,"blog-prev-keyword-research-without-tools":119,"blog-next-keyword-research-without-tools":225},{"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\u002Fkeyword-research-without-tools.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",{},"不买关键词工具也能挖词，只是慢三倍。2026 年 1 月我们给一个预算为零的客户做过一次，三个人三周，挖出 210 个候选词，进排期的 31 个。没花一分钱，靠的是四个免费来源。",[15,16,18],"h2",{"id":17},"第一个来源搜索后台","第一个来源：搜索后台",[11,20,21],{},"GSC 和百度搜索资源平台的查询数据，是唯一免费又真实的搜索量代理。最近 28 天有曝光、排名在 10 到 50 名之间的查询，就是现成的机会词表。",[11,23,24],{},"这个来源比工具准，因为它是你自己的真实数据，不带估算。",[15,26,28],{"id":27},"第二个来源站内搜索","第二个来源：站内搜索",[11,30,31],{},"用户在你站内搜过什么，说明他想找什么但没找到。这类词往往正是该写的内容。",[11,33,34],{},"站内搜索数据一般在统计工具里，或者从产品日志里导。有的话别浪费。",[15,36,38],{"id":37},"第三个来源客服工单","第三个来源：客服工单",[11,40,41],{},"客户描述问题的原话，几乎就是搜索词。报错原文、功能叫法、操作步骤，三类都能直接变成选题。",[11,43,44],{},"工单里的词工具一般挖不出来，量太小，被当噪音过滤了。",[15,46,48],{"id":47},"第四个来源竞品目录和文档搜索","第四个来源：竞品目录和文档搜索",[11,50,51],{},"看竞品写了什么，看他没写什么；看他文档的搜索框提示，看他的 FAQ 结构。",[11,53,54],{},"这一步不是为了抄，是为了确认哪些问题已经有人验证过有需求。",[15,56,57],{"id":57},"没工具最缺什么",[11,59,60],{},"缺搜索量。没有量，就没法排序，只能靠判断。",[11,62,63],{},"我们的替代办法：用搜索后台的曝光当量级，用搜索结果页的竞争程度当机会分，两个加起来排优先级。粗糙，但够用。",[15,65,66],{"id":66},"慢在哪",[11,68,69],{},"慢在没法批量。工具能一次导出两万个词，人工只能一个个过。三周时间里有两周花在整理和核对上。",[11,71,72],{},"如果词库规模超过 500 个词，或者要做多个语言，还是买工具。手工的成本比订阅费高。",[15,74,75],{"id":75},"一个判断",[11,77,78],{},"工具解决的是规模，不解决判断。没有工具的时候，你反而会更认真地看每个词的搜索结果。",[15,80,81],{"id":81},"一个人做的话",[11,83,84],{},"一个人用免费来源挖词，一周能稳定产出 20 到 30 个候选，够一个月写。",[11,86,87],{},"别贪多。词表太大反而没人用，40 个里面挑出 8 个，写完再挖下一批。",[11,89,90],{},"我们那个客户后来买了工具，但选词的标准还是那三条：有没有决策信号、竞品做没做好、我们有没有素材。这三条工具给不了。",{"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,"SEO","2026-06-24","预算为零也能挖词。四个免费来源：搜索后台、站内搜索、客服工单、竞品目录。我们给一个零预算客户做了三周，挖出 210 个词，进排期的 31 个。",false,"md",{},true,"\u002Fblog\u002Fkeyword-research-without-tools",{"title":5,"description":106},"blog\u002Fkeyword-research-without-tools",[115,116,117],"关键词研究","免费工具","小团队","tVGK11VKfwGyUm1HG0kFw6W5_Gx91Fzc-Km3Wtugn4E",{"id":120,"title":121,"author":6,"body":122,"canonical":103,"category":213,"cover":103,"date":214,"description":215,"draft":107,"extension":108,"keywords":103,"meta":216,"navigation":110,"noindex":107,"ogImage":103,"path":217,"seo":218,"seoDescription":103,"seoTitle":103,"stem":219,"tags":220,"updated":103,"__hash__":224},"blog\u002Fblog\u002Fjs-bundle-load-order.md","JS 包体拆完还是慢，问题在加载顺序",{"type":8,"value":123,"toc":204},[124,127,130,133,136,139,142,145,148,151,154,157,160,163,166,169,172,175,178,181,184,187,190,193,196,198,201],[11,125,126],{},"2026 年 7 月一个客户说包体已经拆过了，从 2.1 兆降到 600K，首屏还是 2.8 秒。我打开 DevTools 一看，600K 里有 400K 是首屏根本用不到的东西，只是被放在了主包里。",[15,128,129],{"id":129},"拆包解决的是什么",[11,131,132],{},"它解决下载量，让首屏不用等全部 JS 下完。但首屏时间不只取决于下载，还取决于解析、执行、以及依赖的先后顺序。",[11,134,135],{},"一个 300K 的包，在 4 倍 CPU 降速下执行要一秒多。拆成三个 100K 的包并行下载，执行时间没变。",[11,137,138],{},"所以拆包只是第一步，关键是让主线程上只跑首屏需要的东西。",[15,140,141],{"id":141},"三种常见的拆错",[11,143,144],{},"第一种，把首屏依赖拆进了懒加载。按钮点击才加载的组件里，包含了首屏渲染要用的工具函数，结果首屏卡住等它。",[11,146,147],{},"第二种，拆得太碎。几十个小 chunk，每个都要一个请求，HTTP\u002F2 下虽然能复用连接，但请求排队和依赖解析反而更慢。",[11,149,150],{},"第三种，vendor 全塞一个包。所有第三方库打成一个 1 兆的文件，首屏只用到其中一个，剩下全是白下。",[15,152,153],{"id":153},"加载顺序怎么排",[11,155,156],{},"首屏关键 chunk 用 modulepreload 提前拿，放在 head 里，让它和 HTML 并行。",[11,158,159],{},"非关键的用 defer，别用 async。async 的执行时机不确定，可能抢在关键脚本前面跑，造成页面空白。",[11,161,162],{},"runtime 和 manifest 内联到 HTML 里，省一个请求，也避免版本错配。",[15,164,165],{"id":165},"真正的大头往往不在业务代码",[11,167,168],{},"我们拆过十几个站，主包里最大的三样东西通常是：全量引入的工具库、图标库、polyfill。",[11,170,171],{},"工具库只用了两个函数，却把整个库打进来；图标库引了一千个图标，页面只用八个；polyfill 给现代浏览器也塞了一份。",[11,173,174],{},"这三样加起来能占主包的一半，砍掉比拆十次都有用。",[15,176,177],{"id":177},"怎么判断哪里该砍",[11,179,180],{},"用 bundle 分析工具看每个模块的体积占比，先砍排名前十的。",[11,182,183],{},"再用代码覆盖率看首屏执行了多少。我们见过首屏执行率 12% 的页面，意思是 88% 的 JS 白跑了。",[11,185,186],{},"最后在 4 倍 CPU 降速下测。桌面跑得欢的代码，在中端安卓机上可能是灾难。",[15,188,189],{"id":189},"一个可以立刻做的检查",[11,191,192],{},"打开 DevTools 的 Coverage 面板，录一次首屏加载，它会告诉你每个 JS 文件执行了多少、浪费了多少。",[11,194,195],{},"超过一半没执行的包，就是该拆或者该砍的。这个检查十分钟能做完，比看任何分析报告都直接。",[15,197,75],{"id":75},[11,199,200],{},"包体优化里，砍掉不用的代码比拆包收益大，排好加载顺序比压缩收益大，压缩只是最后一步。",[11,202,203],{},"很多团队把顺序做反了：先上压缩和 CDN，再研究拆包，最后才想起来问这些代码到底用不用。这个顺序应该倒过来。",{"title":92,"searchDepth":93,"depth":93,"links":205},[206,207,208,209,210,211,212],{"id":129,"depth":93,"text":129},{"id":141,"depth":93,"text":141},{"id":153,"depth":93,"text":153},{"id":165,"depth":93,"text":165},{"id":177,"depth":93,"text":177},{"id":189,"depth":93,"text":189},{"id":75,"depth":93,"text":75},"技术SEO","2026-06-23","一个站 JS 从 2.1 兆拆到 600K，首屏还是 2.8 秒。拆包解决下载，解决不了执行和依赖顺序。这篇写拆错的三种情况、关键 chunk 怎么排、真正的大头在哪。",{},"\u002Fblog\u002Fjs-bundle-load-order",{"title":121,"description":215},"blog\u002Fjs-bundle-load-order",[221,222,223],"JavaScript","代码分割","首屏","I_h685YtX-z_-Oh3_MV54zfZl_CDDd1Ub-Pr9GoR4QA",{"id":226,"title":227,"author":6,"body":228,"canonical":103,"category":327,"cover":103,"date":328,"description":329,"draft":107,"extension":108,"keywords":103,"meta":330,"navigation":110,"noindex":107,"ogImage":103,"path":331,"seo":332,"seoDescription":103,"seoTitle":103,"stem":333,"tags":334,"updated":103,"__hash__":338},"blog\u002Fblog\u002Ftopic-rejection-criteria.md","选题的 5 个否决条件：我们为什么不追热点",{"type":8,"value":229,"toc":316},[230,233,236,239,242,246,249,252,256,259,262,266,269,272,276,279,282,286,289,292,295,298,301,304,307,310,313],[11,231,232],{},"选题会最大的浪费不是选错题，是花了时间讨论一个根本不该做的题。我们定了 5 个否决条件，命中任何一条就直接过，不进入讨论。",[15,234,235],{"id":235},"为什么要设否决条件",[11,237,238],{},"以前我们的选题会是\"头脑风暴\"，每个人提想法，讨论半小时，最后选几个。问题是：讨论的题里有一半根本不该做。",[11,240,241],{},"设了否决条件之后，选题会时间缩短了一半，产出反而更稳定。因为大家先自己过滤，不合适的题根本不提。",[15,243,245],{"id":244},"条件一没有搜索需求","条件一：没有搜索需求",[11,247,248],{},"判断方法：目标词在关键词工具里月搜索量低于 30，且在搜索后台看不到任何曝光。",[11,250,251],{},"例外：品牌词、新产品词，可以没有搜索量，但要有明确的承接页。",[15,253,255],{"id":254},"条件二没有转化路径","条件二：没有转化路径",[11,257,258],{},"写完这篇文章，用户下一步能做什么？注册、试用、下载、咨询，至少有一个。",[11,260,261],{},"如果一篇文章读完，用户只能\"知道了\"，这篇就是纯流量内容。纯流量内容我们只在两种情况下做：品牌曝光，或者为后续内容做铺垫。",[15,263,265],{"id":264},"条件三写不出独家","条件三：写不出独家",[11,267,268],{},"判断方法：问一句\"这篇里有没有一句话是同行写不出来的\"。没有，就否决。",[11,270,271],{},"独家的来源：实测数据、客户现场、内部经验、原创调研。都没有，就换个角度或者换题。",[15,273,275],{"id":274},"条件四竞品已经写透","条件四：竞品已经写透",[11,277,278],{},"判断方法：搜目标词，看前 5 名。如果都是大站、内容完整、有数据、有案例，而且我们没有任何增量，就否决。",[11,280,281],{},"不是不能做，是优先级往后排。等我们有独家素材了再做。",[15,283,285],{"id":284},"条件五维护成本过高","条件五：维护成本过高",[11,287,288],{},"有些内容写起来不难，维护起来要命。比如\"2026 年 XX 工具排行榜\"，每年都要更新，数据要重新收集。",[11,290,291],{},"我们一般算一笔账：维护成本超过初次写作成本 2 倍的题，谨慎接。",[15,293,294],{"id":294},"一个被我们否决的选题",[11,296,297],{},"2026 年 2 月，客户提议写\"2026 年 AI 编程工具盘点\"。搜索量很大，但我们判断：",[11,299,300],{},"竞品已经写透（前 10 名都是大站的年度盘点）；我们写不出独家（没有实测数据）；维护成本高（每年更新）；转化路径弱（读者看完就去试工具了）。",[11,302,303],{},"四条命中，直接否决。后来改成\"AI 编程工具在团队协作里的 3 个坑\"，用了客户的真实使用数据，反而排到了前 10。",[15,305,306],{"id":306},"否决之后干什么",[11,308,309],{},"别让否决变成\"什么都不做\"。每个被否决的题，记录原因，三个月后回头看：如果原因消失了（比如我们有了独家数据），可以重新提。",[15,311,312],{"id":312},"一句判断",[11,314,315],{},"选题的能力不是\"能想出多少题\"，是\"能砍掉多少题\"。砍得准，剩下的题才有资源做好。",{"title":92,"searchDepth":93,"depth":93,"links":317},[318,319,320,321,322,323,324,325,326],{"id":235,"depth":93,"text":235},{"id":244,"depth":93,"text":245},{"id":254,"depth":93,"text":255},{"id":264,"depth":93,"text":265},{"id":274,"depth":93,"text":275},{"id":284,"depth":93,"text":285},{"id":294,"depth":93,"text":294},{"id":306,"depth":93,"text":306},{"id":312,"depth":93,"text":312},"内容运营","2026-06-25","选题会最大的浪费不是选错题，是花了时间讨论一个根本不该做的题。我们定了 5 个否决条件：没有搜索需求、没有转化路径、写不出独家、竞品已经写透、维护成本过高。每条都有判断方法，选题会上照着过一遍就行。",{},"\u002Fblog\u002Ftopic-rejection-criteria",{"title":227,"description":329},"blog\u002Ftopic-rejection-criteria",[335,336,337],"内容选题","选题决策","内容策略","B9KXjnbrqY93gT6M8cEQorb5mlCBrhQXfKjrxou8Lhk",1794088104397]