# General Translation Knowledge Base: 如何为多语言 Next.js 应用设置 SEO？ URL: https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx Docs index: https://generaltranslation.com/llms.txt Description: 为每种语言提供带前缀的独立 URL，例如 /en/about 和 /es/about，然后为每种已发布的语言提供 html lang、自引用的规范网址、包含 x-default 的 hreflang 替代项、翻译后的 title 和 description，以及站点地图条目。将未发布的版本标记为 noindex。General Translation 的 gt-next 会将每种语言路由到各自的 URL，并通过 getGT 翻译标题。 Category: 多语言 SEO Last updated: 2026-10-22 Authors: General Translation Team Published: 2026-02-17 在 Next.js 中实现多语言 SEO，就是为页面的每个语言版本分配独立的 URL，并告诉搜索引擎这些 URL 之间的关系。如果页面根据 cookie 或 `Accept-Language` 请求头来决定语言，它就只有一个 URL，搜索引擎通常也只会收录其中一种语言。每个语言版本都需要满足下表中的六项要求，且路由、元数据和站点地图中每种语言的 URL 必须保持一致。 | 要求 | 作用 | 在 Next.js 中的位置 | | -------------- | ---------------------------------------------- | --------------------------------------------- | | 每种语言一个 URL | 每个版本都是可单独抓取和索引的页面 | `[locale]` 路由段和区域设置路由中间件 | | `` | 向浏览器和辅助技术标明页面语言 | 根布局 `app/[locale]/layout.tsx` | | 规范网址 | 表明该 URL 是其所属语言的首选版本，而非其他语言版本的重复页面 | `generateMetadata` 中的 `alternates.canonical` | | `hreflang` 替代项 | 列出该页面所有已发布的语言版本 (包括当前版本) ，外加一个 `x-default` 后备项 | `generateMetadata` 中的 `alternates.languages` | | 翻译后的标题和描述 | 搜索结果中通常以该语言展示的文本 | `generateMetadata` 中的 `title` 和 `description` | | 站点地图条目 | 列出每个页面所有已发布的语言 URL | `app/sitemap.ts` | General Translation 的 `gt-next` 会将每种语言路由到类似 `/es/about` 的 URL，并通过 [`getGT`](/docs/react/nextjs/reference/functions/get-gt) 翻译标题和描述。规范网址、`hreflang` 替代项和站点地图则由 Next.js [元数据 API](https://nextjs.org/docs/app/api-reference/functions/generate-metadata#alternates) 生成。 ## Video The video is narrated in English, with English captions. [How do I set up SEO for a multilingual Next.js app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-nextjs-seo.mp4) (50秒) General Translation lets you give every language its own URL and tell search engines about them. Move your pages into `app/[locale]` with `gt-next`'s middleware, set the html `lang` attribute with `useLocale`, add canonical and hreflang links with a helper, translate the title with `getGT`, and list every page in every language in a sitemap. ## 为什么 Google 只索引了我的 Next.js 网站的一种语言？如果所有语言共用同一个 URL，Google 就只会索引其中一种语言。Googlebot [发送请求时不带 `Accept-Language` 请求头](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages)，也[不会在页面加载之间保留 cookie](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript)。因此，凡是依据这两者来决定显示语言的页面，每次呈现给 Google 的都只是默认语言，其他语言则没有可供 Google 抓取的 URL。解决方法是为每种语言提供独立的 URL，并将其列入 `hreflang` 替代项和站点地图。与使用 Cookies 或浏览器设置相比，Google [更推荐为每个语言版本使用独立的 URL](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)。未配置中间件的 General Translation `gt-next` 应用同样存在这个问题：其区域设置选择器会将用户的选择存储在 cookie 中，而在你添加 [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) 之前，URL 始终不带区域设置前缀。完整翻译的英文页面和法文页面，并不会仅仅因为介绍的是同一款产品就被视为重复内容。只有当主要内容仍未翻译时，Google 才会将本地化版本视为重复内容。 (参见 Google 的[本地化页面指南](https://developers.google.com/search/docs/specialty/international/localized-versions)。) ## 不同语言版本应使用子目录、子域名还是独立域名？除非每个市场都需要独立的服务器位置或独立的站点，否则请使用子目录，例如 `example.com/es/about`。Google 的[管理多地区和多语言网站](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)指南指出，子目录易于设置、维护成本低，因为所有语言版本都位于同一主机上；该指南还不建议使用 URL 参数。 | 结构 | 示例 | Google 的评估 | 在 Next.js 应用中 | | --------------- | --------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | 子目录 | `example.com/es/about` | 易于设置，维护成本低 (同一主机) ，单一服务器位置 | General Translation 的 `gt-next` 中间件默认支持此结构 | | 子域名 | `es.example.com/about` | 易于设置，可使用不同的服务器位置 | 需自行编写基于主机的路由；[`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) 按路径进行路由 | | 国家/地区域名 | `example.es/about` | 地理定位明确，但成本高、所需基础设施更多，且每个域名只能对应一个国家/地区 | 每个域名需单独部署或使用基于主机的路由 | | URL 参数 | `example.com/about?lang=es` | 不推荐 | 避免使用 | | 仅使用 cookie 或请求头 | `example.com/about` | 建议改用独立的 URL | 只会以一种语言被索引 | 如果各市场需要独立托管或按国家/地区定向，请使用子域名或国家/地区域名。如果只有单个 Next.js 部署，子目录所需的代码最少：General Translation 的 `gt-next` 中间件默认即可提供 `/es/about`，而子域名和国家/地区域名则需要你自行编写基于主机的路由。 (各方案的利弊权衡请参阅 [URL 结构对比](/kb/multilingual-url-structure)。) ## 如何在 Next.js 中为每种语言提供独立的 URL？添加区域设置路由中间件和 `app/[locale]` 路由段。如果使用 General Translation 的 `gt-next`，请在项目根目录下创建 `proxy.ts` (Next.js 15 及更早版本则为 `middleware.ts`) ： ```ts title="proxy.ts" import { createNextMiddleware } from 'gt-next/middleware'; export default createNextMiddleware({ prefixDefaultLocale: true }); export const config = { matcher: ['/((?!api|static|.*\\..*|_next).*)'], }; ``` 然后将你的页面移到 `app/[locale]` 目录下： ```text proxy.ts app/ ├── sitemap.ts └── [locale]/ ├── layout.tsx ├── page.tsx └── about/ └── page.tsx ``` `prefixDefaultLocale: true` 会为包括英语在内的所有区域设置加上前缀，因此每个内容 URL 始终只对应一种语言。本文全程采用这一配置。像 `/about` 这样不带前缀的路径会充当入口：中间件会返回临时 `307` 重定向，将访问者引导至其已保存的区域设置或与 `Accept-Language` 最匹配的区域设置；如果两者都没有，则重定向到 `/en/about`。本地化 URL 始终不会跳转；即使浏览器偏好法语，`/en/about` 也会返回英语内容。如果不启用该选项，默认区域设置不带前缀，`/about` 可能会根据 cookie 或浏览器请求头进行重定向。(原因请参阅[区域设置路由与 SEO](/kb/locale-routing-seo)。) 另有两项设置会改变路由行为： * [`pathConfig`](/docs/react/nextjs/reference/functions/create-next-middleware#path-config) 用于翻译路径，例如将 `/about` 翻译为 `/fr/a-propos`。 * 在 `withGTConfig` 中设置 [`ignoreBrowserLocales: true`](/docs/react/nextjs/config#ignore-browser-locales)，中间件将不再根据 `Accept-Language` 请求头选择区域设置。Google [不建议根据对访问者语言的猜测进行重定向](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)。如果你使用 `generateStaticParams` 预渲染页面，还需要在项目根目录下添加 `getLocale.ts`，因为静态生成期间中间件不会运行。[App Router 中间件指南](/docs/react/nextjs/app-router-middleware#root-locale)提供了该文件以及完整的路由配置步骤。 ## 如何为每个区域设置配置 html lang 属性？在根布局 `app/[locale]/layout.tsx` 中，根据 `[locale]` 路由参数设置 `lang`。加上 [`isLocaleSupported`](/docs/react/nextjs/reference/functions/is-locale-supported) 检查后，访问未配置的区域设置时，该 URL 会返回 404，而不会回退到默认区域设置： ```tsx title="app/[locale]/layout.tsx" import { GTProvider, isLocaleSupported } from 'gt-next'; import { notFound } from 'next/navigation'; export default async function LocaleLayout({ children, params, }: { children: React.ReactNode; params: Promise<{ locale: string }>; }) { const { locale } = await params; if (!isLocaleSupported(locale)) { notFound(); } return ( {children} ); } ``` `lang` 属性用于向辅助技术和具备语言感知能力的浏览器功能标明页面语言。Google 依据[可见内容](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#language)而非 `lang` 属性来判断页面语言，因此保持该属性准确是出于无障碍访问的考虑，而不是把它当作影响排名的开关。如果页面需要预渲染，根布局应放在 `app/[locale]/layout.tsx` 中，因为位于 `[locale]` 段之上的布局在静态生成期间无法读取区域设置。如果某个 URL 段是别名 (例如用 `/cn` 表示中文) ，请使用 [`resolveCanonicalLocale`](/docs/react/nextjs/reference/functions/resolve-canonical-locale) 将其转换，使 `lang` 的值为 `zh`。有关如何在元数据和站点地图中处理别名，请参阅[管理区域设置别名的 SEO](/docs/react/nextjs/locale-alias-seo)。 ## 如何在 Next.js App Router 中添加 hreflang 替代链接和规范网址？在 Next.js App Router 中，在每个页面的 `generateMetadata` 中返回 `alternates.languages` 即可添加 `hreflang` 替代链接，返回 `alternates.canonical` 即可设置规范网址。Next.js 会将每个 `alternates.languages` 条目渲染为一个 `` 标签。 Google 要求[每个语言版本都列出自身及所有其他版本](https://developers.google.com/search/docs/specialty/international/localized-versions)，并会忽略未经两个页面相互声明的 `hreflang` 链接，因此同一页面的每个版本都必须返回相同的列表。`x-default` 条目指向的 URL 面向语言与所有版本均不匹配的访问者。每个版本的规范网址都应指向其自身的 URL，不要将翻译页面指向英文页面。规范网址只是一种信号，并不能保证生效。 (参见 [hreflang 与规范网址标签](/kb/what-is-hreflang#should-hreflang-pages-use-self-referencing-canonicals)) 。翻译可能落后于原页面，因此应以同一份 Record (记录每个页面已在哪些区域设置中发布) 为依据，统一生成规范网址、替代项和站点地图。以下辅助函数会根据该 Record 构建规范网址和替代项，并将尚未发布的版本标记为 `noindex`： ```ts title="lib/i18n-metadata.ts" import type { Metadata } from 'next'; import { getLocale } from 'gt-next/server'; export const BASE_URL = 'https://example.com'; // 每个页面已发布的区域设置。某个区域设置的翻译审核通过后，再将其加入列表。 export const PUBLISHED: Record = { '/': ['en', 'fr', 'es'], '/about': ['en', 'fr', 'es'], '/pricing': ['en', 'fr'], // 西班牙语尚未翻译 }; export const localeUrl = (locale: string, path: string) => `${BASE_URL}/${locale}${path === '/' ? '' : path}`; export async function getI18NMetadata(path: string): Promise { const locale = await getLocale(); const published = PUBLISHED[path] ?? []; // 禁止搜索引擎将未发布的版本编入索引。 if (!published.includes(locale)) { return { robots: { index: false }, alternates: null, }; } const languages: Record = {}; for (const loc of published) languages[loc] = localeUrl(loc, path); languages['x-default'] = localeUrl(published.includes('en') ? 'en' : published[0], path); return { alternates: { canonical: localeUrl(locale, path), languages } }; } ``` 然后在每个页面中调用它： ```tsx title="app/[locale]/pricing/page.tsx" import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata() { return getI18NMetadata('/pricing'); } ``` 使用 Next.js 16.4.2 和 `gt-next` 11.4.14 构建后，已发布全部三种语言版本的 `/fr/about` 页面渲染出的 `` 如下： ```html title="/fr/about" ``` `/fr/pricing` 中没有列出西班牙语的 alternate 链接，因为西班牙语定价页面尚未发布： ```html title="/fr/pricing" ``` 该路由仍会响应 `/es/pricing` 的请求，但其 `` 中只包含 ``，不包含规范网址或替代项，这样爬虫才能发现 `noindex` 指令。设置 `alternates: null` 会清除从父布局继承的所有规范网址或替代项。请保持该路由可被抓取；`noindex` 并不是访问控制手段。英语版本已发布时，`x-default` 指向英语；否则指向第一个已发布的区域设置。该辅助函数假定所有区域设置使用相同的路径；如果使用了 `pathConfig` 中的翻译路径、本地化 slug 或路由别名，请改为根据相应的路由映射构建各区域设置的 URL，使 `fr` 指向 `/fr/a-propos`。此外，还应提供[语言切换器](/kb/language-switcher)，用普通链接指向对应的等效页面。Hreflang 无法取代页面上可见的导航选项。 ## 如何在 Next.js 中为每个区域设置翻译页面标题和元描述？翻译 `generateMetadata` 返回的字符串。搜索结果通常会显示页面的标题和描述，因此如果西班牙语页面使用英文标题，西班牙语搜索结果中就会出现英文文本。搜索引擎也可能改写所显示的标题和摘要，因此提供的元数据并不能保证最终会原样呈现。General Translation 的 [`getGT`](/docs/react/nextjs/reference/functions/get-gt) (来自 `gt-next/server`) 会返回一个针对当前请求区域设置的翻译函数，且可在 `generateMetadata` 中使用。将翻译后的标题和描述连同该辅助函数生成的替代项一起返回： ```tsx title="app/[locale]/about/page.tsx" import type { Metadata } from 'next'; import { getGT } from 'gt-next/server'; import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata(): Promise { const gt = await getGT(); const i18nMeta = await getI18NMetadata('/about'); return { title: gt('About us'), description: gt('Meet the team that builds our product.'), ...i18nMeta, }; } ``` 请像上面那样传入字符串字面量，以便构建步骤能够识别它们。[`getGT`](/docs/react/nextjs/reference/functions/get-gt) 的生产环境译文需要在部署前准备就绪，因此请在执行 `next build` 之前运行 [`npx gt translate`](/docs/cli/reference/commands/translate)： ```json title="package.json" { "scripts": { "build": "npx gt translate && next build" } } ``` 英文标题一旦变更，下一次构建就会自动将新文本翻译成所有区域设置的版本，无需手动更新任何消息文件。在将某个区域设置加入 `PUBLISHED` 之前，请先在[仪表板编辑器](/docs/platform/dashboard/guides/reviewing-translations)中审校标题和描述。共享的[词汇表术语](/docs/platform/dashboard/guides/defining-context-for-translations)有助于让页面与其搜索元数据中的产品名称保持一致。发布后，请实际衡量展示次数、点击次数和转化次数，不要预设点击率会有固定幅度的提升。 (如需了解各市场的关键词选择、不同语言下的长度差异以及 Open Graph 标签，请参阅[如何翻译 SEO 标题和元描述？](/kb/translate-seo-metadata)。) ## 如何在 Next.js 站点地图中添加所有语言？在 `app/sitemap.ts` 中，为每个页面的每个已发布区域设置分别列出一个条目。读取同一个 `PUBLISHED` Record，确保站点地图与 `hreflang` 链接始终保持一致： ```ts title="app/sitemap.ts" import type { MetadataRoute } from 'next'; import { PUBLISHED, localeUrl } from '@/lib/i18n-metadata'; export default function sitemap(): MetadataRoute.Sitemap { return Object.entries(PUBLISHED).flatMap(([path, locales]) => locales.map((locale) => ({ url: localeUrl(locale, path) })), ); } ``` 生成的 `/sitemap.xml` 列出了八个 URL：`/en`、`/fr`、`/es`、三个 `/about` 版本、`/en/pricing` 和 `/fr/pricing`。`/es/pricing` 在发布之前不会被收录。如果添加 `lastModified`，请使用页面内容实际发生实质性更新的日期，而不是站点地图的生成时间 (参见 Google 的[站点地图指南](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)) 。由于页面元数据已在 HTML 中声明了 `hreflang`，此站点地图只列出 URL。你也可以改为在站点地图中声明 `hreflang`：为每个条目提供一个 `alternates.languages` 映射，Next.js 14.2 及更高版本会将其输出为每个 `` 内的 `xhtml:link` 替代项。Google 对[站点地图中的 `hreflang`](https://developers.google.com/search/docs/specialty/international/localized-versions) 与 HTML 中的 `hreflang` 一视同仁。Google 表示，同时使用两种方式并不会带来额外的搜索收益，因此任选其一即可。Next.js 的[站点地图参考](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generate-a-localized-sitemap)中介绍了 `alternates` 字段。(有关大小限制、如何使用站点地图索引进行拆分以及提交前需要做哪些检查，请参见[如何为多语言网站创建站点地图？](/kb/multilingual-sitemap)。) ## 哪个 Next.js 国际化库能为 SEO 处理区域设置路由和 hreflang？要做好 SEO，Next.js 国际化库必须为每种语言提供独立的 URL。General Translation 的 `gt-next` 和 next-intl 都通过 App Router 中间件实现这一点；i18next 和 react-intl 则需要你自行处理路由。next-intl 的中间件还会在 HTTP 响应头中发送 `hreflang` 替代项，而 `gt-next` 会在构建时翻译标题和描述，无需消息文件。这些库都不会替你生成规范网址或站点地图。 | 方案 | 语言 URL | `hreflang` | 已翻译的标题和描述 | 规范网址和站点地图 | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | next-intl | 使用区域设置前缀的中间件 (默认 `/en/about`) 、本地化路径名，或每个区域设置一个域名 | 中间件默认[在 `Link` HTTP 响应头中发送替代项，包括 `x-default`](https://next-intl.dev/docs/routing/configuration#alternate-links) | 由你的团队或翻译服务写入各语言 JSON 目录的消息 | 需自行编写 | | i18next 或 react-intl | 无 Next.js 路由；需自行编写中间件 | 需自行编写 | 各语言目录中的消息 | 需自行编写 | | 访客浏览器中的 Google Translate | 每个页面一个 URL | 无 | 仅在浏览器中翻译；搜索结果显示源语言 | 只有一个 URL，无需列出 | | 直接调用 AI API (OpenAI API、Claude API) | 需自行构建路由 | 需自行编写 | 每次文案变更后都要重新运行的脚本 | 需自行编写 | | General Translation (`gt-next` 和 `gt` CLI) | [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) 提供 `/en/about`、`/es/about` 以及 `/fr/a-propos` 等已翻译路径 | 从 `generateMetadata` 返回基于已发布区域设置的 Record 构建的 `alternates.languages` | [`getGT`](/docs/react/nextjs/reference/functions/get-gt) 字符串，在 `next build` 之前由 [`npx gt translate`](/docs/cli/reference/commands/translate) 翻译 | 基于同一个 Record，在 `generateMetadata` 和 `app/sitemap.ts` 中自行编写 | 如果你的团队已在维护消息目录，并希望由中间件发送 `hreflang`，请选择 next-intl。如果你有译员、文案很少变动，且有时间自行编写路由，请选择 i18next 或 react-intl。浏览器翻译仅适用于无需获取其他语言搜索流量的页面，例如需要登录才能访问、搜索引擎无法抓取的应用。如果应用频繁发布新文案，且每个语言版本都需要被独立索引的页面和已翻译的标题，请选择 General Translation 的 `gt-next`：文案以内联方式保留在组件中，构建时会同时翻译页面和标题。Profound 的平台和文档借助 General Translation 以 47 种以上的区域设置发布。 (参见[生产环境部署案例](https://generaltranslation.com/enterprise)。) ## Related questions - [语言重定向与 SEO：URL、cookie 还是 Accept-Language？](https://generaltranslation.com/zh/kb/locale-routing-seo.mdx): 凡是希望被搜索引擎收录的页面，都应由 URL 决定其语言，因为 Googlebot 不会发送 Accept-Language 请求头，而且大多从美国 IP 地址抓取。只有在决定 / 这类中性根路径重定向到哪里时，才应优先参考 cookie 中保存的用户选择，其次是 Accept-Language，并使用临时的 302 或 307 重定向。 - [什么是 hreflang？如何设置？](https://generaltranslation.com/zh/kb/what-is-hreflang.mdx): Hreflang 用于告诉 Google 哪些 URL 是同一页面的不同语言或区域版本，以便在搜索结果中展示正确的版本。你可以通过 HTML link 标签、HTTP Link 响应头或站点地图来添加它，确保所有链接相互指向，并使用有效的代码，例如 en-GB，而不是 en-UK。 - [多语言 SEO：子目录、子域名与 ccTLD 对比](https://generaltranslation.com/zh/kb/multilingual-url-structure.mdx): 如果同一产品共用一个站点和发布流程，请使用 example.com/de/ 这样的子目录。只有 ccTLD 能指明目标国家，子域名便于独立托管；Google 不建议使用 ?lang= 参数，并会将 .io、.ai 等个性化域名视为通用域名。 - [语言切换器最佳实践：用户体验、SEO 与无障碍访问](https://generaltranslation.com/zh/kb/language-switcher.mdx): 用每种语言的本语名称来标注它，例如 Deutsch 或日本語，不要使用国旗，因为国旗代表的是国家。每个选项都应通过可抓取的链接指向该语言版本的同一页面，用 cookie 记住用户的选择，并且切勿对已本地化的 URL 自动重定向。 - [多语言应用本地化测试清单](https://generaltranslation.com/zh/kb/multilingual-app-launch-checklist.mdx): 在生产环境构建中，于每个支持的区域设置下测试九项内容：包括错误状态和邮件在内的完整流程、语言切换、复数形式、货币与时区、文本扩展、从右到左布局、无障碍访问、译文交付，以及可抓取的语言 URL。为每项检查设定明确的通过标准。 ## Previous and next questions - Previous question: [如何翻译 JSX 中的条件文本？](https://generaltranslation.com/zh/kb/translate-conditional-jsx.mdx) - Next question: [面向开发者的最佳本地化软件是什么？](https://generaltranslation.com/zh/kb/best-localization-software.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.