一个外贸独立站做得好不好，往往不在上线那天见分晓。
翻译成目标语言只是第一步。真正决定它能不能带来询盘的，是几件不太显眼的事：每个语种有没有自己的地址、搜索引擎知不知道它们是同一个页面的不同版本、海外客户打开要等几秒、以及半年后还能不能顺手改一处产品参数。
这篇把派迪做多语言站时会处理的几个技术问题梳理一遍，供正在筹备外贸站的企业参考。
01 · 地址结构
每个语种要有自己的地址
多语言站的地址结构是需要在项目一开始就定下来的，后期调整的代价比较高。
核心原则是：每个语种都要有独立、可直接访问的网址。只有这样，Google 才能把各语种分别收录，海外客户搜索时才有机会找到对应语言的页面。
常见的有三种做法，各有适用场景：
| 方案 | 地址形态 | 适合什么情况 |
|---|---|---|
| 子目录 | example.com/en/ example.com/ru/ |
大多数外贸企业的默认选择。权重集中在一个主域上，维护成本低，新增语种快。 |
| 子域名 | en.example.com ru.example.com |
各语种内容差异较大、由不同区域团队各自运营时比较合适。 |
| 独立域名 | example.de example.fr |
在目标市场有本地公司主体、需要本地信任背书时值得考虑。成本相对高。 |
实际项目里，派迪大多会建议采用子目录方案。除非客户在某个市场已经有独立的公司主体和本地团队，否则把权重集中在一个主域上，长期看收益更稳，日常维护也更省心。
hreflang：说明各语种页面之间的关系
地址分开之后，还需要让搜索引擎知道它们是同一个页面的不同语言版本。这靠 hreflang 标注完成。
以一个中英俄三语页面为例，每个语种版本的页面头部都要写上全部三条，外加一条兜底：
几个需要留意的细节：
- 标注需要互指——英文页也要指回中文页和俄文页，单向标注不生效
- 每个页面都要包含指向自己的那一条
- x-default 是兜底项，语种不在列表里的访客会落到这一页，外贸站通常指向英文版
- 同一语言要区分市场时（比如美国英语和英国英语），代码写成 en-US、en-GB
派迪的做法是让系统自动生成这部分标注：新增语种时，各页面的 hreflang 会自动补全并保持互指，不需要人工逐页维护。项目页面多、语种多的时候，这一步能省下大量校对时间。
02 · 内容结构
参数共用，只翻译文字
多语言站的主要成本不在上线，在长期维护。
一个三语种的站点，如果每个语种各存一份完整的产品数据，改一处参数就要改三次，新增型号要录三次。产品线越长，这个负担越明显。
派迪在做产品数据结构时，会把内容拆成两层：
数值型字段只维护一次，各语种自动同步。改一处，所有语种同时更新。
产品名称、应用说明、优势描述这类需要人来写的内容，各语种独立维护。
这样拆开之后，日常改参数只动一处；新增语种时的工作量主要落在翻译上，不需要重建数据结构。客户自己的市场部就能维护，不必每次都找我们。
产品数据的整理方式也值得在项目前期一起定下来。参数字段怎么命名、单位怎么统一、哪些内容需要分语种，这些约定好之后，后续无论是批量导入还是日常维护，都会顺很多。
产品参数结构是派迪比较熟悉的部分。我们做过不少带产品选型功能的制造业官网，参数维度、筛选逻辑、后台配置这套东西，在多语言场景下同样适用——选型规则共用一套，各语种只换界面文案。
03 · 访问速度
海外客户打开要等多久
服务器在国内，海外访客打开通常会慢一些。跨境链路本身的延迟加上偶发丢包，首屏时间会明显拉长。对一个刚从 Google 点进来的陌生访客来说，这段等待往往决定了他会不会留下来。
处理方式主要是两块：
静态资源走 CDN
图片、样式表这类不常变动的文件推到 CDN 上，由离访客最近的节点响应。这一步的投入产出比最高，多数外贸站做完之后首屏时间会有比较明显的改善。
源站位置按目标市场选
如果主要市场集中在欧洲或北美，把源站放到对应区域会更稳。如果多个区域都有量，则需要考虑多区域部署配合智能解析。这部分方案会根据客户的实际市场分布来定。
验收时值得关注的几个指标：目标市场的实测首屏时间（Google 给出的参考是 LCP 控制在 2.5 秒以内）、TTFB，以及移动端在 4G 网络下的表现。建议约定用第三方工具从目标国家实测。
派迪的项目会在上线前从目标市场做一轮实测，把数据交给客户一起确认，而不是只在国内打开看一眼。
04 · 结构化数据
让机器读懂你的产品页
这两年多了一个新的变量：除了搜索引擎，AI 也在读你的网站。
海外客户越来越多地直接向 ChatGPT、Gemini 提问"这类设备有哪些供应商""某个参数范围的型号推荐"。能不能被引用到，很大程度上取决于页面是不是机器可读的。
几件成本不高、但长期有价值的事：
- 产品页部署 Product 结构化数据，把型号、参数、适用范围、供应商信息标注清楚
- 参数表用真正的表格输出。做成图片的话人能看懂，但机器读不到
- 公司信息用 Organization 标注，包含公司全称、地址、联系方式、成立年份
- 常见问题用 FAQ 结构化数据，这类内容被引用的概率相对高
- 各语种分别配置结构化数据，不只在英文版做
派迪的定位是面向搜索引擎与 AI 推荐的企业官网建设，所以这套结构化处理是我们的基础配置，不作为额外增项。它的回报周期偏长，但投入集中在上线阶段，后续基本不需要再维护。
05 · 语种规划
关于语种数量的一点建议
语种要做几种，是客户问得最多、我们回答得也最谨慎的一个问题。
技术上没有数量限制，加语种本身不难。真正需要提前想清楚的是后面的维护：每多一个语种，就多一份需要持续更新的内容。产品参数变了要跟着改，新增型号要跟着翻，术语是否准确也需要有人把关。
派迪不做批量机翻生成，语种按客户的实际需要一个一个添加。这样每个语种上线时都是能拿得出手的状态，客户后续也维护得动。
我们通常会建议这样安排节奏：
中文 + 英文
英文版是基础盘，也是 x-default 的落点。先把产品数据结构、参数表、术语表这套底子打好，后面加语种就是在这个结构上延伸。
加 1–2 个主力市场语种
按实际询盘来源或展会反馈来定，比如俄语、西班牙语、德语。这一步配的不只是翻译，还有该市场的术语习惯和本地联系方式。
跑出结果后再往外扩
前面几个市场有了稳定询盘、内容也维护得住，再加新语种。技术成本不高，关键是维护跟得上。
派迪目前做过的语种包括英语、俄语等，项目多集中在制造业与外贸出海方向。
06 · 上线之后
还有几件事要接着做
多语言站上线只是开始，下面这几件事通常还要持续跟进一段时间：
- 各语种分别提交 sitemap，在 Google Search Console 里单独看收录情况
- 关注 hreflang 是否报错，Search Console 会提示互指缺失之类的问题
- 各语种的流量和询盘分开统计，便于判断哪个市场真的有量
- 术语表随项目沉淀，新增内容时沿用，保证同一个零件在各页面叫法一致
这些事情单看都不复杂，但需要有人定期查看。派迪会在交付时把这套检查项整理成清单交给客户，客户自己能操作；也可以纳入后续的运维服务由我们持续跟进。
07 · 常见问题
常被问到的几个问题
用浏览器翻译插件做多语言，够用吗？
看用途。如果官网主要是给已有客户看的展示窗口，插件可以解决"看得懂"的问题。如果希望官网带来海外新客询盘，则需要各语种有独立地址和实际内容——插件生成的内容通常不会被搜索引擎收录，海外客户搜索时找不到。
最多能支持几种语言？
技术上没有限制，按需要添加。我们一般建议先把两三个主力语种做扎实再往外扩，这样内容质量和维护节奏都更稳。
各语种的产品参数要分别维护吗？
不用。参数层是共用的，改一次各语种同步；需要分别维护的只有产品名称、应用说明这类文本内容。
已经有一个英文站了，想加语种，要重做吗？
看原站的结构。如果原来就是用独立地址做的，多数情况下可以在现有结构上扩展；如果各语种共用同一个地址，地址结构和数据结构都需要调整，改造量会比较大。具体需要看过站点之后再判断，我们可以先帮你做一次结构评估。
做一个多语言外贸站，周期多久？
中英双语的情况下通常 8 到 12 周。多数时间花在产品资料整理和翻译校对上，开发本身不是瓶颈。每增加一个语种，主要增加的是翻译和校对周期。
费用大概什么范围？
取决于页面数量、产品数据规模、语种数量，以及是否需要选型这类功能。多语言外贸站通常落在 2.6 万到 8 万区间，语种多、带选型或复杂功能的项目会更高。
最后
外贸站和国内官网有个明显区别：你很难亲眼看到它在客户那边是什么样子——网速、语言习惯、搜索入口都不一样。所以能在开始阶段就确定下来的部分，比如地址结构、数据结构、加载表现，值得多花点时间做对。
至于语种数量，先想清楚要进哪几个市场，再决定做几种语言，通常比反过来更稳妥。
