[{"data":1,"prerenderedAt":273},["ShallowReactive",2],{"blog-brand-search-zero-to-forty":3,"blog-prev-brand-search-zero-to-forty":78,"blog-next-brand-search-zero-to-forty":205},{"id":4,"title":5,"author":6,"body":7,"canonical":62,"category":63,"cover":62,"date":64,"description":65,"draft":66,"extension":67,"keywords":62,"meta":68,"navigation":69,"noindex":66,"ogImage":62,"path":70,"seo":71,"seoDescription":62,"seoTitle":62,"stem":72,"tags":73,"updated":62,"__hash__":77},"blog\u002Fblog\u002Fbrand-search-zero-to-forty.md","品牌词从查无此名到日均 40 次，我们做了五个月","元析智能",{"type":8,"value":9,"toc":55},"minimark",[10,14,19,22,25,28,31,34,37,40,43,46,49,52],[11,12,13],"p",{},"品牌搜索从无到有，靠的不是投放，是让\"别人提到你\"这件事持续发生。2025 年 9 月接手这个客户时，搜公司全称第一页只有 3 条结果：官网、两个目录页，百度指数查不到这个词，日均品牌搜索不到 5 次。",[15,16,18],"h2",{"id":17},"起点先承认基础是空的","起点：先承认基础是空的",[11,20,21],{},"这个客户做数据工具，产品不差，客户有 200 多家，但网上几乎找不到痕迹。官网博客从 2023 年之后没更新，关于页只有一段话，作者页没有。搜产品名出来的结果里，有两条是竞品的对比文章，把他写成了\"备选\"。",[11,23,24],{},"我们先做了一次盘点：品牌名在网上的写法有 7 种，包括英文名缩写、两个错别字、带不带\"科技\"后缀。这 7 种写法分散在不同平台，搜索引擎根本对不上是同一家公司。改写法这件事听着琐碎，但它是所有后续动作的前提，不统一的品牌名，做多少内容都是散的。",[11,26,27],{},"盘点还有个副产品：我们发现有两个目录页把客户的成立年份写错了，一个写 2015，一个写 2018，实际是 2016。这种错误在搜索结果里会直接削弱可信度，改起来却只要十分钟。",[15,29,30],{"id":30},"五个月的时间线",[11,32,33],{},"9 月做基础。把 7 种写法收敛成 1 种，全平台统一；重写关于页，补公司地址、团队人数、服务客户数；开作者页，写清楚 3 个署名人各自负责什么；把 8 个主要目录的资料补齐。",[11,35,36],{},"10 月到 11 月做内容。写了 4 篇客户案例，每篇带具体数字，比如某客户对账时间从 3 天缩到 4 小时。同时在知乎回答了 3 个行业问题，GitHub 上把他们开源的 SDK 的 README 重新写了一遍。",[11,38,39],{},"12 月做了一次行业媒体投稿，中了一篇。1 月把他们产品后台的脱敏数据整理成一份小型报告，发在官网上，被两个行业公众号转载。",[15,41,42],{"id":42},"结果和能复用的判断",[11,44,45],{},"五个月后的数据：日均品牌搜索从不到 5 次到 40 次左右；GSC 里品牌词月点击从 60 涨到 220；搜公司名第一页有 7 条自有或第三方内容。",[11,47,48],{},"这五个月我们没买量、没刷指数、没买榜单。唯一花出去的钱是一篇媒体稿的编辑费。",[11,50,51],{},"有个细节值得说：前两个月数据几乎没动，客户在 11 月问过一次\"是不是没用\"。转机出现在 12 月，先是知乎的一个回答开始有排名，接着媒体的稿子被收录，品牌词搜索才明显起来。这类事有延迟，前面几个月的动作是给后面铺路。",[11,53,54],{},"品牌搜索是\"被别人看见\"的副产物，买不到。能买到的只有曝光位，但用户记住你，靠的是他在不同地方反复看到同一家公司，而且每次看到的内容都对得上。",{"title":56,"searchDepth":57,"depth":57,"links":58},"",2,[59,60,61],{"id":17,"depth":57,"text":18},{"id":30,"depth":57,"text":30},{"id":42,"depth":57,"text":42},null,"SEO","2026-01-14","一个 B2B 数据工具，2025 年 9 月开始补品牌信号，此前搜公司名只有 3 条结果。五个月后日均品牌搜索 40 次，第一页有 7 条自有或第三方内容。这篇按时间线复盘每一步。",false,"md",{},true,"\u002Fblog\u002Fbrand-search-zero-to-forty",{"title":5,"description":65},"blog\u002Fbrand-search-zero-to-forty",[74,75,76],"品牌搜索","复盘","B2B软件","il16jfNsUPP5IxDHSDED1_fU3h1jkAQJBAwtev90APQ",{"id":79,"title":80,"author":6,"body":81,"canonical":62,"category":193,"cover":62,"date":194,"description":195,"draft":66,"extension":67,"keywords":62,"meta":196,"navigation":69,"noindex":66,"ogImage":62,"path":197,"seo":198,"seoDescription":62,"seoTitle":62,"stem":199,"tags":200,"updated":62,"__hash__":204},"blog\u002Fblog\u002Fcontent-chunking-for-ai.md","内容分块怎么做：AI 按块抓取，先弄清你的块边界",{"type":8,"value":82,"toc":186},[83,86,89,92,95,98,101,104,108,111,114,121,127,133,136,139,142,161,165,168,171,174,177,180,183],[11,84,85],{},"AI 抓内容不是整页吞，是切块。2026 年 1 月我们把 40 个客户页面手工切了一遍，按语义切成\"能独立回答一个问题\"的单元，结果 62% 的块跨了主题。这就是很多页面明明写得好却拿不到引用的原因。",[15,87,88],{"id":88},"块是怎么切出来的",[11,90,91],{},"三种切法，引擎会混用。",[11,93,94],{},"第一种按标题切。一个 H2 到下一个 H2 之间算一块，这是最常用也最符合直觉的。",[11,96,97],{},"第二种按长度切。网页文本太长时，会按固定 token 数开窗，可能一刀切在句子中间。",[11,99,100],{},"第三种按语义相似度切。相邻句子讲同一件事就归一块，话题跳了就在那里断开。",[11,102,103],{},"三种混着来，意味着你的页面结构越乱，切出来的块越不可控。",[15,105,107],{"id":106},"_62-跨主题是怎么数出来的","62% 跨主题是怎么数出来的",[11,109,110],{},"方法很笨：40 个页面，逐段读，把\"这一段讲什么\"写成一句话，然后看相邻段落能不能归进同一块。归不进去就是跨主题。",[11,112,113],{},"跨主题的典型形态有三种：",[11,115,116,120],{},[117,118,119],"strong",{},"一个 H2 下面讲两件事。"," 比如\"性能与安全\"下面，先讲延迟再讲加密。标题已经混了，块必然混。",[11,122,123,126],{},[117,124,125],{},"段落中间换主语。"," 前半段讲产品功能，后半段突然讲客户案例。",[11,128,129,132],{},[117,130,131],{},"表格和正文混排。"," 表格前后没有一句说明这张表在回答什么，引擎拿到表格不知道为什么看它。",[15,134,135],{"id":135},"怎么让边界清楚",[11,137,138],{},"一条规则：一个 H2 覆盖一个完整问题，H2 下面第一段回答它，后面几段展开。",[11,140,141],{},"具体到操作：",[143,144,145,149,152,155,158],"ul",{},[146,147,148],"li",{},"H2 标题写成问题或判断，别写成名词。写\"跨区域同步的延迟是多少\"，不写\"性能表现\"。",[146,150,151],{},"每段只讲一件事，段首句是这句话的结论。",[146,153,154],{},"段落长度 150 到 400 字。太短没信息，太长一定混主题。",[146,156,157],{},"表格前面加一句\"这张表对比了 X 和 Y 在 5 个维度的差异\"，让表格有自己的上下文。",[146,159,160],{},"别用加粗当小标题。视觉上是标题，结构上还是段落，切块时不会被识别为边界。",[15,162,164],{"id":163},"一个-before-和-after","一个 before 和 after",[11,166,167],{},"改之前，一个定价页的结构是：H2\"灵活定价\"，下面一段讲理念，一段讲三个档位，一张表，一段讲企业版，一段讲 FAQ 链接。整页被切成 2 块，两块都说不清主题。",[11,169,170],{},"改之后：H2\"三档定价分别适合什么规模\"，一段结论加一张表；H2\"企业版怎么定制\"，一段说明；H2\"常见计费问题\"，5 条问答。同一篇文字，切成 4 块，每块都能独立回答一个问题。",[11,172,173],{},"改完 5 周，这页在 AI 回答里被挂的次数从 1 次到 6 次。",[15,175,176],{"id":176},"块多大合适",[11,178,179],{},"我们现在的标准是 150 到 400 字。低于 150 字，块里没有足够信息支撑一个判断；高于 400 字，大部分会跨主题。",[11,181,182],{},"这个区间不是定理，是我们拿 40 个页面手切之后定的经验值。你自己数一遍就知道，超过 400 字的段落，八成能拆成两件事。",[11,184,185],{},"写完一段，问一句：这段能不能单独被拿走回答一个问题？能，就是好块。",{"title":56,"searchDepth":57,"depth":57,"links":187},[188,189,190,191,192],{"id":88,"depth":57,"text":88},{"id":106,"depth":57,"text":107},{"id":135,"depth":57,"text":135},{"id":163,"depth":57,"text":164},{"id":176,"depth":57,"text":176},"GEO","2026-01-13","手切 40 个页面之后发现，62% 的内容块跨了主题。AI 抓到的块主题混杂，就不敢引用。块边界由 H2 决定，一段不超过 400 字。",{},"\u002Fblog\u002Fcontent-chunking-for-ai",{"title":80,"description":195},"blog\u002Fcontent-chunking-for-ai",[201,193,202,203],"内容分块","内容结构","AI抓取","TRZJ0p5qakPwinHdwyJyA5xMKI_zi77NpnJk0zK-NNQ",{"id":206,"title":207,"author":6,"body":208,"canonical":62,"category":261,"cover":62,"date":262,"description":263,"draft":66,"extension":67,"keywords":62,"meta":264,"navigation":69,"noindex":66,"ogImage":62,"path":265,"seo":266,"seoDescription":62,"seoTitle":62,"stem":267,"tags":268,"updated":62,"__hash__":272},"blog\u002Fblog\u002Fsecurity-blog-vulnerability-analysis.md","安全厂商的技术博客，别写成产品软文",{"type":8,"value":209,"toc":255},[210,213,216,219,222,225,228,231,234,237,240,243,246,249,252],[11,211,212],{},"安全公司的技术博客，最常见的失败是把漏洞分析写成产品软文。开头一段漏洞背景，中间一段“我们的产品如何检测”，结尾一段“欢迎试用”。这种文章在安全圈传不开，因为读者要的是攻击细节，不是你的功能。",[15,214,215],{"id":215},"一个能传开的写法",[11,217,218],{},"2025 年 12 月我们和一个做 WAF 的客户复盘了他们阅读量最高的 5 篇文章，共同结构是：漏洞怎么被发现的、利用链怎么走、为什么现有防护会漏、检测规则长什么样、最后才提一句产品能力。",[11,220,221],{},"第五部分占比不到 10%，前四部分占 90%。这个比例很关键。读者看到前四部分觉得你有真东西，第五部分他才会看。",[15,223,224],{"id":224},"具体写什么",[11,226,227],{},"第一，带 PoC 或者复现步骤。能公开的细节尽量公开，不能公开的写清“出于负责任披露暂不公开”并给出时间线。安全社区对披露流程很敏感，写清楚反而加分。",[11,229,230],{},"第二，写检测规则。给一条 Sigma 规则、一段 YARA、或者一个 Suricata 签名，这类内容会被大量转载和引用，外链自然来。",[11,232,233],{},"第三，写失败经验。我们有个客户写过一篇“我们漏掉的一个绕过手法”，讲自家规则为什么没挡住。这篇文章带来的正面反馈比十篇成功案例都多，因为它可信。",[15,235,236],{"id":236},"带来的流量长什么样",[11,238,239],{},"漏洞分析类内容的搜索流量不大，长尾很散，但有两个特点：来的都是同行和从业者，以及被引用的周期长。一篇 2024 年的分析，到 2026 年每月还有几十次访问。",[11,241,242],{},"对企业业务真正有用的地方在信任转化。我们追踪过一个客户的转化路径，从漏洞分析页进入的访客，申请 demo 的比例是首页访客的 2.4 倍。样本不大，但方向清楚。",[11,244,245],{},"排版也影响传播。时间线用有序列表，命令和规则用代码块，受影响版本单独一行加粗。这看起来是小事，但转载的人经常直接复制你的排版，格式乱了，传播效果就打折。",[15,247,248],{"id":248},"一条内容纪律",[11,250,251],{},"别追热点追到没有自己的分析。行业里出了大漏洞，所有安全厂商都在写，你写得比别人晚、比别人浅，就是纯陪跑。我们的做法是：只写我们有一手观察的漏洞，其他热点用一条短讯带过，把精力留给能写深的题目。",[11,253,254],{},"安全博客的价值不在更新频率，在不可替代性。一个月一篇有独家细节的分析，胜过十篇转述。",{"title":56,"searchDepth":57,"depth":57,"links":256},[257,258,259,260],{"id":215,"depth":57,"text":215},{"id":224,"depth":57,"text":224},{"id":236,"depth":57,"text":236},{"id":248,"depth":57,"text":248},"内容运营","2026-01-15","漏洞分析写得好能带来客户，写成“我们的产品可以防”就没人愿意看。我们复盘了 3 个安全博客两年里阅读量最高的文章，找出一个可以复用的内容结构和比例。",{},"\u002Fblog\u002Fsecurity-blog-vulnerability-analysis",{"title":207,"description":263},"blog\u002Fsecurity-blog-vulnerability-analysis",[269,270,271],"安全博客","漏洞分析","技术内容","0Qnrkx8_Zj7woAGzGGsHCmVZP6TRiCvnxDDxEhupHuw",1794088109214]