独立站多语言运营：先定 URL 结构再上 hreflang 的分批上线步骤

多语言独立站最容易做反的一步，是先翻译、后想地址。等几十个页面翻完，才发现语言版本全挤在同一个 URL 上，只能靠 Cookie 或者浏览器设置换语言，这时候再回头改结构，hreflang、正文内链、Search Console 里已经收录的语言版本全得跟着重来。Google 明确推荐每种语言版本用不同的 URL，而不是用 Cookie 或浏览器设置来调整页面内容的语言。所以顺序只有一个：先把 URL 结构定成子目录、子域名、国家域名中的一种，再用 hreflang 把各版本双向串起来，按市场优先级分批上线。

对出海做站的人来说，这个顺序决定后面要不要返工。结构没定之前不动翻译。这些插件和 Google 搜索在中国大陆能不能正常使用，以官方为准，本文不展开。

• 是什么：多语言站是同一站点提供一种以上语言内容，多地区站是明确面向不同国家用户，两者能叠加。
• 官方怎么说：每种语言版本用不同 URL，再用 hreflang 标注语言和地区变体。
• 怎么做：先选 URL 结构，再上 hreflang，三种标注方式选一种就够。
• 要花多少钱、多久：官方页只给结构优劣，不给价格和工期；插件页只给功能和免费额度。
• 常见误区：URL 参数做地区定位被官方标成 Not recommended，IP 分析适配内容官方明确不要用。

本文从结构选型、hreflang 标注、分批上线到上线后的维护，把多语言独立站这一件事讲完。站点层面的基础动作可以对着网站运营教程那篇过一遍。

多语言站和多地区站不是一回事，先分清再动手

这两个词经常混着用，落到 URL 和 hreflang 上差别很大。多语言关心的是「这个页面说什么语言」，多地区关心的是「这个页面给哪个国家的人看」。先想清楚你要做哪一个，或者两个都要，再决定 URL 长什么样。

多语言站：一个站点提供不止一种语言的内容

官方举的例子是加拿大企业做英文和法文两个版本。同一个站，两套正文，两套导航，用户点什么语言就看到什么语言的页面。判断一个站算不算多语言，看的是页面上真的有没有第二种语言的正文，不是看页脚挂了个语言下拉框。

多地区站：明确面向不同国家的用户

官方举的例子是同时发货到加拿大和美国的厂商。它的重点不是语言，是国别。同一套英文内容，可以给美国用户一个版本、给加拿大用户一个版本，价格、运费、售后条款各写各的。这时候语言可能只有一种，URL 结构却要能表达国家。

两者叠加：美国版和加拿大版，加拿大内容还分英法两版

官方也给了这种叠加的例子：站点给美国一个版本、加拿大一个版本，加拿大版本里又有英文和法文两套内容。到了这一步，URL 结构要能同时表达语言和地区，hreflang 的值也要写到 en-CA、fr-CA 这个级别，不能只写 en 和 fr 两个语言代码。

值得做的原因在搜索结果这一端。Google 搜索会尝试找和搜索者语言匹配的页面，也会尝试给对地区。页面有多个语言或地区版本时，显式告诉 Google 这些变体，能帮它把用户指向最合适的版本。即使不主动标注，Google 也可能找到页面的其他语言版本，但通常最好还是显式标注语言或地区页面。

独立站多语言子目录、子域名、国家域名怎么选

官方给的三种 URL 原型是国家域名 example.de、gTLD 子域名 de.example.com、gTLD 子目录 example.com/de/。三种都能用，差别在花钱、服务器位置、站点能不能拆开这三件事上。

语言多不等于一定要选最贵的那种。站点刚起步、预算有限，子目录能最快跑起来；要按国家拆成几个独立站来运营，才轮到国家域名。

官方明确不推荐的两种做法

