WordPress 多语言与小语种站
插件选错，后面全是返工
做中东市场要阿语、做南美要西语、做德国要德语，很多企业第一反应是”装个翻译插件”。但 WPML、Polylang、TranslatePress 三者的数据结构和 SEO 输出方式完全不同，选错之后换方案的代价接近重做。这一页讲清三者的取舍、URL 结构与 hreflang 的正确写法、多语言商城的同步问题，以及阿语 RTL 这类容易被忽略的排版细节。
三个主流方案
不是功能多少的区别，是架构的区别
判断标准只有一条：你的内容是不是需要”每种语言一套独立的页面”。需要，就选生成独立内容的方案；只是想把界面文字换掉，另一类方案更轻。
WPML
为每种语言生成独立的 post 记录，翻译内容存在自己的表里，通过语言分组关联。生态最完整：WooCommerce、ACF、表单、菜单、字符串翻译都有官方组件，翻译管理界面成熟，可接机翻服务。
- 适合产品多、需要多语言商城的站
- 体积重，查询比单语言多，需配对象缓存
- 按站点类型分档收费，商城与多站点属高档
Polylang
复用同一套 post 表，用语言分类法和翻译组把不同语言的页面绑在一起。核心版免费，轻量，后台逻辑接近原生 WordPress，内容编辑上手快。WooCommerce 支持在 Pro 版，字符串翻译需另配组件。
- 适合内容型官网、博客为主的站
- 复杂商城的变体、属性翻译支持较弱
- 与部分页面构建器的兼容需要逐项测
TranslatePress
在前台直接点选翻译，所见即所得，译文存在独立表里，不复制页面。上线最快，适合几十页规模、需要快速验证小语种市场的站。代价是每次请求要做一次输出替换，页面多时性能开销明显。
- 适合展示型站点，不适合重交互商城
- 动态内容（筛选结果、结账字段）覆盖有限
- 译文与原文混存，后期迁移到别的方案较麻烦
常见误判是用 TranslatePress 做 WooCommerce 商城：前期看着都能翻，等到做属性筛选、变量商品、结账地址格式时才发现覆盖不到，只能整体换方案，翻译工作重做一遍。产品超过 100 个或要接支付，直接按 WPML 规划。
URL 结构先定死
上线后再改要全站 301
多语言站点最常见的 SEO 事故，是 hreflang 写了、canonical 却指向主语言，导致小语种页面被搜索引擎判定为重复内容，连索引都进不去。
子目录优先
site.com/en/、site.com/de/ 是首选：权重集中在一个域名，运维只有一套程序，加语言不影响服务器。子域名（de.site.com）适合需要分区域部署或独立 CDN 的情况，但要单独做 Search Console 验证与权重积累。参数形式 ?lang=de 不利于收录，不建议。
hreflang 三原则
一是自指，每个页面都要包含指向自己的那条；二是双向，A 指向 B，B 也必须指回 A；三是每页输出全部语言版本加一条 x-default。语言代码用 ISO 639-1，区分地区时再加国家码，如 en-GB、pt-BR、zh-Hans。
canonical 必须自指
德语页的 canonical 要指向德语页自己，不能指向英语原版。很多主题或 SEO 插件默认输出主语言 canonical，这一条不改，hreflang 做得再全也没用。同时确认 hreflang 指向的 URL 是 200 状态、可索引、未被 robots 屏蔽。
只输出一次
主题、多语言插件、SEO 插件三方都可能往 head 里塞 hreflang，重复输出会被判为冲突。上线前用源码或爬虫工具检查每页的 alternate 标签数量，应该等于语言数加一（含 x-default）。
三种方案横向对比
按站点类型对号入座
| 对比项 | WPML | Polylang | TranslatePress |
|---|---|---|---|
| 内容存储 | 每语言独立记录，独立翻译表 | 同一 post 表，按语言与翻译组关联 | 原文不复制，译文存独立表 |
| WooCommerce | 官方组件，产品、属性、结账均可翻 | Pro 版支持，复杂变体需额外处理 | 基础界面可翻，动态字段覆盖有限 |
| 上手难度 | 中，后台概念较多 | 低，接近原生逻辑 | 最低，前台点选即翻 |
| 性能开销 | 查询偏重，建议配对象缓存 | 较轻 | 每次请求做输出替换，页面多时明显 |
| 适合规模 | 100 页以上或带商城 | 50 到 300 页的内容站 | 50 页以内的展示站 |
| 后期可迁移性 | 数据结构清晰，迁移成本可控 | 中等 | 偏低，译文与原文耦合 |
上线后最容易出问题的五处
每一条都真实发生过
切换器记不住选择
用户选了西语，点进产品页又跳回英语，因为切换只改了当前页 URL，没有写入 cookie 或 session。正确做法是切换后写入偏好，后续访问按偏好 302 到对应语言，但不要用 302 阻挡搜索引擎抓取其他语言版本。
浏览器语言自动跳转
按 Accept-Language 自动跳转是另一个坑：Googlebot 从美国抓取，可能永远只看到英语，其他语言版本收录不到。建议首访只给提示条，不强制跳转，跳转逻辑放前端并保留返回默认语言的入口。
库存与价格不同步
多语言商城的产品是不同记录，库存字段要同步。WPML 的翻译组内产品共享库存，但第三方 ERP 插件经常只认主语言产品 ID，导致西语站显示有货、英语站显示缺货。对接前必须确认同步键。
内链还指向旧语言
翻译页面正文里的链接，是从原文复制过来的，全部指向英语页。用户在西语页点”查看详情”跳到英语，跳出率立刻上来。翻译交付前要跑一遍站内链接检查，把链接替换成对应语言版本。
机翻没校对
工业品术语机翻错误率很高，阀门”口径”被译成口径尺寸、”法兰”被译成国家。建议先做术语表，把产品名、材质、认证名称固定下来，再让母语审校过一遍核心页面。宁可只翻 20 页，也不要全站机翻。
sitemap 与索引
多语言站要为每种语言生成独立 sitemap，并在 Search Console 分别提交（子目录形式在同一资源下按 sitemap 区分）。检查 sitemap 里没有混入 noindex 页面、没有把翻译页的 lastmod 全部写成同一时间。
小语种不只是换文字
排版和格式都要跟着变
德语单词长度平均比英语长三成，阿语从右往左读，俄语和泰语需要不同的字体文件。这些细节不处理，页面看起来”能读”，但客户一眼就知道不是本地站。
阿语 RTL
不能只加 dir="rtl"，模板里写死的 margin-left、float、绝对定位都会错位。要用逻辑属性（margin-inline-start）或单独输出一份 RTL 样式。图标方向、进度条、轮播箭头也要镜像，数字仍保持从左到右。
德语长词
“Druckluftaufbereitung”这类复合词会把按钮撑破。按钮宽度不要写死，导航在小屏改汉堡菜单，标题允许 hyphens: auto。表格列宽用百分比而非固定像素。
字体子集
阿拉伯语、泰语、希伯来语需要专门字体，不能靠系统默认。字体文件按语种拆分加载，避免一个字体包几百 KB 拖慢 LCP。中文站做多语言时，别让中文字体去渲染西文，字重和行高都会不对。
格式与合规
日期用 31.12.2026 还是 12/31/2026、价格小数用逗号还是点、地址顺序从街道还是从城市写，都要按目标市场调整。欧盟站点还要有 GDPR cookie 同意与 imprint 页面，这些不是翻译问题，是本地化问题。
多语言站点常见问题
看内容量和是否带商城。纯展示站 30 页以内，TranslatePress 就够用，成本低、上线快；一旦有产品筛选、变体、结账流程，建议直接用 WPML，避免中途换方案。Polylang 适合以文章为主、预算有限的站。
可以用于长尾内容做初稿，但产品页、首页、关于我们这类核心页面必须人工校对。工业品的型号、材质、认证名称机翻错误会直接影响询盘质量。我们的做法是先建术语表，再机翻，再由母语或熟悉行业的译审过一遍。
先查三处：canonical 是否指向自己、页面是否被 noindex、内链是否只有英语版本指向它。hreflang 只是提示，不保证收录；小语种页需要有独立的内容价值和站内入口。也可以用WordPress SEO 优化里的方法做一轮抓取诊断。
有必要的。生成式引擎更依赖结构化、可引用的内容，多语言站如果只是把英语段落直译，很难被引用。建议每种语言单独准备 FAQ、参数表和案例，具体思路见GEO 生成式引擎优化。外贸站的整体结构可参考WordPress 外贸独立站。
先定语言优先级
再决定翻多少页
把目标市场、现有询盘来源和产品线发给我们，先出一份语言与页面优先级建议：哪些语言先上、先翻哪 20 个页面、用哪个方案、hreflang 怎么落。商城多语言的实施可以对照WooCommerce 商城搭建一起规划。
电话/微信 13280692153 邮箱 web@wordpressx.com 地址 山东省淄博市张店区电子产业创新园 B 座