[{"data":1,"prerenderedAt":276},["ShallowReactive",2],{"blog-reciprocal-link-negotiation":3,"blog-prev-reciprocal-link-negotiation":77,"blog-next-reciprocal-link-negotiation":194},{"id":4,"title":5,"author":6,"body":7,"canonical":61,"category":62,"cover":61,"date":63,"description":64,"draft":65,"extension":66,"keywords":61,"meta":67,"navigation":68,"noindex":65,"ogImage":61,"path":69,"seo":70,"seoDescription":61,"seoTitle":61,"stem":71,"tags":72,"updated":61,"__hash__":76},"blog\u002Fblog\u002Freciprocal-link-negotiation.md","互链谈判怎么做：从发邮件到撤链的完整流程","元析智能",{"type":8,"value":9,"toc":54},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51],[11,12,13],"p",{},"互链谈判不是话术问题，是筛选问题。八成精力该花在判断对方值不值得换，剩下两成才是怎么开口。今年 3 月到 9 月，我们替客户谈了 14 次互链，成 5 次，另外 2 次是谈成之后又主动撤掉的。",[15,16,17],"h2",{"id":17},"第一封邮件写什么",[11,19,20],{},"三段就够。第一段说清楚你是谁、做什么产品、站点是什么；第二段说你看了对方某个具体页面，为什么觉得合适，必须具体到页面，不能夸；第三段给出交换位置和页面，比如\"我们放在首页底部友链区，你们放在资源页\"。",[11,22,23],{},"不要群发模板，站长一眼能看出来。我们收到的群发邮件里，有一半连对方站点名都没替换，这种直接进垃圾箱。",[11,25,26],{},"邮件里不要写\"求交换贵站链接\"这种话。平等合作和求人办事，语气差一点，回复率差很多。14 次谈判里，开头发了具体页面的 9 封，回了 6 封；群发式的 5 封，回了 1 封。",[15,28,29],{"id":29},"谈判中的三个判断点",[11,31,32],{},"对方要求首页互换，可以谈，但要看首页外链数。超过 30 条的，我直接放弃，因为那个位置没有多少价值。",[11,34,35],{},"对方要求三家互链、或者先让我们挂上再\"审核\"，一律拒。这是联盟操作的典型形态，后面出事会连着一起出。",[11,37,38],{},"对方提出付费，注意性质变了：这时候不是互链，是买链。要按买链的标准走，看页面流量、看收录、看历史快照，别因为\"聊得挺好\"就付钱。我们去年就吃过这个亏，一笔 3000 元的付费互换，链接挂了 40 天被下掉，钱没退。",[15,40,41],{"id":41},"撤链的流程",[11,43,44],{},"发现对方站点变了内容、掉了收录、或者整体转向，就该撤。流程是：发邮件通知站长，给 7 天期限，同时截图留证据；到期没动静，自己把对方链接下掉，别等对方先动。",[11,46,47],{},"撤的时候不用 301，也不用藏着，直接删掉链接就行。删完在台账里记一笔，注明原因和日期。",[11,49,50],{},"8 月我们撤了 2 条，其中一条在撤掉后第 3 天掉出索引，说明它当时已经是个死页面。这类链挂着不是资产，是噪音。",[11,52,53],{},"互链这件事，我的态度很明确：宁可一年只成 3 次，也别为了凑数换进来一堆需要善后的链接。",{"title":55,"searchDepth":56,"depth":56,"links":57},"",2,[58,59,60],{"id":17,"depth":56,"text":17},{"id":29,"depth":56,"text":29},{"id":41,"depth":56,"text":41},null,"SEO","2025-10-27","今年我们替客户谈过 14 次互链，成 5 次，撤 2 次。这篇给完整流程：第一封邮件怎么写、遇到高价互换怎么拒、问题链接怎么在两周内撤掉，附三段能直接改着用的邮件话术。",false,"md",{},true,"\u002Fblog\u002Freciprocal-link-negotiation",{"title":5,"description":64},"blog\u002Freciprocal-link-negotiation",[73,74,75],"互链谈判","友情链接","外链操作","Av36rzjUxhD95RpZ2TFNcH_67htR1qhOYzM5iy8XdQo",{"id":78,"title":79,"author":6,"body":80,"canonical":61,"category":182,"cover":61,"date":183,"description":184,"draft":65,"extension":66,"keywords":61,"meta":185,"navigation":68,"noindex":65,"ogImage":61,"path":186,"seo":187,"seoDescription":61,"seoTitle":61,"stem":188,"tags":189,"updated":61,"__hash__":193},"blog\u002Fblog\u002Fbrand-entity-page-guide.md","品牌实体页怎么写：About 页要当成知识图谱的正式入口",{"type":8,"value":81,"toc":175},[82,85,89,92,95,99,102,109,115,121,127,133,136,142,148,154,157,160,163,166,169,172],[11,83,84],{},"2025 年 11 月，一个客户被 AI 描述成\"一家做 BI 报表的公司\"。他们实际做的是数据管道，BI 只是下游客户在用的东西。这个错误描述至少挂了两个月，销售在电话里被问\"你们是不是也做报表\"问了十几次。查下来，问题不在官网首页，在 About 页。",[15,86,88],{"id":87},"ai-认实体靠四类信息","AI 认实体，靠四类信息",[11,90,91],{},"AI 判断一个品牌实体，需要四个东西：叫什么、做什么、在哪里、谁在做。这四样缺一样，它就会去别处找，找到什么就是什么。",[11,93,94],{},"那个客户的 About 页写了 400 字，讲愿景、讲价值观、讲团队来自哪些大厂，唯独没写\"我们做数据管道，客户是 50 到 500 人的 SaaS 公司\"。于是 AI 从第三方拿到一个更省事的描述：BI。",[15,96,98],{"id":97},"about-页的五段结构","About 页的五段结构",[11,100,101],{},"我们现在给客户改 About 页，固定五段：",[11,103,104,108],{},[105,106,107],"strong",{},"第一段，一句定义。"," 用最简单的句式：X 是一家做 Y 的公司，客户是 Z。不超过 50 字，主谓宾齐全。",[11,110,111,114],{},[105,112,113],{},"第二段，产品清单。"," 三个以内，每个一句话说明做什么。别用\"矩阵\"\"体系\"这类词，直接说功能。",[11,116,117,120],{},[105,118,119],{},"第三段，规模与地点。"," 成立年份、团队人数、办公城市、服务多少客户。这四组数字是实体消歧的关键。",[11,122,123,126],{},[105,124,125],{},"第四段，和同类的区别。"," 一句话说清不做什么。我们帮一个安全工具客户写的是\"我们不做终端杀毒，只做 API 网关的权限校验\"。这句被引用了 6 次。",[11,128,129,132],{},[105,130,131],{},"第五段，指向外部。"," 指向文档、GitHub、公司注册信息。这是给 AI 做交叉验证的入口。",[15,134,135],{"id":135},"三种别写的话",[11,137,138,141],{},[105,139,140],{},"\"我们是一支充满热情的团队\"。"," 这句在 AI 眼里没有信息量，在客户眼里也是。",[11,143,144,147],{},[105,145,146],{},"\"我们的解决方案覆盖多个行业\"。"," 覆盖哪几个？写出来。写不出来说明没想清楚。",[11,149,150,153],{},[105,151,152],{},"\"创立于 2015 年，多年来……\"。"," 年份有用，后面那句没用。",[15,155,156],{"id":156},"改完的变化",[11,158,159],{},"那个客户改 About 页花了 3 小时，改完第 3 周复查品牌词查询：4 个引擎里有 3 个的描述变成了\"数据管道\"，剩下 1 个还是 BI。第 6 周，4 个都对了。",[11,161,162],{},"顺带的效果是 About 页的跳出率降了 11 个百分点。人也不想读 400 字愿景。",[15,164,165],{"id":165},"实体不是一页的事",[11,167,168],{},"About 页是入口，不是全部。名称写法要统一：官网、GitHub、领英、应用商店里用同一个中英文名，别今天带\"科技\"明天不带。地址和注册主体也要一致，AI 会用这些做消歧。",[11,170,171],{},"我们见过一家公司，官网写\"XX（杭州）科技有限公司\"，GitHub 上写\"XX Labs\"，领英写\"XX Inc\"。三个名字，AI 当成三家，导致一条本该合并的记录被拆成三条，每条都信息不全。这种活儿没有技术含量，就是笨功夫，但不做的话，后面所有优化都是给错的实体加分。",[11,173,174],{},"先把名字对齐，再谈内容。",{"title":55,"searchDepth":56,"depth":56,"links":176},[177,178,179,180,181],{"id":87,"depth":56,"text":88},{"id":97,"depth":56,"text":98},{"id":135,"depth":56,"text":135},{"id":156,"depth":56,"text":156},{"id":165,"depth":56,"text":165},"GEO","2025-10-26","客户被 AI 说成\"做 BI 的公司\"，实际做数据管道。问题出在 About 页：没写清做什么、给谁做、在哪。改完 3 周，品牌词回答里的错误描述从 4 处降到 1 处。",{},"\u002Fblog\u002Fbrand-entity-page-guide",{"title":79,"description":184},"blog\u002Fbrand-entity-page-guide",[182,190,191,192],"实体优化","知识图谱","品牌","j9v6VIF8sbKq5SoHBnsH0Y-h9uaiXSj6UdVc-GZ7k1U",{"id":195,"title":196,"author":6,"body":197,"canonical":61,"category":264,"cover":61,"date":265,"description":266,"draft":65,"extension":66,"keywords":61,"meta":267,"navigation":68,"noindex":65,"ogImage":61,"path":268,"seo":269,"seoDescription":61,"seoTitle":61,"stem":270,"tags":271,"updated":61,"__hash__":275},"blog\u002Fblog\u002Fchangelog-page-seo.md","更新日志页要不要给搜索引擎看：我的答案是分版本",{"type":8,"value":198,"toc":258},[199,202,206,209,212,216,219,222,225,233,236,243,246,249,252,255],[11,200,201],{},"更新日志（changelog）全量索引，是 SaaS 站里最常见的一种自我伤害。2025 年 1 月我们看一个协作工具的站，changelog 有 640 条记录，每条一个 URL，内容平均 60 个字，整站被索引的页面里三成是这种薄页。我们改成只索引三类，三个月后整站的平均排名位置好了 2.3 位。",[15,203,205],{"id":204},"更新日志对-seo-的真实作用","更新日志对 SEO 的真实作用",[11,207,208],{},"它几乎不带来搜索流量，这是事实。用户不会搜“XX 产品 2025 年 3 月 12 日更新了什么”。它能带来的是另外两件事：一是给产品页提供新鲜度信号，二是让 AI 回答引擎判断这个产品还在维护。",[11,210,211],{},"所以目标不是“让每条更新被搜到”，是“让搜索引擎知道你在持续更新，同时别制造垃圾页”。这两件事可以同时做到。",[15,213,215],{"id":214},"三类进索引其余不进","三类进索引，其余不进",[11,217,218],{},"第一类，大版本发布。功能模块级的变化，值得一个独立页面，标题写清版本号和核心能力。这类页面通常能吃到“XX 新功能”“XX 支持 XX”这类词。",[11,220,221],{},"第二类，迁移和弃用公告。 Breaking change 一定要独立页，用户会搜报错和新写法，这类页面意图极强。",[11,223,224],{},"第三类，年度汇总。把一年的更新按季度归并成一页，这是给搜索引擎和 AI 看的产品活跃度证明，也方便媒体引用。",[11,226,227,228,232],{},"其余的小修小补，全部放在一个按月分页的列表里，列表页可以索引，单条不进索引。我们用 ",[229,230,231],"code",{},"noindex"," 处理单条，同时在列表页保留完整文本，用户和爬虫都能读到。",[15,234,235],{"id":235},"一个容易忽略的细节",[11,237,238,239,242],{},"changelog 页面上的日期要用机器可读格式，加 ",[229,240,241],{},"datePublished"," 结构化数据。我们给一个客户加上之后，Google 抓取频率从每周两次到每天都有，这不是排名魔法，就是抓取预算分配变了。",[11,244,245],{},"另外，changelog 里的功能名要和产品页的叫法一致。我们见过一个产品在 changelog 里叫“智能分组”，在产品页叫“自动分群”，两套词互相稀释。",[15,247,248],{"id":248},"别做的事",[11,250,251],{},"别把 changelog 做成论坛式的碎碎念。“修复了一些问题”“优化了体验”这种条目对用户没用，对搜索引擎更是噪音。我们要求客户每条更新至少写清：改了什么、影响谁、要不要动手。三条写不出来，就别发。",[11,253,254],{},"还有一个用法：把 changelog 接进 RSS，让社区和技术周报订阅。有几个项目的更新会被行业周报自动抓取，等于免费的二次曝光，成本只是一行订阅入口。",[11,256,257],{},"小团队没有精力维护 changelog 的话，可以只发大版本，一个月一条也比六百条碎记录强。索引量不是资产，能被信任的页面才是。",{"title":55,"searchDepth":56,"depth":56,"links":259},[260,261,262,263],{"id":204,"depth":56,"text":205},{"id":214,"depth":56,"text":215},{"id":235,"depth":56,"text":235},{"id":248,"depth":56,"text":248},"技术SEO","2025-10-28","一个 SaaS 的 changelog 有 600 多条记录，全索引等于制造 600 个薄页面。我们把它拆成三类，只放其中一类进索引，结果反而更好。",{},"\u002Fblog\u002Fchangelog-page-seo",{"title":196,"description":266},"blog\u002Fchangelog-page-seo",[272,273,274],"更新日志","内容策略","SaaS SEO","ZDZyEwjfnMIboOrv15jzZGR9oBx_RyCntFI1-nIMod4",1794088111313]