[{"data":1,"prerenderedAt":240},["ShallowReactive",2],{"blog-sdk-multilanguage-docs-seo":3,"blog-prev-sdk-multilanguage-docs-seo":87,"blog-next-sdk-multilanguage-docs-seo":149},{"id":4,"title":5,"author":6,"body":7,"canonical":71,"category":72,"cover":71,"date":73,"description":74,"draft":75,"extension":76,"keywords":71,"meta":77,"navigation":78,"noindex":75,"ogImage":71,"path":79,"seo":80,"seoDescription":71,"seoTitle":71,"stem":81,"tags":82,"updated":71,"__hash__":86},"blog\u002Fblog\u002Fsdk-multilanguage-docs-seo.md","同一套 API 六种语言 SDK，文档别复制六份","元析智能",{"type":8,"value":9,"toc":63},"minimark",[10,14,18,21,25,33,36,39,42,45,48,51,54,57,60],[11,12,13],"p",{},"多语言 SDK 文档最省事的做法，是每种语言复制一份，改改代码示例。这个做法会制造大量近似重复页面。2025 年 8 月我们处理一个对象存储产品的文档站，六种语言各有一套完整文档，被索引的页面 620 个，其中内容重复度超过八成的有 400 多个，互相抢排名，谁都没排好。",[15,16,17],"h2",{"id":17},"重复度的实际代价",[11,19,20],{},"我们抽了 30 组页面做对比，同一接口的 Python 版和 Node 版，正文文字差异不到 12%，只有代码块不同。搜索引擎对这类页面的处理是挑一个留下，其余的降权或不索引。问题是它挑的那个未必是你想要的那个，而且六份页面把抓取预算吃掉了，真正该被索引的指南页反而抓得慢。",[15,22,24],{"id":23},"我们的改法一个主页面语言用参数区分","我们的改法：一个主页面，语言用参数区分",[11,26,27,28,32],{},"第一步，正文只写一份。接口说明、参数表、错误码、注意事项，这些和语言无关的内容放在主页面。第二步，代码示例按语言切换，切换用 URL 参数（",[29,30,31],"code",{},"?lang=python","）而不是纯前端 tab。第三步，主页面 canonical 指向自己，参数版本不单独索引。",[11,34,35],{},"改完之后索引页从 620 降到 190，文档站的整体点击涨了 34%。原因不复杂：所有信号集中到了真正有内容的那批页面上。",[15,37,38],{"id":38},"但有三类页面必须按语言拆",[11,40,41],{},"第一类，安装和初始化。每种语言的包管理器、依赖、初始化代码完全不同，用户会直接搜“XX python sdk 安装”。这类页面独立 URL，标题带语言名。",[11,43,44],{},"第二类，框架集成指南。Django、Spring、Rails 各有各的坑，这类内容差异大，值得独立页。",[11,46,47],{},"第三类，语言特有的错误。类型错误、异步写法、内存管理，这些问题只在特定语言出现。",[11,49,50],{},"判断标准是：语言之间除了代码块，正文差异有没有超过四成。超过就拆，不到就合。",[11,52,53],{},"六种语言同步更新是个长期成本。我们的做法是以主文档为唯一源，代码示例用片段文件管理，发布时按语言拼装。这样改一处说明，六个语言版本同时更新，不会出现 Python 文档说 2.0、Node 文档说 1.8 的情况。",[15,55,56],{"id":56},"语言名怎么放进关键词",[11,58,59],{},"用户搜的是“python sdk”“node.js client”“java library”，不是“多语言 SDK”。所以独立页的 title 要直接写语言名加工件名，正文第一段说明这个 SDK 支持哪些版本。我们还会在页面里放一句“其他语言看这里”，链回主文档。",[11,61,62],{},"一个提醒：别为了覆盖关键词硬造语言页。产品只支持 Python 和 Go，就别写 Java 页，用户点进去发现没有包，信任直接没了。",{"title":64,"searchDepth":65,"depth":65,"links":66},"",2,[67,68,69,70],{"id":17,"depth":65,"text":17},{"id":23,"depth":65,"text":24},{"id":38,"depth":65,"text":38},{"id":56,"depth":65,"text":56},null,"技术SEO","2025-11-05","SDK 文档按语言复制粘贴，会出现六个内容几乎一样的页面互相抢排名。我们用一个主页面加语言参数的做法，把索引页从 620 个压到 190 个。",false,"md",{},true,"\u002Fblog\u002Fsdk-multilanguage-docs-seo",{"title":5,"description":74},"blog\u002Fsdk-multilanguage-docs-seo",[83,84,85],"SDK 文档","重复内容","开发者工具","9l3J4RBDK7tt2B_ZY14q-zZefpsIvURdgljBPYKgbhk",{"id":88,"title":89,"author":6,"body":90,"canonical":71,"category":72,"cover":71,"date":138,"description":139,"draft":75,"extension":76,"keywords":71,"meta":140,"navigation":78,"noindex":75,"ogImage":71,"path":141,"seo":142,"seoDescription":71,"seoTitle":71,"stem":143,"tags":144,"updated":71,"__hash__":148},"blog\u002Fblog\u002Fremoved-reciprocal-links-review.md","我们撤掉 23 条友链之后：排名没掉，抓取频次涨了四成",{"type":8,"value":91,"toc":133},[92,95,99,102,105,108,112,115,118,121,124,127,130],[11,93,94],{},"老板最怕的一件事是\"链接一撤，排名就掉\"。今年 7 月我们建议一个做工程管理软件的客户撤掉 23 条存量友链，客户犹豫了两周才同意。撤完 6 周的数据和我们预期的一样：排名没掉，抓取反而变快了。",[15,96,98],{"id":97},"为什么要撤这-23-条","为什么要撤这 23 条",[11,100,101],{},"这 23 条是 2019 到 2021 年之间换的，那时候没人审，谁找上门都换。我们逐条查历史快照后发现：6 条来自同一批注册的域名；4 条页面已经改成了赌博类内容；3 条页面 404；剩下 10 条是导航站和采集站，页面上挂着一两百条外链。",[11,103,104],{},"这种链接挂在站上，唯一的作用是让蜘蛛顺着爬到一堆垃圾页面上。它不会直接让你降权，但会持续稀释抓取预算，也会让站点的链接关系变得混乱。",[11,106,107],{},"撤之前我们做了一张对照表，把每条链接的页面状态、收录情况、历史快照、主题相关度标在一行里。23 条里能通过我们验收四步的只有 1 条。这张表交给客户看的当天，对方就同意了。后来我把它固定成模板，每次盘存量链接都用，比口头讲风险管用得多。",[15,109,111],{"id":110},"撤的过程怎么撤才不伤站","撤的过程：怎么撤才不伤站",[11,113,114],{},"没有一次性删。23 条分三批，每周撤 8 条左右，撤之前存档截图和 URL。不是因为分批有技术上的必要，是为了方便观察，万一有波动能定位到是哪一批。",[11,116,117],{},"对还在运营的站点，我们提前发了通知邮件，说明因站点调整下掉链接，语气客气，留了 7 天时间让对方也处理。对方的反应大多很淡，没人追究。",[11,119,120],{},"有一点要提醒：撤链之前先确认自己的站内结构没问题。如果站内本来就有一堆死链、空分类，撤完看不到变化，就会误判成\"撤链没用\"。",[15,122,123],{"id":123},"六周后我们看的四组数据",[11,125,126],{},"核心词进前 10 的数量，从 11 个变成 12 个；百度蜘蛛日抓取量，从 1400 次涨到 2000 次；首页快照更新时间，从 9 天缩到 2 天；GSC 引荐流量从每月 260 次降到 244 次，掉了 6%。",[11,128,129],{},"最后这个数就是撤链的可见代价，掉了 6% 的引荐流量，换来抓取和快照的改善。我觉得这笔账划算，因为引荐流量里那部分本来也不是目标客户。",[11,131,132],{},"存量垃圾链接是负债。它不像内容那么显眼，但每个月都在产生成本。真要说风险，最大的风险是\"一直没盘点过\"。",{"title":64,"searchDepth":65,"depth":65,"links":134},[135,136,137],{"id":97,"depth":65,"text":98},{"id":110,"depth":65,"text":111},{"id":123,"depth":65,"text":123},"2025-11-04","2025 年 7 月我们建议一个客户撤掉 23 条存量友链，客户最怕排名崩。撤完 6 周的数据：核心词前 10 数量没掉，百度蜘蛛日抓取从 1400 次涨到 2000 次，首页快照从 9 天缩到 2 天。",{},"\u002Fblog\u002Fremoved-reciprocal-links-review",{"title":89,"description":139},"blog\u002Fremoved-reciprocal-links-review",[145,146,147],"友链清理","抓取频次","复盘","pIeWGQT-bSPb3kH5pMywigubVLj7cFQp5N16MOJJdgM",{"id":150,"title":151,"author":6,"body":152,"canonical":71,"category":228,"cover":71,"date":229,"description":230,"draft":75,"extension":76,"keywords":71,"meta":231,"navigation":78,"noindex":75,"ogImage":71,"path":232,"seo":233,"seoDescription":71,"seoTitle":71,"stem":234,"tags":235,"updated":71,"__hash__":239},"blog\u002Fblog\u002Fone-content-baidu-google.md","一套内容兼顾百度和 Google，我们只改三处",{"type":8,"value":153,"toc":220},[154,157,160,164,167,170,173,177,180,183,187,190,193,196,199,202,205,208,211,214,217],[11,155,156],{},"一套内容同时喂百度和 Google 是可行的，但不是复制粘贴。我们给软件公司做双引擎时，只改三个地方，其余复用，内容生产成本降了约六成。",[11,158,159],{},"先说清楚：这里讲的是同一语言的内容，比如中文站要同时被百度、Bing、搜狗收，英文站要同时被 Google、Bing 收。中英文互译是另一件事，翻译解决不了关键词对不上的问题。",[15,161,163],{"id":162},"第一处标题","第一处：标题",[11,165,166],{},"百度标题偏\"关键词前置加利益点\"，Google 标题偏\"具体对象加结果\"。同一篇正文配两个标题。",[11,168,169],{},"举个例子，我们写 API 监控的内容，百度版标题是\"API 监控工具怎么选：5 个指标先看\"，Google 版是\"API monitoring tools: 5 metrics that matter\"。关键词都在，语序和卖点不同。",[11,171,172],{},"不做的：一个标题硬套两边。\"最好的 API 监控工具推荐\"这种，Google 上没竞争力，百度上信息量也不够。",[15,174,176],{"id":175},"第二处首段","第二处：首段",[11,178,179],{},"百度用户习惯先看结论，Google 现在也偏结论前置，尤其涉及精选摘要和 AI 概览的查询。我们首段统一写成 60 到 80 字的直接答案。",[11,181,182],{},"好处是两边通吃。今年 8 月我们改了一批客户文章的首段，把铺垫删掉、第一句就给答案，百度收录没变化，Google 的精选摘要命中数从 4 个涨到 11 个。",[15,184,186],{"id":185},"第三处结构化数据","第三处：结构化数据",[11,188,189],{},"这处其实是\"给 Google 加、给百度简化\"。",[11,191,192],{},"Google 对 Article、FAQPage、SoftwareApplication 这类 schema 有明确收益，尤其 FAQPage，能直接影响搜索结果展示。百度对 schema 的读取有限，重点还是正文结构和 META，塞太多结构化数据没意义，还增加页面负担。",[11,194,195],{},"我们的做法：同一套页面，给 Google 输出完整 schema，百度抓到的还是普通 HTML，不影响。",[15,197,198],{"id":198},"不需要改的部分",[11,200,201],{},"正文结构、案例、数据，两边算法对\"第一手经验\"的判断逻辑越来越像。有实测、有截图、有具体数字的内容，百度和 Google 都给分。反过来，空话两边都不给。",[15,203,204],{"id":204},"什么时候不该这么做",[11,206,207],{},"中文站和英文站是两个独立市场的时候，不要共用一套内容。我们一个客户同时卖国内和东南亚，两边的竞品、价格、使用场景完全不同，硬套一套内容，两边都不精准。",[11,209,210],{},"这种时候就该分开写，按市场调研关键词，按当地用户的说法组织案例。省下的成本，抵不过丢掉的转化。",[15,212,213],{"id":213},"效果",[11,215,216],{},"6 个客户这么操作，内容生产成本降了约 60%，百度收录量没掉，Google 收录涨了 20% 到 35%。",[11,218,219],{},"别为每个引擎单独写一套。一套底稿加三处适配，投入产出比最高。预算特别充足、两个市场都是主战场的公司，再考虑分开写。",{"title":64,"searchDepth":65,"depth":65,"links":221},[222,223,224,225,226,227],{"id":162,"depth":65,"text":163},{"id":175,"depth":65,"text":176},{"id":185,"depth":65,"text":186},{"id":198,"depth":65,"text":198},{"id":204,"depth":65,"text":204},{"id":213,"depth":65,"text":213},"内容运营","2025-11-06","中英文双站各写一套成本太高。我们给软件公司的做法是：一套底稿只改标题、首段、结构化数据三处，其余复用，内容成本降六成，Google 收录还涨了两三成。三处分别改什么、为什么不用全改，下面按顺序说。",{},"\u002Fblog\u002Fone-content-baidu-google",{"title":151,"description":230},"blog\u002Fone-content-baidu-google",[236,237,238],"多引擎内容","标题优化","结构化数据","YoDPsMpuwebY_Rco9g3aYPfIoFZzO7jOQg32b7WfPY0",1794088111086]