多语言站做不起来，通常是三个结构性原因
出海独立站SEO 最容易做重、也最容易做漏的一块，就是语言与地区信号：多语言版本上线半年没带来询盘，问题往往不在文案，而在搜索引擎不知道这些页面之间是什么关系，于是当成重复内容，只留一个版本排名。
第一个原因是一套英文打全球。英语站默认覆盖美国、英国、澳洲、新加坡，但采购习惯、计量单位、认证要求、付款方式都不同，落地页却说同一件事。
第二个原因是批量机翻铺语种。2024 年 Google 把多类低质内容整合为「批量生成内容」，纯机翻堆出的几十个语言目录正落在这个灰区里。
第三个原因是缺 hreflang 声明。没有这层声明，搜索引擎无法确认 /de/ 是 /en/ 的德语替代版本，只能各自独立索引，站内自己抢同一批词。
结构怎么选：子目录、子域名与独立域名
结构决定后面所有工作的成本，上线后再改要付全站 301 的代价。
| 对比项 | 子目录 /de/ | 子域名 de.example.com | 地区域名 example.de |
|---|---|---|---|
| 权重继承 | 完全继承主域 | 部分继承，需单独养 | 从零开始 |
| 地区信号 | 中等，靠 hreflang 与内容 | 中等 | 最强，本地信任度高 |
| 上线速度 | 最快，加目录即可 | 中等，DNS 与部署分离 | 最慢，注册资质前置 |
| 适合阶段 | 2-5 个语种的成长期 | 单市场需独立团队 | 单市场营收占比高 |
2-5 个语种阶段子目录性价比最高：一套 CMS、一份 sitemap、一次部署就能覆盖，hreflang 也最好写。更稳的做法是先用子目录验证哪个市场真有需求，等某国询盘占比稳定后再拆独立域名。
hreflang 的正确写法：四件事必须做到
hreflang 不是排名因素，它说的是「这几个 URL 是同一内容的不同语言或地区版本，请分发对应版本」。守住四条即可。
- 双向互指：/en/ 指向 /de/，/de/ 必须回指 /en/，缺一边等于没写。
- 包含自指：每个版本都要有指向自己的声明，漏掉是最常见的失效原因。
- 补 x-default：给语言选择页或通用版本一条 x-default，避免未知地区用户被随意分配。
- canonical 自指：德语页的 canonical 指向德语页本身，不能统一指向英文页，否则会被吞掉。
部署位置有三种，效果等价：模板能改就用 <head> 里的 <link rel="alternate">；页面多、模板难动就用 sitemap 里每个 URL 上的 <xhtml:link> 并列全部变体；PDF 只能用 HTTP 响应头的 Link。
<link rel="alternate" hreflang="en-au" href="https://example.com/au/products/" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de/produkte/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/products/" />语言码用 ISO 639-1，地区码用 ISO 3166-1 Alpha-2，站内统一小写。「欧盟」没有地区码，en-eu 是无效值，只能落到具体国家，或只用 en 表示无地区差异。
高频 hreflang 错误对照
这些错误几乎都能在模板层一次修掉，但要抽查才会发现。
| 错误现象 | 搜索引擎的处理 | 正确做法 |
|---|---|---|
| 只有 /en/ 指向 /de/，没回指 | 声明不完整，可能整体忽略 | 双向补齐并各自加自指 |
| 指向已 301 或 404 的地址 | 该条作废，变体失去关联 | 统一写最终返回 200 的地址 |
| 德语页 canonical 指向英文页 | 德语页被判重复，不进索引 | 各语言 canonical 自指 |
| http/https、www 与非 www 混用 | 同一组声明被当成不同站点 | 全站统一规范域名 |
| 地区码写错，如 en-UK、en-EU | 无效值被丢弃 | 用 en-gb 或具体国家码 |
抽查方法：随机取 20 个页面，看渲染后的 <head> 是否每页都指向全部变体且包含自己。有一页漏了，往往说明模板分支有遗漏。
本地化内容三档：直译、审校与真本地化
内容投入的差别，比技术配置更直接体现在转化率上。
| 做法 | 投入量级 | 典型结果 |
|---|---|---|
| 机器直译 | 低 | 术语生硬，难承接品牌词 |
| 母语审校 | 中 | 术语与语法正确，能承接品类词 |
| 真本地化 | 高 | 换本地单位、货币、认证、案例与话术，转化最好 |
判断标准很朴素：一位德国采购能否在三屏内确认「你在欧洲有服务能力、符合 CE 体系、能开欧元发票」。做不到就还停在直译阶段。
地区化关键词：别把中文词直译过去
- 用当地真实搜索词：同一意思在不同市场的主词可能完全不同，直译中文词常没人搜。
- 英美拼写分开：organize 与 organise、customize 与 customise，文案跟随市场，别混用。
- 单位与货币本地化：英制与公制、美元与澳元混着写，会让人怀疑你不是本地卖家。
- 认证前置：CE、UKCA、FCC、RoHS 本身就是搜索入口，写进小标题比藏在附录有用。
取词不必复杂：Google Trends 按国家筛选、Search Console 查询报告按国家下钻、当地前十名竞品的 H2 与产品页命名，三者交叉即可。
上线前的七步落地清单
下面七步是趣凡科技在出海项目里固定走的顺序：前四步是技术配置，后三步是内容与验收。
- 定结构与语种：先选 2-3 个主力市场，清单写进规划文档，避免边做边加。
- 统一 URL 规则：用
/<lang>/二级路径加语义化 slug，全站小写、统一结尾斜杠。 - 输出 hreflang：模板层统一生成双向互指、自指与 x-default，不要靠编辑手工加。
- canonical 自指：每种语言的页面只指向自己，分页与筛选页单独定规则。
- sitemap 加变体声明：分语言拆分或用 xhtml:link 并列全部变体，提交后核对索引数量。
- 语言切换器可抓取：用真实 a 链接，不要纯 JS 下拉或图标，爬虫要靠链接发现语种。
- 本地化验收：货币、单位、地址、认证、发票主体逐项过一遍，主流程由母语同事点一遍。
上线后怎么验证：三处信号
Search Console 的「国际定位」报告已在 2022 年下线，不必再去后台找。现在验证 hreflang 看三处：效果报告按「国家/地区」与「语言」拆开看，判断流量有没有分到对应市场；「网页」索引状态里「备用网页（有适当的规范标记）」的数量，反映变体是否被正确归并；URL 检查工具看渲染后的头部，确认声明真输出到页面。
抓取侧两个易漏点：按 IP 强制 302 跳转，会让多来自美国节点的爬虫长期只看到一种语言；语种之间至少要有一条可爬取的横向链接，语言切换器就够，完全孤立的目录很难被发现。
多语言站的 GEO 补充信号
被 AI 引擎引用时，语言与地区信息的表达方式和排名略有不同：它更依赖页面能否被切成可摘取的块。
- 页面语言自洽：一页只用一种语言，
<html lang>与 hreflang 保持一致。 - 结构化数据补语言：Organization、Product 可声明语言与地区，价格用 priceCurrency 标币种。
- 表格与清单优先：对比表、编号步骤比大段散文更容易被摘取。
- llms.txt 可做但别当标准：它是行业自发约定，目前没有搜索引擎官方承诺支持。
顺序不能反：先让每个语言版本完整、可索引、canonical 干净，再谈被摘取。旧文《GEO 优化实战》里那五个动作同样适用，只是要按语种各做一遍。深圳不少团队的出海站卡在第一步——版本本身就不完整。
什么时候该找外部团队
已有英文版本、正纠结第二三个语种怎么开，可以先做一次结构评估：语种清单、URL 规则、hreflang 位置、canonical 规则，四项定了再写内容，返工最少。
需要一起规划站群与本地化内容时，外贸独立站服务覆盖多语言结构设计与 hreflang 落地，出海业务衔接主体、资质与本地化运营；收款结算的技术细节见旧文《独立站收款方案对比》。趣凡科技的做法是先跑通一个主力市场，再复制到第二、第三个语种。
常见问题
hreflang 和 canonical 会冲突吗？
不冲突。canonical 说「这组重复页面里谁是主版本」，hreflang 说「这组页面互为语言替代，请分发对应版本」。所以每个语言版本 canonical 自指，再用 hreflang 串起来；把德语页 canonical 到英文页，等于自己取消了德语版本。
只有两三个语种，还需要 hreflang 吗？
需要。语种少不代表不会被判重复——一页英文、一页德文，标题与结构高度相似时，仍可能只留一个版本参与排名。两三语种写进模板成本很低，一次配好长期受益。
子域名会影响访问速度吗？
结构本身对速度影响很小，决定速度的是服务器位置与 CDN。子域名可以单独部署到不同机房，但要留意各地区延迟差异；子目录共用一套基础设施，配好全球 CDN 后差别不大。
机器翻译会被判为低质吗？
自动翻译本身不违规，风险在规模化铺量：几十个语种、每页只有机翻且无人工校对，容易落入批量生成内容的判定。稳妥做法是先做主力市场、每篇过母语审校，其余语种先 noindex。