别再按语言自动重定向访客了——Hydrogen 的正确做法
你的店铺支持五种语言。一位意大利访客落在了英文首页。服务器要不要悄悄把他弹到
/it/？听起来很贴心。实际上这是对 SEO 伤害最大的做法之一。Shopify、Google 和 2026 年爬虫实测为什么都这么说——以及正确的替代方案是什么。
每个多语言店铺都会问的问题
当一个 Hydrogen 站点支持多种语言（EN / DE / FR / IT / ES）时，这个问题立刻就会出现：
能不能检测访客的语言，然后自动重定向到对应版本？
直觉上的答案是”当然可以”——读取浏览器的 Accept-Language 头或 IP 地理位置，然后服务端 302 到对应语言路径。
但深入研究 Shopify 官方文档、Google Search Central 指南和 2026 年爬虫行为研究后，三方独立来源指向同一个结论：自动重定向是 Bad Practice，Banner 提示才是 Best Practice。
什么是”Locale-Adaptive”页面？
这是解释一切的核心概念。Google 在 Search Central 文档中定义了它：
Locale-adaptive pages change their content to reflect the user’s language or perceived geographic location.
简单说：如果你的服务器对同一个 URL，根据访客的语言或地理位置返回不同内容——或跳转到不同地址，你的页面就是 locale-adaptive 的。
举例：
- 访客 A（浏览器语言
de）访问/→ 服务器返回 302 跳转到/de/ - 访客 B（浏览器语言
it）访问/→ 服务器返回 302 跳转到/it/ - 访客 C（无
Accept-Language）访问/→ 得到英文首页
这就是 locale-adaptive 行为。问题在于：Google 爬虫和 AI 爬虫不是普通访客。
Googlebot 实际是怎么抓的
Google 官方说明了三个事实：
- Googlebot 默认不发
Accept-Language请求头——所以你的服务器收到的请求”看起来像”美国英语用户。 - Googlebot 的默认 IP 看起来在美国——所以 IP 地理位置检测也会认为爬虫在美国。
- Google 可能无法完整索引你的所有语言版本——因为它主要从美国 IP、无语言偏好的角度抓取。
Google 确实在 2015 年后增加了非美国 IP 的分布式抓取和带 Accept-Language 的语言感知抓取——但那是自动检测后选择性启用的。你不能依赖它来保证所有语言版本被发现和索引。
Google 推荐的做法
We continue to support and recommend using separate URLs as they are still the best way for users to interact and share your content, and also to maximize indexing and better ranking of all variants of your content.
— Google Search Central Blog, 2015
也就是说：独立 URL + hreflang 注解——而不是一个 URL 根据来的人自适应。
Shopify 官方的立场
Shopify Hydrogen Localization Detection 文档用一个 Caution 框说得很清楚。无论你用不用 Shopify Markets，这个结论都成立：
| 官方原文 | 含义 | |
|---|---|---|
| ✅ Good | “Show a banner asking the user if they want to switch country” | 用横幅询问用户是否要切换 |
| ❌ Bad | “The user gets automatically redirected” | 用户被自动重定向 |
一个重要的边界：Shopify 并不是说”不要检测 locale”——检测明确可以用于改善用户体验。坏的是拿检测结果做自动重定向。
Shopify 列出了三个技术缺陷：
Other drawbacks of this approach are that page caching ignores locale cookies, headers and URL search params. SEO bots tend to origin from the US, don’t have cookies, and will not change their
accept-languageheaders.
翻译过来：
- 边缘缓存忽略 locale cookie 和请求头。 Hydrogen 运行在 Oxygen 边缘节点上，边缘会缓存响应。
Accept-Language和 locale cookie 都不是缓存键的一部分——第一个德国访客的 302 被缓存后，后续所有访客（包括美国人）都会被重定向到德语版。 - SEO 爬虫来自美国。 爬虫 IP 定位在美国 → IP 检测判定”美国” → 内容偏向英语。
- 爬虫不带 cookie。 即使用 cookie 记住用户的语言选择，爬虫来的时候也没有 cookie，重定向逻辑对它们的行为不可控。
Shopify 官方 Demo Store 是怎么做的
看 Shopify 官方 Hydrogen Demo Store 的 utils.ts。getLocaleFromRequest 函数只从 URL 路径提取 locale——完全不读 Accept-Language 做重定向：
export function getLocaleFromRequest(request: Request): I18nLocale {
const url = new URL(request.url);
const firstPathPart = '/' + url.pathname.substring(1).split('/')[0].toLowerCase();
return countries[firstPathPart]
? { ...countries[firstPathPart], pathPrefix: firstPathPart }
: { ...countries['default'], pathPrefix: '' };
}
Shopify 自己的参考实现就不做自动语言跳转。
2026 年的爬虫行为数据
MERJ 2026 年的研究实测了所有主流搜索引擎和 AI 爬虫的 Accept-Language 行为（发布于 2026 年 3 月，数据截至 2026 年 2 月）。这张表是决定性证据：
| 爬虫 | Accept-Language 行为 |
|---|---|
| Googlebot（Gemini 也用） | 不发。渲染阶段跟随 JS 重定向时会带 en-US |
| Bingbot（Copilot 也用） | 不发 |
| GPTBot (OpenAI) | 不发 |
| OAI-SearchBot (OpenAI) | 不发 |
| ClaudeBot (Anthropic) | 不发 |
| PerplexityBot | 不发 |
| ChatGPT-User | 有时 en-US,en;q=0.9，有时不发 |
| Applebot | 按 ccTLD 猜（.com → 不发，.de → de-DE） |
| Baiduspider | 不发 或 zh-CN,zh-TW |
| DuckDuckBot | 不发 或 en-US,en;q=0.8 |
最危险的边缘情况：渲染阶段
Googlebot 的初始 HTML 抓取确实不发 Accept-Language。但在渲染阶段，当页面中的 JavaScript 触发重定向后，后续请求会继承浏览器实例的默认 Accept-Language: en-US（MERJ 实测观察）。
如果你的重定向逻辑写在客户端 JS 里（比如 React Router 的 client loader），触发链是这样的：
1. Googlebot 抓取 / （HTML，无 Accept-Language）→ 返回英文页（正确）
2. Googlebot 渲染 / 中的 JS → JS 读取 navigator.language
3. 客户端语言重定向逻辑触发 → 跳转到 /en/
4. 索引信号变混乱：初始 HTML 是英文页，渲染后跳走了
这就是为什么即使服务端不做重定向，客户端的语言检测逻辑也可能干扰爬虫索引。
AI 搜索让问题更严重
GPT、Claude、Perplexity、Gemini 都在抓取网页用于检索增强生成。它们的 Accept-Language 行为更不可预测：
- 有些完全不发（安全）
- 有些发
en-US,en;q=0.9（默认值，不是用户意图） - 几乎没有任何 AI 爬虫会根据用户 prompt 的语言动态调整
Accept-Language
When present, Accept-Language is typically default
en-US,en;q=0.9. Therefore, Accept-Language based redirects for bots do not reliably improve user experience, introduce content accessibility risks, and can reduce indexing quality for both search engines and LLM retrieval systems.— MERJ, 2026
自动重定向的完整缺陷清单
如果你仍然坚持自动重定向（按 Accept-Language 或 IP 地理位置），你必须处理全部这些问题：
| # | 问题 | 原因 | 解法 |
|---|---|---|---|
| 1 | 边缘缓存语言污染 | Oxygen 缓存 302 响应；第一个访客的语言”污染”所有后续访客 | 加 Vary: Accept-Language 或对该路由禁用缓存 |
| 2 | 用户选择不被记住 | 纯 Accept-Language 没有记忆；手动切回去的用户下次又被重定向 | 加 locale cookie 覆盖层 |
| 3 | 深链接不触发 | 检测只在 / 生效；/about 永远不重定向 | 把逻辑搬到全局路由层（复杂度上升） |
| 4 | 302 vs 301 困境 | 301 会把根路径的 canonical 推向某个语言版本；302 多一次往返 | 只能用 302 |
| 5 | Googlebot 渲染阶段干扰 | 渲染用的浏览器实例带 en-US，可能触发客户端重定向 | 排除爬虫 UA（不可靠） |
| 6 | AI 爬虫语言偏差 | AI 爬虫发默认 en-US → 被弹到英文 → 非英文内容被忽略 | 维护爬虫白名单（永远滞后） |
| 7 | 额外网络往返 | / → 302 → /de/ 多一次 round trip | 无法消除 |
结论：问题 1–6 都有”解法”，但每个解法都在增加系统复杂度和维护成本。Banner 方案一次性消除全部七个问题。
Best Practice：Language Suggestion Banner
Shopify 推荐、Google 认可、实现最简单的方案。
工作原理
意大利访客访问 /（英文首页）
↓
服务端正常渲染英文页面（不重定向）
↓
服务端同时计算"推荐语言"（基于 Accept-Language 或 oxygen-buyer-country）
↓
推荐语言传给前端
↓
前端检查：
├─ 当前 locale ≠ 推荐 locale？（比如当前英文，推荐意大利语）
├─ 没有"已关闭"的 cookie？
└─ 两者都满足 → 显示 Banner
↓
Banner: "This site is also available in Italiano"
├─ [Switch to Italiano] → 跳转 /it/ + 写 cookie
└─ [Stay in English] → 关闭 Banner + 写 cookie
↓
下次访问：
└─ 优先读 cookie → 不再弹 Banner
方案对比
| 维度 | 自动重定向 | Banner 提示 |
|---|---|---|
| Shopify 官方 | ❌ Bad Example | ✅ Good Example |
| Google SEO | 有 locale-adaptive 风险 | 零风险 |
| AI 爬虫索引 | 有偏差风险 | 零风险 |
| 边缘缓存 | 需要 Vary 否则灾难 | 无影响 |
| 用户体验 | 强制猜测，不可逆 | 用户自选，可逆 |
| 实现复杂度 | 高（7 个问题逐一解决） | 低（一个组件 + 一段 cookie 逻辑） |
| 网络性能 | 多一次 round trip | 零额外请求 |
Hydrogen / React Router 实现要点
- 服务端推断推荐语言。 在 root loader 里读
accept-language或oxygen-buyer-country（Oxygen 提供 IP→国家映射），映射到支持的 locale，传给前端。不做重定向。 - Banner 组件。 一个
<LocaleSuggestionBanner>，检查当前 locale 是否与推荐语言不同，以及是否有”已关闭”cookie。 - Cookie 持久化。 用户点”切换”或”关闭”都写 cookie，Banner 不再重复出现。
- 保留手动切换器。 无论有没有 Banner，始终提供语言切换器——用户应该随时能按自己的意愿切换语言。
如果你的店面还要处理货币和市场路由，我们的用一个 Shopify 店铺卖向全球指南讲了 Markets 如何组织语言、货币和域名——Banner 就是建立在那套结构之上的。
如果我们不用 Shopify Markets，这个结论还适用吗？
适用。Shopify 官方文档的 “Good Example / Bad Example” 判断写在 Markets 章节下，但底层原因（缓存、cookie、爬虫行为）是 HTTP 和 SEO 层面的，与是否使用 Markets 无关。
大公司如 Amazon、IKEA 不是在做自动重定向吗？
是的，他们确实在做。但他们有专门的 SEO 团队维护爬虫白名单，有基础设施处理 Vary 头和边缘缓存，有预算做持续的爬虫行为监控。对于 Headless Storefront 项目，Banner 方案的投入产出比远高于自动重定向。
意大利访客打开网站看到英文，体验会不会很差？
Banner 可以做得很优雅——页面顶部一行提示，用访客的语言，一键切换。这比”我被传送到一个地方，不知道发生了什么”要好，而且选择权留在了用户手里。从我们在 Headless 项目上的实践看，Banner 的切换效果并不比自动重定向差——想换语言的用户本来就会换，不想换的用户被强制跳转反而是负体验。
推断推荐语言用 oxygen-buyer-country 还是 accept-language？
两个一起用，分层处理：
oxygen-buyer-country：IP → 国家（准确度高，但用户可能在用 VPN 或旅行）accept-language：浏览器语言偏好（准确度中等，但反映用户自己的选择）
我们的推荐策略：优先 accept-language（用户的显式偏好更可靠），fallback 到 oxygen-buyer-country。
搭建多语言 Hydrogen 店面是很多团队转向 Headless 的初衷之一——转过去之后别忘了，店面事件追踪需要从头重建。
来源
- Shopify — Hydrogen Localization Detection
- Google Search Central — Locale-Adaptive Pages
- Google Search Central Blog (2015) — Crawling and Indexing of Locale-Adaptive Pages
- MERJ — Your Accept-Language Redirects Could Be Blocking Search Engines and AI Crawlers（2026）
- Shopify Hydrogen Demo Store — app/lib/utils.ts
本文于 2026-08-11 基于 Shopify 官方文档、Google Search Central 与 MERJ 2026 年爬虫实测交叉核查。爬虫行为数据截至 2026 年 2 月（MERJ 测试）——搜索引擎和 AI 爬虫行为会持续演化，以官方文档为最终依据。
信息核对
核查日期: 2026-08-11
- Shopify — Hydrogen Localization Detection
- Google Search Central — Locale-Adaptive Pages
- Google Search Central Blog (2015) — Crawling and Indexing of Locale-Adaptive Pages
- MERJ — Your Accept-Language Redirects Could Be Blocking Search Engines and AI Crawlers (2026)
- Shopify Hydrogen Demo Store — app/lib/utils.ts