多站点 SEO 治理：从关键词簇到页面合并与跨域分工

这篇不叫"站群 SEO 教程"。中文互联网上说"站群"一般指 PBN（私有博客网络，用来互相刷外链的假站）、批量建站和搜索操纵，但本文要解决的是一个完全正当的现实问题：

一家公司有十几个真实的业务网站——不同品牌、不同市场、不同产品线——它们之间怎么分配搜索需求、处理重复页面，怎么用询盘而不是排名来衡量结果。

全文内容分三种，用标签区分：

• 【官方】：Google 自己的文档里写明的规则。每条都附了出处链接，你可以点进去核实。
• 【框架】：我根据官方规则和实际经验总结的操作方法。可以直接拿来用，但不是唯一正解——如果你的数据告诉你别的做法更好，以你的数据为准。
• 【示例】：一家虚构的 B2B 塑料托盘公司，用来把流程讲具体。里面的数字都是编的，不代表任何真实客户。

先说结论

• 冲突的根因不是"好几个页面用了一样的关键词"，而是同一个搜索需求没有指定由谁的哪个页面来承接。结果就是好几个页面在抢同一拨客户，谁也说不清哪个页面真正带来了询盘。
• 【官方】Google 不会因为内容重复就罚你（除非你是故意作弊），但它会把重复的网址归成一组，只选其中一个显示在搜索结果里，并把外链等权重集中到那一个上。问题在于：选哪个由 Google 决定，你说了不算。
• 【官方】多域名有一条明确的红线：Google 把"建多个只在网址和首页上略有不同的网站、目的是尽可能多地占住某个搜索词"直接列为 doorway abuse（门页滥用）。合法的多站必须各有独立价值，不能只是换个域名换个首页。
• 解决方案不是立刻合并所有网站，而是先给高价值需求指定主力页面，先做差异化和冻结，最后才考虑跨域 301（永久跳转）。
• "排名 4—30"不能单独当筛选条件：只有 1 次展示、0 次点击的时候，数据太少，连"点击率低"都说不了——统计原理见「怎样从 GSC 找出值得治理的前 50 个簇」一节。
• 中央关键词表可以用，但必须缩到 20—100 个高价值簇，还要配发布门禁和一名有裁决权的负责人。三样缺一个，它三个月内必然变成没人维护的文档。

本文所有硬结论的出处集中在这里，方便直接核实：

结论	关键事实	官方出处
多个近似站属于 doorway abuse	"multiple websites with slight variations to the URL and home page"	Google Spam Policies
301 保留时长	"as long as possible, generally at least 1 year"	Site move with URL changes
canonical 是信号不是指令	重定向（强）> rel=canonical（强）> sitemap（弱）	Consolidate duplicate URLs
302 不传递 canonical	临时重定向不作为"目标应为 canonical"的信号	Redirects and Google Search
GSC 数据上限	API：50K 行/天/搜索类型/属性；单次请求 rowLimit ≤ 25000	Export data using the API
Bulk export 不回填历史	首次导出在配置后 48 小时内，此前数据不包含	Bulk data export
BigQuery 平均排名算法	sum_position 是 0 基，平均排名 = SUM(sum_position)/SUM(impressions) + 1	导出表字段说明
跨域整站迁移工具的边界	只支持域名级、需双向验证、信号转发 180 天	Change of address tool
GA4 落地页口径	会话首个 pageview 的路径，会话级作用域	Landing page report

---

为什么"多个网站"不等于更大的搜索覆盖

多站点本身完全正常。合法理由至少有四种：不同品牌、不同语言、不同市场主体、不同产品线且客户群不重叠。问题出在第五种——"多一个站就多一份流量"。

三种冲突不是一回事

很多团队把它们混为一谈，但处理方式完全不同：

类型	定义	发生位置	是否违规	处理方向
站内蚕食	同一站点内多个页面在争同一个搜索需求	一个域名内	否	合并或差异化
跨域竞争	同一公司的多个域名在争同一个搜索需求	多个自有域名	否	分工、冻结，必要时跨域合并
doorway abuse	为抢排名而造出的近似站或近似页	多个域名或页面	是	停止并整改

前两种是效率问题，不违规。【官方】 Google 的态度是：内容重复本身不会被处罚，除非你是故意骗人、操纵搜索结果。Google 会做的事是：把内容重复的网址归成一组，自己选一个当代表，把其他网址的外链权重合并到代表上。

