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