[{"data":1,"prerenderedAt":436},["ShallowReactive",2],{"blog-question-words-support-tickets":3,"blog-prev-question-words-support-tickets":108,"blog-next-question-words-support-tickets":299},{"id":4,"title":5,"author":6,"body":7,"canonical":92,"category":93,"cover":92,"date":94,"description":95,"draft":96,"extension":97,"keywords":92,"meta":98,"navigation":99,"noindex":96,"ogImage":92,"path":100,"seo":101,"seoDescription":92,"seoTitle":92,"stem":102,"tags":103,"updated":92,"__hash__":107},"blog\u002Fblog\u002Fquestion-words-support-tickets.md","问题词从客服工单里挖，比关键词工具靠谱","元析智能",{"type":8,"value":9,"toc":81},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78],[11,12,13],"p",{},"最准的问题词表不在关键词工具里，在客服工单里。用户遇到问题时会同时做两件事：找客服，和去搜索引擎里打一句话。这两句话几乎是一样的。",[15,16,17],"h2",{"id":17},"工单里能挖出三类词",[11,19,20],{},"第一类是报错原文，比如“连接被拒绝”“证书过期”。第二类是功能叫法，用户管它叫“同步”，你们内部叫“数据集成”，搜索量差十倍。第三类是操作步骤，比如“怎么批量导入”“怎么撤销删除”。",[11,22,23],{},"这三类词工具一般挖不出来，因为量太小，被工具当噪音过滤了。",[15,25,26],{"id":26},"我们做的一次抽取",[11,28,29],{},"2025 年 11 月，我们让一个客户导出近 6 个月共 1200 条工单标题，按动词聚成 8 组：配置、导入、导出、报错、权限、计费、升级、对接。",[11,31,32],{},"人工过一遍抽出 87 个短语，再去搜索后台对照。其中 31 个在后台有稳定曝光，但工具显示月搜不到 50。",[15,34,35],{"id":35},"客户用词和你们用词不是一回事",[11,37,38],{},"这一步最容易漏。客户说“证书”，你们的文档写“TLS 凭证”；客户说“多账号”，文档写“多租户”。搜客户用词的人，永远找不到你们的文档。",[11,40,41],{},"我们的做法是：正文里两个词都出现一次，标题用客户的说法，文档内部继续用规范说法。",[15,43,44],{"id":44},"这些词该写成什么页面",[11,46,47],{},"问题词大多该写文档页、排错页、FAQ，而不是博客文章。博客是给还在了解的人看的，问题词是给已经在用的人看的。",[11,49,50],{},"一个排错页做得好，能带来续费和口碑，虽然它看起来不像内容营销。",[15,52,53],{"id":53},"每月半小时的流程",[11,55,56],{},"客服每月导一次工单标题，我们花 30 分钟过一遍，新的进长尾池，重复的并进已有页面的问题列表。",[11,58,59],{},"这个动作我们从 2025 年 8 月起固定下来，四个月里给客户的文档页补了 60 多个问题句。",[15,61,62],{"id":62},"挖出来的词别只做内容",[11,64,65],{},"工单里的问题词，一半以上在提示产品本身的缺口。一个问题被问 50 次，说明界面或文档没讲清楚，这时候该改产品文案，不是只写文章。",[11,67,68],{},"我们 2025 年 10 月把一批高频问题反馈给客户的产品团队，他们改了三个提示文案，同类工单一个月下降了 30%。内容和技术在这里是同一条链。",[15,70,71],{"id":71},"一个别做的事",[11,73,74],{},"不要把工单原文直接贴到页面上。用户的问题带着账号、订单、内部名称，脱敏要做干净，能改写成通用问句就改。",[11,76,77],{},"我们见过一个客户把工单标题原样做成 FAQ，里面带着客户公司名，后来被对方发现，关系闹得很僵。",[11,79,80],{},"工单是最便宜的关键词研究。不花钱，不依赖工具，还自带真实语境。",{"title":82,"searchDepth":83,"depth":83,"links":84},"",2,[85,86,87,88,89,90,91],{"id":17,"depth":83,"text":17},{"id":26,"depth":83,"text":26},{"id":35,"depth":83,"text":35},{"id":44,"depth":83,"text":44},{"id":53,"depth":83,"text":53},{"id":62,"depth":83,"text":62},{"id":71,"depth":83,"text":71},null,"SEO","2026-01-02","最准的词表不在工具里，在工单里。2025 年 11 月我们导了 1200 条工单，抽出 87 个真实搜索词，其中 31 个月搜不到 50，但搜索后台有稳定曝光。",false,"md",{},true,"\u002Fblog\u002Fquestion-words-support-tickets",{"title":5,"description":95},"blog\u002Fquestion-words-support-tickets",[104,105,106],"问题词","关键词研究","客服工单","-XLIeTJrYpSKClW7h6O3rJ4fEAnuBdHnb7_h1EqqDK0",{"id":109,"title":110,"author":6,"body":111,"canonical":92,"category":288,"cover":92,"date":289,"description":290,"draft":96,"extension":97,"keywords":92,"meta":291,"navigation":99,"noindex":96,"ogImage":92,"path":292,"seo":293,"seoDescription":92,"seoTitle":92,"stem":294,"tags":295,"updated":92,"__hash__":298},"blog\u002Fblog\u002Fcache-control-misconfig.md","静态资源缓存头配错的四种样子，我们逐个拆开",{"type":8,"value":112,"toc":279},[113,116,120,135,138,142,145,148,152,162,169,173,176,179,183,186,189,192,195,236,242,245,248,272,275],[11,114,115],{},"缓存头配错，表现不是页面打不开，而是\"改了没生效\"和\"每次都重新下载\"。今年 1 月我们给一个软件站做资源审计，四种错误全占了，最离谱的是 3.4MB 的静态资源每周产生 12 万次 304 请求。",[15,117,119],{"id":118},"错误一html-和带-hash-的资源用同一套头","错误一：HTML 和带 hash 的资源用同一套头",[11,121,122,126,127,130,131,134],{},[123,124,125],"code",{},"max-age=0, must-revalidate"," 配在 HTML 上是对的，配在 ",[123,128,129],{},"main.a1b2c3.js"," 上就是纯浪费。带 hash 的文件内容一变名字就变，可以直接 ",[123,132,133],{},"max-age=31536000, immutable","。",[11,136,137],{},"这个站两种资源共用一套配置，结果每次访问都要对 40 多个静态文件做条件请求，移动端多花 300 毫秒。",[15,139,141],{"id":140},"错误二改了文件没改-hash","错误二：改了文件没改 hash",[11,143,144],{},"反向的坑。文件名没变、内容变了、头又是长缓存，用户三个月看不到新版本。我们见过一个站改了 CSS 但没改 hash，客服被投诉两周\"按钮错位\"。",[11,146,147],{},"查法：对比 CDN 上的文件名和构建产物里的 hash。改法是把构建的 hash 和内容绑定做好，别用时间戳糊弄，时间戳一秒内构建两次就会撞。",[15,149,151],{"id":150},"错误三cdn-上用了-private-或-no-store","错误三：CDN 上用了 private 或 no-store",[11,153,154,155,158,159,161],{},"有些框架默认给所有响应加 ",[123,156,157],{},"no-store","，CDN 一看就不缓存，等于白买。这个站的营销页 HTML 就是 ",[123,160,157],{},"，回源率 100%，TTFB 高得离谱。",[11,163,164,165,168],{},"改成 ",[123,166,167],{},"public, max-age=600"," 之后，回源请求从每天 6 万降到 8 千。这一步没改任何代码，只改了响应头。",[15,170,172],{"id":171},"错误四多台机器各算-etag","错误四：多台机器各算 ETag",[11,174,175],{},"ETag 默认基于文件 inode 和修改时间生成。多台机器部署同一个文件，算出来的 ETag 各不相同，用户在不同节点间切换就会反复全量下载。",[11,177,178],{},"改法是在构建时统一生成基于内容哈希的 ETag，或者干脆去掉 ETag，靠 Cache-Control 和文件名版本控制。",[15,180,182],{"id":181},"一个附带问题service-worker-和缓存头打架","一个附带问题：Service Worker 和缓存头打架",[11,184,185],{},"有些软件站为了做离线可用或者推送，注册了 Service Worker。它有自己的缓存层，会绕过浏览器的 HTTP 缓存策略。这时候你把 Cache-Control 改对了，用户还是看到旧版本，因为 SW 把旧资源扣在手里。",[11,187,188],{},"查法是 DevTools 的 Application 面板里看 Service Workers 和 Cache Storage，改完记得版本号加一。我们遇到过一个站，SW 缓存了三个月前的 JS，排查了两天才想到这一层。",[15,190,191],{"id":191},"怎么验证改对了",[11,193,194],{},"改完头别只看代码，用 curl 直接看线上响应：",[196,197,201],"pre",{"className":198,"code":199,"language":200,"meta":82,"style":82},"language-bash shiki shiki-themes github-light github-dark","curl -sI https:\u002F\u002Fexample.com\u002Fmain.a1b2c3.js | grep -i -E \"cache-control|etag|age\"\n","bash",[123,202,203],{"__ignoreMap":82},[204,205,208,212,216,220,224,227,230,233],"span",{"class":206,"line":207},"line",1,[204,209,211],{"class":210},"sScJk","curl",[204,213,215],{"class":214},"sj4cs"," -sI",[204,217,219],{"class":218},"sZZnC"," https:\u002F\u002Fexample.com\u002Fmain.a1b2c3.js",[204,221,223],{"class":222},"szBVR"," |",[204,225,226],{"class":210}," grep",[204,228,229],{"class":214}," -i",[204,231,232],{"class":214}," -E",[204,234,235],{"class":218}," \"cache-control|etag|age\"\n",[11,237,238,241],{},[123,239,240],{},"age"," 这个头很有用，它是 CDN 缓存的时间戳，能直接看出命中了没有。命中时 age 会递增，回源时是 0。",[15,243,244],{"id":244},"十分钟检查清单",[11,246,247],{},"我们给客户的顺序是三件事：",[249,250,251,262,269],"ol",{},[252,253,254,255,258,259],"li",{},"打开首页，看 HTML 的 ",[123,256,257],{},"Cache-Control"," 是不是 ",[123,260,261],{},"public",[252,263,264,265,268],{},"看带 hash 的 JS 和 CSS 是不是 ",[123,266,267],{},"immutable"," 长缓存",[252,270,271],{},"去 CDN 后台看缓存命中率，低于 80% 就有问题",[11,273,274],{},"三项查完十分钟，比读代码见效快。缓存这类问题有个特点：配置错误一次，之后每个用户都在承担代价，而且没人投诉，因为大家以为\"网站就这样\"。",[276,277,278],"style",{},"html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .szBVR, html code.shiki .szBVR{--shiki-default:#D73A49;--shiki-dark:#F97583}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":82,"searchDepth":83,"depth":83,"links":280},[281,282,283,284,285,286,287],{"id":118,"depth":83,"text":119},{"id":140,"depth":83,"text":141},{"id":150,"depth":83,"text":151},{"id":171,"depth":83,"text":172},{"id":181,"depth":83,"text":182},{"id":191,"depth":83,"text":191},{"id":244,"depth":83,"text":244},"技术SEO","2026-01-01","一个软件站的资源审计，四种缓存头错误全占了：HTML 和 hash 资源共用一套头、改文件没改 hash、CDN 上用 no-store、多机 ETag 不一致。附十分钟能跑完的检查清单。",{},"\u002Fblog\u002Fcache-control-misconfig",{"title":110,"description":290},"blog\u002Fcache-control-misconfig",[257,296,297],"HTTP缓存","静态资源","bxf_OiUT5ysR8ewmkR365YQa8SrFBzLHzRBxnsnjmPk",{"id":300,"title":301,"author":6,"body":302,"canonical":92,"category":423,"cover":92,"date":424,"description":425,"draft":96,"extension":97,"keywords":92,"meta":426,"navigation":99,"noindex":96,"ogImage":92,"path":427,"seo":428,"seoDescription":92,"seoTitle":92,"stem":429,"tags":430,"updated":92,"__hash__":435},"blog\u002Fblog\u002Fai-citation-rate-denominator.md","AI 引用率怎么算：分母选错，同一个团队能得出两个结论",{"type":8,"value":303,"toc":415},[304,307,311,318,324,330,333,336,339,342,345,348,351,363,366,369,372,375,378,381,384,387,397,400,403,406,409,412],[11,305,306],{},"AI 引用率这个数，八成算错在分母。同一批数据，用品牌词做分母能算出 23%，换成品类词只剩 9%。差 14 个百分点，足够让一个团队做错半年的决定。",[15,308,310],{"id":309},"三种分母三个结论","三种分母，三个结论",[11,312,313,317],{},[314,315,316],"strong",{},"分母是品牌词。"," 用户搜的就是你，AI 回答里出现你的概率自然高。测出来通常 20% 以上，好看，没用。这个数只说明你还没被 AI 忘掉。",[11,319,320,323],{},[314,321,322],{},"分母是品类词。"," 用户搜\"数据同步工具\"，没指定谁。测出来通常 5% 到 15%。这才是获客相关的口径。",[11,325,326,329],{},[314,327,328],{},"分母是全量查询。"," 把你后台所有关键词都算进去，包括那些你根本不该出现的词。测出来接近 0，除了打击士气没别的用。",[11,331,332],{},"我们给客户的标准是第二种：品类词加对比词，固定 60 个。",[15,334,335],{"id":335},"我们的固定口径",[11,337,338],{},"60 个查询，四类各 15 个：品类词、对比词、场景词、品牌加场景。",[11,340,341],{},"每月同一批、同一时间、同样的引擎列表。不换词，不加减。听着死板，但只有固定才能比。",[11,343,344],{},"有个客户中途要求加 20 个新词，说新品类要测。我们单开一张表记，不混进主口径。混进去之后环比就没意义了。",[15,346,347],{"id":347},"分子怎么算",[11,349,350],{},"三种出现方式，权重不同：",[352,353,354,357,360],"ul",{},[252,355,356],{},"品牌名或产品名出现，计 1 分",[252,358,359],{},"出现官网链接，计 2 分",[252,361,362],{},"出现在首位推荐或作为主答案，计 3 分",[11,364,365],{},"单条回答取最高分，不叠加。60 个查询跑 4 个引擎，满分 720 分。",[11,367,368],{},"这不是精确科学，是把\"出现了\"和\"被推荐了\"分开。我们试过只记二元（出现\u002F没出现），结果一个客户的分数涨了 30%，实际全是\"也有人用\"这类备选位，询盘没动。",[15,370,371],{"id":371},"一个被虚高的例子",[11,373,374],{},"2025 年 12 月，一个客户自己算的引用率是 23%，拿来跟我们说做得不错。",[11,376,377],{},"我们按品类词重算，9%。差异来自哪儿？他们的品牌词占了查询池的 60%。也就是说，他们一直在测\"AI 认不认识我\"，而不是\"AI 会不会推荐我\"。",[11,379,380],{},"重算之后，发现真正的问题是他们在对比类查询里几乎不出现。改的方向从\"多发品牌新闻\"变成了\"补对比页和第三方评测\"。",[15,382,383],{"id":383},"给老板怎么讲",[11,385,386],{},"别用一个数字。给两个：",[11,388,389,392,393,396],{},[314,390,391],{},"覆盖率","，60 个查询里有多少条回答提到你，反映存在感。\n",[314,394,395],{},"首位率","，提到你的那些里，多少在首位，反映推荐强度。",[11,398,399],{},"覆盖率 40%、首位率 10%，说明大家知道你但没人首选你。覆盖率 12%、首位率 60%，说明小众但精准。",[11,401,402],{},"两个数一起看，才不会互相骗。",[15,404,405],{"id":405},"口径要写进报告首页",[11,407,408],{},"我们现在给客户的报告第一页固定三行：查询池是哪 60 个、引擎是哪 4 个、每月的采集日期。谁都能照着复现。",[11,410,411],{},"这看着是形式主义，实际能省很多吵架。有次客户换了市场负责人，新来的第一句话是\"这个数怎么算的\"。翻到第一页，三行字解释清楚，会议十分钟结束。",[11,413,414],{},"反过来，口径不写的报告，数字一变就会被怀疑在挑数据。GEO 这行现在没有第三方审计，可信度只能靠口径透明撑着。",{"title":82,"searchDepth":83,"depth":83,"links":416},[417,418,419,420,421,422],{"id":309,"depth":83,"text":310},{"id":335,"depth":83,"text":335},{"id":347,"depth":83,"text":347},{"id":371,"depth":83,"text":371},{"id":383,"depth":83,"text":383},{"id":405,"depth":83,"text":405},"工具评测","2026-01-03","同一份数据，用品牌词做分母算出 23%，换成品类词只有 9%。分母决定结论。我们固定 60 个品类词和对比词，每月同一批，口径写进报告。",{},"\u002Fblog\u002Fai-citation-rate-denominator",{"title":301,"description":425},"blog\u002Fai-citation-rate-denominator",[431,432,433,434],"AI引用率","监测方法","GEO","数据口径","RE-y7EH5R6F86YHzfu_UR0sJCJhJUPLhkgKVRm1Ttz8",1794088109549]