[{"data":1,"prerenderedAt":343},["ShallowReactive",2],{"blog-fact-density-citation-test":3,"blog-prev-fact-density-citation-test":178,"blog-next-fact-density-citation-test":272},{"id":4,"title":5,"author":6,"body":7,"canonical":162,"category":163,"cover":162,"date":164,"description":165,"draft":166,"extension":167,"keywords":162,"meta":168,"navigation":169,"noindex":166,"ogImage":162,"path":170,"seo":171,"seoDescription":162,"seoTitle":162,"stem":172,"tags":173,"updated":162,"__hash__":177},"blog\u002Fblog\u002Ffact-density-citation-test.md","事实句密度不能太高：每千字放 5 条时 AI 引用率最高","元析智能",{"type":8,"value":9,"toc":152},"minimark",[10,14,18,21,24,27,30,33,36,92,95,99,102,105,109,112,115,118,121,124,127,130,146,149],[11,12,13],"p",{},"事实句不是越多越好。2025 年 9 月到 10 月，我们把 30 篇文章按每千字事实句数量分成三组，跑了 6 周引用监测。密度最高那组（每千字 8 条以上）引用率 11%，最低。中间那组（3 到 5 条）是 34%。",[15,16,17],"h2",{"id":17},"事实句的判定标准",[11,19,20],{},"先定义。事实句指能脱离原文单独成立、且带可核对信息的句子。三个条件：有主体、有具体量、不依赖上下文。",[11,22,23],{},"\"我们的同步延迟很低\"不是事实句。\n\"跨区域同步 P99 延迟 180 毫秒，测试环境为两地三可用区\"是。",[11,25,26],{},"一条合格的事实句，从文章里剪下来贴到别处，读者不需要回去看前文。这个标准很硬，用它能筛掉大部分自我表扬。",[15,28,29],{"id":29},"实验怎么做的",[11,31,32],{},"30 篇，同一个客户的博客，主题分散在 API、数据同步、权限管理三块。按密度分三组，每组 10 篇。每周三跑固定 40 个查询，记录 AI 回答里有没有出现这几篇的句子或链接，连续 6 周。",[11,34,35],{},"结果：",[37,38,39,55],"table",{},[40,41,42],"thead",{},[43,44,45,49,52],"tr",{},[46,47,48],"th",{},"组别",[46,50,51],{},"每千字事实句",[46,53,54],{},"6 周被引次数",[56,57,58,70,81],"tbody",{},[43,59,60,64,67],{},[61,62,63],"td",{},"低密度",[61,65,66],{},"0 到 2 条",[61,68,69],{},"19",[43,71,72,75,78],{},[61,73,74],{},"中密度",[61,76,77],{},"3 到 5 条",[61,79,80],{},"41",[43,82,83,86,89],{},[61,84,85],{},"高密度",[61,87,88],{},"8 条以上",[61,90,91],{},"14",[11,93,94],{},"高密度组为什么最差，我们猜了两个原因，第二个更可信。",[15,96,98],{"id":97},"原因一句子之间会打架","原因一：句子之间会打架",[11,100,101],{},"一篇文章堆 20 条事实，引擎挑哪条都合理，挑到的那条可能不是你想让它说的。我们观察到一次：某篇写权限体系的文章，被引用的是里面一句\"支持 200 人以下团队\"，结果用户搜\"企业级权限\"时看到这句，直接跳走了。",[11,103,104],{},"句子多了，你失去对\"被引用的那句\"的控制权。",[15,106,108],{"id":107},"原因二密度高了句子会变短","原因二：密度高了，句子会变短",[11,110,111],{},"这是更根本的问题。为了塞进更多事实，作者会把句子压缩成参数罗列，一条一句，句与句之间没有解释。这种文本对机器友好，对人是灾难。而且引擎需要上下文的支撑，孤立的参数反而不好判断可信度。",[11,113,114],{},"我们回头看了高密度组，有 7 篇是一个参数一张列表，读起来像说明书目录。这类内容更适合放在文档里，不适合做博客。",[15,116,117],{"id":117},"位置比数量重要",[11,119,120],{},"同样一条事实，放在段首和埋在段中，被引用的概率差很多。我们统计了中密度组，落在段首第一句的事实句被引用 26 次，落在段中的 15 次。",[11,122,123],{},"所以实际操作是：每篇文章先定 3 到 5 条关键事实，一条放首段，其余放在各个 H2 下面的第一段第一句。剩下的细节都往表格里塞，表格被整块搬走的概率比散句高。",[15,125,126],{"id":126},"我们的检查清单",[11,128,129],{},"写完一篇，过这四条：",[131,132,133,137,140,143],"ol",{},[134,135,136],"li",{},"能单独剪出来的句子有没有 3 条以上",[134,138,139],{},"每条有没有具体数字或明确条件",[134,141,142],{},"有没有一条放在首段",[134,144,145],{},"有没有超过 6 条",[11,147,148],{},"前三条不满足就补，第四条不满足就删。删除比补充难，但通常更有用。",[11,150,151],{},"密度这件事，做减法比做加法赚钱。",{"title":153,"searchDepth":154,"depth":154,"links":155},"",2,[156,157,158,159,160,161],{"id":17,"depth":154,"text":17},{"id":29,"depth":154,"text":29},{"id":97,"depth":154,"text":98},{"id":107,"depth":154,"text":108},{"id":117,"depth":154,"text":117},{"id":126,"depth":154,"text":126},null,"GEO","2025-10-18","30 篇文章按事实句密度分三组测了 6 周。每千字 8 条以上那组引用率最低，只有 11%，因为 AI 会挑走不重要的一句。每千字 3 到 5 条是甜区，引用率 34%。",false,"md",{},true,"\u002Fblog\u002Ffact-density-citation-test",{"title":5,"description":165},"blog\u002Ffact-density-citation-test",[163,174,175,176],"事实句","内容写作","AI引用","1Otq6MKao1iAZ9HGJwcjk1JWcg8mUnaNut2FQM-E264",{"id":179,"title":180,"author":6,"body":181,"canonical":162,"category":259,"cover":162,"date":260,"description":261,"draft":166,"extension":167,"keywords":162,"meta":262,"navigation":169,"noindex":166,"ogImage":162,"path":263,"seo":264,"seoDescription":162,"seoTitle":162,"stem":265,"tags":266,"updated":162,"__hash__":271},"blog\u002Fblog\u002Fpillar-cluster-blog-structure.md","支柱页加簇页，软件站的博客目录该怎么搭",{"type":8,"value":182,"toc":250},[183,186,189,192,195,198,201,204,207,210,213,217,220,223,226,229,232,235,238,241,244,247],[11,184,185],{},"博客目录按时间排是最省事的做法，也是最浪费的做法。我们给一家做安全审计的软件公司重排过 200 多篇文章，分成 6 个问题域，每个域 1 篇支柱页加 10 到 15 篇簇页。12 周后，那 6 篇支柱页里 4 篇进前 20，最好的一篇从第 40 名到第 9 名。",[15,187,188],{"id":188},"支柱页不是目录页",[11,190,191],{},"支柱页是一个问题域的入口，三千字左右，把这个域里的 20 到 30 个子问题都讲一遍，每个子问题给出结论，详细展开交给簇页。",[11,193,194],{},"它得自己是一篇能读的文章，不能只有一堆链接。2025 年 8 月我看过一个客户的“支柱页”，正文 400 字，50 个链接，那不是支柱页，那是导航菜单。",[15,196,197],{"id":197},"一个簇要有几篇才撑得起来",[11,199,200],{},"少于 5 篇簇页，别做支柱页，先老老实实写单篇。",[11,202,203],{},"我们的经验值是 8 到 15 篇。少于 8 篇，支柱页看起来像在硬凑一个主题；超过 15 篇，该拆成两个域了，不然内链会乱。",[15,205,206],{"id":206},"具体怎么搭",[11,208,209],{},"以“单点登录”这个域为例。支柱页叫“单点登录的 12 个工程问题”，簇页是“SSO 和 OAuth 的区别”“SAML 断言签名失败怎么排查”“多租户系统怎么做 SSO”这类，每篇两千字上下。",[11,211,212],{},"每篇簇页开头一句链回支柱页，结尾再链两个同域的其他簇页。支柱页正文里，每个子问题后面挂一个“展开看”的链接。",[15,214,216],{"id":215},"url-和目录结构","URL 和目录结构",[11,218,219],{},"我们建议用 \u002Fblog\u002Fsso\u002F 这样的路径放整个簇，而不是把 200 篇全塞在 \u002Fblog\u002F 下。路径带主题，内链和统计都好管。",[11,221,222],{},"改动 URL 要 301，并且一次只动一个簇。我们有过一次动全站路径的教训，恢复收录花了六周。",[15,224,225],{"id":225},"常见错误",[11,227,228],{},"支柱页写成纯目录；簇页之间完全不互链；一个主题硬塞进 30 篇，读者找不到重点；还有就是支柱页更新了，簇页还是两年前的内容，整组一起过期。",[15,230,231],{"id":231},"支柱页的更新节奏",[11,233,234],{},"支柱页每半年更新一次，主要是补新出现的子问题和换数据。更新时标题和 URL 都不动，只改正文和日期。",[11,236,237],{},"簇页写完之后如果发现支柱页缺这个子问题，先补支柱页，再发簇页。顺序反了，新簇页会变成孤儿页，只能靠内链慢慢被发现。",[15,239,240],{"id":240},"簇页之间怎么不写重复",[11,242,243],{},"每个簇页只回答一个问题，标题里只出现一个核心词。写之前把同簇的 10 个标题摆在一起看，如果两个标题能让读者分不清该点哪个，就合并。",[11,245,246],{},"我们在一个 12 篇的簇里干过这事，选题时看着都不同，写完发现 3 篇在讲同一件事，最后并成 1 篇加 301。",[11,248,249],{},"我们判断一个站的博客能不能起量，先看它有没有 3 个完整的簇。有 3 个，说明内容是真按问题域排的；只有一堆散篇，写再多也只是在填目录。",{"title":153,"searchDepth":154,"depth":154,"links":251},[252,253,254,255,256,257,258],{"id":188,"depth":154,"text":188},{"id":197,"depth":154,"text":197},{"id":206,"depth":154,"text":206},{"id":215,"depth":154,"text":216},{"id":225,"depth":154,"text":225},{"id":231,"depth":154,"text":231},{"id":240,"depth":154,"text":240},"内容运营","2025-10-17","博客目录不该按发布时间排，该按问题域排。我们给一家安全软件公司把 200 篇文章重组成 6 个簇，支柱页从第 40 名爬到第 9 名，簇页平均曝光涨了 2.3 倍。",{},"\u002Fblog\u002Fpillar-cluster-blog-structure",{"title":180,"description":261},"blog\u002Fpillar-cluster-blog-structure",[267,268,269,270],"内容架构","支柱页","主题簇","内链","mcRmw5GL8i4qV3fZd2Ux5rGkweO7dmreOveWmT5HQhs",{"id":273,"title":274,"author":6,"body":275,"canonical":162,"category":331,"cover":162,"date":332,"description":333,"draft":166,"extension":167,"keywords":162,"meta":334,"navigation":169,"noindex":166,"ogImage":162,"path":335,"seo":336,"seoDescription":162,"seoTitle":162,"stem":337,"tags":338,"updated":162,"__hash__":342},"blog\u002Fblog\u002Freciprocal-link-red-lines.md","互链换量可以做，站群那套东西碰都别碰",{"type":8,"value":276,"toc":326},[277,280,283,290,296,302,305,308,311,314,317,320,323],[11,278,279],{},"先说结论：互链本身没问题，它是正常商业合作的一部分。但一旦变成\"一群站互相对着链、链成一个网\"，性质就变了。今年 6 月我们拒过一个合作，对方手里 200 个站，要求 A 链 B、B 链 C、C 链 A，还附了一张名单让我们挑。我们看完名单只问了一句：这 200 个站里，有多少是你们自己注册的？对方没回答，合作就到此为止。",[15,281,282],{"id":282},"三条红线",[11,284,285,289],{},[286,287,288],"strong",{},"三角链和闭合链。"," 搜索引擎识别站点关联的能力比大多数老板想的强，注册信息、服务器 IP、页面模板、友链名单重叠，都能成为线索。闭合互链是最容易被识别的一类，别做。",[11,291,292,295],{},[286,293,294],{},"批量互换。"," 一次换十几条、几十条，基本可以判定为联盟操作。正常的商业互链，一年也就几条到十几条，而且是零散发生的。我们给自己的客户定过一条内部规则：单月新增互链不超过 2 条，一年累计不超过 10 条。超过这个量，动作本身就开始像操作了。",[11,297,298,301],{},[286,299,300],{},"跨主题硬换。"," 做工业软件的站和做母婴用品的站互换，除了让两边的主题信号变乱，没有任何收益。这类交换往往是对方主动找上门，说\"我们权重高，互换个首页\"，一律拒。",[15,303,304],{"id":304},"为什么三角链最危险",[11,306,307],{},"单条互链是两家的事，风险可控。三角链一旦形成网，任何一家出问题都会牵连整张网。2024 年我们接过一个善后：客户被一家合作站牵连，核心词掉了 9 位，恢复用了 4 个月。中间我们还发现，客户自己都没意识到那 6 条链接连成一圈，是对方给的一张\"合作站点\"表格造成的。客户当时觉得\"只是换个链接，能有多大事\"，恢复期的损失远超当初省下的推广费。",[11,309,310],{},"所以我们现在对这类合作的态度是：不接，不管对方报价多低。有些钱不赚，是因为后面要花更多钱去修。",[15,312,313],{"id":313},"换链的正确姿势",[11,315,316],{},"一年 5 到 8 条，主题相关，位置在首页或频道页都行，加 nofollow 也能接受。原因很简单：互链的真实价值是引流和品牌曝光，不是纯粹传权重。指望互链拉排名，本身就是把命交给别人。",[11,318,319],{},"还有一个判断标准很好用：对方要求你的首页挂 20 条以上友链，说明他的首页就是个链接集散地，这种链换了等于给自己找麻烦。",[11,321,322],{},"存量互链也要盘。我们把客户站点的友链导出，一条条查历史快照和主题，三个月盘一次，掉队的一次性撤掉。盘完通常能砍掉三到五成，排名没有变化，反而少了一个隐患。这件事不难，难的是坚持做，因为没人会因为\"没出事\"给你发奖金。",[11,324,325],{},"我宁愿客户一年只换 4 条友链，也不愿意看到一张\"互链联盟\"名单。少而真，比多而乱值钱。",{"title":153,"searchDepth":154,"depth":154,"links":327},[328,329,330],{"id":282,"depth":154,"text":282},{"id":304,"depth":154,"text":304},{"id":313,"depth":154,"text":313},"SEO","2025-10-19","今年 6 月我们拒了一个互链联盟的合作，对方手里 200 个站，要求三家互链。这篇讲互链的三条红线、为什么三角链最危险，以及软件公司换链的正确姿势。",{},"\u002Fblog\u002Freciprocal-link-red-lines",{"title":274,"description":333},"blog\u002Freciprocal-link-red-lines",[339,340,341],"互链","链接风险","站群","4Vkz4fFVJDpOBUXxe9HXx52liVKuRiou7ErqTfH6-Hs",1794088111551]