Open for new projects · sublimearts.io
← Blog
Web Design2026年5月28日·8分钟阅读

为什么我在每个项目中默认构建原生多语言Next.js路由 (IT/EN/ES)。

在Next.js/Astro中规划国际SEO路由,可以避免渲染延迟,并消除使用缓慢的自动翻译工具时暴露的缺陷。这正是此刻支撑本网站、以9种语言运行的架构。

喜欢这篇文章吗?文末有一个❤️在等你。

为什么多语言比看上去更重要

本地企业只用一种语言思考。想要吸引国际客户的企业——旅游、酒店、专业服务、电商——需要网站以原生方式存在于真实客户所搜索的语言中,而不是事后硬加上去的补丁。我为任何希望触达本国以外市场的客户构建网站时,都会从第一天起就配置多语言路由,因为之后再给单语言网站补上这一点,意味着要把元数据、URL结构,往往还有内容策略全部重做一遍。

为什么两种显而易见的捷径都行不通

大家最先想到的有两种捷径,而它们对真正的SEO都不奏效。第一种是悬浮的翻译小组件(嵌入Google Translate或类似工具):它在客户端运行,此时页面已经以原始语言加载完毕,因此搜索引擎收录的是原始文本——用西班牙语搜索的西班牙语访客,永远找不到一个在Google看来是西班牙语的页面。第二种是带查询参数的单一URL,比如?lang=es。搜索引擎并不能可靠地把查询参数变体视为独立、可单独排名的页面——它们常被当作同一URL的重复内容,这意味着你的西班牙语内容会与英语内容相互竞争,而不是在西班牙语搜索中独立排名。

解决办法:真正的路由,每种语言一个

每种语言都有自己可被抓取的路径——/it/、/en/、/es/——各自在服务器端渲染,包含完整翻译的内容、独立的<html lang>属性和独立的元数据。在Next.js中,把localePrefix设为“always”的next-intl开箱即用地提供了这些:不是一个靠JavaScript替换文字的页面,而是真正独立的页面,搜索引擎可以抓取、收录并独立排名——每一个都是该语言下真实、完整的页面,而不是套在同一内容上的翻译外壳。

本站实际是如何接线的

1定义支持的语言,并在next-intl路由配置中设置localePrefix: “always”,使每个URL——包括默认语言——都带有明确的/it/、/en/、/es/前缀,不存在含糊的根路由
2每种语言用一个JSON文件存放翻译字符串(messages/en.json、messages/it.json等),让每个界面字符串和每段页面文案按语言各有归处,而不是散落在各个组件里
3在generateMetadata()中,将alternates.canonical设为当前语言的URL,将alternates.languages设为包含每种语言对应URL的完整映射——这才是真正输出hreflang标签的地方,搜索引擎靠它把同一页面的各语言版本关联起来
4为每个页面设置openGraph.locale和合适的og:image,使分享出去的链接无论分享的是哪种语言版本都能正确预览
5绝不在请求时做机器翻译。翻译一次、存起来、按语言静态提供——这样首字节时间保持很快,关键渲染路径中也没有翻译API

这样做究竟能带来什么

每个语言版本各自按自己的条件排名——意大利语搜索会出现意大利语页面,西班牙语搜索会出现西班牙语页面,在Google眼中两者互不竞争,也不互相稀释。对转化同样重要的是:访客落地的页面读起来确实像是用他们的语言写成的,而不是角落里挂着一个明显的翻译小组件。对于想在国际受众面前显得可信的餐厅、酒店或专业服务来说,这种差别往往就是“跳出”与“成交”之间的差距。

想让这套架构运行在你的网站上吗?

聊一聊 →

About

Patrick Chen——Sublimearts.io背后的独立开发者兼网页设计师。正是这套路由方案——next-intl、localePrefix always、按语言设置的元数据——在渲染你此刻正在阅读的这个页面,无论你用的是9种语言中的哪一种。

Did you find this helpful?