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

这是《多站点 SEO 治理：从关键词簇到页面合并与跨域分工》的配套执行包。

主文回答的是怎么判断：哪些冲突要合并、哪些要差异化、301（永久跳转）该留多久、跨域该按什么顺序处理。这篇回答的是怎么落地：谁来干、30 天怎么排、表格长什么样。

和主文一样，全文用【框架】标注属于我的操作方法——可以直接拿来用，但不是 Google 官方标准，也没经过随机对照实验验证。如果你的数据告诉你别的做法更好，以你的数据为准。

先对齐三个术语

没读过主文也能用这篇，但要先接受三个定义：

关键词簇：一组能由同一个页面满足的搜索词。单位是"需求"，不是词组。判断方法见主文的五维判据与 SERP 重合度。
主域名与主页面：一个高价值簇只指定一个域名、一个核心页面来承接采购意图，其他站只能做辅助内容。
冻结：停止在弱站新建同意图页面，但已有页面不删、不加 noindex、不做 301，观察 8—12 周。冻结可逆，这是它的全部价值。

判断两个页面该保留、差异化还是合并，用主文那棵决策树，本文不重复。

谁来负责：7—8 人团队的联邦式治理

【框架】这一整节是我根据官方搜索机制和团队协作需求总结的操作方法。

小团队管十几个站，完全集中管理和完全放任都不行：前者让中央成为瓶颈，后者就是"每个站各自抢词"的乱局。可行的中间态是联邦式——中央决定每个簇归谁，各站保留自己日常运营的自主权。

角色	人数	负责	不负责
中央负责人	1	域名定位表、簇登记表、跨站规则、冲突裁决	各站的日常内容和优化
站点负责人	5—6	自己站的内容、优化、询盘转化	跨站分工的最终决定权
数据 / 技术支持	1	GSC/GA4/CRM 打通、取数脚本、门禁检查	内容判断

三条运转规则：

新页面发布前走轻量检查：只查三项——clusterId 是否已登记、该簇的主域名是不是当前站、标题是否含采购意图词（supplier / manufacturer / price / for sale / buy）且当前站不是主域名。不做全面审稿，目标是几分钟内出结论——审查一慢，人就想办法绕过它。
跨站冲突由中央负责人裁决，给出 SLA（响应承诺）：提交后 5 个工作日内出结论，写明依据（哪个簇、看了什么数据、为什么判给这个站）。裁决必须留痕，下一次同类冲突要靠它当判例。
绩效双轨：站点负责人保留自己站的询盘指标，同时加一个全局指标（比如所有站合计的有效询盘数，或前 20 个簇的合计有效询盘数）。

第 3 条是整个模型的成败关键。如果一个站点负责人把某个簇让给别的站会直接导致自己绩效下降，那再好的规则都没用——不是因为人不配合，而是因为规则在要求他损害自己的利益，这不可持续。你可以自己验证这条因果链：先看你的绩效结构是否在惩罚正确的行为，再谈执行力。

本节动作：把上表填上真实姓名。如果"中央负责人"这一格填不出来，不要开始做多站点治理——先解决授权问题。

30 天落地计划

【框架】 每周都有交付物和退出标准。做不到退出标准就不要进下一周。

第 1 周：盘家底

输出域名清单：域名、产品线、目标市场、站点负责人、GSC/GA4/CRM 数据权限是否打通。
给每个站打标 active / 重新定位 / 候选关停。判断标准是三个问题：关掉它客户会不会失去别处拿不到的东西？它有自己的产品数据和报价流程吗？它承接的搜索需求能不能用一句不跟其他站重复的话说清楚？
找出 3—5 个真正活跃的核心站（有在更新、有流量、有询盘的）。
同时给所有站配置 BigQuery 批量导出。这一步很容易被排到后面，但它不回填历史数据——第一批数据只在配置成功后 48 小时内开始攒，之前的数据永远拿不到。今天配和下个月配，差的就是一个月的数据。

退出标准：每个域名都有负责人姓名和数据权限状态，没有"不确定"。

第 2 周：建簇

用 Search Analytics API 导出 6 个月 GSC 数据（rowLimit 设 25000，startRow 分页）。批量导出拿不到历史，这一步只能走 API。
归一化 + 聚类，用主文的评分表选出前 20—50 个高价值簇。
找出 10 个最明显的冲突（同一个簇有 ≥2 个自家页面在争的）。
逐个走主文的决策树，写出处置结论。

退出标准：每个冲突都有一个结论（保留 / 差异化 / 合并 + 301），而且都写明了依据。

第 3 周：试点

只选一个产品簇。同时开三个，出了问题你分不清是哪个动作起的作用。
做完差异化或单页合并，走本文「三张可复制模板」里的 301 检查清单，一定先备份。
在弱站执行冻结：停止新建同意图内容，已有页面不动。
记录基线：合并前的展示、点击、平均排名、落地页 key events（关键事件）、询盘数。

