2026 年 9 月 24 日，Google 启动了当年第四次垃圾内容更新，覆盖全球所有语言，官方给出的推送周期最长两周；到 10 月上旬，最后一轮推送结束。和前三次（3 月、6 月、8 月）相比，这次推送时间明显拉长，波动也更分散。这意味着"某一天流量掉了就赶紧改站"的排查方式基本失效，真正被检验的是站点长期的结构。
对做多站群出海的企业来说，这次更新值得单独拿出来讲。原因不是"站群被封了"，而是过去那套靠域名数量堆曝光的做法，在 2026 年的成本结构里已经不划算：一边是 Google 把"规模化生产内容"写进垃圾政策，另一边是 AI 搜索把点击截留在结果页。站越多，不等于流量越多；站越多，只等于要维护的资产、要承担的合规和要解释的内容越多。本文只谈技术底座：域名怎么选、hreflang 怎么工程化、抓取数据怎么才不被自己骗、AI 时代该看什么指标。
一、先认清这次更新打的是什么
Google 的垃圾政策里，和多站群直接相关的有三条：scaled content abuse（规模化内容滥用）、site reputation abuse（站点声誉滥用）、expired domain abuse（过期域名滥用）。第一条针对"以操纵排名为主要目的、规模化生产内容"，官方明确说过判断标准不是有没有用 AI，而是"规模乘以对用户是否有独立价值"；第二条针对"在主站挂第三方内容、借主站权重排名"，2024 年 5 月的政策说明里已经明确，单靠 noindex 不算整改；第三条针对"买下有过历史的老域名、丢掉原内容换主题"。
把这三条翻译成站群语言，就是三种最常见的死法：一是同一套模板复制出几十个"城市站""国家站"，页面上除了地名和电话没有任何本地信息；二是几个站互相在页脚、友情链接区堆同一批锚文本；三是买一批过期域名，301 到主站或者直接换皮。这三种做法在 2022 年可能还有效，在 2026 年 9 月这次更新之后，属于"模式太容易被识别"的那一类。
反过来，Google 并没有禁止一个企业拥有多个站点。官方多次表示，多站本身不影响排名，真正影响的是这些站是否分散了内容投入、是否有独立价值。换句话说，站群的合法性不取决于数量，而取决于每一个站能不能回答一个问题：如果这个站明天消失，会不会有一批用户真的找不到替代？
二、三个该扔掉的技术迷信
迷信一：独立 IP、不同 C 段能防"连坐"。这是中文 SEO 圈流传最久的一条。Google 的 John Mueller 从 2016 年到 2022 年多次公开说过同一句话：共享 IP 完全没问题，独立 IP 没有 SEO 优势；即使同 IP 上有垃圾站，也不会因此牵连你的站。真正需要担心的是共享主机带来的资源挤占和攻击波及，那是可用性问题，不是排名问题。把预算花在"多买几个 C 段"上，不如花在 CDN、缓存和稳定性上。
迷信二：子域名是独立站，权重可以"隔离"。Google 的 John Mueller 多次说明，子域名在技术上属于同一站点的一部分；它需要单独在 Search Console 验证、单独看数据，但"独立"不等于"另起一套权重"。真正带有独立地理信号的是 ccTLD，代价是每个域名都要从零积累。把子域名当成"风险隔离墙"，通常只隔离了运营精力，没有隔离风险。
迷信三：站间互链能"养权重"。页脚互链、导航互链、同一批锚文本，是多站群最容易被识别的模式之一。它同时踩两条线：链接方案（link scheme）和 doorway pages（用多个站点或页面承接同一批查询，再把用户导向同一个目的地）。判断标准很朴素：如果这些链接对用户没有导航价值，只是为了让爬虫看见，它就不该存在。
三、架构选型：子目录、子域名还是 ccTLD
这是多站群出海第一个不可逆的决策，因为迁移要付 301 和排名波动的代价。先看一组结构数据：SE Ranking 与 GA Agency 在 2024 年对全球搜索结果的研究显示，ccTLD 占据了 Google 前三名结果的约 56%，在部分欧洲市场超过 80%；子目录约占 20%；子域名只出现在约 3% 的前三结果里。这组数字经常被误读成"ccTLD 最好"，但它真正说明的是：在本地市场，最强的地理信号仍然来自国别域名，而子域名的"半独立"状态在结果页里存在感最弱。
三种结构的取舍，可以压成三句话。子目录（example.com/de/）共享主域权重、上线最快、维护成本最低，适合 2 到 10 种语言、中央团队统一运营的大多数企业。子域名（de.example.com）适合区域团队有独立技术栈、或者内容形态差异很大的场景，代价是权重继承有限、要单独做 SEO。ccTLD（example.de）地理信号最强、本地信任度最高，但每个域名从零开始，注册、DNS、SSL、合规都要单独处理，部分国别域名对注册主体和本地联系人还有额外要求。
所以决策顺序应该是：先问"有没有本地实体和本地团队"，再问"内容是否真的需要按市场彻底重写"，最后才问预算。有本地公司、本地仓、本地客服，ccTLD 值这个钱；只有一个中央团队、内容以产品和技术为主，子目录几乎总是更优解；介于两者之间，用子域名，但要做好"每个子域名都是一个新站"的心理准备。
还有一类经常被混淆：多品牌矩阵。同一集团下不同品牌、不同受众、不同产品线，用独立 .com 是合理的，因为它们本来就是不同的生意；但如果只是同一品牌切了五个国家，却用五个独立域名、五套几乎一样的文案，那不是矩阵，是同一份内容被复制了五遍。
四、hreflang：最容易做错、也最容易自动化的一环
hreflang 的作用只有一个：告诉搜索引擎"这一页还有哪些语言或地区版本，分别在哪"。它不是排名工具，但配错会让多个语言版本互相竞争，或者让德语用户看到中文页。工程上有七条硬规则，建议直接写进生成器，而不是靠编辑手工维护。
第一，自引用。每个语言版本的页面，hreflang 列表里必须包含它自己。第二，双向闭合。A 指向 B，B 也必须指向 A，缺一个方向，整组配置可能被忽略。第三，x-default。它不是必填，但少了它，语言不匹配的用户落到哪个版本由搜索引擎自己判断，通常是英文版或首页。第四，语言地区码要规范。用 ISO 639-1 语言码加 ISO 3166-1 地区码，比如 de-DE、pt-BR、zh-Hant；不要造 en-EU 这种不存在的组合，也不要一会儿 en 一会儿 en-US 混着用。第五，只对可索引页面输出。返回 404、被 noindex、被 robots 屏蔽的页面不要写进 hreflang。第六，canonical 指向自己。不要用 canonical 把德语页指到英文页，那等于告诉搜索引擎"这页不用收录"。第七，别用 JS 注入。hreflang 要出现在初始 HTML 的 head 里，或者写进 sitemap 的 xhtml:link，客户端渲染出来的标签经常来不及被读取。
这些规则听起来琐碎，但放到 5 个站、8 种语言、几百个 URL 的规模上，手工维护必然出错。正确做法是把它变成构建流程的一部分：维护一份"页面乘以语言"的矩阵，静态生成时自动输出 head 里的 alternate、自动生成带 xhtml:link 的分站 sitemap、自动生成语言切换器的真实链接；上线前跑一个校验脚本，检查每条 alternate 的目标是否返回 200、是否双向、x-default 是否指向存在的 URL。这套校验一次写好，之后每次发版都能用。
另外两条经验。其一，Search Console 的国际定位工具早在 2022 年就下线了，现在没有"指定国家"的开关，能依赖的只有 hreflang、URL 结构和服务器行为，不要再找那个按钮。其二，不要根据用户 IP 自动跳转语言，也不要根据 Accept-Language 直接 302。Google 明确说过这类自动跳转会影响抓取，因为爬虫大多没有语言偏好，被跳转到英文版之后，德语页就永远进不了索引。正确做法是给一个不跳转的默认页，让用户自己选，或者用不阻断抓取的提示条。
五、内容层：每个站要有一个"可核验的实体"
多站群最容易滑坡的地方在内容。技术架构可以复制，内容不能。判断一个站群是否健康，我习惯看三个指标：同一目录下的单日发布密度、去掉实体词之后的模板相似度、以及每个站有多少"只有这个站才有"的信息。
第一个指标是防批量。一个正常运营的企业站，单目录一天发三五篇已经是极限；如果某个目录一天出现几十上百篇结构相同的页面，无论内容是不是人写的，都很容易被归到"规模化生产"。第二个指标是防模板，把两篇页面的正文去掉公司名、地名、产品名之后做相似度比对，超过 0.85 基本就是同一套模板换词。第三个指标是防空洞：每个站至少要有 30% 的内容是本地独有的，比如当地的法规、支付方式、物流时效、客户真实问题。这部分内容没法从主站翻译过来，也正因为没法翻译，它才是这个站存在的理由。
与之配套的是"实体一致性"。每个站都应该能清楚回答：公司全称是什么、注册在哪、地址和电话是什么、作者是谁、和主品牌是什么关系。Organization、LocalBusiness、Person 这些结构化数据要写，但更重要的是页面上要能被人看见、被第三方核验。AI 搜索时代这一点变得格外重要：模型在决定引用谁的时候，看的是"这个说法有没有可追溯的来源"，而不是"这个页面关键词密度多高"。
还要提醒一类隐蔽风险：主站挂第三方内容。供稿、白皮书、合作方专栏，如果挂在主域名子目录下、署的是"本站编辑部"、内容对本站读者没有独立价值，就属于站点声誉滥用的范畴。多站群里这种"资源置换"很常见，处理原则是：要么真的有编辑审核和署名，要么放到独立域名，要么不要。
六、抓取与索引：别用 User-Agent 做报表
讲一个我们自己的实测。本站 10 月 12 日到 20 日的 nginx 日志一共 64583 行，其中 User-Agent 里带 Googlebot 的请求有 1147 次。如果只看这个数字，会以为抓取很健康。但按 IP 拆开就露馅了：来自 66.249.*（Google 官方抓取段）的只有 89 次；604 次返回 404，539 次返回 301，只有 4 次拿到 200；490 次请求打在 .env、.git、wp-login、xmlrpc、vendor 这类扫描路径上。更典型的是一个 IP，35.246.249.43，反向解析是 *.bc.googleusercontent.com，它一边以 Googlebot 身份出现 270 次，一边以 OAI-SearchBot 身份出现 166 次。
这就是多站群运维里最容易被忽略的一课：日志里的 UA 是可以随便写的字符串，直接按 UA 统计抓取量，误差可以是十倍量级。可靠的抓取分析必须三源交叉，按官方公布的 IP 段过滤、对可疑 IP 做反向解析、再和 Search Console 的抓取统计对账。这三步做完，你才会发现真正需要优化的是"301 太多"（HTTP 到 HTTPS、带 www 到不带 www 的归一没做好，每次抓取都浪费一跳），而不是"爬虫不来"。
索引侧的基础设施，每个站都要独立配齐：独立的 sitemap、独立的 robots.txt、独立的 canonical 规则。提交渠道要分开看：IndexNow 覆盖 Bing、Yandex、Naver、Seznam 等，一次提交多引擎生效，但不包括 Google 和百度；Google 靠 sitemap 加内链发现；百度的主动推送有每日配额，不能当主力。多站群最容易犯的错是"一套 sitemap 塞所有域名"，结果每个搜索引擎都只能看到一部分。
AI 爬虫要单独做策略。GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot 这些 UA 背后是两种目的：训练语料和实时检索。要不要放开，取决于你的商业模式。希望被 AI 引用，就放开检索类；不希望内容进入训练集，就在 robots.txt 里按 UA 分组限制。但前提还是那句话：先验证 IP，再决定放行，否则你放行的可能只是一个扫描器。
七、AI 搜索之后，站群的 KPI 要重算
2026 年的流量环境已经和"多铺几个站就能多拿流量"的年代不一样了。SparkToro 与 Similarweb 的统计显示，2026 年 1 月到 4 月，美国 Google 搜索里 68.01% 以零点击结束，2024 年这个数字是 60.45%。宾夕法尼亚大学与东北大学的研究者在 2026 年 8 月发布于 arXiv 的预注册随机对照实验更直接：1100 名美国用户被随机分配，强制使用 AI Mode 的一组，跳转到外部网站的点击率下降 18.8 个百分点；而把 AI 概览完全隐藏的一组，点击率反而上升 8.8 个百分点，且用户对信任度、满意度的自评没有可察觉的下降。
但同一批研究也给出了另一面。Seer Interactive 在 2026 年 4 月对 53 个品牌、547 万条查询的统计显示，被 AI 概览引用的品牌，每次曝光带来的自然点击比未被引用的品牌高 120%。换句话说，点击没有消失，而是集中到了"被答案引用的少数实体"身上。Pew 研究中心的对照更早也指向同一方向：有 AI 概览时只有 8% 的用户会点传统结果，没有时是 15%。
这对站群的含义是：过去衡量站群用"收录页数、站点数量、关键词覆盖"，现在要加三个指标，品牌词在 AI 答案里的出现率、被引用页面的比例、以及每个站被第三方提及的次数。一个只有 3 个站、但每站都有独立数据和独立案例的矩阵，比 30 个互相复制、只靠互链撑着的站更抗打。反过来，如果你的 10 个站回答的是同一个问题、用的是同一套论据，那它们在 AI 眼里只是同一个来源的 10 个副本，能拿到的引用不会变成 10 倍。
八、合规：多站不等于多套免责声明
多站群出海还有一个常被技术团队忽略的成本：合规不是"复制一份隐私政策到 8 个站"就完事。面向欧盟用户，没有本地实体的卖家通常需要按 GDPR 第 27 条指定欧盟代表；Cookie 和追踪脚本要符合 ePrivacy 的同意要求；卖实物还要面对 GPSR 的产品安全与责任人义务；2025 年 6 月 28 日起，欧盟无障碍法案对面向消费者的电商服务生效，页面结构、对比度、键盘可操作性都进入义务范围。
这些义务按市场不同而不同，所以每个站的隐私政策、退换货政策、免责声明都应该是本地版本，而不是同一份英文模板的机翻。从 SEO 角度看，这也不是纯合规问题：八个站共用一份从没更新过的"关于我们"，本身就是"批量模板"的强信号。
九、一套可以照着走的 90 天路线
第 0 到 30 天，先做盘点。把所有域名、站点、语言版本列成一张表，标注主体是谁、服务器在哪、内容来源、有没有本地团队、最近 90 天的收录与点击。同时做三件事：在 Search Console 里按站点、按国家建立基线；用日志验证真实爬虫占比；抽样 20 篇页面算模板相似度。这一步的目标不是改，而是知道哪些站其实不该存在。
第 31 到 60 天，定架构、补地基。按上一节的决策顺序确定子目录、子域名或 ccTLD，能不迁移就不迁移；把 hreflang 生成和校验写进构建流程；每个站补齐独立的 sitemap、robots、canonical、实体页（关于我们、作者、联系方式）；把 IndexNow 和 sitemap 提交做成定时任务。
第 61 到 90 天，做差异化和减法。给每个保留的站补 30% 本地独有内容；把重复度最高的站合并或 301；删掉页脚互链和没有导航价值的站间链接；把 KPI 从"收录页数"换成"被引用页面数、品牌词出现率、有效询盘"。
六条红线，碰一条就够毁掉整个矩阵：批量生成地区落地页；站间页脚互链、锚文本堆砌；买过期域名换主题；八个站共用一套关于我们和隐私政策；整站机翻不做本地改写；按 IP 或 Accept-Language 自动跳转语言。
最后回到那个最朴素的问题：多站群出海的技术本质，不是"如何让搜索引擎以为你有十个站"，而是"如何用一套可控的技术底座，服务十个真实存在的市场"。前者在 2026 年 9 月这次更新之后越来越难，后者反而因为 AI 搜索对"可核验实体"的偏好而变得更有价值。域名数量是最容易复制的部分，也是最不值钱的部分；真正难复制的是每个站背后的本地信息、真实案例和可追溯的主体。把这三样做出来，站群才从"风险敞口"变成"资产"。
