--- title: "本地化 URL 会搞坏 hreflang：只保留一个英文 slug" canonical: https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/ language: zh description: "翻译 URL slug 会给系统加上按文档维护的对应表，并带来一整类静默的 hreflang 失败。为什么该用一个与语言无关的 slug，以及诚实的取舍。" image: "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 分钟 阅读 · 2026年8月18日 最近审核 2026年8月18日 [**下一篇**](/zh/blog/can-an-ai-agent-use-your-product/) # 本地化 URL 会搞坏 hreflang，我们只保留一个英文 slug 要点速览 多语言站点上大多数 hreflang 缺陷来自翻译 URL，而不是标注本身。hreflang 要求同一语言集合里的每个页面都指向所有版本（包括它自己），并且每个指向都要被目标页面反向返回。用翻译过的 slug 时，这种互指依赖一张正确且最新的对应表，把每个文档的多个字符串关联起来，于是产生四类反复出现的失败：重命名之后互指断裂、标注指向重定向、翻译还不存在时留下死指针，以及两个文档翻译成同一个 slug 造成的路径冲突。这四种都是按文档发生而不是全站发生，所以抽查看起来是干净的。保留一个与语言无关的 slug，会让语言图谱变成路径前缀的函数，于是 hreflang 可以直接从语言列表生成，不需要维护任何表格，而翻译一致性也变成构建关卡可以强制执行的集合比较。代价是真实的：除英文之外的每种语言都会失去 URL 里的关键词。相比完整翻译的标题、各级标题和正文，这是一个较弱的信号，在四种语言、几百条路由的规模上值得交换。如果你的站点很小、只面向一个市场，那就翻译 slug。 **多语言站点上大多数 hreflang 问题并不是 hreflang 的问题，而是 slug 的问题。**如果你在翻译页面之外还翻译 URL，那么每一次重命名、每一次重定向、每一处缺失的翻译，都会变成语言图谱悄悄崩掉的一条路径，而且只发生在没人盯着的那一小部分页面上。 这个网站以四种语言运行，而我们刻意不翻译 slug。AI 可见性的德语页面在 `/de/services/ai-visibility/`，而不是某个德语路径下。这是一个有真实代价的真实取舍，我们认为对多数团队来说这个取舍是对的。下面是理由，以及代价。 ## hreflang 实际要求的是什么 这份约定比工具让人以为的更简单。同一语言集合里的每个页面，都必须指向其他所有版本，包括它自己，而且每一个指向都必须被它所指向的那个页面反向返回。自引用的 hreflang 是正确且必需的，不是可以优化掉的冗余。 正是这条互指要求让本地化 slug 变得昂贵。用一个 slug 时，你只需要知道语言前缀。用翻译过的 slug 时，你需要一张正确且最新的对应表，把每个文档的四个不同字符串关联起来，而且它必须活过任何人做的每一次编辑。 ## 本地化 slug 造成的四种失败 | 失败 | 成因 | 症状 | | --- | --- | --- | | 互指断裂 | 某个语言的 slug 被重命名，其他语言仍指向旧字符串 | 语言簇裂成两个，而两边看起来都像权威版本 | | hreflang 指向重定向 | 标注指向重命名之前的 URL，那个 URL 现在返回 301 | 标注被打折处理，页面之间变成竞争而不是归组 | | 部分翻译 | 某个语言还没有这个文档的版本 | 要么是一个死指针，要么是一处静默的缺口，取决于循环是怎么写的 | | 路径冲突 | 两个英文文档翻译成了目标语言里同一个 slug | 一个页面覆盖另一个，通常是客户先发现的 | 这些没有一个是解决不了的。它们都是按文档发生的，而这正是问题所在：它们只出现在少数页面上而不是全站，所以抽查看起来是干净的。 ## 只用一个 slug 能换到什么 如果 slug 与语言无关，语言图谱就变成了路径前缀的函数。模板可以只依据语言列表和页面自己的文件名生成每一个 hreflang 指向，没有对应表需要维护，也没有东西可以失去同步。互指从需要你去核查的事，变成了结构上必然成立的事。 它也让相邻的检查变得便宜。一旦一个文档的每个语言版本共用同一个 slug，"这个文档是不是每种语言都翻译了" 就是一次基于文件名的集合比较。我们把这一点写进了构建：一个脚本断言四种语言在每个数据文件里包含相同的条目集合，另一个比较各语言内容是否出现漂移。这两件事之所以可能，只因为标识符是共用的。 同一个特性也帮到了非搜索引擎的机器。拿到你英文 URL 的智能体，可以按规则推出德语 URL。再配合 [每条路由一份 Markdown 镜像](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) ，就意味着每个文档、每种语言都有一个可预测的地址，中间不需要查表这一步。 ## 诚实的代价 除英文之外的每种语言，你都失去了 URL 里的关键词。对于一个用德语短语搜索的德国买家来说，德语 slug 是一个不大但真实的相关性与点击信号，而我们选择了不要它。 我们接受这一点有三个理由。相比标题、各级标题和正文，URL 里的关键词是很弱的信号，而那三者都是完整翻译的。它避免的失败是静默且会累积的，而它付出的收益是小而可衡量的。而在一个答案引擎和搜索引擎同样重要的站点上，一个可预测的地址比路径里的一个关键词更值钱。 如果你的生意主要是单一市场里的本地语言搜索，而且只有二十几个页面，那就翻译 slug 吧。对应关系小到可以靠人工保持正确。这里讨论的是四种语言、几百条路由的情形，在那种规模上没人能靠人工把对应表维持正确。 ## 迁移时不要丢掉已有的页面 如果你已经在用本地化 slug，这件事既不紧急，也不免费。真要做的时候： 1. 选定英文 slug 作为规范形式，并从此保持稳定。你现在做的这次重命名，应该是最后一次。 2. 把每个本地化 slug 永久 301 到它。这些重定向就留在那里；没有任何好理由去删掉它们。 3. 从语言列表生成 hreflang，而不是从一张表生成，并确认每个页面都返回自引用。 4. 重新提交 sitemap 并通知 IndexNow 端点，让改动在几天内而不是几个月内被收录。 5. 检查内部链接是否直接指向新 slug，而不是绕经重定向，因为一个满是内部 301 的站点本身就是一个慢性问题。 第五步是最容易被跳过的。一个只能从你自己的导航到达的重定向，是一个你永远不会发现它出错了的重定向。 ## 常见问题 ### URL slug 该为每种语言翻译吗？ 对于一两种语言的小站点，该翻译：关键词值得要，对应关系也还管得住。一旦超过几百条路由、三种以上语言，每个文档一个与语言无关的 slug 更稳健，因为那样 hreflang 的互指是由路径前缀推出来的，而不是靠一张没人维护的对应表。 ### 自引用的 hreflang 标签是必需的吗？ 是的。同一语言集合里的每个页面都必须列出所有版本，包括它自己。它不是冗余，删掉它是语言簇被忽略的常见原因。 ### 英文 slug 会影响本地排名吗？ 会略有影响，这一点我们直说。你会失去目标语言里一个较弱的相关性与点击信号。标题、各级标题和正文的权重要大得多，而它们保持完整翻译，这也是我们认为在较大规模上这个取舍值得的原因。 ### 如果某个页面还没有翻译成所有语言怎么办？ 只为已存在的版本输出 hreflang，绝不要指向缺失或会重定向的 URL。一个死掉的标注比没有标注更糟。 ### 怎么防止各语言的翻译逐渐脱节？ 把共用的 slug 当作关联键，并在构建里检查它。我们会断言四种语言在每个数据文件里包含相同的条目集合，并比较各语言内容是否漂移。这两项检查都依赖标识符在语言之间是共用的。 ### 旧的本地化 URL 需要一直可用吗？ 需要，而且是永久的。用 301 把它们指到规范 slug，并把重定向留着。外部链接和引用不会被更新，而一个失效的旧 URL 就是一次丢掉的引用。 ## 最终思考 翻译 URL，等于给一个本来不需要对应表的系统按文档加了一张对应表，而表里的每一条都是语言图谱静默断裂的一次机会。 保留一个与语言无关的 slug，把语言放进路径前缀，从语言列表生成 hreflang，并在构建里守住翻译一致性。你放弃的是一个较弱的关键词信号，换掉的是一整类静默失败。 ## 你可能也喜欢.. [**智能体可读的网站：llms.txt 与 Markdown 镜像** 决定答案引擎能否读到你的四个接口，以及值得用关卡守住的转换错误。](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) [**Wavect 对比通用型开发机构** 工作重叠在哪里，而计价模式与范围归属又不重叠在哪里。](/zh/compare/wavect-vs-dev-agencies/) 智能体工程 ## 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [AI 智能体能用你的产品，还是只能读到它？](/zh/blog/can-an-ai-agent-use-your-product/) - [Graft 评测 2026：智能体仓库地图该进 Git 吗？](/zh/blog/graft-review-agent-repo-map/) - [通过工具输出压缩降低编码代理成本](/zh/blog/codag-cost-control/) - [用 AI 编码智能体更聪明地管理 Token](/zh/blog/smarter-token-usage-with-your-ai-coding-agent/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 分钟 阅读 · 2026年8月18日 最近审核 2026年8月18日 [**下一篇**](/zh/blog/can-an-ai-agent-use-your-product/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "多语言站点上大多数 hreflang 缺陷来自翻译 URL，而不是标注本身。hreflang 要求同一语言集合里的每个页面都指向所有版本（包括它自己），并且每个指向都要被目标页面反向返回。用翻译过的 slug 时，这种互指依赖一张正确且最新的对应表，把每个文档的多个字符串关联起来，于是产生四类反复出现的失败：重命名之后互指断裂、标注指向重定向、翻译还不存在时留下死指针，以及两个文档翻译成同一个 slug 造成的路径冲突。这四种都是按文档发生而不是全站发生，所以抽查看起来是干净的。保留一个与语言无关的 slug，会让语言图谱变成路径前缀的函数，于是 hreflang 可以直接从语言列表生成，不需要维护任何表格，而翻译一致性也变成构建关卡可以强制执行的集合比较。代价是真实的：除英文之外的每种语言都会失去 URL 里的关键词。相比完整翻译的标题、各级标题和正文，这是一个较弱的信号，在四种语言、几百条路由的规模上值得交换。如果你的站点很小、只面向一个市场，那就翻译 slug。", "articleBody": " 博客概览/AI 与智能体/智能体工程 本地化 URL 会搞坏 hreflang，我们只保留一个英文 slug 要点速览 多语言站点上大多数 hreflang 缺陷来自翻译 URL，而不是标注本身。hreflang 要求同一语言集合里的每个页面都指向所有版本（包括它自己），并且每个指向都要被目标页面反向返回。用翻译过的 slug 时，这种互指依赖一张正确且最新的对应表，把每个文档的多个字符串关联起来，于是产生四类反复出现的失败：重命名之后互指断裂、标注指向重定向、翻译还不存在时留下死指针，以及两个文档翻译成同一个 slug 造成的路径冲突。这四种都是按文档发生而不是全站发生，所以抽查看起来是干净的。保留一个与语言无关的 slug，会让语言图谱变成路径前缀的函数，于是 hreflang 可以直接从语言列表生成，不需要维护任何表格，而翻译一致性也变成构建关卡可以强制执行的集合比较。代价是真实的：除英文之外的每种语言都会失去 URL 里的关键词。相比完整翻译的标题、各级标题和正文，这是一个较弱的信号，在四种语言、几百条路由的规模上值得交换。如果你的站点很小、只面向一个市场，那就翻译 slug。 多语言站点上大多数 hreflang 问题并不是 hreflang 的问题，而是 slug 的问题。如果你在翻译页面之外还翻译 URL，那么每一次重命名、每一次重定向、每一处缺失的翻译，都会变成语言图谱悄悄崩掉的一条路径，而且只发生在没人盯着的那一小部分页面上。 这个网站以四种语言运行，而我们刻意不翻译 slug。AI 可见性的德语页面在 /de/services/ai-visibility/，而不是某个德语路径下。这是一个有真实代价的真实取舍，我们认为对多数团队来说这个取舍是对的。下面是理由，以及代价。 hreflang 实际要求的是什么 这份约定比工具让人以为的更简单。同一语言集合里的每个页面，都必须指向其他所有版本，包括它自己，而且每一个指向都必须被它所指向的那个页面反向返回。自引用的 hreflang 是正确且必需的，不是可以优化掉的冗余。 正是这条互指要求让本地化 slug 变得昂贵。用一个 slug 时，你只需要知道语言前缀。用翻译过的 slug 时，你需要一张正确且最新的对应表，把每个文档的四个不同字符串关联起来，而且它必须活过任何人做的每一次编辑。 本地化 slug 造成的四种失败 失败成因症状 互指断裂某个语言的 slug 被重命名，其他语言仍指向旧字符串语言簇裂成两个，而两边看起来都像权威版本 hreflang 指向重定向标注指向重命名之前的 URL，那个 URL 现在返回 301标注被打折处理，页面之间变成竞争而不是归组 部分翻译某个语言还没有这个文档的版本要么是一个死指针，要么是一处静默的缺口，取决于循环是怎么写的 路径冲突两个英文文档翻译成了目标语言里同一个 slug一个页面覆盖另一个，通常是客户先发现的 这些没有一个是解决不了的。它们都是按文档发生的，而这正是问题所在：它们只出现在少数页面上而不是全站，所以抽查看起来是干净的。 只用一个 slug 能换到什么 如果 slug 与语言无关，语言图谱就变成了路径前缀的函数。模板可以只依据语言列表和页面自己的文件名生成每一个 hreflang 指向，没有对应表需要维护，也没有东西可以失去同步。互指从需要你去核查的事，变成了结构上必然成立的事。 它也让相邻的检查变得便宜。一旦一个文档的每个语言版本共用同一个 slug，\"这个文档是不是每种语言都翻译了\" 就是一次基于文件名的集合比较。我们把这一点写进了构建：一个脚本断言四种语言在每个数据文件里包含相同的条目集合，另一个比较各语言内容是否出现漂移。这两件事之所以可能，只因为标识符是共用的。 同一个特性也帮到了非搜索引擎的机器。拿到你英文 URL 的智能体，可以按规则推出德语 URL。再配合每条路由一份 Markdown 镜像，就意味着每个文档、每种语言都有一个可预测的地址，中间不需要查表这一步。 诚实的代价 除英文之外的每种语言，你都失去了 URL 里的关键词。对于一个用德语短语搜索的德国买家来说，德语 slug 是一个不大但真实的相关性与点击信号，而我们选择了不要它。 我们接受这一点有三个理由。相比标题、各级标题和正文，URL 里的关键词是很弱的信号，而那三者都是完整翻译的。它避免的失败是静默且会累积的，而它付出的收益是小而可衡量的。而在一个答案引擎和搜索引擎同样重要的站点上，一个可预测的地址比路径里的一个关键词更值钱。 如果你的生意主要是单一市场里的本地语言搜索，而且只有二十几个页面，那就翻译 slug 吧。对应关系小到可以靠人工保持正确。这里讨论的是四种语言、几百条路由的情形，在那种规模上没人能靠人工把对应表维持正确。 迁移时不要丢掉已有的页面 如果你已经在用本地化 slug，这件事既不紧急，也不免费。真要做的时候： 选定英文 slug 作为规范形式，并从此保持稳定。你现在做的这次重命名，应该是最后一次。 把每个本地化 slug 永久 301 到它。这些重定向就留在那里；没有任何好理由去删掉它们。 从语言列表生成 hreflang，而不是从一张表生成，并确认每个页面都返回自引用。 重新提交 sitemap 并通知 IndexNow 端点，让改动在几天内而不是几个月内被收录。 检查内部链接是否直接指向新 slug，而不是绕经重定向，因为一个满是内部 301 的站点本身就是一个慢性问题。 第五步是最容易被跳过的。一个只能从你自己的导航到达的重定向，是一个你永远不会发现它出错了的重定向。 常见问题 URL slug 该为每种语言翻译吗？ 对于一两种语言的小站点，该翻译：关键词值得要，对应关系也还管得住。一旦超过几百条路由、三种以上语言，每个文档一个与语言无关的 slug 更稳健，因为那样 hreflang 的互指是由路径前缀推出来的，而不是靠一张没人维护的对应表。 自引用的 hreflang 标签是必需的吗？ 是的。同一语言集合里的每个页面都必须列出所有版本，包括它自己。它不是冗余，删掉它是语言簇被忽略的常见原因。 英文 slug 会影响本地排名吗？ 会略有影响，这一点我们直说。你会失去目标语言里一个较弱的相关性与点击信号。标题、各级标题和正文的权重要大得多，而它们保持完整翻译，这也是我们认为在较大规模上这个取舍值得的原因。 如果某个页面还没有翻译成所有语言怎么办？ 只为已存在的版本输出 hreflang，绝不要指向缺失或会重定向的 URL。一个死掉的标注比没有标注更糟。 怎么防止各语言的翻译逐渐脱节？ 把共用的 slug 当作关联键，并在构建里检查它。我们会断言四种语言在每个数据文件里包含相同的条目集合，并比较各语言内容是否漂移。这两项检查都依赖标识符在语言之间是共用的。 旧的本地化 URL 需要一直可用吗？ 需要，而且是永久的。用 301 把它们指到规范 slug，并把重定向留着。外部链接和引用不会被更新，而一个失效的旧 URL 就是一次丢掉的引用。 最终思考 翻译 URL，等于给一个本来不需要对应表的系统按文档加了一张对应表，而表里的每一条都是语言图谱静默断裂的一次机会。保留一个与语言无关的 slug，把语言放进路径前缀，从语言列表生成 hreflang，并在构建里守住翻译一致性。你放弃的是一个较弱的关键词信号，换掉的是一整类静默失败。 你可能也喜欢.. 智能体可读的网站：llms.txt 与 Markdown 镜像 决定答案引擎能否读到你的四个接口，以及值得用关卡守住的转换错误。 Wavect 对比通用型开发机构 工作重叠在哪里，而计价模式与范围归属又不重叠在哪里。 智能体工程 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 从核心文章开始AI 智能体的图工程：知识图谱什么时候值得做？ 智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里 AI 智能体能用你的产品，还是只能读到它？ Graft 评测 2026：智能体仓库地图该进 Git 吗？ 通过工具输出压缩降低编码代理成本 用 AI 编码智能体更聪明地管理 Token 集群中的上一篇智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里集群中的下一篇AI 智能体能用你的产品，还是只能读到它？ 相关服务路径： AI 可见性 看看生产环境中的应用: 债券分析平台 先做决定: 如何挑选软件开发公司 只收重要内容 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 Company 电子邮箱 你希望接收哪些内容？ 完整的 Wavect 博客接收六个主题下的每一篇新文章。 仅接收所选主题请在下方选择一个或多个分类。 选择主题 AI 与智能体 产品与 MVP 交付与 QA 领导力与团队 商业与监管 Web3 与隐私 我希望接收所选的 Wavect 博客邮件，并已阅读 隐私信息。我可以随时退订。 发送确认邮件→ 免费、双重确认、不使用跟踪像素。 ", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "多语言站点上大多数 hreflang 缺陷来自翻译 URL，而不是标注本身。hreflang 要求同一语言集合里的每个页面都指向所有版本（包括它自己），并且每个指向都要被目标页面反向返回。用翻译过的 slug 时，这种互指依赖一张正确且最新的对应表，把每个文档的多个字符串关联起来，于是产生四类反复出现的失败：重命名之后互指断裂、标注指向重定向、翻译还不存在时留下死指针，以及两个文档翻译成同一个 slug 造成的路径冲突。这四种都是按文档发生而不是全站发生，所以抽查看起来是干净的。保留一个与语言无关的 slug，会让语言图谱变成路径前缀的函数，于是 hreflang 可以直接从语言列表生成，不需要维护任何表格，而翻译一致性也变成构建关卡可以强制执行的集合比较。代价是真实的：除英文之外的每种语言都会失去 URL 里的关键词。相比完整翻译的标题、各级标题和正文，这是一个较弱的信号，在四种语言、几百条路由的规模上值得交换。如果你的站点很小、只面向一个市场，那就翻译 slug。", "headline": "本地化 URL 会搞坏 hreflang：只保留一个英文 slug", "image": "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.svg", "inLanguage": "zh", "keywords": "AI 可见性, 多语言", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/", "wordCount": 221 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/english-slugs-vs-localized-urls-hreflang/", "name": "本地化 URL 会搞坏 hreflang：只保留一个英文 slug | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对于一两种语言的小站点，该翻译：关键词值得要，对应关系也还管得住。一旦超过几百条路由、三种以上语言，每个文档一个与语言无关的 slug 更稳健，因为那样 hreflang 的互指是由路径前缀推出来的，而不是靠一张没人维护的对应表。" }, "name": "URL slug 该为每种语言翻译吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "是的。同一语言集合里的每个页面都必须列出所有版本，包括它自己。它不是冗余，删掉它是语言簇被忽略的常见原因。" }, "name": "自引用的 hreflang 标签是必需的吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "会略有影响，这一点我们直说。你会失去目标语言里一个较弱的相关性与点击信号。标题、各级标题和正文的权重要大得多，而它们保持完整翻译，这也是我们认为在较大规模上这个取舍值得的原因。" }, "name": "英文 slug 会影响本地排名吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "只为已存在的版本输出 hreflang，绝不要指向缺失或会重定向的 URL。一个死掉的标注比没有标注更糟。" }, "name": "如果某个页面还没有翻译成所有语言怎么办？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "把共用的 slug 当作关联键，并在构建里检查它。我们会断言四种语言在每个数据文件里包含相同的条目集合，并比较各语言内容是否漂移。这两项检查都依赖标识符在语言之间是共用的。" }, "name": "怎么防止各语言的翻译逐渐脱节？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "需要，而且是永久的。用 301 把它们指到规范 slug，并把重定向留着。外部链接和引用不会被更新，而一个失效的旧 URL 就是一次丢掉的引用。" }, "name": "旧的本地化 URL 需要一直可用吗？" } ] } ```