双语站的排名信号经常是”静默漏的”——translationKey 拼错、单向链接、缺自指、还有最经典的 zh vs zh-CN。这篇给你一个 30 分钟的 AI 辅助审计流程，能在 1000 篇规模的站点上抓出 4 大类常见错误，不需要去研究 Search Console 的 hreflang 报告。产出是一份”坏对清单”的 CSV，你可以直接回到源仓库改，再加一次 HTML 抽查。
这篇讲什么
一条可脚本化的审计管道：导出每篇文章的元数据、让 LLM 找结构性缺陷、回源修、重渲、重交 sitemap。AI 在做的是”上千行的模式匹配”，你本来要人肉一行行盯。我们只看 HTML head 里的 hreflang 和 sitemap 里的 hreflang——不讨论 HTTP header 形式（内容站很少用）。
这篇适合谁看
双语 / 多 locale 内容站的拥有者和维护者——EN/ZH、EN/JA、EN+ES+FR 都行，Astro / Next.js / Hugo 都行。如果你已有 translationKey 或 i18n-key 这种字段，工作流直接用。没有也行，因为 slug pair 本身就能当键。
什么时候适合用
每批内容上线后（10 篇以上新增或翻译）、每次大型 SEO 推进前（外链、sitemap 重交）、每次改 locale 代码或重命名 slug 之后。hreflang 错容易留下、人肉极难发现——必须自动化。
什么时候不适合
文章对数 < 50 篇就别上 AI 审计了，Search Console 的国际定位报告免费做这事。单语站也跳过，根本不需要 hreflang。
开始前准备
- 先确认 hreflang 策略。大多数双语站用
<link rel="alternate" hreflang="en" href="..."/>加一条x-default。写下来，等下对照渲染结果验证。 - 确定要支持的 locale 代码。
zh/zh-CN/zh-Hans/zh-Hant选一个用到底。混着用是 hreflang 集群被忽略的 #1 原因。 - 用一个长上下文模型。1000 行 CSV 加上渲染后的标签列，很容易超过 10 万 token。
具体步骤
- 生成 CSV，一行一篇。列：
slug、lang、translationKey、canonical_url、以及那一页渲染后的整段<link rel="alternate">。一个读 content collection 的 Node 脚本不到一分钟搞定。 - 用一份精确的清单去 prompt 模型：
审计这份 hreflang 配置。每行要标的问题：
1. 缺对：translationKey 相同但只有一种语言
2. translationKey 不匹配：同 slug 不同 key、或同 key 但 slug 对不上
3. locale 代码错：不在 [en, zh-CN] 允许集里（或你的集合）
4. 缺自指：该行没有自己语言的 hreflang
5. 缺 x-default
返回 TSV 列：issue, slug, lang, suggested_fix- 回源修。两种真正的修法：补缺失翻译，或改 translationKey。不要靠”删掉一条 hreflang 链接”来糊弄——审计看不到，但 Google 看得到。
- 重渲后抽查 5 个有代表性的页面：一篇热门 EN、它的 ZH 对、一篇只有 EN（也应该有 x-default 和自指）、首页、一个标签 / 索引页。
- 更新 sitemap 交到 Search Console。用 sitemap index 的话把所有子 sitemap 一起 ping。盯国际定位报告 7-14 天，错误应该趋向 0。
第一次实操怎么跑
- 第一次只审一个子目录或一个标签，30-50 篇。小批量模型准确率更高，prompt 的失败模式也便宜地暴露。
- 故意提前破坏一篇，跑前 plant 一个 bug，看 AI 抓不抓得到。漏抓说明 prompt 或 CSV 不够。
- AI 出的 TSV 跟修复 commit 一起存。下月再审时 diff 两份 TSV，能看到哪类 bug 在偷偷回潮。
- 第一次的 prompt 100% 抓到 plant 的 bug 之后，再扩到全站。
完成后检查
- 重渲后随机开 3 个页面看 head：每页都要有自指 hreflang、所有兄弟 locale 的 alternate、一条 x-default。
- 验 hreflang 的 URL 返回 200 而不是 301 / 404。模型不会跑这个——单独写一个失链脚本。
- 抽查每页的 canonical。hreflang 指向非 canonical URL 时整个集群会被静默忽略。
怎么复用这套流程
- 把审计 prompt 进 CI。每个 PR 改 > 10 篇文章就跑一次。
- “允许的 locale 代码”放在数据里，不要写死在 prompt 里。加第三语言时改起来方便。
- 留一份历史错误回归日志。同一个 translationKey 坏两次，就在 build 里直接加约束（每个 key 必须正好出现在 N 个 locale）。
建议的操作流程
CSV 导出 → 带明确清单的 AI 审计 → 回源修 → 重渲 → 抽查 5 个 HTML 页 → 重交 sitemap → 盯 Search Console 14 天。
容易踩的坑
- 用
zh而非zh-CN/zh-Hans——Google 当不同信号处理。全站统一。 - 忘
x-default——意外 locale 的用户被分到最坏 fallback。 - hreflang 在 head 但指向非 canonical URL——整个集群会被静默忽略。
- 单向 pair——EN 链到 ZH 但 ZH 没链回。hreflang 集群必须互指否则会被丢弃。
- 只审线上 HTML 没看 sitemap——两边必须一致，冲突时 Google 干脆都不信。
- 不抽查就照搬 AI 的”修复”——模型偶尔会建议看起来对但其实错的 locale 代码。
FAQ
- hreflang 错 Google 会惩罚吗？: 不会直接惩罚，但流量被分到错的 locale，CTR 和转化在该市场会跌。
- 是不是每页都要写 hreflang？: 每个可索引、有翻译的页面都要：首页、分类页、文章页都算。
- 只有 EN 的页面怎么处理？: 自指 EN，加一条
x-default指向自己。不要编一个 ZH 翻译出来。 - 模型多大概率会”幻觉”出一个 hreflang 问题？: 干净 prompt 下大概 5% 假阳性。永远先核实再改，不要照单全收。
- 没有 translationKey 也能跑吗？: 能。按 slug pair 约定分组，告诉模型规则即可。