本地化 URL slug 与 hreflang：为什么我们保留一个英文 slug

本地化 slug 是有效方案，它的成本是 hreflang 周围多出的一层对应关系。Google 的多语言网站指南明确说明 URL 可以使用本地化文字。重命名、重定向和缺失翻译并不会让方案本身失效，但会增加每个文档需要保持一致的状态。

这个网站以四种语言运行，而我们刻意不翻译 slug。AI 可见性的德语页面在 /de/services/ai-visibility/，而不是某个德语路径下。这是适合我们模板和验证关卡的工程取舍，不是普遍规则。

hreflang 实际要求的是什么

这份约定比工具让人以为的更简单。Google 的 hreflang 文档要求每个页面列出自身和所有可用版本，每个目标也必须返回这层关系。自引用是完整集合的一部分。

正是这条互指要求让本地化 slug 变得昂贵。用一个 slug 时，你只需要知道语言前缀。用翻译过的 slug 时，你需要一张正确且最新的对应表，把每个文档的四个不同字符串关联起来，而且它必须活过任何人做的每一次编辑。

本地化 slug 对应关系必须防住的四种失败

这些没有一个是解决不了的。它们都是按文档发生的，而这正是问题所在：它们只出现在少数页面上而不是全站，所以抽查看起来是干净的。

只用一个 slug 能换到什么

如果 slug 与语言无关，语言图谱就变成了路径前缀的函数。模板可以只依据语言列表和页面自己的文件名生成每一个 hreflang 指向，没有对应表需要维护，也没有东西可以失去同步。互指从需要你去核查的事，变成了结构上必然成立的事。

它也让相邻的检查变得便宜。一旦一个文档的每个语言版本共用同一个 slug，"这个文档是不是每种语言都翻译了" 就是一次基于文件名的集合比较。我们把这一点写进了构建：一个脚本断言四种语言在每个数据文件里包含相同的条目集合，另一个比较各语言内容是否出现漂移。这两件事之所以可能，只因为标识符是共用的。

同一个特性也帮到了非搜索引擎的机器。拿到你英文 URL 的智能体，可以按规则推出德语 URL。再配合每条路由一份 Markdown 镜像，就意味着每个文档、每种语言都有一个可预测的地址，中间不需要查表这一步。

诚实的代价

英文之外的语言会失去本地化且更直观的路径。读者在打开链接之前，可能会觉得地址不够清楚或熟悉。

我们接受这项体验成本，因为可预测的地址能简化模板、验证和机器可读镜像。Google 表示页面语言由可见内容而不是 URL 决定，因此我们不会把英文 slug 说成已证实的排名损失，也不会把本地化 slug 说成已证实的排名提升。

如果你的生意主要是单一市场里的本地语言搜索，而且只有二十几个页面，那就翻译 slug 吧。对应关系小到可以靠人工保持正确。这里讨论的是四种语言、几百条路由的情形，在那种规模上没人能靠人工把对应表维持正确。

迁移时不要丢掉已有的页面

如果你已经在用本地化 slug，这件事既不紧急，也不免费。真要做的时候：

1. 选定英文 slug 作为规范形式，并从此保持稳定。你现在做的这次重命名，应该是最后一次。
2. 从每个旧 slug 设置服务器端永久重定向，例如 301 或 308。至少保留一年；继续保留还能服务使用旧地址的用户和外部链接。
3. 从语言列表生成 hreflang，而不是从一张表生成，并确认每个页面都返回自引用。
4. 在 Search Console 提交更新后的 sitemap，并用 URL 检查工具检查有代表性或重要的地址。Google 的网址迁移指南没有承诺固定时限。
5. 检查内部链接是否直接指向新 slug，而不是绕经重定向，因为一个满是内部 301 的站点本身就是一个慢性问题。

第五步是最容易被跳过的。一个只能从你自己的导航到达的重定向，是一个你永远不会发现它出错了的重定向。