Next.js+Express英阿双语双UI结构多语言站点SEO友好方案咨询

你原来的方案出现SEO问题的核心原因是将locale判断逻辑放在了客户端hydration之后执行，首屏SSR返回的HTML不包含实际页面内容，用下面的方案可以完全解决该问题，不需要额外做冗余的重定向逻辑： #

方案1：基于Next.js内置i18n能力做服务端渲染级别的组件判断 #

第一步：开启Next.js内置国际化配置 #

在next.config.js中添加i18n配置，声明支持的语言、默认语言：

module.exports = {
  i18n: {
    locales: ['en', 'ar'],
    defaultLocale: 'en',
  },
}

开启后Next.js会自动处理路由前缀（比如/en/xxx对应英文、/ar/xxx对应阿拉伯语），服务端侧可以直接拿到当前请求的locale参数，不需要等客户端加载后再判断。

第二步：在页面层做服务端侧的组件判断 #

不管是用Pages Router还是App Router，都可以在服务端阶段拿到locale直接渲染对应组件，返回的HTML就是完整的对应语言内容，完全满足SEO要求：

Pages Router写法（和你现有代码适配度最高）

// 页面组件文件
import EnglishPage from './EnglishPage'
import ArabicPage from './ArabicPage'

// 服务端阶段就可以拿到locale，不需要客户端判断
export default function Page({ locale }) {
  return locale === 'en' ? <EnglishPage /> : <ArabicPage />
}

// 不需要额外写业务逻辑，Next.js会自动把locale注入到页面props中
export function getServerSideProps(context) {
  return {
    props: {
      locale: context.locale,
    },
  }
}

如果你用自定义Express服务器

只需要保留Next.js内置的i18n路由处理逻辑即可，不需要自己写重定向规则，Next.js会自动根据请求头Accept-Language匹配对应语言，也支持用户手动切换语言后持久化偏好。 #

方案2：优化复用逻辑减少双组件维护成本 #

如果大部分UI只是排版方向差异，不需要完全维护两套组件，可以结合CSS逻辑属性降低维护量：

• 用margin-inline-start/padding-inline-start代替margin-left/padding-left，浏览器会自动根据dir属性适配LTR/RTL的左右边距
• 全局给html标签添加对应dir属性：英文页面加<html dir="ltr" lang="en">，阿拉伯语页面加<html dir="rtl" lang="ar">，所有CSS逻辑属性会自动生效
• 仅在结构差异极大的场景做组件分支判断，大幅减少重复代码

不需要额外重定向的原因 #

Next.js内置的i18n能力已经默认支持：

• 搜索引擎爬取/en/xxx路径时直接返回英文SSR内容，爬取/ar/xxx时直接返回阿拉伯语SSR内容，两套内容对应独立路径，完全符合SEO规则
• 普通用户访问根路径时会自动根据浏览器语言偏好跳转到对应语言路径，也支持用户手动切换

内容的提问来源于stack exchange，提问作者Elias Naf