英文页和德文页都能打开，语言切换也正常，却发现德文 URL 的 canonical 指向英文页。这个配置是否合适，要先看两页的主内容：如果是完整的不同语言版本，通常应分别表达自己的规范 URL，再用 hreflang 关联；不能因为属于同一篇文章，就把所有语言都归到英文地址。
canonical 表达重复或高度相似内容的首选 URL，hreflang 说明哪些 URL 是对应的语言或地区版本。它们承担不同任务，检查时也要分别看。
先判断这两张网页，为什么需要各自存在
打开两个页面，直接比较正文。英文和德文都完整讲解同一操作，属于不同语言版本；只翻译菜单，正文仍是同一段英语，则不能按完整翻译处理。Google 说明，主内容已翻译的语言版本不会仅因对应同一主题而被视为重复。本地化版本说明
再看同一种语言的地区页。例如美国和英国页面，可能只是切换币种，也可能确实提供不同的配送范围、商品与退货条件。先把这些差别写下来，再决定是否需要分别保留页面，以及怎样表达首选版本。
这一步适合做成一张小清单：最终 URL、正文语言、服务地区、与另一页的实际差别。没有地区限定的英文内容可标为 en；不要仅凭目录叫 /uk/，就认定内容已经为英国读者准备好了。
如果还在规划多语言目录，可以先放回Google SEO 学习路径中的网站结构工作里一起处理。标签只能描述已有关系，无法替网站补出尚不存在的本地内容。
英文与德文完整翻译：先把最小关系配对
以下使用保留的示例域名 example.com。假设两页主内容都已完整翻译，计划分别编入索引，最终 URL 可正常访问，且没有误设 noindex 或抓取限制，在英文页的 HTML head 中输出：
<link rel="canonical" href="https://example.com/en/guide/">
<link rel="alternate" hreflang="en" href="https://example.com/en/guide/">
<link rel="alternate" hreflang="de" href="https://example.com/de/ratgeber/">
德文页对应输出：
<link rel="canonical" href="https://example.com/de/ratgeber/">
<link rel="alternate" hreflang="en" href="https://example.com/en/guide/">
<link rel="alternate" hreflang="de" href="https://example.com/de/ratgeber/">
验收时把两页的语言集合抄成同一个映射：en → /en/guide/、de → /de/ratgeber/，实际标签中仍使用上面的完整URL。若英文页的de指向新地址、德文页自身de仍指旧地址，就没有得到同一套映射；修正关系数据后重新读取两边输出，而不是只数标签有几条。
两组 hreflang 列出同一套对应地址，每页包含自己，也有指回另一页的关系。Google 要求使用完整 URL，并说明缺少返回链接时，对应标记可能被忽略。hreflang HTML 配置要求
代码里的 canonical 单独成行，别给同一个 canonical 标签加上 hreflang 属性来“兼任”语言声明。Google 的规范网址文档要求把这两种声明分开。canonical 与 hreflang 的配合
这些代码应由主题、插件或页面 head 配置输出，不是粘进文章正文的内容。替换成自己的最终 URL 后，保存页面，再检查实际生成的 HTML；后台设置界面正确，不代表前台没有被另一个插件覆盖。
美国和英国都用英语时，不要机械套用上一组代码
现在把场景换成 /us/guide/ 与 /gb/guide/。如果两页主要内容几乎一样，只因地区路由保留两个地址，Google 的多地区文档建议选择首选版本，并结合 canonical 与 hreflang 处理这些同语种相似或重复页面。同语言多地区页面的处理
这与上面的英德完整翻译不是同一种情况。不能把“每个地区页都必须 self-canonical”写成无条件规则，也不能把“相似地区页可选首选版本”推广成所有语言都 canonical 到英文。
实际检查可以从交易信息开始。英国页面是否提供不同的适用商品、配送限制和服务条件？这些内容是否直接影响用户选择？如果答案是肯定的，先完整保留这些差别，再评估两页是否真的属于应合并的近重复内容；别为减少 URL 数量把用户需要的信息一起消掉。
若两页实际上是同一份通用说明，仅目录不同，则记录计划中的首选 URL，并检查站内链接与其他规范化声明是否一致。这里没有一套代码能代替页面比较。特别是旧站已有地区流量时，应先拿少量对应页核对关系，再按确认过的规则调整模板。
从一组错配页面，追到真正需要修改的设置
假设一篇英文尺寸指南有完整德文翻译。英文页有en和de两条对应关系；德文页正文正确，但canonical指向英文，hreflang也只列英文首页。此时有两个独立问题：规范地址设置不符合这份完整翻译的关系，语言关联又丢失了具体文章。只把canonical改成德文地址，还不能修好第二个问题。
在WordPress中，先打开这篇德文文章的编辑记录，确认它确实关联到那篇英文尺寸指南，而非孤立创建后仅手工添加了一个语言切换按钮。再核对文章级SEO设置：有没有复制英文草稿时一并复制了自定义canonical字段。若存在，移除错误的覆盖值或改为计划中的德文最终地址；由插件默认生成规范地址时，不必额外手写第二套标签。
接着保存对应关系、清除影响该页的缓存，重新打开前台源代码。合格结果应是德文canonical指向德文最终地址，两页都有en/de同一组关系且分别包含自身。若后台字段改了，源代码仍不变，查看缓存与其他输出来源；若源代码出现两条不同canonical，先确定主题、SEO插件或自定义代码谁在重复生成，而不是继续往正文追加标签。
最后抽查另一篇同模板德文文章。如果它也被统一指向英文首页，问题更可能在生成规则；如果它完全正常，则优先处理这篇翻译的关联记录。这个例子中的验证目标是修好实际输出，没有承诺Google会在下一次抓取后马上给德文页排名。
发布后查实际HTML，再看Google选了谁
先访问 hreflang 指向的每个地址，确认打开的是预期页面，并记录最终 URL。若 /de/old-guide/ 已跳到新地址，标记里继续写旧路径会让检查复杂化；应把对应关系整理到当前真正使用的地址上。
然后检查网页源代码中 head 的实际输出，必要时再比较渲染后的 DOM。每页 canonical 有无被输出两次、href 是否拼错、语言页是否指到自己、两端是否对应同一篇内容，都能在这里发现。主内容可能已更新，插件保存的语言关联却仍是旧记录，所以不能只检查首页。
接下来用 Search Console 网址检查这些 URL，查看已有索引记录中的 Google 所选规范网址。它是 Google 已处理的结果；实时测试不能预测最终会选择哪个规范 URL。网址检查工具说明
如果实际选择与你的声明不同，先比较记录的抓取时间与本次修改时间，再回查重复内容、跳转和站内链接。不必在刚改完的一分钟内，根据旧记录再次切换设置。
一组标记通过语法检查，也不能证明目标国家或语言的搜索结果一定会展示对应页面。最终表现还需要结合页面本身与搜索数据观察，不能用“标签存在”替代效果验证。
遇到四种异常，分别改对应的地方
下面是排查位置示例，不代表遇到这些情况就能保证某项排名恢复。
| 看见的异常 | 优先核对什么 | 对应处理 |
|---|---|---|
| 英文指向德文，德文没有指回 | 德文页实际输出的语言集合 | 补齐同一组页面的返回关系 |
| 完整德文正文却 canonical 到英文 | 插件的规范 URL 设置及其他重复输出 | 按完整翻译页的实际关系修正，再复查两页 |
| 每篇德文文章都指向英文首页 | 翻译页是否关联到具体原文 | 关联对应文章；没有版本时不要用首页冒充 |
| hreflang 仍写搬迁前的地址 | 最终落地 URL 与语言关联缓存 | 更新到现行地址，并检查另一端 |
修复一个模板问题后，从同模板抽查不同语言和不同文章，不要只看刚手动改好的那一页。若只有某篇缺翻译，修正该篇关联；若整批都输出相同错误地址，再处理生成规则。这样能避免把单页内容缺失误当成全站插件故障。
版本没有齐全时，只声明真实存在的对应页
多语言站很少同时翻译完所有文章。尺寸指南只有英文和德文，保养指南只有英文，这两篇就应有不同的语言集合。不要为了让全站标签数量一致，把保养指南的de地址填成德文首页，也不要让未翻译页面以200状态输出空壳内容。先发布完整可用的翻译，再加入那篇文章的双向关系。
如果旧德文地址永久搬迁到新路径，除了跳转，还要同步英文页的de地址、德文新页自身关系及生成这些关系的记录。只修德文新页而漏掉英文端，留下的仍是一组过时关联。若德文版本彻底取消，则从对应页面和相关声明中移除它；是否把旧地址跳转到其他页，要另行判断有没有真正合适的替代内容。
x-default也应按落地体验选择。站点首页可以使用语言选择页作为未匹配偏好的入口；文章没有专用选择页时，不需要机械地把每篇文章的回退全部填成首页。访问者原本想读某个尺寸问题，跳到没有该文章入口的首页，体验可能更差。没有x-default不会让完整en/de关系自动失效。
用一种可维护的方式声明，再验收整组关系
Google支持HTML标签、HTTP响应头和XML Sitemap三种等效的hreflang实现。普通WordPress页面已由插件在head输出，通常继续维护这一套即可；PDF等非HTML资源可以考虑HTTP头，大批语言映射也可由系统生成Sitemap。多写几套不会增加搜索收益，却增加地址不一致的风险。实现方式及要求
上线前可按下面的记录验收同一组页面。这里仍以英文、德文指南为假设示例：
| 验收项 | 合格观察 | 不符合时的下一步 |
|---|---|---|
| 访问结果 | 两个最终URL各自显示对应完整正文 | 排查404、登录限制或自动地区跳转 |
| 主体语言 | 英文和德文内容真实存在 | 未完成翻译先不把空壳加入对应组 |
| 规范关系 | 各自声明计划中的最终规范地址，没有互相冲突输出 | 查文章级覆盖与重复生成来源 |
| 对应关系 | en/de都引用同一组具体文章，且双向匹配 | 修翻译关联，不拿语言首页顶替 |
| 处理结果 | 后续网址检查记录已反映修改后的抓取 | 若仍是旧记录，先等待处理；新记录仍异常再查信号 |
还要实际点一次语言切换，并用未登录窗口直接访问另一语言URL。如果程序根据IP强制把所有访问者送回英文目录，德文页即使有标签，也可能难以被正常访问或抓取。可以提供选择建议和可点击的切换入口，让独立语言地址保持可访问；Google的多语言站指南不建议仅靠自动跳转决定用户看到哪个版本。多语言访问方式
不同国家的表现仍应分别看。英国点击落到美国页面时，先固定查询、国家和页面比较，再检查英国版的实际内容与标记；一次手工搜索受到位置和语言等条件影响，不能单凭它决定把全站canonical改来改去。对声明正确但Google仍选了其他规范页的情况，继续沿重复内容和信号一致性排查。Google规范化排错说明
常见问题
英国英语应该写 en-UK 还是 en-GB？
使用 en-GB。hreflang 先写语言代码，地区代码可选；不需要地区区分的英语内容可用 en。标签应反映页面实际服务的语言和地区。
每组页面都必须加 x-default 吗？
不必把它当作固定必填项。x-default 可为未匹配到的语言偏好提供回退页面，例如语言选择页；使用前先确认用户落到那里后能够继续选择。
安装多语言插件后，还需要手动检查吗？
需要检查实际输出，但不必手工重写所有标签。插件可能正确生成关系，也可能因为原文关联、旧路径或其他 SEO 插件产生冲突。先从一组真实对应页完成上述验收，再决定修改数据还是生成配置。