退出标准：301 已经用 curl -I 在真实域名上实测通过了；基线数据已存档。

第 4 周：验证与制度化

检查四层：抓取（GSC 是否已经爬到新旧网址）、索引（旧网址是否已经让位）、排名（这个簇的平均排名趋势）、转化（落地页 key events 和销售反馈）。
根据结果三选一：复制到下一个簇 / 调整方案再试 / 回滚。
建立每月跨站复盘机制。我把自己在用的月报结构做成了公开模板，见 GSC / GA4 SEO 月度复盘模板，可以直接改成多站版本。
上线「谁来负责：7—8 人团队的联邦式治理」里那三项发布门禁检查。

退出标准：下个月的复盘会已经在日历上了，而且有明确的主持人。

一个必须说清楚的预期

4 周不够看到稳定的排名和询盘变化。 第 4 周检查的是"动作有没有正确执行、方向有没有明显错误"，不是"效果好不好"。真正的效果判断需要 8—12 周，而且要在簇级（一组相关搜索词）而不是单个关键词级去看。任何承诺 30 天见效的多站点方案，都是在卖幻觉。

三张可复制模板

A. Cluster Registry（关键词簇登记表）

CSV 表头，可直接粘进表格工具：

cluster_id,intent,market_locale,primary_domain,primary_url,allowed_scope,owner,status,last_review,score,inquiries_6m

填好长这样：

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

（示例数据来自主文那家虚构的塑料托盘公司，不代表任何真实客户。）

字段规则：

cluster_id：产品缩写-属性缩写-序号，比如 PAL-HYG-001。编号一旦分配就永不复用，页面下线了也不回收。
status：active（正在治理）/ watching（观察中）/ frozen（弱站已冻结）/ stale（超 6 个月没复核，需要强制复核）。
allowed_scope：写"允许 X；不允许 Y"，不要只写"禁止"。太僵硬的规则只会被绕开。
inquiries_6m：过去 6 个月这个主页面的有效询盘数，由销售来填，不是 SEO 填。

第三行那种信息类的簇也要登记——它恰恰是最容易被各站重复生产的类型。

只填 10 行开始。 10 行能维护住再扩到 50 行；上来就填 500 行的表，一行都维护不住。

B. 页面合并 301 检查清单

上线前：

[ ] 两页 12 个月 GSC 数据已导出存档
[ ] 两页 GA4 落地页 + key events 数据已存档
[ ] 弱页 HTML 快照已保存
[ ] 弱页外链清单已导出
[ ] 弱页独有内容（规格/FAQ/图片/案例）已重新编辑进强页
[ ] 全站指向弱页的内链已改为直接指向强页
[ ] 301/308 规则已写好（服务端，非 meta refresh，非 JS）
[ ] 确认无 A→B→C 链式跳转
[ ] 弱页已移出 sitemap，强页保持自引用 canonical
[ ] 结构化数据已合并到强页

上线后：

[ ] curl -I 在真实域名实测返回 301 且 Location 正确
[ ] 移动端与桌面端均验证
[ ] GSC 提交更新后的 sitemap
[ ] 第 1、2、4、8 周各记录一次新旧 URL 的抓取、索引、展示、点击
[ ] 落地页 key events 与销售反馈同步跟踪
[ ] 301 规则写入年度复核清单，默认动作为保留

前四项是回滚依据。没有基线数据的合并，事后既无法判断成败，也没法回滚。最后一项对应主文那条官方基线：重定向"generally at least 1 year"（至少保留一年），而且要删除必须写明理由。

C. 跨站冲突登记模板

冲突编号：
涉及簇 ID：
涉及页面：站点A/URL、站点B/URL
各页 6 个月数据：展示 / 点击 / 平均排名 / 有效询盘
决策树命中节点：Q__
结论：保留两页 / 内容差异化 / 合并+301 / 冻结观察
依据（一句话）：
裁决人：
裁决日期：
复核日期：

这张表最容易被省掉，也最不该省。没有留痕的裁决没法成为判例，下一次同类冲突还得从头吵一遍。

边界

本文的角色分工、SLA、评分和 30 天节奏都属于【框架】——是可以直接拿来用的默认起点，也是可以被你的数据推翻的假设。用之前先想清楚它在你的组织里是否成立。

表格里的公司、站点和数字沿用主文那个虚构案例，不代表任何真实客户，也不构成任何效果承诺。我没有任何一家公司十几个站的真实 GSC/GA4/CRM 数据，也没有"用了联邦式治理后增长了 X%"这类结论——所以这里一个字都没写。

判断依据、官方规则出处和完整论证在主文：多站点 SEO 治理：从关键词簇到页面合并与跨域分工。