多语言网站 Hreflang QA 检查清单

Hreflang QA 检查清单的作用，是避免多语言网站上线后让搜索引擎无法判断哪个页面应该展示给哪个用户。Hreflang 不是排名技巧，而是一个技术信号，用来说明哪些本地化 URL 属于同一组内容。

这份清单适合多语言网站、Shopify Markets、Headless Commerce 店铺、WordPress 主题上线，以及新增或重组语言版本的网站改版项目。上线前、内容迁移后，以及 URL、canonical、重定向或 locale 路由规则变更时，都应该重新执行。

不要从代码开始。先建立一张 URL 矩阵，列出每个语言和地区版本的精确页面集合。每一行代表一个内容主题，每一列代表一个 locale URL。这样能在上线前看到缺口，而不是等生产环境出现错误标签。

URL 矩阵也应该包含页面状态。还在草稿中、被 noindex、发生重定向或暂时缺失的翻译页面，不应该被当作已上线替代版本。如果关系还不完整，就记录 fallback 决策，不要发布假的 alternate。

• 建立内容类型、默认 URL、各语言 URL、canonical URL、索引状态、重定向状态、负责人和上线状态字段。
• 使用完整的 HTTPS URL，不要使用相对路径或省略协议的 URL。
• 区分语言级目标，例如 en，以及地区级目标，例如 en-us 或 en-gb。
• 标记故意不翻译的页面，避免它们收到错误的替代版本。
• 把 URL 矩阵和重定向表、sitemap 备注、内容迁移状态放在同一个 QA 工作区。

每个已上线的本地化页面，都应该列出自己，以及同一组中其他有效语言或地区版本。关系也需要双向成立。如果英文页指向中文页，中文页也应该指回英文页。

很多多语言上线问题都出在这里。团队只在默认语言模板里加了标签，却忘记翻译模板；或者新增一个地区页面后，只让新页面指向旧页面集合，而旧页面没有指回来。搜索引擎可能忽略不完整的关系，所以要检查整组，而不是只看单个页面。

• 打开一组样例中的每个 locale URL，并并排比较 alternate 集合。
• 确认当前页面也出现在自引用 alternate 中。
• 确认每个列出的 alternate 都返回 200、可索引，并且属于同一内容意图。
• 检查语言和地区代码是否有效且格式一致，例如 en、zh、en-us 或 zh-hant。
• 不要把 noindex、robots 阻挡、登录墙或强制重定向页面放进 alternate 集合。

Canonical 和 hreflang 解决的是不同问题，但输出必须一致。Canonical 通常应该指向同语言页面的规范 URL，而不是统一指向一个全局默认语言。如果所有翻译页都 canonical 回英文页，翻译 URL 可能无法作为有效替代版本参与搜索。

对于内容非常相似的地区版本，要提前制定策略。加拿大英文页、英国英文页和通用英文页可以是一组有效 alternates，但每个页面都需要清楚的 canonical 规则。不要让 CMS 默认值、Shopify 主题设置或 SEO 插件在背后替你决定。

• 在渲染后的 HTML 中验证每个 locale 页面上的 canonical，而不是只看 CMS 字段。
• 检查 canonical URL 是否使用最终生产环境的协议、域名、路径、尾斜杠和语言前缀规则。
• 除非翻译页面本来就不打算索引，否则不要把所有语言版本 canonical 到默认语言。
• 对比 canonical、sitemap URL 和内部链接，避免搜索信号互相冲突。
• 预览域名切到生产域名、反向代理规则变化或 Shopify Markets 路由变化后，重新测试 canonical。

当用户的语言或地区不匹配任何具体 alternate 时，x-default 很有用。它通常指向全球选择页、默认语言页，或让用户选择市场的首页。关键不是一定要加，而是团队要主动决定。

不要因为插件提供了 x-default 选项就直接开启。如果默认页会根据地理位置、语言或浏览器设置自动重定向，要确认搜索引擎和用户仍然能访问各个替代 URL。强制跳转会破坏检查、索引和人工 QA。

• 决定 x-default 指向选择页、默认语言页，还是该组页面不使用 x-default。
• 确认 x-default URL 可抓取，并且在需要时可索引，同时不会被强制地理跳转阻挡。
• 同一组 alternate 中的所有页面应使用同一套 x-default 决策。
• 为结账、账户、法务、支持或活动页面记录例外。
• 新增国家、语言、币种或市场域名时，重新检查 x-default。

Google 支持通过 HTML head 标签、HTTP header 或 XML sitemap 提供 hreflang。三种方式都可以工作，但同时维护多个来源很容易产生漂移。选择团队日常发布时最能保持准确的来源，而不是只在上线周能勉强维护的来源。

在 Shopify 和 WordPress 中，实现可能来自主题、SEO 插件、多语言 App 或 sitemap 生成器。在 Headless Commerce 中，实现可能来自路由层、CMS 内容模型、edge middleware 或构建时 sitemap 任务。既要检查事实来源，也要检查最终渲染输出。

• 确认 hreflang 是由主题代码、CMS 字段、插件设置、App 配置、HTTP header 还是 sitemap 生成逻辑输出。
• 除非 HTML 和 XML sitemap 的值完全一致且有意维护，否则避免从两个来源发布冲突的 alternates。
• 测试商品、collection、博客文章、资源页和落地页等动态模板，不要只测试首页。
• 只有在 HTTP header 实现被明确支持并记录时，才把非 HTML 资源纳入 hreflang。
• 在每次多语言发布前，加一个可重复的 QA 步骤，把生成结果和 URL 矩阵对比。

即使 hreflang 标签完全正确，如果 URL 意外重定向、语言切换指向错误页面，或 alternate 被 noindex，也会失败。要像用户一样测试页面，也要像爬虫一样测试页面。正确 URL 应该能直接打开、保持可索引，并允许用户切换到另一种语言中的对应页面。

网站改版和迁移后要特别注意。旧语言前缀、国家目录、子域名和翻译 slug 经常会和 canonical、sitemap 逻辑一起变化。这会让一组本来正确的替代关系在多个位置断掉。

• 在没有 cookie 的情况下直接请求每个 alternate URL，确认它不会强制跳到另一个 locale。
• 按 URL 矩阵检查桌面端和移动端语言切换。
• 确认 noindex、canonical、robots.txt 和登录规则不会把有效替代版本从搜索中移除。
• 验证旧翻译 URL 的重定向链，确保它们落到对应的新语言页面。
• 单独检查 Open Graph locale 标签；它不能替代 hreflang，但经常能暴露映射错误。

Hreflang QA 不会在标签出现在源码里时结束。上线后继续查看 Search Console、服务器日志、sitemap 抓取、抓取统计和自然搜索落地页表现。重点观察错误语言曝光、意外 canonical 选择、缺失 alternate，以及几乎没有抓取活动的 locale 页面。

第一轮监控要短而具体。先看最高价值模板：首页、核心商品页、核心 collection、服务页、资源页和高流量博客文章。等搜索引擎有时间重新抓取 sitemap 和模板后，再安排第二轮复查。

• 提交更新后的 sitemap，并在 Search Console 中抽查重要 URL。
• 跟踪优先市场的点击、曝光和落地页语言分布。
• 检查应该独立索引的翻译页面是否被选择为正确 canonical。
• 记录每个问题的 URL、预期 alternate、实际 alternate、输出来源、负责人和修复状态。
• 新增翻译、重定向、CMS 模板或市场规则后，同步更新 URL 矩阵。