先说最要命的：用 URL 参数做地区定位，比如 site.com?loc=de。官方在结构对比表里把它标成 Not recommended，理由是参数会让 URL 分割变难，用户从地址上也看不出这是给哪个国家的页面。还有个事，用 IP 分析来适配内容，官方明确说不要用，因为 IP 定位本身难，通常不可靠，Google 也可能抓不全所有变体。

怎么定：看市场数量、预算、要不要独立服务器位置

目标市场集中在一个国家、预算够、想把地理定位做干净，选国家域名。市场多、语言多、想快速上线，子目录和子域名更省事。需要把不同语言放到不同服务器上，子域名或国家域名才做得到。定完就不再改，因为改一次 URL 结构，hreflang 整组要重做，正文里指向其他语言版本的链接也要一条条改回来。

出问题怎么回查 URL

URL 里分隔单词用连字符，不用下划线，Google 的说法是这样用户和搜索引擎都更容易看出 URL 里的概念。Google 对 URL 大小写敏感，会把 /APPLE 和 /apple 当成两个不同的 URL，所以全站要统一成一种写法。参数堆太多会生成大量指向相同或相似内容的 URL，抓取上会出问题，地区定位尤其不要靠参数。

独立站多语言SEO 的核心：hreflang 怎么标才生效

hreflang 是一段告诉 Google「这几个页面互为语言或地区版本」的标注。它的作用是让搜索结果把用户带到正确的那一个版本上。标注方式有三种：HTML、HTTP Headers、Sitemap。Google 看这三种是等价的，选你最方便的一种就行，三种同时用不会多出搜索收益。PDF 这类非 HTML 文件适合用 HTTP Headers。

HTML 写法：head 里给每个变体放一条 link

语法照官方原样是这样：

<link rel="alternate" hreflang="lang_code" href="url_of_page" />

每个语言版本一条 link，每个版本的 head 里都要包含自己那一条，而且所有版本这组链接要完全相同。link 必须在格式正确的 head 段里，不要把 hreflang 和 media 这类属性合并在同一个 link 标签上，官方专门提醒过这一点。

Sitemap 写法：每个 url 元素列出所有版本

每个 url 元素要有 loc 子元素，再用 xhtml:link 列出包括自己在内的所有语言版本。xhtml 命名空间照官方写成这样：

xmlns:xhtml="http://www.w3.org/1999/xhtml"

子元素的样子是 <xhtml:link rel="alternate" hreflang="supported_language-code">。sitemap 里漏掉自己那一条，整组也可能不生效，这点和 HTML 写法一样。

HTTP Headers 写法：每个版本返回的 Link 头一样

格式是：

Link: <url1>; rel="alternate"; hreflang="lang_code_1", <url2>; rel="alternate"; hreflang="lang_code_2"

每个版本返回的 Link 头完全相同。这条最容易被服务器配置漏掉，尤其是 CDN 在前面挡了一层的时候，头信息可能被改写或者丢掉。

三条硬规则

1. 每个语言版本必须列出自己，也列出所有其他版本。少一个，指向关系就断了。
2. 替代 URL 必须完整限定，包含 http 或 https。写 https://example.com/foo，不能写 //example.com/foo 或 /foo。替代 URL 不必在同一个域名下，跨域名也可以。
3. 两个页面不互相指向时，标签会被忽略。这是官方为了防止别的站随便把自己标成你的替代版本。

同语言多地区要加一个 catchall

同一语言面向不同地区时，除了 en-IE、en-CA、en-AU 这些具体版本，官方建议再给一个不限地区的通用 en 页。原因是有些搜索者的地区判断不出来，没有通用版本就落不到任何一个页面上。另外要记清一点：Google 不用 hreflang 或 HTML lang 属性来判断页面语言，它用算法判断页面可见内容，所以正文得真的是那种语言，光靠标签改不过来。

语言切换器和 x-default：让用户自己选，别自动跳

页面上放指向其他语言版本的超链接，让用户自己点，这是官方建议的做法。与之相反的是按猜测的用户语言自动重定向，官方明确说要避免，因为这种跳转会阻止用户和搜索引擎看到站点的所有版本。

