hreflang 要工程化，别靠人工。页面超过 200 个，手写一定漏，而且漏了不会报错。我们现在的做法是生成器加校验脚本，接进发布流程，漏了就不让上线。
三种实现位置
HTML head 里的 link 标签、HTTP 响应头、sitemap 里的 xhtml:link。我们统一用 HTML head 加 sitemap 双写，两处必须一致，冲突时以 HTML 为准。非 HTML 资源（PDF 白皮书之类）才用响应头。
生成器怎么设计
输入是页面 ID、语言、地区、这个页面有哪些翻译版本，输出是每个语言版本页面上的完整 link 标签组。数据来自内容库里的翻译关联表，不是从 URL 字符串猜。这点很重要：URL 规则一改，猜出来的关系就全错了。
三条校验规则
- 每个页面必须包含自身语言的 hreflang，自引用不能缺。
- A 指向 B，B 必须指向 A，双向关系。
- 一个语言组里 x-default 有且只有一个。
再加两条容错：指向的 URL 必须返回 200 且不是 noindex；语言代码必须在合法列表里，en-UK 这种拼错要拦住。
2025 年 11 月那次接入
一个出海 SaaS，14 个语言、8000 个翻译页面。原来人工维护 sitemap 里的 hreflang，抽查发现漏了 23%。接入生成器后，校验脚本全量跑一遍 8 分钟，一次通过；新增语言版本的上线时间从两天缩到半天。
发布流程
语言版本上线，生成器写入 hreflang，校验脚本跑，通过才允许发布。失败时输出具体页面和缺失的语言，直接给到开发。这套流程跑了一年多，没再出现过整组失效的问题。
校验脚本长什么样
输入是爬虫导出的全站 HTML，输出是三张表：缺自引用的页面、单向指向的页面、语言组合法但 URL 异常的页面。用 Python 加正则就能写，一百行以内。我们把它做成 CI 里的一步，每次构建失败会直接指出哪个页面、缺哪个语言，不用人去翻源码。
什么时候不值得做
只有两三个语言版本、每个版本页面不多的站，别上这套工程。HTML head 里手写一组 link 标签就够，维护成本比写脚本低。语言版本超过 5 个、或者翻译页面超过 500 个，再考虑生成器。
还有一个判断：如果某个语言版本的内容只是机翻、没有本地化，先把内容补齐再谈 hreflang。语言组里塞一堆机翻页，搜索引擎会整组降低信任，比不配更糟。
立场
没有校验脚本的 hreflang 等于没有 hreflang。配错了搜索引擎不会提醒你，只会安静地展示错的语言版本，然后你以为是内容问题。
元析智能
为软件公司做 SEO 和 GEO 优化