开源项目的内容该放 GitHub 还是官网

开源项目的内容经常两边都发，官网一篇、GitHub 一篇，最后哪边都没做深。2025 年 10 月我们给 6 个开源项目做内容盘点，共同问题是分工不清。重新划完之后最明显的变化在对比页：官网承接“XX alternative”类搜索，三个月带来 60 多条企业咨询。

分工的原则

GitHub 回答“这东西怎么用、靠不靠谱”，官网回答“该不该买、买哪个版本”。这条线划清楚，内容归属就明确了。

放 GitHub 的：安装部署、配置参数、常见报错、架构说明、贡献指南、版本变更。这些内容的读者已经在用或者准备用，他们要的是准确，不是说服。

放官网的：产品定位、适用场景、和竞品的差异、定价、案例、企业版功能、安全合规。这些内容的读者在选型，他们要的是判断依据。

一个具体的错位

很多项目把架构说明和 benchmark 放在官网博客里，其实应该放 GitHub。我们在一个数据库项目上验证过：把一篇“存储引擎设计”从官网博客搬到 GitHub 的 docs 目录，三个月自然流量涨了 2.2 倍。原因很直接，搜这类词的人会去 GitHub 和 Hacker News，不会去你的营销站。

反过来，把“我们和 XX 的区别”写在 GitHub Discussions 里，是纯浪费。那类内容需要结构化对比表、需要定价、需要 CTA，GitHub 给不了。

导流方向要单向

内容可以双向存在，导流最好单向：GitHub 往官网导，官网不要往 GitHub 导。官网首页放一个“查看源码”够了，别在定价页放 GitHub 链接，那是在把要付钱的人送走。

README 里的链接要有优先级。我们一般排：文档、快速开始、官网定价、社区。定价放第三位，太靠前显得急，太靠后没人点。

别在两边写同一篇

重复内容的问题在开源项目里特别常见。同一篇“如何部署”官网一份、docs 一份，两边都没排名。我们现在的规则是：技术内容只有一个权威版本，另一个位置只放摘要加链接。摘要 150 字以内，链接指向权威版本。

判断权威版本放哪，看搜索场景。用户搜报错信息时在 Google 上，跳到 GitHub 也能接受；用户搜“XX 企业版 价格”时必须在官网。按搜索词来源分，比按团队习惯分靠谱。

这套分工的代价

需要有人守边界。工程师习惯把什么都写进 GitHub，市场习惯把什么都搬上官网，两边都会越界。我们的做法是在内容规范里写死一张归属表，新内容先查表再动笔。这事听起来官僚，实际省下的返工时间比写表的时间多。