第三种才违规。【官方】 垃圾内容政策点名了三种门页滥用：建一批只在网址和首页上略有差异的网站来抢排名；建一堆地区性域名然后把访客全导到同一个页面；批量造页面当入口、把人引到网站里真正有用的部分。同一份政策还说了：故意把批量生产的内容分散到多个站来掩盖其批量性质，也属于违规（scaled content abuse）。

判断自己有没有踩线：三个问题

【框架】 拿第 2 到第 N 个站逐个问：

1. 独立价值：关掉这个站，客户会不会失去某种在别处拿不到的东西（不同产品线、服务范围、法律主体、本地化支持）？
2. 独立运营：它有自己的产品数据、报价流程和联系人，还是同一套内容换了个模板和域名？
3. 独立需求：它承接的搜索需求能不能用一句话说清，而且这句话跟其他站不重复？

三个都答不上来的站不需要做 SEO，需要的是决定它该关停、并入还是重新定位。

本节动作：列出全部自有域名，逐个回答这三个问题填进一张表。这就是「中央关键词表在现实中能不能用」一节说的 Domain Charter（域名定位表）。

---

从查询到询盘：完整的决策链

大多数多站点方案失败，都是因为只做了前半段——把词分到各站，然后就没然后了。完整链条是一个闭环：

关键在最后那根回流线：询盘和销售反馈会反过来改变关键词簇的边界、页面定位和优先级。没有这根线，前面七步就只是一次性的分词表，三个月后就跟现实脱节了。

【示例】贯穿全文的例子

虚构公司 P 是塑料托盘制造商，有 12 个英文站，其中 4 个真正活跃。

① 真实查询——用户实际在 Google 搜索框里打的字：

food grade plastic pallets
hygienic plastic pallet supplier
sanitary pallets for food industry

query（搜索词）是原始数据。不要给每个 query 单独建一个页面，这条纪律是后面一切的前提。

② 搜索意图——三个 query 用词不同，但要解决的是同一件事：为食品、医药或洁净场景找卫生型塑料托盘供应商。这是采购意图，不是查资料。

③ 关键词簇——把能由同一个页面满足的 query 归到一起，得到 Cluster: Hygienic / Food-grade Plastic Pallet。簇的单位是需求，不是某个固定词组。

④ 主域名——12 个站里只有一个最适合承接这个需求：面向工业托盘采购商的 B 站。判断依据包括目标国家、站点定位、现有排名、外链质量、产品资料完整度和已有的有效询盘。不是谁先抢到这个词就归谁。

⑤ 主页面——一个簇只指定一个核心采购页 /hygienic-plastic-pallet/，放产品说明、规格表、应用场景、质量证据（材质证书和认证）和询价按钮。

⑥ 辅助页面——不是复制主页面，而是回答更窄的问题：食品行业客户案例、清洁与消毒指南、HDPE 与 PP 材料比较、冷库与医药仓储应用、尺寸与承重选型。它们通过内链支持主页面，但绝不能把自己的标题也写成 Hygienic Plastic Pallet Supplier——这是站内蚕食最常见的起因，往往是内容团队"顺手优化 SEO"造成的。

⑦⑧ 连到询盘——真实的数据链不是"一个关键词直接对应一个客户"：

GSC：query → landing page（落地页）
GA4：landing page → inquiry key event（询盘关键事件）
CRM / 销售：inquiry → 有效 / 无效 / 报价 / 成交

【官方】 GA4 里的 landing page（落地页）就是用户在一次访问中打开的第一个页面。在同一个报告里可以看到 key events（关键事件）；但 key event 需要你先采集事件、再手动标记为"关键"，它不会自动出现。

一个必须承认的局限：因为隐私保护和数据截断，通常做不到把每个搜索词精确对应到某个具体客户。只能在落地页、产品、国家和时间段这些粗粒度上做近似判断。任何方案声称能把自然搜索询盘精确归因到具体关键词，先问它怎么绕过 GSC 的匿名查询机制。

本节动作：在你的分析表里把"关键词"和"落地页"分成两列，转化数据只挂在落地页那一列。这一条能挡掉后面 80% 的错误归因。

---

关键词簇是什么，又不是什么