给未匹配的语言准备一个 fallback 页，用 x-default 值，尤其用在语言或国家选择器、以及会自动跳转的首页上。写法是：

<link rel="alternate" href="https://example.com/" hreflang="x-default" />

切换器本身也要落到真实 URL 上。既然官方推荐每种语言用不同 URL，切换器指过去的就是那个语言版本自己的地址，不能是同一个 URL 换一套文案。用脚本只换文字不换地址，用户收藏、分享出去的还是原来那个语言，搜索也抓不到第二个版本。

还有一层是翻译质量。机器翻译批量生成页面，读不通的句子会直接留在搜索结果里，用户点进来两行就退出去了。翻完要有人读一遍，产品名、参数、售后条款这几类页面尤其不能省这一步。

独立站多语言插件怎么选：Weglot、TranslatePress、Polylang 的定位差异

插件解决的是翻译和语言 URL 生成这两件事。装之前 URL 结构要先想好，因为插件会按自己的方式生成语言地址，装完再改结构，等于把前面的活重做一遍。三款插件在这个点上给的选项不太一样。

Polylang：语言数量不设上限，语言可放 URL 代码也可放独立域名

语言可以由 URL 里的语言代码设定，也可以每种语言用不同子域名或域名。装过其他多语言插件的话，启用 Polylang 前要先停用，官方说同时开着可能出现意外结果。安装后会自动启动设置向导，帮你把主要功能配起来。它更适合想把每种语言当成一套独立内容来管的人。

Weglot：子目录或子域名，自动生成 hreflang

按语言的 URL 是子目录 /es/、/fr/ 这种，或者子域名，让每种语言被单独索引。它会自动生成 hreflang 标签，也会翻译元数据，包括页面标题、meta 描述和翻译后的 slug。支持按语言发布或取消发布，控制每个市场实际在线的内容。要注意翻译存在 Weglot 的服务器上，停用之后网站就不再被翻译了，决定不用之前先用导入导出功能把翻译全部导出来。

TranslatePress：翻译存本地数据库，前台直接翻

翻译全部存在自己服务器的数据库里。可以设置默认语言是否启用 URL 子目录。SEO Pack 附加组件能翻元信息，包括页面标题、描述、URL slug、图片 alt 标签。Different Domain per Language 附加组件可以给每种语言分一个独立域名。入口是后台 Settings 里的 TranslatePress 选翻译语言，再从管理栏打开前台翻译编辑器逐页翻。

选型时可以顺带对照的几篇

要翻的语言种类多、想看 WPML翻65+种语言怎么处理，可以对照着看。拿不定网页翻译工具怎么选，先过一遍网页翻译软件对比。想看外语竞品的原文和译文并排读，用沉浸式翻译双语对照。

按市场优先级分批上线：先翻哪几种语言、先翻哪些页

一次把整站所有语言全量翻完，麻烦不在翻译本身，在维护。产品改了、价格变了、条款更新了，每个语言版本都要跟着改一遍。分批上线是先让一两个市场跑通，再把同一套流程复制到下一个语言。排序依据是你手上已经有的东西：哪个市场已经有订单、有客服能接、有物流能发，就先做哪个，不是哪个语言搜索量大就先做哪个。

每种语言的第一批页面也有先后。先翻首页、核心产品或服务页、转化路径上的页面，这些页面决定用户能不能看懂你是卖什么的、能不能下单。内容页、博客、帮助中心放到第二批，这部分页面多，改起来也慢。

1. 把待翻译页面列成清单，按语言分组，标出先上线哪几种语言。
2. 每种语言先翻首页、核心产品或服务页、转化路径上的页面，再扩到内容页。
3. 上线后看各语言版本的收录，决定哪些语言保留、哪些先下线。

回查有一条容易漏：新扩展的语言页要双向链回原始语言或主导语言。官方允许在维护不了完整双向链接时，在部分页面省略部分语言，Google 仍会处理互相指向的那些。但新加的语言页必须链回去，否则那一组就只有它是孤立的。

