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