多语言站第一个技术决策，往往是「子目录还是子域」。选错了，后期迁移成本很高。这篇不讲虚的，直接把两种架构的取舍、hreflang 怎么配、语言包怎么管，一次说清。
这篇复盘只讲三件事：我们接手时这个站卡在哪、我们怎么重新规划、以及后台具体怎么一步步落地。对同样做 多语言站点架构 的出口企业来说，这套路径可以直接复用。
为了让你看得清楚，这篇按我们实际交付的顺序写：先看问题，再看怎么规划，最后看后台怎么落地。看完你能判断自己的站该先改哪一步。
一、先说结论：没有更优解，只有最适合
先说结论：子目录（/en/）和子域（en.xxx.com）没有较为优劣。子目录权重集中、维护简单，适合大多数外贸站；子域隔离性强，适合多品牌或多区域独立运营。选哪个，看你的运营结构。
这条结论听起来简单，但真正落地时，大多数人会败在「舍不得」——舍不得删掉堆在首屏的旧内容，舍不得把一个栏目拆成三个。取舍，才是这件事的难点。
二、模式拆解
一个品牌多语言 → 子目录；多品牌/多区域独立 → 子域。
每个语言版本互相指向，告诉搜索引擎这是同一页的不同语言。
导航、按钮、表单提示进语言包，内容按栏目做双语。
我们交付时会把这三步写成一页 SOP，客户运营照着做就行，不用每次重新想。
这三步还有个隐藏前提：你得先知道买家是谁。面向工程采购和面向终端用户，三步的内容完全不同。先定人群，再定动作。
三、案例对照：不同行业的同一套逻辑
我们交付的双语站里，绝大多数用子目录，因为客户是「一个品牌卖多个市场」；少数集团客户用子域，因为各业务线要独立形象。架构跟着运营走，别为了技术而技术。
把同一套逻辑放到不同行业，会发现「变的只是产品和词，不变的是路径」。所以你不需要照抄某个行业的具体做法，只需要照抄它「先回答什么、后回答什么」的顺序。
你会发现，行业不同，「证据」的形式不同：机械看参数和认证，消费品看评价和场景，科技看白皮书和数据。但「先给证据，再谈别的」这个顺序，是一致的。
对照案例时，别只看「他们做了什么」，看「他们在哪一步下了重手」。往往决定成败的，就是那一两个动作做到位了，其他的都差不多。
四、后台怎么落地
上线不是终点。我们会跑一轮 SEO 诊断，从技术底座、元数据、内容质量、GEO 结构化、索引转化五个维度逐项体检，出带优先级的清单，按「影响大、改动小」先修。要说清：诊断分数只是结构完整度的参考，不代表排名。
后台把「栏目—文档—关键词—内链」串成一条链，编辑按栏目填内容即可，不用关心技术细节。
效率提升最明显的一步，是把「重复劳动」系统化。栏目模板、TDK 批量生成、图片统一入库、表单统一管理——这些动作单看都不起眼，合起来能省掉大量重复沟通。
我们也会把「重复出现的动作」做成模板：同样的栏目结构、同样的 TDK 规范、同样的询盘字段。模板不是偷懒，是把验证过的东西固化下来，减少每次重新试错。
五、常见误区
改造之前，先看看自己有没有中这几条。中了不用慌，基本都是结构问题，能改。
六、可复用清单
多语言架构不是「技术选型」，是「运营结构的映射」。你想清楚怎么卖，架构自然就定了。