数字和限制：插件门槛、免费额度、语言数

动手之前先看服务器的版本和插件的门槛，装到一半发现 PHP 版本不够，是常见的时间浪费。下面这些是插件页面上写明的数字。

这些是功能边界，不是性价比。价格和付费档位金额不在本文范围里，多语言站上线要多久、翻译要花多少字成本，也不在插件页给的信息里。

还有一个版本对照要看：WordPress 官方下载页建议的 PHP 版本和数据库版本，比 Polylang 的最低要求高。装插件前先看服务器上跑的是哪个版本，别按最低要求去配一台新机器。

常见误区和排查：hreflang 不生效先查这五处

误区一：用 URL 参数做地区定位

别用参数区分地区。官方把 site.com?loc=de 这种写法标成 Not recommended，原因是 URL 分割变难，用户从地址上也看不出这是给哪个国家的页面。

误区二：用 IP 分析适配内容

不要用。官方明确说 IP 定位本身难，通常不可靠，Google 也可能抓不全所有变体，你做了一个德国用户看到的版本，Googlebot 从美国来，看到的是另一个。

误区三：按猜测语言自动重定向

不要做。官方说这类重定向会阻止用户和搜索引擎看到站点的所有版本，等于自己把其他语言版本藏起来。

误区四：只翻模板文字，正文还是单一语言

只翻导航和页脚，正文不翻，同一篇内容会以好几种模板语言出现在搜索结果里，用户点进来看到的还是原来那种语言，体验很差。官方把「只翻模板、正文单一语言」列为需要用 hreflang 标注的场景之一，但要解决的是正文本身得翻。

排查顺序

1. 两个页面是不是互相指向。单向链接的标签会被忽略，从第一个语言版本查起，逐个看它列出的地址是否都回指了它。
2. link 标签是不是在 head 里。把渲染后的页面代码贴进 HTML 校验器，确认链接落在 head 段内。
3. 桌面和移动分开做 URL 时，移动版的 hreflang 要指向移动 URL，桌面版指向桌面 URL，有没有分开链。
4. 同一语言在多个地区出现相似或重复内容时，选一个首选版本，用 rel="canonical" 和 hreflang 把正确的语言或地区 URL 给到搜索者。
5. URL 大小写是不是统一，参数是不是堆太多。

收录层面用 Search Console跑收录逐个语言版本看。面向欧盟这类市场，各语言版本的隐私政策和 Cookie 政策要分别对得上当地要求，这块写在隐私政策与Cookie政策里。

真实案例：三个站做多语言后公开的结果

The Bradery：每天 500+ 产品翻译，目录保持一致

这个时尚电商站把站扩展到每天 500+ 产品翻译，各语言的目录保持一致。它的电商经理说，每周两次、每次约十分钟复核运行情况，其余交给 Weglot 完成。复核这个动作能做得这么轻，前提是前面的结构和词条统一都做好了。

REVIEWS.io：本地化后德语流量增长 120%，转化提升 20%

它公开的说法是本地化网站之后，德语流量增长 120%，转化提升 20%。德语是单独一个市场，不是一个语言版本顺手带出来的，这一点在做分批上线时值得记一下。

Ron Dorff：现在 70% 收入来自国际市场

它的说法是现在 70% 的收入来自国际市场，靠的是完全本地化的客户体验。这个比例是收入结构，不是流量数字，两件事别混着看。

这三个数字是客户在 Weglot 插件页里的原话，页面上没说同期还做了什么别的事，别当成因果。动作可以照着做，结果不能照着抄，行业和起点都不一样。

多语言站上线后怎么衡量：先量基线再改页面

各语言版本要分开看，别只看整站一个总数。在 Search Console 里按语言版本看收录，哪个语言版本收录慢，先回头查那一组的 hreflang 互指，再查那个语言版本的页面有没有被 sitemap 带到。英文版的收录量不能拿来当其他语言的标准，市场规模本来就不一样。

