1. 糟糕的开头
凌晨三点，我盯着 Google Search Console 那个死掉的心电图，整个人都麻了。我辛辛苦苦搓出来的“大作”，在中文搜索里排前三，但在英文、日文搜索里连个影子都见不到。最离谱的是，Google 居然把我手动翻译的几个页面标记为“重复内容（Duplicate content）”，直接不给收录。那一刻我才意识到：如果你只是生硬地加个中英文切换按钮，而没有一套完整的边缘路由 i18n 方案，你的代码在 Google 眼里就是个透明人。
2. 我的思考
市面上的 i18n 方案，要么是纯前端 react-i18next 动态渲染（爬虫根本等不及你加载 JS），要么就是要把每个语言的代码都复制一份（维护起来想死）。在 daima.life 的架构里，我追求的是：
- 静态先行 + 边缘加速：利用 Next.js 14 的
next-intl配合 Cloudflare Pages，在边缘侧就决定给用户发哪个语言的包。 - SEO 自动化：每一个工具路由（比如
/zh/json和/en/json）都必须有独立的metadata和hreflang标签。 - 无感切换：通过 Cloudflare 的
Accept-Language请求头实现自动跳转，同时支持/zh这种子路径路由，让 Google 觉得这就是给本地用户量身定制的。
3. 技术硬核区：边缘侧的 i18n 路由是怎么搓出来的？
我没用那些笨重的插件，而是直接在 src/middleware.ts 里玩了把大的：
- 子路径策略：统一使用
daima.life/[locale]/tool-name的格式。这样 Google 爬虫会把/en和/ja当作独立的站点权重来处理。 - Hreflang 自动化注入：在每个页面的
<head>里，我写了一个递归函数，自动生成当前页面的所有语言版本映射。这告诉 Google：“兄弟，这两页内容一样但语言不同，别把它们当成抄袭。” - JSON 扁平化处理：为了不让几千个翻译字段撑爆打包体积，我搓了一个脚本，在编译阶段只给对应的语言包注入对应的 JSON。配合
next-intl的 Server Components 渲染，首屏 HTML 里的文案直接就是对应语言，SEO 收录效率直接飞起。
4. FAQ 模块
Q: 为什么不用域名后缀（.jp, .us）做多语言？
A: 兄弟，那得买多少个域名？子路径路由（/en）能继承主域名的权重，对小站来说，这是“白嫖”SEO 权重的最佳姿势。
Q: 翻译质量太差会被 Google 降权吗？
A: 绝对会。所以我用 GPT-4o 搓了一个自动化翻译管线，专门根据技术文档的语境做校对，而不是生硬的机翻。
Q: Cloudflare Pages 处理多语言路由会有冷启动延迟吗？
A: 几乎没有。因为我们把多语言逻辑编译成了边缘侧的 Edge Middleware，配合缓存，响应时间依然是毫秒级，真香！