同一个词不一定代表同一个意图：plastic pallet 可能是找供应商、查价格，也可能是学生查资料。判断依据不在词本身，而在搜索结果页（SERP）上排的是什么类型的页面。

不同的词可能代表同一个意图：hygienic plastic pallet 和 sanitary pallets for food industry 文字完全不同，但用同一个页面就能同时满足。

所以归类的正确标准是"同一个页面能不能同时满足这些词"，而不是"这些词长得像不像"。

五维判据

【框架】 判断两个 query 该不该归进同一个簇，对着这五条逐条看：

维度	要问的问题	【示例】
产品实体	指向同一个可售物品吗？	卫生型塑料托盘 = 同一实体
修饰词性质	修饰词改变的是属性还是产品本身？	food grade / hygienic / sanitary 都是"洁净等级"这一个属性
市场与语言	目标国家和语言相同吗？	都是英文 / US、UK
意图类型	采购、比较、学习还是导航？	都是采购
SERP 重合度	搜索结果前 10 名有多少网址重合？	见下

SERP 重合度的具体做法：从簇里挑 3—5 个有代表性的 query，在目标国家用浏览器的无痕模式各搜一次，记下前 10 个自然结果的网址。【框架】 重合 ≥3 个就按同簇处理，≤1 个就按不同簇处理，正好 2 个的放进人工判断池。这个阈值是我的经验值，不是 Google 标准，你可以按自己行业调整，但必须先定死再执行——不定死的话，归类就变成谁嗓门大谁说了算。

一个正例和一个反例

【示例】正例——应该归为一簇：

food grade plastic pallets
hygienic plastic pallet supplier
sanitary pallets for food industry
plastic pallets for food processing

四个词的搜索结果前 10 名高度重合，都是供应商产品页和分类页，一个 /hygienic-plastic-pallet/ 就能满足全部。

【示例】反例——看起来像一簇，其实必须拆开：

plastic pallet price per unit          → 采购意图，比价阶段
plastic pallet vs wooden pallet        → 比较意图，选型阶段
how to clean plastic pallets           → 使用意图，已购客户
plastic pallet recycling               → 处置意图，完全不同的客户旅程

四个词都含 plastic pallet，却分属不同阶段，搜索结果类型也不同（比价页、对比文章、操作指南、回收服务）。硬塞进一个页面的结果是四个都不排名。

什么时候一个簇要拆成信息页和采购页

【框架】 当同一个簇的搜索结果前 10 名稳定出现两类页面（比如 6 个产品页 + 4 篇教程），说明 Google 认为这个搜索词同时包含两种需求。做法是：主页面仍然只有一个、负责采购意图；另建一个信息页负责学习意图；两者用内链连起来，信息页的行动按钮指向主页面。两个页面的标题必须让不懂业务的人一眼就能分清。

本节动作：给每个候选簇写一句"这个簇要用一个页面回答什么问题"。写不出这一句的，说明它还不是一个真正的簇。

---

怎样从 GSC 找出值得治理的前 50 个簇

先选对取数方式

十几个站不可能靠手工一个个复制数据。三种取数方式各有各的限制：

方式	单次上限	历史数据	适用规模	官方依据
GSC 界面导出	1000 行	有	单站抽查	—
Search Analytics API	rowLimit ≤ 25000/请求，50K 行/天/搜索类型/属性	有	3—20 个站	API 参考、导出说明
BigQuery Bulk Export	无实际行数上限	不回填	长期建设	Bulk data export

这里有个很容易踩的坑。【官方】 BigQuery 批量导出（Bulk Export）的第一批数据，是在你配置成功后 48 小时内才开始攒的。配置之前的历史数据拿不到，官方也明确说了要看历史得回去用 API 或界面报表。所以正确顺序是：

1. 今天就给所有站配好批量导出——它只往后攒数据，越早开越好；
2. 同时用 Search Analytics API 拉过去 6 个月的历史（startRow 分页，rowLimit 设 25000）；
3. 两份数据分开存，别试图对齐——因为它们的统计口径不一样（原因见下面）。

一个必须知道的统计口径差异

【官方】 GSC 在不同维度上用了不同的统计方法：query（搜索词）、country（国家）、device（设备）、date（日期）这些维度按整个站来统计；page（页面）和 search appearance（搜索外观）按单个网页来统计。

