同属一家公司的两个站点，内容如何分工？把同一篇文章两边都发、文档两边都建，看起来是"覆盖更全"，实际是自我竞争与双份维护。我们在重建官网时把这件事当成一个架构问题来处理，定下了四组规则。
规则一：单一出处，不做复制
每类内容只有一个"家"：
| 内容类型 | 唯一出处 | 另一站怎么处理 |
|---|---|---|
| 产品文档（用户手册） | 产品站 | 母公司站不建入口页，需要时一跳直达 |
| 价格、套餐、订阅配置 | 产品站 | 母公司站只保留"查看套餐与价格"的导流按钮 |
| 产品功能与模块说明 | 产品站（应用详情页） | 母公司站以"产品家族"页概括并指过去 |
| 公司动态、技术服务实践 | 母公司站 | 产品站博客只发产品与行业主题 |
| 法务（隐私、条款） | 两站各备 | 各站服务各自的表单与账号体系，条款内容不同 |
复制内容的代价不只是维护双份：当两个域名互为竞争页面时，搜索引擎会替你"选择一个"，而那个选择往往不是你想要的。
规则二：没有的内容，不要装
英文内容没写完，就不放一个机翻或空壳的英文页。这条规则要三层一致地落实，缺一层就漏：
- 列表层：只有中文的文章不进英文列表；
- 详情层：英文直接访问该文章返回 404，而不是渲染一个中文正文的英文壳；
- 索引层：
hreflang只声明实际可用的语言版本，中文-only 的文章只声明zh-CN + x-default，不给搜索引擎指 404。
这套机制还有个副产品：将来补上英文版时，不需要改任何开关——正文存在与否本身就是开关，hreflang、列表和 sitemap 都从同一处事实推导。
规则三：跨域导流全部带账
所有从母公司站到产品站的链接，统一走一个导流注册表（代码里的 funnel.ts）：链接目标、utm 参数、出现位置集中声明，类型系统保证只有登记过的"导流位"能用：
// 导流位是枚举，拼 UTM 只走这一个函数
export const HZ_PLACEMENTS = ['nav-hongzhai', 'home-hero', 'footer-product', ...] as const
export function hongzhaiUrl(placement: HzPlacement, path = '/', locale: AppLocale = 'zh-CN') {
// utm_source / utm_medium / utm_campaign / utm_content 在此统一拼装
}
配套两条测试：每个导流位的 utm_content 必须唯一；页面中不允许出现硬编码的对方域名。效果是"改一处全站生效，每个入口的流量都能归因"——上线后看数据时，能从 utm_content 直接定位到是哪个按钮带来的转化。
规则四：每一跳都要能落地
导流按钮点过去 404 是最伤的体验。我们对所有跨域链接做了双向核对：目标页真实存在（抽样 HTTP 校验）、路径带正确的语言前缀、带必要查询串。老站迁移同理：64 个旧 URL 逐项清单——站内改名走 301、产品词跨域到产品站、模板遗留页 410——全部落在边缘层的一张 map 文件里，随代码版本管理，改规则不必发版。
小结
双站架构的关键词是边界感：内容有单一的出处，语言有诚实的声明，导流有可归因的通道，每一跳有确定的落点。边界清晰之后，两个站点的关系不是"多发一份"，而是互相背书——母公司站证明产品的工程底子，产品站证明服务的交付能力。