[{"data":1,"prerenderedAt":253},["ShallowReactive",2],{"blog-removed-reciprocal-links-review":3,"blog-prev-removed-reciprocal-links-review":76,"blog-next-removed-reciprocal-links-review":180},{"id":4,"title":5,"author":6,"body":7,"canonical":60,"category":61,"cover":60,"date":62,"description":63,"draft":64,"extension":65,"keywords":60,"meta":66,"navigation":67,"noindex":64,"ogImage":60,"path":68,"seo":69,"seoDescription":60,"seoTitle":60,"stem":70,"tags":71,"updated":60,"__hash__":75},"blog\u002Fblog\u002Fremoved-reciprocal-links-review.md","我们撤掉 23 条友链之后：排名没掉，抓取频次涨了四成","元析智能",{"type":8,"value":9,"toc":53},"minimark",[10,14,19,22,25,28,32,35,38,41,44,47,50],[11,12,13],"p",{},"老板最怕的一件事是\"链接一撤，排名就掉\"。今年 7 月我们建议一个做工程管理软件的客户撤掉 23 条存量友链，客户犹豫了两周才同意。撤完 6 周的数据和我们预期的一样：排名没掉，抓取反而变快了。",[15,16,18],"h2",{"id":17},"为什么要撤这-23-条","为什么要撤这 23 条",[11,20,21],{},"这 23 条是 2019 到 2021 年之间换的，那时候没人审，谁找上门都换。我们逐条查历史快照后发现：6 条来自同一批注册的域名；4 条页面已经改成了赌博类内容；3 条页面 404；剩下 10 条是导航站和采集站，页面上挂着一两百条外链。",[11,23,24],{},"这种链接挂在站上，唯一的作用是让蜘蛛顺着爬到一堆垃圾页面上。它不会直接让你降权，但会持续稀释抓取预算，也会让站点的链接关系变得混乱。",[11,26,27],{},"撤之前我们做了一张对照表，把每条链接的页面状态、收录情况、历史快照、主题相关度标在一行里。23 条里能通过我们验收四步的只有 1 条。这张表交给客户看的当天，对方就同意了。后来我把它固定成模板，每次盘存量链接都用，比口头讲风险管用得多。",[15,29,31],{"id":30},"撤的过程怎么撤才不伤站","撤的过程：怎么撤才不伤站",[11,33,34],{},"没有一次性删。23 条分三批，每周撤 8 条左右，撤之前存档截图和 URL。不是因为分批有技术上的必要，是为了方便观察，万一有波动能定位到是哪一批。",[11,36,37],{},"对还在运营的站点，我们提前发了通知邮件，说明因站点调整下掉链接，语气客气，留了 7 天时间让对方也处理。对方的反应大多很淡，没人追究。",[11,39,40],{},"有一点要提醒：撤链之前先确认自己的站内结构没问题。如果站内本来就有一堆死链、空分类，撤完看不到变化，就会误判成\"撤链没用\"。",[15,42,43],{"id":43},"六周后我们看的四组数据",[11,45,46],{},"核心词进前 10 的数量，从 11 个变成 12 个；百度蜘蛛日抓取量，从 1400 次涨到 2000 次；首页快照更新时间，从 9 天缩到 2 天；GSC 引荐流量从每月 260 次降到 244 次，掉了 6%。",[11,48,49],{},"最后这个数就是撤链的可见代价，掉了 6% 的引荐流量，换来抓取和快照的改善。我觉得这笔账划算，因为引荐流量里那部分本来也不是目标客户。",[11,51,52],{},"存量垃圾链接是负债。它不像内容那么显眼，但每个月都在产生成本。真要说风险，最大的风险是\"一直没盘点过\"。",{"title":54,"searchDepth":55,"depth":55,"links":56},"",2,[57,58,59],{"id":17,"depth":55,"text":18},{"id":30,"depth":55,"text":31},{"id":43,"depth":55,"text":43},null,"技术SEO","2025-11-04","2025 年 7 月我们建议一个客户撤掉 23 条存量友链，客户最怕排名崩。撤完 6 周的数据：核心词前 10 数量没掉，百度蜘蛛日抓取从 1400 次涨到 2000 次，首页快照从 9 天缩到 2 天。",false,"md",{},true,"\u002Fblog\u002Fremoved-reciprocal-links-review",{"title":5,"description":63},"blog\u002Fremoved-reciprocal-links-review",[72,73,74],"友链清理","抓取频次","复盘","pIeWGQT-bSPb3kH5pMywigubVLj7cFQp5N16MOJJdgM",{"id":77,"title":78,"author":6,"body":79,"canonical":60,"category":169,"cover":60,"date":170,"description":171,"draft":64,"extension":65,"keywords":60,"meta":172,"navigation":67,"noindex":64,"ogImage":60,"path":173,"seo":174,"seoDescription":60,"seoTitle":60,"stem":175,"tags":176,"updated":60,"__hash__":179},"blog\u002Fblog\u002Fproduct-entity-vs-brand-entity.md","产品实体和品牌实体混在一页，AI 会把公司当产品",{"type":8,"value":80,"toc":161},[81,84,88,91,94,97,104,110,116,119,122,125,128,131,134,137,140,143,146,149,152,155,158],[11,82,83],{},"产品名和公司名写在同一个标题里，AI 会把两条实体记录合成一条。这不是理论，是我们 10 月在一个客户身上看到的：他们的产品页标题是\"XX 数据平台 - XX 科技\"，结果搜产品名时，AI 回答的是公司简介；搜公司名时，AI 回答的是产品功能。两边都答得半对。",[15,85,87],{"id":86},"在-ai-眼里这是两条记录","在 AI 眼里，这是两条记录",[11,89,90],{},"品牌实体是公司：法人、地址、成立时间、员工数、融资、客户。产品实体是软件：功能、版本、定价、部署方式、兼容性、许可证。",[11,92,93],{},"这两条记录在知识图谱里各有节点，用\"开发方\"这类关系连着。你把它们塞进一个页面、一个标题，引擎就得自己猜哪个是哪个。猜错不要紧，要紧的是它猜完就固定了，后面很难改。",[15,95,96],{"id":96},"混写的三个后果",[11,98,99,103],{},[100,101,102],"strong",{},"品牌词回答变窄。"," 搜公司名，回答里全是产品功能，看不到团队规模和客户类型，采购方判断不了你靠不靠谱。",[11,105,106,109],{},[100,107,108],{},"对比类查询缺席。"," 用户搜\"XX 和 YY 哪个好\"，AI 需要一个能被拿来对比的产品条目。条目不存在，它就不提你。我们查了 4 个混写客户的对比类查询，40 个查询里出现 3 次。拆开之后是 17 次。",[11,111,112,115],{},[100,113,114],{},"结构化数据打架。"," 同一页里放 Organization 和 SoftwareApplication，属性互相污染。有人把定价写到 Organization 的 priceRange 里，机器读出来就是\"这家公司收费 99 元\"。",[15,117,118],{"id":118},"拆开的三条做法",[11,120,121],{},"第一，产品页独立。每个产品一条 URL，标题只写产品名，不带公司后缀。公司名放到正文第一段和页脚。",[11,123,124],{},"第二，schema 分开写。Organization 放公司页和全站页脚，SoftwareApplication 放产品页。SoftwareApplication 里至少给 name、applicationCategory、operatingSystem、offers 四项。别偷懒只写 name。",[11,126,127],{},"第三，命名统一。产品名在所有渠道用同一个写法，包括大小写。产品名里有版本号的就别把版本号写进主名称，\"XX 2.0\"和\"XX\"是两个实体。",[15,129,130],{"id":130},"一个客户的六个月",[11,132,133],{},"那个数据平台客户，11 月开始拆。做了三件事：产品页改标题、产品页加 SoftwareApplication、About 页补公司信息。",[11,135,136],{},"六周复查：搜产品名，回答里出现功能描述的比例从 30% 到 78%；搜公司名，出现客户类型和团队规模的比例从 0 到 60%；对比类查询从 3 次到 17 次。",[11,138,139],{},"没有新写内容，只是把已有的信息归位。",[15,141,142],{"id":142},"什么时候不用拆",[11,144,145],{},"只有一个产品、且产品名就是公司名的情况，不用拆。比如很多工具类公司，公司叫 X，产品也叫 X。这时候一条记录更清楚。",[11,147,148],{},"判断标准是：你的客户会不会用\"你们公司\"和\"你们产品\"问两个不同的问题。会，就该拆。不会，别折腾。",[15,150,151],{"id":151},"一个容易被忽略的连带影响",[11,153,154],{},"拆实体还会顺带修好一个东西：AI 回答里的\"适合谁\"。混写的时候，引擎只能从公司层面判断，于是把你们推给所有人，或者推给所有人里最便宜的那批。产品实体独立之后，它能从功能、部署方式、定价区间推出适用规模，推荐就变准了。",[11,156,157],{},"我们那个客户拆完两个月，AI 回答里开始出现\"适合 50 到 200 人的团队\"这类描述。这种句子比任何广告词都值钱，因为它出现在用户提问的那一刻。",[11,159,160],{},"实体这件事，最怕的是模糊。宁可少写，别混着写。",{"title":54,"searchDepth":55,"depth":55,"links":162},[163,164,165,166,167,168],{"id":86,"depth":55,"text":87},{"id":96,"depth":55,"text":96},{"id":118,"depth":55,"text":118},{"id":130,"depth":55,"text":130},{"id":142,"depth":55,"text":142},{"id":151,"depth":55,"text":151},"GEO","2025-11-03","产品名和公司名写在同一个标题里，AI 会把两条实体记录合并。后果是品牌词回答错、产品对比缺席。我们拆开三个客户，六周后对比类查询开始出现他们。",{},"\u002Fblog\u002Fproduct-entity-vs-brand-entity",{"title":78,"description":171},"blog\u002Fproduct-entity-vs-brand-entity",[169,177,178],"实体优化","结构化数据","BJ2rTzFo_jFABOs70dYQsXk4Ip-VQu59fxf6Vl7DaO0",{"id":181,"title":182,"author":6,"body":183,"canonical":60,"category":61,"cover":60,"date":242,"description":243,"draft":64,"extension":65,"keywords":60,"meta":244,"navigation":67,"noindex":64,"ogImage":60,"path":245,"seo":246,"seoDescription":60,"seoTitle":60,"stem":247,"tags":248,"updated":60,"__hash__":252},"blog\u002Fblog\u002Fsdk-multilanguage-docs-seo.md","同一套 API 六种语言 SDK，文档别复制六份",{"type":8,"value":184,"toc":236},[185,188,191,194,198,206,209,212,215,218,221,224,227,230,233],[11,186,187],{},"多语言 SDK 文档最省事的做法，是每种语言复制一份，改改代码示例。这个做法会制造大量近似重复页面。2025 年 8 月我们处理一个对象存储产品的文档站，六种语言各有一套完整文档，被索引的页面 620 个，其中内容重复度超过八成的有 400 多个，互相抢排名，谁都没排好。",[15,189,190],{"id":190},"重复度的实际代价",[11,192,193],{},"我们抽了 30 组页面做对比，同一接口的 Python 版和 Node 版，正文文字差异不到 12%，只有代码块不同。搜索引擎对这类页面的处理是挑一个留下，其余的降权或不索引。问题是它挑的那个未必是你想要的那个，而且六份页面把抓取预算吃掉了，真正该被索引的指南页反而抓得慢。",[15,195,197],{"id":196},"我们的改法一个主页面语言用参数区分","我们的改法：一个主页面，语言用参数区分",[11,199,200,201,205],{},"第一步，正文只写一份。接口说明、参数表、错误码、注意事项，这些和语言无关的内容放在主页面。第二步，代码示例按语言切换，切换用 URL 参数（",[202,203,204],"code",{},"?lang=python","）而不是纯前端 tab。第三步，主页面 canonical 指向自己，参数版本不单独索引。",[11,207,208],{},"改完之后索引页从 620 降到 190，文档站的整体点击涨了 34%。原因不复杂：所有信号集中到了真正有内容的那批页面上。",[15,210,211],{"id":211},"但有三类页面必须按语言拆",[11,213,214],{},"第一类，安装和初始化。每种语言的包管理器、依赖、初始化代码完全不同，用户会直接搜“XX python sdk 安装”。这类页面独立 URL，标题带语言名。",[11,216,217],{},"第二类，框架集成指南。Django、Spring、Rails 各有各的坑，这类内容差异大，值得独立页。",[11,219,220],{},"第三类，语言特有的错误。类型错误、异步写法、内存管理，这些问题只在特定语言出现。",[11,222,223],{},"判断标准是：语言之间除了代码块，正文差异有没有超过四成。超过就拆，不到就合。",[11,225,226],{},"六种语言同步更新是个长期成本。我们的做法是以主文档为唯一源，代码示例用片段文件管理，发布时按语言拼装。这样改一处说明，六个语言版本同时更新，不会出现 Python 文档说 2.0、Node 文档说 1.8 的情况。",[15,228,229],{"id":229},"语言名怎么放进关键词",[11,231,232],{},"用户搜的是“python sdk”“node.js client”“java library”，不是“多语言 SDK”。所以独立页的 title 要直接写语言名加工件名，正文第一段说明这个 SDK 支持哪些版本。我们还会在页面里放一句“其他语言看这里”，链回主文档。",[11,234,235],{},"一个提醒：别为了覆盖关键词硬造语言页。产品只支持 Python 和 Go，就别写 Java 页，用户点进去发现没有包，信任直接没了。",{"title":54,"searchDepth":55,"depth":55,"links":237},[238,239,240,241],{"id":190,"depth":55,"text":190},{"id":196,"depth":55,"text":197},{"id":211,"depth":55,"text":211},{"id":229,"depth":55,"text":229},"2025-11-05","SDK 文档按语言复制粘贴，会出现六个内容几乎一样的页面互相抢排名。我们用一个主页面加语言参数的做法，把索引页从 620 个压到 190 个。",{},"\u002Fblog\u002Fsdk-multilanguage-docs-seo",{"title":182,"description":243},"blog\u002Fsdk-multilanguage-docs-seo",[249,250,251],"SDK 文档","重复内容","开发者工具","9l3J4RBDK7tt2B_ZY14q-zZefpsIvURdgljBPYKgbhk",1794088111115]