这就是 GSC 里图表数字和表格数字经常对不上的原因。

对你意味着什么：不能把各个页面的搜索词展示量直接加起来当成簇的总展示量。同一次搜索如果涉及你的多个网址，两种统计方式下会被记成不同的数字。【框架】 我的做法是：看簇级展示量时只用 query 维度的汇总数字，页面维度的数据只用来判断"这个词主要落在哪个页面上"。两个数字在报告里分开列，永远不做加减。

BigQuery 里算平均排名的正确写法

【官方】 BigQuery 导出表里的 sum_position 字段是从 0 开始计数的（排名第 1 的位置记为 0），所以算平均排名时最后要 +1：

-- searchdata_url_impression：按页面看某个簇的表现
SELECT
  url,
  SUM(impressions)                                     AS impressions,
  SUM(clicks)                                          AS clicks,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions))           AS ctr,
  SAFE_DIVIDE(SUM(sum_position), SUM(impressions)) + 1 AS avg_position
FROM `project.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-01-01' AND '2026-06-30'
  AND country = 'usa'
  AND is_anonymized_query = FALSE
  AND REGEXP_CONTAINS(query, r'(hygienic|sanitary|food.grade).*pallet')
GROUP BY url
ORDER BY impressions DESC

写成 AVG(position) 是错的——那是没有加权的平均值，跟真实排名会有偏差。

七步流程

【框架】

1. 导出每个站过去 6 个月的 query、page、country、clicks（点击）、impressions（展示）、CTR（点击率）、position（排名）。
2. 排除品牌词——【官方】 GSC 效果报告从 2025-03-11 起提供了品牌词 / 非品牌词筛选器，但它不适用于子属性（如 example.com/blog/）和展示量过少的站点——如果你的报告里看不到这个筛选器，就需要自己维护一份品牌名正则来过滤（记得包括拼写错误和域名变体）。用 API 取数时同样用正则。
3. 归一化（只用来生成候选分组，不覆盖原始 query 列）：转小写、去首尾空格、压缩连续空格；单复数归一（pallets → pallet）；去掉 for、of、the、in 等停用词；把单词排序生成 key，让 plastic pallets food grade 和 food grade plastic pallet 都变成 food grade pallet plastic；最后人工维护一张同义词映射表（hygienic ↔ sanitary ↔ food grade）——这一步没法自动化，因为两个词是不是同义取决于具体行业。
4. 按产品 + 意图归类，再用上一节的 SERP 重合度来复核。归一化只产生候选，最终成簇必须人工确认。
5. 汇总簇内所有 query 的展示、点击、平均排名（注意上面说的统计口径差异）。
6. 补两列非 GSC 数据：产品商业价值（让销售或产品经理来填，不要 SEO 自己填）和该簇落地页过去 6 个月的有效询盘数。
7. 打分排序，取前 20—50 个进治理范围。

高价值簇评分表

【框架】 满分 100。这是个排序工具不是预测工具——它的作用是让"先做哪个"有据可查，不是说得分高就一定效果好。

维度	权重	评分标准
需求规模 D	25	簇月均展示 ≥5000 → 25；1000—4999 → 18；200—999 → 12；50—199 → 6；<50 → 2
商业价值 V	30	由销售按毛利 × 复购 × 成单周期打 1—5 分，再 ×6
竞争可行性 F	20	自有页面最好排名 1—3 → 8（已拿到，提升空间小）；4—10 → 20；11—30 → 14；31+ 或无 → 6
资产就绪度 R	15	已有可承接页面 + 完整规格与证据 → 15；有页面缺证据 → 9；两者皆无 → 3
冲突损耗 C	10	自有站中争同一簇的页面数 ≥4 → 10；2—3 → 6；1 → 0

一条越级规则：只要某个簇在过去 6 个月产生过哪怕 1 条销售确认的有效询盘，不管得分多少都直接进人工复核池。有真实成交证据的簇比单纯数字大的簇更值得重视。

【示例】 卫生托盘簇：D=18（月均 2400 展示）、V=24（销售打 4 分）、F=20（最好排名第 7）、R=9（有页面但缺认证材料）、C=6（3 个页面在争）→ 总分 77，排进前 10 优先处理。

"只有一次展示"到底该怎么处理

这是实操中最容易被滥用的数据。先说一个直觉：观察次数越少，"没发生"就越不能当结论。

统计学里有个简单规律叫三法则（Rule of Three）：如果你观察了 n 次、某件事一次都没发生，你最多只能说"这件事每次发生的概率大概不超过 3÷n"。

举个例子：你丢了 100 次硬币、一次正面都没出现。3÷100 = 3%，所以你可以比较有把握地说"正面的概率低于 3%"。但如果你只丢了 1 次，3÷1 = 300%——300% 比 100% 还大，等于什么结论都下不了。

套到 GSC 的展示和点击上：

展示了多少次	0 次点击时，真实点击率最高可能是多少	说明什么
1 次	最高约 300%（比 100% 还高，没意义）	什么都说明不了
30 次	最高约 10%	几乎说明不了什么
100 次	最高约 3%	勉强能说"点击率不超过 3%"
300 次	最高约 1%	可以说"点击率确实很低"

简单说：想下"这个簇点击率异常低"的结论，至少得有上百次展示。而且"低"的参照必须是你自己网站在类似排名位置的历史点击率，不是什么行业平均值。同理，只展示了 1 次对应的"平均排名"就是一个孤零零的数字，根本撑不住任何趋势判断。

【官方】 还有一个更麻烦的事：搜索量极少的关键词会被 GSC 匿名处理，直接从报表里消失。所以"只有 1 次展示"甚至不能证明它真的只被展示了 1 次——可能还有几次被隐藏了。

【框架】 六种情况分别怎么处理：

情况	怎么处理
1 次展示、0 点击、0 询盘	放进观察池，不要据此改页面
连续几个月每月都只有 1 次	仍然数据太少，继续观察，可以当选题灵感
20 个近义 query 各 1 次展示	合在一起看有点价值（总共 20 次展示还是偏少，但至少成了一个观测单位）
1 次展示 → 1 次点击 → 1 条有效询盘	数据少但商业价值高，人工核实这条询盘的真实来源
销售明确说这个产品值钱	可以先做内容试试，不用等展示量攒够
排名 4—30 但展示不到 50 次	数据不够做决策，回观察池

所以"排名 4—30"永远不能单独当筛选条件，至少要和展示量、重复出现次数、商业价值、询盘四项一起看。

本节动作：今天就给所有站配好批量导出（它不回填历史，晚一天开就少一天的数据），同时用 API 拉 6 个月历史，再按评分表产出前 20 个簇。

---

两个页面：差异化还是合并

决策树

【框架】 按顺序问下去，碰到第一个符合的答案就是结论，不要跳步：

两个页面命中同一个簇吗？
├─ 否 → 不是冲突。登记为不同簇，结束。
└─ 是
   ├─ Q1 搜索意图相同吗？
   │      否 → 【保留两页】明确各自意图，重写标题，互相内链
   ├─ Q2 目标国家或语言相同吗？
   │      否 → 【保留两页】配 hreflang（多语言标签），绝对不要 301
   ├─ Q3 产品实体、规格或应用场景不同吗？
   │      是 → 【保留两页】各自建独立簇
   ├─ Q4 过去 6 个月两页各自都产生过有效询盘吗？
   │      是 → 【内容差异化】有真实询盘的不要为了整齐而合并
   ├─ Q5 弱页有独立外链、品牌资产或长期合作方引用吗？
   │      是 → 优先【内容差异化】；确需合并则必须 301 保住外链信号
   └─ 全否 → 【合并 + 301】

内容差异化不是只改标题就完事，必须同时做四件事：标题和大标题（让人一眼分辨两个页面是干嘛的）；正文第一屏（前 200 字说清"这一页是给谁看的"）；内链方向（弱页指向强页，不要互指）；行动按钮（一个放"询价"，另一个可以放"下载选型指南"）。

【示例】合并的七步

公司 P 的 B 站有两个页面在争卫生托盘这个簇：/hygienic-plastic-pallet/（月均 1800 展示、5 条询盘）和 /food-grade-pallet-supplier/（月均 260 展示、0 询盘、没有外链）。走完决策树命中"合并 + 301"。

1. 备份两页数据：各自 12 个月的 GSC 表现、GA4 落地页数据、当前页面快照、外链列表。这是回滚依据，也是事后判断合并效果的基线。
2. 搬内容：把弱页独有的规格参数、FAQ、图片和案例重新编辑进强页——不是复制粘贴，要融入强页的结构。
3. 改内链：全站指向弱页的内链直接改成强页网址，不要留给 301 来兜底——多一次跳转就多一次出错机会。
4. 上 301：弱网址 → 强网址，用服务端 301 或 308 永久跳转。【官方】 Google 明确说服务端重定向"被正确识别的概率最高"，而临时重定向（302）不会让 Google 把目标当成正式网址（canonical）。
5. 更新 sitemap、canonical 和结构化数据：弱网址移出 sitemap；强页保持自引用 canonical（告诉 Google"我就是正式版本"）；Product/FAQ 等结构化数据合并到强页。
6. 消灭链式跳转：确认没有 A→B→C 的连环跳，全部改成 A→C 直达。
7. 监测：【官方】 用 Search Console 的 sitemap、索引和搜索报告同时看新旧网址的抓取和流量变化。至少看 4—8 周，别在第 5 天就下结论。

本节动作：把第 1 步的备份做成模板文件（配套执行包里有完整清单）。没有基线数据的合并，事后既判断不了成败，也回滚不了。

---

为什么 301 至少要保留一年

【官方】 Google 在站点迁移文档里的原话是：

Keep the redirects for as long as possible, generally at least 1 year.

这里要纠正一个常见误读："至少一年"是最低要求，不是"第 366 天就能安全删除"的意思。

理由有四个：

1. 【官方】 301 只是告诉 Google"这个网址搬家了"的信号，不是立刻生效的命令。Google 得重新访问旧网址和新网址才能完成权重转移。
2. 不同页面被 Google 访问的频率差异很大。冷门页面可能隔几个月才被爬一次。
3. 用户收藏的旧链接远比一年活得久——书签、几年前的邮件、客户存的 PDF 报价单、第三方 B2B 目录、行业协会网站上的链接。
4. 提前撤掉 301，这些链接立刻全变 404。丢的不只是 SEO 信号，是正在找你的采购商打不开页面。

一个容易搞混的 180 天

【官方】 Change of address 工具（换址工具）会把旧站的权重信号转发给新站，但只转发 180 天。

注意：这 180 天不是说 301 只需要保留 180 天。 它只是 Google 主动帮你转发信号的时间窗口。窗口关了之后 Google 不再认为两个站有关系，但你的 301 仍然需要继续保留——因为还有大量网址没被重新爬取、还有真人在用旧链接。

把这两个数字搞混，是我见过代价最大的迁移错误之一。

三种情形要区别对待

【框架】

情形	建议	理由
整站迁移	至少一年，这是官方底线	全部信号需要重新分配
单页合并	维护成本低的话长期保留	一条重写规则成本接近零，收益是旧链接永远不断
内容已不存在且没有合适的替代页	返回 404 或 410，不要跳首页	把无关网址跳到首页对用户和 Google 都是噪音

第三条值得强调：不要为了"避免 404"把下线的页面统统跳到首页。用户点进来发现不是自己要找的内容会直接关掉，Google 也会把这种跳转当作"假装有内容实际没有"（软 404）来处理。没有对应内容的时候，老老实实返回 410（意思是"永久删除了"）比敷衍地跳首页更诚实也更有效。

【真实】一个只能说明单站流程的小例子

我把这个博客从 yesyes.qzz.io 迁到 eigentime.org 时，决定旧域名的 301 至少保留 12 个月作为回滚保障，完整复盘在这篇。站内改路径和撤稿我也用同一套纪律：改路径 → 加 301；撤稿 → 返回 410 + X-Robots-Tag: noindex 而不是普通 404，因为 410 明确告诉搜索引擎"这页永久删了"，比 404 的"暂时找不到"更快促使它摘除索引。

还有一个真实踩过的坑：重定向规则写好了，但边缘路由只对显式登记过的路径才运行 Worker——只写了规则没登记路径，301 就是死代码：代码对、测试过、构建绿灯，线上照样返回 404。 教训适用于所有平台：

重定向上线后必须用 curl -I 在真实域名上实测状态码。本地测试通过不等于线上生效。

这个例子的边界：它只能说明单站搬家和撤稿的流程可行，不能当多站点治理的成效证据。我没有十几个站的 GSC 和 CRM 数据，本文里关于多站的内容都是方法框架，不是我的实测结果。

本节动作：给每条 301 在配置文件里加上"创建日期"注释，把"重定向清单年度复核"排进日历。默认动作是保留，要删必须写明理由。

---

跨域竞争：差异化、冻结还是合并

跨域比站内难处理，因为牵扯的不只是页面，还有人和绩效考核。【框架】 严格按四个层级来，不要跳级：

第 1 级：明确分工。 成本最低、风险最小。写清楚"A 站做欧洲的重载托盘，B 站做北美的卫生托盘"，大半冲突自然就没了，一行代码都不用改。

第 2 级：给次要站重新定位。 次要站不再正面跟主站争同一个簇，转去做它有独特资格做的角度——本地化服务、特定认证、特定行业。它仍然可以有关于卫生托盘的内容，但不再有争采购意图的采购页。

第 3 级：冻结。 冻结必须定义清楚才能执行：停止在弱站新建同意图的采购页；已有页面不删、不加 noindex、不做 301；也不再给已有页面追加优化投入（不扩词、不加内链）；观察 8—12 周，看主站是否接住了流量和询盘。冻结可逆，这是它最大的价值——观察期结束后再决定是回退（重新差异化）还是推进（合并）。

第 4 级：跨域 301 或整站合并。 只在证据充分时做。证据要包括：弱站这个簇连续两个季度没有有效询盘、没有独立外链价值、而且主站已经证明能接得住。

为什么不要用跨域 canonical 来解决

先解释一下 canonical（规范网址标记）：你可以在页面里加一个标签，告诉 Google"这个页面的正式版本在另一个网址"。但——

【官方】 canonical 是建议不是命令。Google 会自己判断哪个网址才是最佳代表。官方给出的信号强度排序是：301 重定向（最强）> rel=canonical 标签（较强）> sitemap 声明（较弱）。

跨域 canonical 在自有站之间经常失败：你标了 canonical，但两个页面内容差异够大，Google 认为它们不是重复内容，就直接忽略你的声明——结果你以为冲突解决了，实际两个页面还在互相争，而且没有任何报错告诉你。【框架】 跨域整合优先用 301（内容和意图确实一样时）或内容差异化（不一样时）。跨域 canonical 只在一种场景下好用：同一份内容被合作方合法转载，你要声明原创归属。

整站合并前必须了解的工具限制

【官方】 Change of address 工具有三条硬限制：只能用于域名级别的整站搬家，不能处理 example.com/petstore/ 这样的路径级迁移；必须同时是新旧两个站的所有者；不会自动迁移子域名（包括 www），每个子域要单独申请。

这意味着"只把 A 站的托盘产品线搬到 B 站"这种局部合并用不上这个工具——只能靠一个个网址写 301、更新 sitemap 和内链，然后等 Google 重新爬取。低估这件事的工作量，是跨域合并翻车的常见原因。

本节动作：先把第 1 级（分工）和第 3 级（冻结）做完，观察一整个季度。任何跳过前三级直接谈跨域合并的方案，都应该打回去。

---

中央关键词表在现实中能不能用

结论：能用，但必须比大多数人想象的小得多。

不能用的版本长这样：把所有长尾 query 塞进人工表格，给每个词标一个"归属站"，其他站"禁止做"。它失败的原因很具体——长尾关键词无穷无尽，人工维护跟不上；"禁止"没有例外机制，碰到真实业务需求就会被绕开；一旦被绕过一次，整张表就没人当回事了。

可用的 MVP 表结构

【框架】 只登记高价值簇：

Cluster ID	需求 / 意图	市场语言	主域名与页面	其他站允许范围	负责人	状态	最后复核
PAL-HYG-001	卫生托盘采购	英文 / US、UK	B 站 /hygienic-plastic-pallet/	允许食品行业案例与清洁指南；不允许新建同意图采购页	张三	active	2026-07
PAL-HD-002	重载托盘采购	英文 / EU	A 站 /heavy-duty-pallet/	允许仓储自动化应用文；不允许新建采购页	李四	active	2026-07
PAL-HYG-003	托盘清洁方法	英文 / 全球	B 站 /blog/clean-plastic-pallets/	各站可引用并内链，不得建同标题页	张三	watching	2026-06

注意第三行：信息类的簇也要登记，因为它恰恰是最容易被各站重复生产的类型。

八条让它活下来的规则

【框架】

1. 只登记前 20—100 个高价值簇，不登记所有 query。长尾关键词靠原则约束，不靠表格。
2. 每个新产品页或解决方案页必须填 Cluster ID。填不出来说明定位没想清楚——这本身就是有价值的拦截。
3. 博客可以覆盖长尾问题，但不能抄主页面的采购意图。判断标准要硬：标题含 supplier / manufacturer / for sale / price 的页面必须走登记流程。
4. 把"禁止"改成"允许范围 + 例外"，留一个申请例外的入口。太僵硬的规则只会被绕开。
5. 每月只审两件事：本月新发的内容，和前 20 个高价值簇有没有新冲突。不做全量审计。
6. 必须有一个人有裁决权。没有裁决权的协调者不是负责人，是记录员。
7. 每条记录写"最后复核"日期，超过 6 个月没复核的自动降为 stale，月会上强制过一遍。
8. 如果绩效只看个人站点，必须加一个全局共享指标。这条最容易被跳过，也最致命——如果让出一个簇会直接拉低自己的绩效，再好的规则也会在压力下变成废纸。

让表格真正生效的发布门禁

表格本身没有约束力，门禁才有。【框架】 最小可行的门禁：在内容管理流程里加一个必填的 clusterId 字段，发布前做三项自动检查：

1. clusterId 是否存在于登记表？        → 否则拒绝发布
2. 该 clusterId 的主域名是否 = 当前站？ → 否则要求填写"允许范围"依据
3. Title 是否命中采购意图词表
   (supplier / manufacturer / price / for sale / buy)
   且当前站不是主域名？                 → 转人工审批

三条检查加起来不到一天的开发量，但能把治理从"靠自觉"变成"靠流程"。没有门禁的关键词表，寿命一般是三个月。

本节动作：先把表建起来，只填 10 行。10 行能维护住再扩到 50 行。上来就填 500 行的表，一行都维护不住。

---

接下来：谁来负责、30 天怎么排、模板长什么样

判断框架到这里就完整了。把它变成日程和文件是另一件事，我拆成了配套的执行包：

多站点 SEO 治理落地包：30 天计划与三张模板

里面是本文没展开的三样：7—8 人团队的联邦式分工（谁裁决、为什么绩效必须双轨）、30 天落地计划（每周的交付物和退出标准），以及三张可以直接复制的表——簇登记表、301 合并检查清单、跨站冲突登记模板。

---

结论：治理不是消灭重合

成熟的多站点治理，目标不是让十几个站之间关键词零重合——那既不可能也没必要。真正的目标是：

让每一个高价值搜索需求，都有明确的主力页面、明确的责任人、可核实的证据，以及一条可执行的退出机制。

主力页面回答"这个需求由哪个域名的哪个页面来接"；责任人回答"谁对结果负责、谁有权裁决冲突"；证据是落地页询盘和销售反馈，不是排名截图；退出机制回答"什么条件下停止在弱站投入、什么条件下合并、什么条件下回滚"。

关键词重合本身不是病。没人知道该谁负责、也没人能证明哪个页面真的带来了生意，才是病。

---

本文的边界

本文有三类内容，可靠程度不同：

Google 说的（标了【官方】的部分）：这些是 Google 自己文档里白纸黑字写的规则。每条都附了出处链接，你可以点进去核实。可以放心引用。

我总结的方法（标了【框架】的部分）：比如评分表的权重怎么分、SERP 重合度多少算同簇、跨域冲突按什么顺序处理。这些是我根据官方规则和实际经验总结出来的做法。你可以直接拿来用，但如果你的数据告诉你另一种做法更好，以你的数据为准——框架是起点不是终点。

编的例子（标了【示例】的部分）：公司 P、它的 12 个站、所有展示量和询盘数字都是虚构的，不代表任何真实客户，也不是效果承诺。

我没有的东西：任何一家公司真实的域名清单、内部关键词分配、团队人数、绩效制度、各站的 GSC/GA4/CRM 数据，以及"用了这套方法之后增长了多少"这类结论。我手上没有这些数据，所以文里一个字都没写。「为什么 301 至少要保留一年」一节那个域名迁移是我自己博客的真实经历，但那只是一个站搬家，不能当多站点治理的成效证据。