[{"data":1,"prerenderedAt":290},["ShallowReactive",2],{"blog-keyword-research-five-steps":3,"blog-prev-keyword-research-five-steps":91,"blog-next-keyword-research-five-steps":196},{"id":4,"title":5,"author":6,"body":7,"canonical":74,"category":75,"cover":74,"date":76,"description":77,"draft":78,"extension":79,"keywords":74,"meta":80,"navigation":81,"noindex":78,"ogImage":74,"path":82,"seo":83,"seoDescription":74,"seoTitle":74,"stem":84,"tags":85,"updated":74,"__hash__":90},"blog\u002Fblog\u002Fkeyword-research-five-steps.md","软件公司做关键词研究，我们固定跑这五步流程","元析智能",{"type":8,"value":9,"toc":65},"minimark",[10,14,19,22,25,28,32,35,38,42,45,49,52,55,59,62],[11,12,13],"p",{},"关键词研究我们不是从工具开始的。顺序固定为：先翻手里已有的数据，再去噪，再分层，再跟具体页面匹配，最后上线复检。工具用在第一步和第二步之间，用完就退场。2025 年 3 月给一家做接口监控的软件公司重做词库，两万一千个词导进来，真正进排期的只有 71 个。",[15,16,18],"h2",{"id":17},"第一步先把手里已有的三份数据摆出来","第一步：先把手里已有的三份数据摆出来",[11,20,21],{},"一上来就买工具的公司很多，其实最值钱的三份数据在自己手里：客服工单、销售丢单记录、搜索后台的真实查询。",[11,23,24],{},"工单里客户怎么描述问题，就是他们会在百度里怎么搜。丢单记录里那句“我们最后选了别家，因为……”经常直接给出一个对比词。搜索后台最直接，最近 28 天有曝光、排不到名的查询，就是现成的高意图词表。",[11,26,27],{},"那次 71 个选题里，30 个来自工单，11 个来自丢单记录，剩下的来自后台。工具导出的两万一千个词贡献了几个？三个。",[15,29,31],{"id":30},"第二步去噪比挖词更费时间","第二步：去噪比挖词更费时间",[11,33,34],{},"两万一千个词，机器按词根去重和否定词过滤后剩一万二，再人工过一遍剩八千出头。噪音主要四类：破解下载、招聘外包、同名不同义、以及完全不相干的行业词。",[11,36,37],{},"否定词表我们固定三十几个，包括免费、破解、下载、教程、招聘、外包、源码、汉化。每次都要补充，但起点不动。这一步省不了，谁省谁后面写废稿。",[15,39,41],{"id":40},"第三步分层不是列一张长表","第三步：分层，不是列一张长表",[11,43,44],{},"词库按意图分成四张表：学习类、方案类、对比类、操作类。四张表分别对应四种页面，也分别对应四个负责人。分层之后，一个词该由谁写、写成什么，不用再开会讨论。",[15,46,48],{"id":47},"第四步词表要落到具体页面上","第四步：词表要落到具体页面上",[11,50,51],{},"词和页面是一对多。一个功能页能承接二十来个长尾词，但一个词只能落一个页面。两个页面对同一个词，等于自己跟自己抢位置。",[11,53,54],{},"定稿前我要求每个词后面写一个 URL。写不出来的词，说明还没想清楚写什么，先放着。",[15,56,58],{"id":57},"第五步上线四周后复检","第五步：上线四周后复检",[11,60,61],{},"发布后第 28 天翻一次后台。有曝光的留着，三周零曝光的，要么删掉，要么并进相邻页面。第一轮复检我们会砍掉大约 15% 的选题，这个比例比我预想的高，后来就接受了。",[11,63,64],{},"关键词研究不是做完一次就归档的项目。每次写稿之前，我都得把这些词重新看一遍。",{"title":66,"searchDepth":67,"depth":67,"links":68},"",2,[69,70,71,72,73],{"id":17,"depth":67,"text":18},{"id":30,"depth":67,"text":31},{"id":40,"depth":67,"text":41},{"id":47,"depth":67,"text":48},{"id":57,"depth":67,"text":58},null,"SEO","2025-09-07","关键词研究不是打开工具导一张表。我们的顺序是来源、去噪、分层、匹配、复检，两万多个词最后进排期的只有 71 个。五步分别怎么做、素材从哪来，都写在下面。",false,"md",{},true,"\u002Fblog\u002Fkeyword-research-five-steps",{"title":5,"description":77},"blog\u002Fkeyword-research-five-steps",[86,87,88,89],"关键词研究","词库搭建","软件公司","选题","63BTO5nuoPqLe0chnAKs_sSuf-NtyXAJDEoj-i3xAYI",{"id":92,"title":93,"author":6,"body":94,"canonical":74,"category":184,"cover":74,"date":185,"description":186,"draft":78,"extension":79,"keywords":74,"meta":187,"navigation":81,"noindex":78,"ogImage":74,"path":188,"seo":189,"seoDescription":74,"seoTitle":74,"stem":190,"tags":191,"updated":74,"__hash__":195},"blog\u002Fblog\u002Flcp-hero-image-bottleneck.md","首图拖慢首屏，软件公司官网 LCP 卡住的三个真实原因",{"type":8,"value":95,"toc":177},[96,99,103,106,109,112,116,128,131,134,138,144,155,159,162,165,168,171,174],[11,97,98],{},"我们审计过 11 个软件公司官网，其中 8 个的 LCP 元素是首屏那张产品截图，不是文字标题。原因集中在三处：图按设计稿尺寸直接导出、首屏图被统一加了懒加载、首图写在 CSS 背景里。改完这三处，平均能从 4 秒出头压到 2.2 秒左右，不需要动服务器。",[15,100,102],{"id":101},"原因一图按设计稿尺寸导出","原因一：图按设计稿尺寸导出",[11,104,105],{},"去年 11 月接的一个项目管理 SaaS，首页 hero 图是 2400×1350 的 PNG，1.8MB，而它在页面上实际只渲染 720 像素宽。设计师给的 2 倍图，前端直接放了原图，没人算过这一张占了首屏流量的七成。",[11,107,108],{},"改成 1440 宽、WebP 质量 78，体积 180KB。同一张图，在笔记本上肉眼分辨不出差别。这个站的 LCP 从 4.1 秒降到 2.9 秒，只动了这一处。",[11,110,111],{},"查法很简单：Performance 面板里看 LCP 请求的 transfer size，再和 Elements 里这张图的实际渲染尺寸对一下。传输体积超过渲染面积所需的两倍，就是浪费。这个判断不需要工具，手算一下就行。",[15,113,115],{"id":114},"原因二首屏图被统一加了懒加载","原因二：首屏图被统一加了懒加载",[11,117,118,119,123,124,127],{},"很多模板给所有 ",[120,121,122],"code",{},"img"," 统一加 ",[120,125,126],{},"loading=\"lazy\"","，图省事。首屏图懒加载的代价是浏览器不会在解析 HTML 阶段就拿它，要等布局算完、判断它进入视口，才开始下载。移动端这一步能拖 300 到 600 毫秒。",[11,129,130],{},"我们查过一个开发者工具站，LCP 元素明明是首屏的架构图，Lighthouse 里这个请求的发现时间排在第 9 位。把首屏那张图的 lazy 去掉，它从第 9 位提到第 2 位，LCP 从 3.6 秒到 2.4 秒。",[11,132,133],{},"判断标准：首屏内的图不要 lazy，首屏外的图必须 lazy。一个属性的事，值得单独检查一遍。",[15,135,137],{"id":136},"原因三首图是-css-背景图","原因三：首图是 CSS 背景图",[11,139,140,143],{},[120,141,142],{},"background-image"," 写在样式表里，浏览器要先下载 CSS、解析、匹配选择器，才知道有这么张图。这层依赖让它的发现时间比 HTML 里的 img 晚一个 RTT 以上。",[11,145,146,147,150,151,154],{},"一个安全工具站的首图是背景图，2.4MB。我们把它改成 ",[120,148,149],{},"\u003Cimg>"," 加 ",[120,152,153],{},"object-fit: cover","，顺手做了响应式尺寸，LCP 从 3.9 秒到 2.6 秒。如果非要用背景图，至少在 HTML 里加 preload，但维护成本更高，不如直接换标签。",[15,156,158],{"id":157},"先改图再谈别的","先改图，再谈别的",[11,160,161],{},"这三处的共同点是：改的是资源本身，不是加载策略。很多团队一上来就研究 CDN、预加载、HTTP\u002F3，方向反了。首图 1.8MB 摆在那儿，CDN 再快也得把这 1.8MB 传完。",[11,163,164],{},"顺序应该是：先把图减到该有的体积，再去掉阻碍发现的属性，最后才考虑链路优化。前两步能解决软件站七成的 LCP 问题，剩下三成才是服务端和协议的事。",[15,166,167],{"id":167},"一个我们常用的取舍",[11,169,170],{},"客户经常问，首图到底该放多大。我们的经验值是按容器渲染宽度的 2 倍出图，质量 75 到 80，WebP 优先。超过这个规格，画质提升用户看不出来，体积却线性上涨。遇到一定要放 3 倍图的设计需求，让设计师把纹理和高光做成渐变，比提高分辨率更省。",[11,172,173],{},"另一个容易忽略的点是首图的 alt 和尺寸属性。宽高写死能让浏览器提前占位，既避免 CLS，也让 LCP 记录更准。我们见过好几个站，首图没有 width 和 height，布局抖一下，LCP 时间跟着延后 200 毫秒。",[11,175,176],{},"最后提醒一句：改完图要清 CDN 缓存，再重新测。我们有一次改完等了两天没效果，最后发现是边缘节点还挂着旧的 1.8MB 版本。",{"title":66,"searchDepth":67,"depth":67,"links":178},[179,180,181,182,183],{"id":101,"depth":67,"text":102},{"id":114,"depth":67,"text":115},{"id":136,"depth":67,"text":137},{"id":157,"depth":67,"text":158},{"id":167,"depth":67,"text":167},"技术SEO","2025-09-06","审计 11 个软件公司官网，8 个的 LCP 元素是首屏产品截图。三个原因最常见：设计稿原图直出、首屏图被加懒加载、首图写在 CSS 背景里。改完平均从 4 秒压到 2.2 秒。",{},"\u002Fblog\u002Flcp-hero-image-bottleneck",{"title":93,"description":186},"blog\u002Flcp-hero-image-bottleneck",[192,193,194],"LCP","图片优化","首屏速度","ZiTxUQwWAqBk7wb8pbARG82nSvZ0shnpFHsE2jbZh_s",{"id":197,"title":198,"author":6,"body":199,"canonical":74,"category":279,"cover":74,"date":280,"description":281,"draft":78,"extension":79,"keywords":74,"meta":282,"navigation":81,"noindex":78,"ogImage":74,"path":283,"seo":284,"seoDescription":74,"seoTitle":74,"stem":285,"tags":286,"updated":74,"__hash__":289},"blog\u002Fblog\u002Fai-overview-citation-mechanics.md","AI Overviews 引用机制：被选中的为什么总是某一段",{"type":8,"value":200,"toc":272},[201,204,208,211,214,217,220,223,226,229,232,235,248,251,254,257,260,263,266,269],[11,202,203],{},"AI Overviews 引用你，靠的不是首页，是某一段。这是我们统计 6 个 B2B 软件客户、47 条 AI Overviews 引用之后的结论：只有 4 条指向首页，占 8.5%，其余全部落在对比页、文档页和说明页的具体段落上。",[15,205,207],{"id":206},"引用是按块挑的不是按页面挑","引用是按块挑的，不是按页面挑",[11,209,210],{},"AI Overviews 的抓取单位是内容块。它把页面切成分段、列表、表格，再拿每个块跟用户的问题做匹配，匹配上的块被拿去生成摘要，旁边挂一个链接。链接指向落地页，但决定权在那一块文字。",[11,212,213],{},"所以\"首页权重高\"这套经验在这里失效。首页写的是公司介绍、产品卖点、客户 logo，没有一段能独立回答\"这两家有什么区别\"。",[11,215,216],{},"2025 年 8 月我们复盘了 3 个站的引用明细，47 条里 19 条来自对比页，14 条来自文档页的单段说明，10 条来自带具体数字的案例段，剩下 4 条才是首页。",[15,218,219],{"id":219},"三种最容易被选中的块",[11,221,222],{},"第一种是一个段落答完一个问题的块。开头一句给结论，后面三句给理由和数字，整段 80 到 140 字，不跨小节。",[11,224,225],{},"第二种是边界清楚的表格。表格被引用的密度比散文高，因为引擎不需要重组语言，直接搬。一个做数据同步的客户把定价页从三段散文改成一张五行表，当月被引用从 2 次变成 9 次。",[11,227,228],{},"第三种是定义段。\"XX 是一种……\"这类句子，抓取成本最低。这段要放在 H2 下面的第一段，别埋到第三段去。",[15,230,231],{"id":231},"我们实际改了什么",[11,233,234],{},"拿一个客户举例。他们官网 40 个页面，AI Overviews 一个月引用 2 次。我们做了三件事：",[236,237,238,242,245],"ol",{},[239,240,241],"li",{},"12 个产品页，把 H2 下面第一段改成结论句，说清这个模块解决什么问题、省多少时间",[239,243,244],{},"8 个对比页各补一张表，列 5 个维度",[239,246,247],{},"删掉 9 段\"我们致力于……\"式的文字，这些段落不含任何事实",[11,249,250],{},"改完第 6 周，引用次数到 11 次；第 12 周 23 次。没有新增页面，没有改标题，没有动外链。",[15,252,253],{"id":253},"两个常见的错",[11,255,256],{},"第一个是把结论写得太软。\"我们提供多种方案\"这种句子，抓了也没用，它不构成事实。改成\"三种方案，按数据量分：10 万行以下用 A，10 万到 1000 万行用 B\"，就变成可引用的事实。",[11,258,259],{},"第二个是段落太长。超过 200 字的段落，切块时容易把两个主题粘在一起，结果哪个都不匹配。我们现在的标准是每段不超过 150 字，一段只说一件事。",[15,261,262],{"id":262},"一个反常识的判断",[11,264,265],{},"我们越来越觉得，页面数量对 AI Overviews 的引用影响很小。47 条引用里，有 31 条来自客户官网不到 60 个页面的站。页面多的那个客户有 400 多个页面，引用反而最少，因为它有 300 多页是同一套模板生成的地区页。",[11,267,268],{},"真影响引用的是\"可被独立搬走的句子\"有多少。我们内部管这个叫引用句存量：一篇内容里能单独拎出来还成立的事实句有几条。存量低于 3 条的页面，基本不会被挂。",[11,270,271],{},"这活儿不难，难在忍住不加形容词。你写的是给机器搬的句子，不是给评审看的文案。",{"title":66,"searchDepth":67,"depth":67,"links":273},[274,275,276,277,278],{"id":206,"depth":67,"text":207},{"id":219,"depth":67,"text":219},{"id":231,"depth":67,"text":231},{"id":253,"depth":67,"text":253},{"id":262,"depth":67,"text":262},"GEO","2025-09-08","统计 6 个 B2B 软件客户 47 条 AI Overviews 引用后，我们发现只有 4 条指向首页。AI 是按内容块挑引用，不是按页面挑。这条差异决定你该改哪里。",{},"\u002Fblog\u002Fai-overview-citation-mechanics",{"title":198,"description":281},"blog\u002Fai-overview-citation-mechanics",[279,287,288],"AI搜索","内容结构","W6ovHUEr2P4oPEGcF0f3dx2FIT7LMEDWxkWqsJcHdto",1794088112608]