[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"blog-controllable-ranking-factors":3,"blog-prev-controllable-ranking-factors":89,"blog-next-controllable-ranking-factors":163},{"id":4,"title":5,"author":6,"body":7,"canonical":73,"category":74,"cover":73,"date":75,"description":76,"draft":77,"extension":78,"keywords":73,"meta":79,"navigation":80,"noindex":77,"ogImage":73,"path":81,"seo":82,"seoDescription":73,"seoTitle":73,"stem":83,"tags":84,"updated":73,"__hash__":88},"blog\u002Fblog\u002Fcontrollable-ranking-factors.md","排名因素里真正可控的，只有这 6 个","元析智能",{"type":8,"value":9,"toc":65},"minimark",[10,14,19,22,25,28,31,34,37,41,44,47,50,53,56,59,62],[11,12,13],"p",{},"排名因素被讲得太玄。我们给客户做诊断，先分清楚哪些能动手、哪些动不了。能动的只有 6 个：内容质量、页面结构、内链、外链来源、站点速度、品牌搜索。剩下的，花钱也没用。",[15,16,18],"h2",{"id":17},"可控的-6-个按投入产出排","可控的 6 个，按投入产出排",[11,20,21],{},"第一，内容质量。判断标准很土：把你的文章删掉，同行内容能不能完全替代。能替代就是零分。我们给客户定的线是每篇至少 2 处独家信息，比如实测数据、版本变更、我们自己的操作记录。2025 年给 6 个客户做过内容盘点，平均一个站有 34% 的页面属于“删掉也没人发现”，这批页面占着抓取预算，还拉低整站评价。",[11,23,24],{},"第二，页面结构。标题层级、正文可读性、关键信息是否在首屏。这件事一两天能改完，效果通常在两周内出现。",[11,26,27],{},"第三，内链。一个 500 页的站，至少要有 3 条路径能到达每个页面。我们检查内链用一个笨办法：随机抽 20 个页面，看从首页点几次能点到。",[11,29,30],{},"第四，外链来源。数量不是重点，来源页的相关性和质量才是。行业媒体一篇真实报道，比 100 条论坛签名有用。",[11,32,33],{},"第五，站点速度。LCP 控制在 2.5 秒内，这件事我们 2025 年帮 11 个客户做过，平均能带来 5% 到 12% 的流量提升，不算大，但稳定。",[11,35,36],{},"第六，品牌搜索。这是最慢也最值钱的一个。品牌词月搜索量从 200 涨到 800，我们用了 14 个月，靠的是持续发内容加行业曝光。监测的 4 个站里，品牌词涨得最快的一个做了 22 个月行业内容，前 12 个月几乎看不到变化，后面才起量。",[15,38,40],{"id":39},"不可控的三个别花预算","不可控的三个，别花预算",[11,42,43],{},"域名历史，你买来是什么样就是什么样；竞品动作，对手降价或者砸广告你管不了；算法偏好，每季度都在变。",[11,45,46],{},"我们见过客户花 8 万买一个\"有历史权重\"的域名，结果那个域名之前做过灰色行业，三个月后整站被降权，钱和流量一起没了。",[15,48,49],{"id":49},"优先级怎么排",[11,51,52],{},"上个月我们内部复盘了一次这个顺序，结论没变，只补了一条：内容质量这一项不要等到结构和内链全修完再开工，两条线可以并行，不然时间全耗在技术上。",[11,54,55],{},"我们的顺序：页面结构 → 内链 → 内容质量 → 外链来源 → 站点速度 → 品牌搜索。",[11,57,58],{},"前两个是技术活，投入小见效快；内容质量是长期活，决定天花板；品牌搜索最后做，因为它依赖前面所有事情的结果。",[15,60,61],{"id":61},"一个判断",[11,63,64],{},"预算有限的时候，不要把 6 项平均分。先花 20% 的钱把结构和内链修好，剩下的全押内容。外链和品牌是有了内容之后才谈的事。",{"title":66,"searchDepth":67,"depth":67,"links":68},"",2,[69,70,71,72],{"id":17,"depth":67,"text":18},{"id":39,"depth":67,"text":40},{"id":49,"depth":67,"text":49},{"id":61,"depth":67,"text":61},null,"SEO","2025-11-23","排名因素被讲得太玄。我们把能动手的归成 6 个：内容质量、页面结构、内链、外链来源、站点速度、品牌搜索。其余三个不可控，预算别花在那上面。这篇写清楚每个怎么改，也按投入产出给了个排序，预算紧的时候照着砍。",false,"md",{},true,"\u002Fblog\u002Fcontrollable-ranking-factors",{"title":5,"description":76},"blog\u002Fcontrollable-ranking-factors",[85,86,87],"排名因素","预算分配","SEO策略","STBgWi117-VxSHioH_JoncUvw9i5wSnGNj73dqeVbKg",{"id":90,"title":91,"author":6,"body":92,"canonical":73,"category":151,"cover":73,"date":152,"description":153,"draft":77,"extension":78,"keywords":73,"meta":154,"navigation":80,"noindex":77,"ogImage":73,"path":155,"seo":156,"seoDescription":73,"seoTitle":73,"stem":157,"tags":158,"updated":73,"__hash__":162},"blog\u002Fblog\u002Fopen-source-site-vs-github.md","开源项目的内容该放 GitHub 还是官网",{"type":8,"value":93,"toc":145},[94,97,100,103,106,109,112,115,118,121,124,127,130,133,136,142],[11,95,96],{},"开源项目的内容经常两边都发，官网一篇、GitHub 一篇，最后哪边都没做深。2025 年 10 月我们给 6 个开源项目做内容盘点，共同问题是分工不清。重新划完之后最明显的变化在对比页：官网承接“XX alternative”类搜索，三个月带来 60 多条企业咨询。",[15,98,99],{"id":99},"分工的原则",[11,101,102],{},"GitHub 回答“这东西怎么用、靠不靠谱”，官网回答“该不该买、买哪个版本”。这条线划清楚，内容归属就明确了。",[11,104,105],{},"放 GitHub 的：安装部署、配置参数、常见报错、架构说明、贡献指南、版本变更。这些内容的读者已经在用或者准备用，他们要的是准确，不是说服。",[11,107,108],{},"放官网的：产品定位、适用场景、和竞品的差异、定价、案例、企业版功能、安全合规。这些内容的读者在选型，他们要的是判断依据。",[15,110,111],{"id":111},"一个具体的错位",[11,113,114],{},"很多项目把架构说明和 benchmark 放在官网博客里，其实应该放 GitHub。我们在一个数据库项目上验证过：把一篇“存储引擎设计”从官网博客搬到 GitHub 的 docs 目录，三个月自然流量涨了 2.2 倍。原因很直接，搜这类词的人会去 GitHub 和 Hacker News，不会去你的营销站。",[11,116,117],{},"反过来，把“我们和 XX 的区别”写在 GitHub Discussions 里，是纯浪费。那类内容需要结构化对比表、需要定价、需要 CTA，GitHub 给不了。",[15,119,120],{"id":120},"导流方向要单向",[11,122,123],{},"内容可以双向存在，导流最好单向：GitHub 往官网导，官网不要往 GitHub 导。官网首页放一个“查看源码”够了，别在定价页放 GitHub 链接，那是在把要付钱的人送走。",[11,125,126],{},"README 里的链接要有优先级。我们一般排：文档、快速开始、官网定价、社区。定价放第三位，太靠前显得急，太靠后没人点。",[15,128,129],{"id":129},"别在两边写同一篇",[11,131,132],{},"重复内容的问题在开源项目里特别常见。同一篇“如何部署”官网一份、docs 一份，两边都没排名。我们现在的规则是：技术内容只有一个权威版本，另一个位置只放摘要加链接。摘要 150 字以内，链接指向权威版本。",[11,134,135],{},"判断权威版本放哪，看搜索场景。用户搜报错信息时在 Google 上，跳到 GitHub 也能接受；用户搜“XX 企业版 价格”时必须在官网。按搜索词来源分，比按团队习惯分靠谱。",[11,137,138],{},[139,140,141],"strong",{},"这套分工的代价",[11,143,144],{},"需要有人守边界。工程师习惯把什么都写进 GitHub，市场习惯把什么都搬上官网，两边都会越界。我们的做法是在内容规范里写死一张归属表，新内容先查表再动笔。这事听起来官僚，实际省下的返工时间比写表的时间多。",{"title":66,"searchDepth":67,"depth":67,"links":146},[147,148,149,150],{"id":99,"depth":67,"text":99},{"id":111,"depth":67,"text":111},{"id":120,"depth":67,"text":120},{"id":129,"depth":67,"text":129},"行业观察","2025-11-22","两边都在发内容，结果互相打架。我们给 6 个开源项目重新分工：GitHub 管使用和信任，官网管选型和采购，流量涨得最明显的是对比页。",{},"\u002Fblog\u002Fopen-source-site-vs-github",{"title":91,"description":153},"blog\u002Fopen-source-site-vs-github",[159,160,161],"开源","内容策略","GitHub","Qh6LouLw8q8iZbxJn2TfIpnUTKCNobX24eblYEZ8K7s",{"id":164,"title":165,"author":6,"body":166,"canonical":73,"category":225,"cover":73,"date":226,"description":227,"draft":77,"extension":78,"keywords":73,"meta":228,"navigation":80,"noindex":77,"ogImage":73,"path":229,"seo":230,"seoDescription":73,"seoTitle":73,"stem":231,"tags":232,"updated":73,"__hash__":236},"blog\u002Fblog\u002Fai-generated-pages-indexing.md","AI 批量生成落地页，我们踩过的两个收录坑",{"type":8,"value":167,"toc":218},[168,171,175,178,181,185,188,191,194,197,200,203,206,209,212,215],[11,169,170],{},"2025 年 10 月我们给一个做 API 监控的服务批量生成了 180 个集成页，每个第三方服务一页。上线 6 周后 GSC 收录 41 页，其余全是已抓取未编入索引。这次踩的坑很典型，值得写下来。",[15,172,174],{"id":173},"坑一模板化太明显","坑一：模板化太明显",[11,176,177],{},"180 个页面，除了服务名，正文的措辞、段落结构、二级标题几乎一样。工具生成的时候看着每页都通顺，放到一起看就露馅了。搜索引擎判断重复不需要完全一致，结构相同、信息量相同就够它把你归到低质那堆里。",[11,179,180],{},"改法不是换同义词，是给每页补真差异。这个服务的接入步骤、它的接口和别家有什么不同、配置示例里实际要填哪几个字段、常见报错怎么处理。一页至少要有一段别处没有的内容，我们后来定的是每页 300 字左右的真差异，写不出来的页面直接删掉，不凑数。",[15,182,184],{"id":183},"坑二内链没有","坑二：内链没有",[11,186,187],{},"这 180 个页面只出现在站点地图里，从导航和产品文档都点不到。搜索引擎给它们的权重自然很低。我们后来加了一个集成目录页，按类别分组列出所有集成，再从产品文档的相关章节链过去，每页至少拿到 3 条内链。",[11,189,190],{},"内链加完第三周，收录从 41 涨到 96。不是全部，但趋势对了，剩下的页面继续等，同时补内容。",[15,192,193],{"id":193},"判断一页该不该生成",[11,195,196],{},"我总结了一个土办法：把服务名换掉，这段话还成立吗。成立，说明是模板废话，不该生成。不成立，说明里面确实有这个服务特有的东西，值得收。",[11,198,199],{},"另一种判断是看它能不能回答一个具体问题。用户搜“某服务监控怎么配”，这页能不能给出配置步骤和字段说明。答不了，就别指望它带来流量。",[15,201,202],{"id":202},"现在我们的做法",[11,204,205],{},"先做 10 页小样，两周后看收录率，低于五成就别放量，回头改模板。放量之后每页加软件类的结构化数据，把服务名、厂商、集成类型标清楚。GSC 里按目录单独建一个分组，只看这个目录的收录率和曝光，出了问题能第一时间发现。",[15,207,208],{"id":208},"一个反常识的观察",[11,210,211],{},"被收录的 41 页里，有 12 页是用户从搜索结果点进来过的。也就是说，先有人访问，收录才更稳。这跟很多人的理解反过来：不是收录了才有流量，有时候是有了流量才更容易被收录。所以小批量上线、然后想办法让页面被点到，比一次放 180 页更有效。",[11,213,214],{},"我们后来在一个页面上挂了首页的入口，两周后那页的抓取频次从每周 1 次变成每周 4 次，收录也跟着来了。这类信号搜索引擎是认的。",[11,216,217],{},"批量的诱惑在于看起来能一次做很多事，但搜索不吃数量这一套。180 页里有 96 页被收录，真正能带来注册的可能不到 20 页，剩下的投入其实白花。",{"title":66,"searchDepth":67,"depth":67,"links":219},[220,221,222,223,224],{"id":173,"depth":67,"text":174},{"id":183,"depth":67,"text":184},{"id":193,"depth":67,"text":193},{"id":202,"depth":67,"text":202},{"id":208,"depth":67,"text":208},"技术SEO","2025-11-24","180 个集成页上线 6 周，GSC 只收了 41 页。模板化太重、内链缺失，这两个坑让批量生成的内容白做。这篇写我们后来改的三处和放量前的验证法。",{},"\u002Fblog\u002Fai-generated-pages-indexing",{"title":165,"description":227},"blog\u002Fai-generated-pages-indexing",[233,234,235],"批量内容","收录","落地页","ggHgmqxlMRB9QQvZM7jAhiFUA0uM42PnCsyPjQOa3tM",1794088110611]