[{"data":1,"prerenderedAt":356},["ShallowReactive",2],{"blog-pillar-cluster-blog-structure":3,"blog-prev-pillar-cluster-blog-structure":107,"blog-next-pillar-cluster-blog-structure":191},{"id":4,"title":5,"author":6,"body":7,"canonical":90,"category":91,"cover":90,"date":92,"description":93,"draft":94,"extension":95,"keywords":90,"meta":96,"navigation":97,"noindex":94,"ogImage":90,"path":98,"seo":99,"seoDescription":90,"seoTitle":90,"stem":100,"tags":101,"updated":90,"__hash__":106},"blog\u002Fblog\u002Fpillar-cluster-blog-structure.md","支柱页加簇页，软件站的博客目录该怎么搭","元析智能",{"type":8,"value":9,"toc":79},"minimark",[10,14,18,21,24,27,30,33,36,39,42,46,49,52,55,58,61,64,67,70,73,76],[11,12,13],"p",{},"博客目录按时间排是最省事的做法，也是最浪费的做法。我们给一家做安全审计的软件公司重排过 200 多篇文章，分成 6 个问题域，每个域 1 篇支柱页加 10 到 15 篇簇页。12 周后，那 6 篇支柱页里 4 篇进前 20，最好的一篇从第 40 名到第 9 名。",[15,16,17],"h2",{"id":17},"支柱页不是目录页",[11,19,20],{},"支柱页是一个问题域的入口，三千字左右，把这个域里的 20 到 30 个子问题都讲一遍，每个子问题给出结论，详细展开交给簇页。",[11,22,23],{},"它得自己是一篇能读的文章，不能只有一堆链接。2025 年 8 月我看过一个客户的“支柱页”，正文 400 字，50 个链接，那不是支柱页，那是导航菜单。",[15,25,26],{"id":26},"一个簇要有几篇才撑得起来",[11,28,29],{},"少于 5 篇簇页，别做支柱页，先老老实实写单篇。",[11,31,32],{},"我们的经验值是 8 到 15 篇。少于 8 篇，支柱页看起来像在硬凑一个主题；超过 15 篇，该拆成两个域了，不然内链会乱。",[15,34,35],{"id":35},"具体怎么搭",[11,37,38],{},"以“单点登录”这个域为例。支柱页叫“单点登录的 12 个工程问题”，簇页是“SSO 和 OAuth 的区别”“SAML 断言签名失败怎么排查”“多租户系统怎么做 SSO”这类，每篇两千字上下。",[11,40,41],{},"每篇簇页开头一句链回支柱页，结尾再链两个同域的其他簇页。支柱页正文里，每个子问题后面挂一个“展开看”的链接。",[15,43,45],{"id":44},"url-和目录结构","URL 和目录结构",[11,47,48],{},"我们建议用 \u002Fblog\u002Fsso\u002F 这样的路径放整个簇，而不是把 200 篇全塞在 \u002Fblog\u002F 下。路径带主题，内链和统计都好管。",[11,50,51],{},"改动 URL 要 301，并且一次只动一个簇。我们有过一次动全站路径的教训，恢复收录花了六周。",[15,53,54],{"id":54},"常见错误",[11,56,57],{},"支柱页写成纯目录；簇页之间完全不互链；一个主题硬塞进 30 篇，读者找不到重点；还有就是支柱页更新了，簇页还是两年前的内容，整组一起过期。",[15,59,60],{"id":60},"支柱页的更新节奏",[11,62,63],{},"支柱页每半年更新一次，主要是补新出现的子问题和换数据。更新时标题和 URL 都不动，只改正文和日期。",[11,65,66],{},"簇页写完之后如果发现支柱页缺这个子问题，先补支柱页，再发簇页。顺序反了，新簇页会变成孤儿页，只能靠内链慢慢被发现。",[15,68,69],{"id":69},"簇页之间怎么不写重复",[11,71,72],{},"每个簇页只回答一个问题，标题里只出现一个核心词。写之前把同簇的 10 个标题摆在一起看，如果两个标题能让读者分不清该点哪个，就合并。",[11,74,75],{},"我们在一个 12 篇的簇里干过这事，选题时看着都不同，写完发现 3 篇在讲同一件事，最后并成 1 篇加 301。",[11,77,78],{},"我们判断一个站的博客能不能起量，先看它有没有 3 个完整的簇。有 3 个，说明内容是真按问题域排的；只有一堆散篇，写再多也只是在填目录。",{"title":80,"searchDepth":81,"depth":81,"links":82},"",2,[83,84,85,86,87,88,89],{"id":17,"depth":81,"text":17},{"id":26,"depth":81,"text":26},{"id":35,"depth":81,"text":35},{"id":44,"depth":81,"text":45},{"id":54,"depth":81,"text":54},{"id":60,"depth":81,"text":60},{"id":69,"depth":81,"text":69},null,"内容运营","2025-10-17","博客目录不该按发布时间排，该按问题域排。我们给一家安全软件公司把 200 篇文章重组成 6 个簇，支柱页从第 40 名爬到第 9 名，簇页平均曝光涨了 2.3 倍。",false,"md",{},true,"\u002Fblog\u002Fpillar-cluster-blog-structure",{"title":5,"description":93},"blog\u002Fpillar-cluster-blog-structure",[102,103,104,105],"内容架构","支柱页","主题簇","内链","mcRmw5GL8i4qV3fZd2Ux5rGkweO7dmreOveWmT5HQhs",{"id":108,"title":109,"author":6,"body":110,"canonical":90,"category":179,"cover":90,"date":180,"description":181,"draft":94,"extension":95,"keywords":90,"meta":182,"navigation":97,"noindex":94,"ogImage":90,"path":183,"seo":184,"seoDescription":90,"seoTitle":90,"stem":185,"tags":186,"updated":90,"__hash__":190},"blog\u002Fblog\u002Finp-improvement-case-study.md","把后台筛选的 INP 从四百二十毫秒压到一百八十",{"type":8,"value":111,"toc":170},[112,115,118,122,125,128,132,135,139,142,146,149,152,155,158,161,164,167],[11,113,114],{},"今年 10 月我们给一个安全审计 SaaS 的后台做交互优化，P75 的 INP 从 420 毫秒降到 180 毫秒。这个产品每天有客户在里面点几百次筛选，卡不卡直接关系到他们愿不愿意续费。",[11,116,117],{},"问题集中在一个页面：客户列表。1200 条记录，七个筛选条件，每次改动都重新拉数据、重新渲染整张表。用户点一下复选框，页面要停半秒。销售在演示时也遇到过，鼠标点下去没反应，场面很难看。",[15,119,121],{"id":120},"先复现再动手","先复现，再动手",[11,123,124],{},"我们没有直接改代码，先按真实操作录了 20 次 Performance。结论很清楚：一次筛选交互里，主线程上有三个 300 毫秒以上的长任务，分别是数据深拷贝、全量重渲染、以及一个第三方埋点的同步上报。",[11,126,127],{},"顺带说个细节，客户自己一直说\"不卡\"，因为开发机是 M 系列芯片，而他们的客户用的是四年前的办公本。测 INP 必须用降速环境，或者直接看真实用户数据。",[15,129,131],{"id":130},"改动一列表虚拟化","改动一：列表虚拟化",[11,133,134],{},"1200 行只渲染视口内的 40 行，滚动时动态替换。这一项把重渲染时间从 380 毫秒压到 60 毫秒。虚拟化的代价是导出、全选、跨行拖拽这些功能要单独适配，我们花了三天补。",[15,136,138],{"id":137},"改动二把计算挪出事件处理器","改动二：把计算挪出事件处理器",[11,140,141],{},"原来的筛选逻辑在 onchange 里同步过滤数组、做深拷贝、算统计。改成先更新 UI 状态，计算放到 requestIdleCallback 里分批做，中间留一帧渲染。用户先看到勾选生效，结果稍后到。这个体验上的处理比纯性能数字更重要。",[15,143,145],{"id":144},"改动三埋点改成异步批量","改动三：埋点改成异步批量",[11,147,148],{},"那个第三方埋点在每次筛选时同步上报，一次 80 毫秒。改成 1 秒合并上报，用户交互路径上不再有它。",[15,150,151],{"id":151},"结果和一条教训",[11,153,154],{},"三处改完，P75 从 420 到 180 毫秒，P95 从 1100 到 340 毫秒。客户那边的反馈从\"卡\"变成\"还行\"。",[15,156,157],{"id":157},"落地时的协作问题",[11,159,160],{},"这类改动最大的阻力不是技术，是排期。虚拟化要改列表组件，筛选要改状态管理，埋点要跟第三方沟通，三件事分属三个人的活。我们的做法是先做一行能立刻验证的改动——把埋点延后，半天就上线，第二天客户能自己看到数据变化。有了这个信任，后面两周的排期才好谈。",[11,162,163],{},"另一个坑是回归测试。虚拟化之后导出 CSV、全选、行内编辑全都要重新走一遍。我们让客户的产品经理列了 14 个操作场景，逐个手点，漏一个就是线上事故。",[15,165,166],{"id":166},"一条教训",[11,168,169],{},"不要用开发机测 INP。我们坚持用 CPU 4 倍降速加 4G 网络复现，第一次测出来的数据比客户描述的还差。真实环境总是更差的那个，不会更好。另外 INP 改完不是立刻见效的，我们等了两周真实数据才稳定下来，因为长尾交互要攒够样本。",{"title":80,"searchDepth":81,"depth":81,"links":171},[172,173,174,175,176,177,178],{"id":120,"depth":81,"text":121},{"id":130,"depth":81,"text":131},{"id":137,"depth":81,"text":138},{"id":144,"depth":81,"text":145},{"id":151,"depth":81,"text":151},{"id":157,"depth":81,"text":157},{"id":166,"depth":81,"text":166},"技术SEO","2025-10-16","一个安全审计 SaaS 的客户列表页，1200 条数据七个筛选条件，点一下停半秒。虚拟化、把计算挪出事件处理器、埋点改异步三步做完，P75 从 420 毫秒降到 180 毫秒。",{},"\u002Fblog\u002Finp-improvement-case-study",{"title":109,"description":181},"blog\u002Finp-improvement-case-study",[187,188,189],"INP","性能复盘","SaaS后台","LLU_4zvtF7huMyfTTrOfWH84dF7njjzyWoG0KX32h-Q",{"id":192,"title":193,"author":6,"body":194,"canonical":90,"category":344,"cover":90,"date":345,"description":346,"draft":94,"extension":95,"keywords":90,"meta":347,"navigation":97,"noindex":94,"ogImage":90,"path":348,"seo":349,"seoDescription":90,"seoTitle":90,"stem":350,"tags":351,"updated":90,"__hash__":355},"blog\u002Fblog\u002Ffact-density-citation-test.md","事实句密度不能太高：每千字放 5 条时 AI 引用率最高",{"type":8,"value":195,"toc":336},[196,199,202,205,208,211,214,217,220,276,279,283,286,289,293,296,299,302,305,308,311,314,330,333],[11,197,198],{},"事实句不是越多越好。2025 年 9 月到 10 月，我们把 30 篇文章按每千字事实句数量分成三组，跑了 6 周引用监测。密度最高那组（每千字 8 条以上）引用率 11%，最低。中间那组（3 到 5 条）是 34%。",[15,200,201],{"id":201},"事实句的判定标准",[11,203,204],{},"先定义。事实句指能脱离原文单独成立、且带可核对信息的句子。三个条件：有主体、有具体量、不依赖上下文。",[11,206,207],{},"\"我们的同步延迟很低\"不是事实句。\n\"跨区域同步 P99 延迟 180 毫秒，测试环境为两地三可用区\"是。",[11,209,210],{},"一条合格的事实句，从文章里剪下来贴到别处，读者不需要回去看前文。这个标准很硬，用它能筛掉大部分自我表扬。",[15,212,213],{"id":213},"实验怎么做的",[11,215,216],{},"30 篇，同一个客户的博客，主题分散在 API、数据同步、权限管理三块。按密度分三组，每组 10 篇。每周三跑固定 40 个查询，记录 AI 回答里有没有出现这几篇的句子或链接，连续 6 周。",[11,218,219],{},"结果：",[221,222,223,239],"table",{},[224,225,226],"thead",{},[227,228,229,233,236],"tr",{},[230,231,232],"th",{},"组别",[230,234,235],{},"每千字事实句",[230,237,238],{},"6 周被引次数",[240,241,242,254,265],"tbody",{},[227,243,244,248,251],{},[245,246,247],"td",{},"低密度",[245,249,250],{},"0 到 2 条",[245,252,253],{},"19",[227,255,256,259,262],{},[245,257,258],{},"中密度",[245,260,261],{},"3 到 5 条",[245,263,264],{},"41",[227,266,267,270,273],{},[245,268,269],{},"高密度",[245,271,272],{},"8 条以上",[245,274,275],{},"14",[11,277,278],{},"高密度组为什么最差，我们猜了两个原因，第二个更可信。",[15,280,282],{"id":281},"原因一句子之间会打架","原因一：句子之间会打架",[11,284,285],{},"一篇文章堆 20 条事实，引擎挑哪条都合理，挑到的那条可能不是你想让它说的。我们观察到一次：某篇写权限体系的文章，被引用的是里面一句\"支持 200 人以下团队\"，结果用户搜\"企业级权限\"时看到这句，直接跳走了。",[11,287,288],{},"句子多了，你失去对\"被引用的那句\"的控制权。",[15,290,292],{"id":291},"原因二密度高了句子会变短","原因二：密度高了，句子会变短",[11,294,295],{},"这是更根本的问题。为了塞进更多事实，作者会把句子压缩成参数罗列，一条一句，句与句之间没有解释。这种文本对机器友好，对人是灾难。而且引擎需要上下文的支撑，孤立的参数反而不好判断可信度。",[11,297,298],{},"我们回头看了高密度组，有 7 篇是一个参数一张列表，读起来像说明书目录。这类内容更适合放在文档里，不适合做博客。",[15,300,301],{"id":301},"位置比数量重要",[11,303,304],{},"同样一条事实，放在段首和埋在段中，被引用的概率差很多。我们统计了中密度组，落在段首第一句的事实句被引用 26 次，落在段中的 15 次。",[11,306,307],{},"所以实际操作是：每篇文章先定 3 到 5 条关键事实，一条放首段，其余放在各个 H2 下面的第一段第一句。剩下的细节都往表格里塞，表格被整块搬走的概率比散句高。",[15,309,310],{"id":310},"我们的检查清单",[11,312,313],{},"写完一篇，过这四条：",[315,316,317,321,324,327],"ol",{},[318,319,320],"li",{},"能单独剪出来的句子有没有 3 条以上",[318,322,323],{},"每条有没有具体数字或明确条件",[318,325,326],{},"有没有一条放在首段",[318,328,329],{},"有没有超过 6 条",[11,331,332],{},"前三条不满足就补，第四条不满足就删。删除比补充难，但通常更有用。",[11,334,335],{},"密度这件事，做减法比做加法赚钱。",{"title":80,"searchDepth":81,"depth":81,"links":337},[338,339,340,341,342,343],{"id":201,"depth":81,"text":201},{"id":213,"depth":81,"text":213},{"id":281,"depth":81,"text":282},{"id":291,"depth":81,"text":292},{"id":301,"depth":81,"text":301},{"id":310,"depth":81,"text":310},"GEO","2025-10-18","30 篇文章按事实句密度分三组测了 6 周。每千字 8 条以上那组引用率最低，只有 11%，因为 AI 会挑走不重要的一句。每千字 3 到 5 条是甜区，引用率 34%。",{},"\u002Fblog\u002Ffact-density-citation-test",{"title":193,"description":346},"blog\u002Ffact-density-citation-test",[344,352,353,354],"事实句","内容写作","AI引用","1Otq6MKao1iAZ9HGJwcjk1JWcg8mUnaNut2FQM-E264",1794088111571]