转化也一样，按语言分开量。先量出每个语言版本的基线，再动标题、动结构。基线没量就改，改完分不清是改动起了作用还是季节在起作用。GA4量出转化基线这篇讲的就是怎么先把基线跑出来。

还有一条替代路径：有些市场用户的问题不是翻译能解决的，售前问参数、售后问退换，直接上人工客服比继续加语言版本划算。多语言客服工具怎么选，看售前咨询和售后工具。

用 AI 帮多语言运营：能帮哪几步、人要核什么

AI 在这件事上省的是整理和比对的时间。上哪个市场、先翻哪几种语言、插件里点不点发布，这些还是人定。把它当成一个能快速出草稿和清单的助手，别指望它替你验收。

AI 能帮的四步

1. 按市场优先级把待翻译页面列成清单，按语言分组，标出先上线哪几种语言。
2. 生成 hreflang 代码片段草稿，HTML 和 sitemap 两种写法都能出，人工贴进 head 或 sitemap。
3. 把插件导出的翻译词条做术语统一，品牌名、产品词固定成一种译法。
4. 按语言版本逐条比对标题、meta 描述、slug 是不是都已经翻了。

必须人做的三件事

1. 在 WordPress 后台 Plugins 菜单里装并启用选定的多语言插件，按向导填默认语言和要加的语言。
2. 在插件设置里选 URL 结构（子目录、子域名、独立域名），确认后到前台看语言切换链接是不是正常。
3. 打开 Search Console 看各语言版本的收录和 hreflang 报错，决定哪些语言先保留、哪些先下线。

三条能直接照抄的提示词

下面是本文给的示例，不是官方模板。

「下面是我站点的页面清单和语言列表，请按市场优先级给出分批上线顺序，每种语言列出先翻哪些页面，不要编造搜索量数据。」

「按 Google 官方 hreflang 规则，为以下 URL 生成 HTML head 里的 link 标签组，每个版本都要包含自己，并加 x-default，输出纯代码。」

「这是我导出的翻译词条，请找出同一术语的不同译法，列成对照表，不要改动其他词条。」

多语言版本的成稿和本地化这一层，可以交给猎者出海的AI Agent 走一遍，出稿之后人再按语言版本逐条核。

常见问题

独立站多语言一定要用子目录吗

不一定。官方给的是子目录、子域名、国家域名三种结构，各有各的代价。市场多、想省维护成本，子目录好上手；要按国家拆站点、预算够，国家域名更清楚。定下来就别来回改。

hreflang 三种写法要同时用吗

不用。HTML、HTTP Headers、Sitemap 在 Google 看来是等价的，选一种最方便的就行，三种同时用不会多出搜索收益。PDF 这类非 HTML 文件用 HTTP Headers。

多语言站会被判重复内容吗

只有正文还没翻的本地化版本才会被当成重复内容。正文真的翻成了另一种语言，就不在这个范围里。同一语言多个地区出现相似内容，选一个首选版本，用 canonical 加 hreflang 处理。

Polylang 和 WooCommerce 能一起用吗

能，但要装 Polylang for WooCommerce 这个付费附加组件，两个插件才能配合工作。只装 Polylang 本体不够。

TranslatePress 的翻译存在哪里、会不会拖慢站点

存在自己服务器的数据库里。插件页的说法是对站点速度影响很小。语言版本多、词条量大以后，还是按语言版本自己量一次加载时间。

语言版本能不能先只上一两种

可以，而且推荐这么做。先让一两个市场跑通，把翻译、上线、收录检查这套流程走顺，再复制到下一个语言。一次全量翻译，后面一个产品改动要改十几个版本，维护跟不上。

多语言独立站这件事，结构定错后面全是返工，hreflang 漏一条那一组就白标，语言一次上太多维护跟不上。按市场优先级一批一批来，每批上线后看收录再决定下一步。上线后每周该改哪几篇、先改哪个语言版本，这种拉数据的活可以交给猎者出海的AI Agent 出单子，判断还是人来做。