Next.js canonical 指向错误域名：我们实测的原因与修复方法

如果 Next.js 页面的 canonical 指向旧域名，仅修改 metadataBase 可能无效。在我们的绝对 URL 场景中，即使基础地址正确，输出仍然保留旧地址。修改页面的 alternates.canonical 后才恢复预期值。排查应从实际输出的 URL 开始，再追溯生成它的配置。

我们测试了什么

2026 年 10 月 4 日，我们使用 Next.js 15.5.22、React 19.2.6 和 Node.js v25.2.1 搭建了独立的 App Router 测试项目。在采集数据之前，预先设定了 8 种配置：1 个正确的对照场景，以及 7 个故意设置错误的场景。每组修改前后的页面都来自同一次生产构建，每组只改变一项元数据设置，对照组保持不变。

每个 URL 请求两次，共获得 16 个 URL 的 32 次 HTTP 响应，随后在浏览器中检查全部 16 个渲染后的文档。所有响应均为 200，head 中均只有一个 canonical。两次 HTTP 采集与浏览器 DOM 的结果一致。对应设置修改后，7 个预先引入的偏差全部消失。这是配置行为实验，不是网站错误发生率调查。

/cXX/before 和 /cXX/after 用于隔离测试场景。预设 canonical 使用保留的 example.com 示例域名和商品路径，并不复制本地测试 URL。测试项目本身设置了 noindex, nofollow。

8 种配置及其实际输出

HTTP 200 无法区分配置是否正确：所有测试页面都返回 200。应核对完整 URL，包括路径和语言前缀。在 C04 中，Next.js 输出的首页地址没有末尾斜杠，但它仍不是预设商品页的正确目标。

找到决定错误部分的配置

相对 canonical 的域名错误：C02、C05、C08。检查根 layout 和嵌套 layout 的 metadataBase。C05 删除嵌套覆盖后恢复根配置。C08 的受控构建变量提供了 preview 域名，换成预期的公开域名后输出正确。

绝对 canonical 的域名错误：C03。页面已提供旧域名上的完整 URL，正确的 metadataBase 并未替换它。应修改该值或生成它的数据来源，再核对输出标签。

商品页指向首页：C04。页面继承了 layout 的 canonical。给页面设置独立的 alternates.canonical 后，恢复了预期商品路径。也应检查其他受影响的页面模板。

域名正确但路径错误：C06、C07。即使 canonical 以 / 开头，基础地址中的 /catalog 仍保留在结果中。去除不需要的基础路径修复了 C06，补上 /fr 修复了 C07。实际部署需要的前缀应保留。

可按实际站点调整的明确配置

对于部署在域名根目录的网站，可在 layout 中设置基础域名，在页面元数据中设置页面路径。以下是 C02 修复后的配置模式。请替换示例域名和路径；部署在子目录的网站需要单独确定路径规则。

// app/layout.tsx
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
};

// app/products/widget/page.tsx
export const metadata = {
  alternates: { canonical: "/products/widget" },
};

如果页面包含下方旧域名的绝对 URL，仅修改 layout 不够。C03 只修改了这个 canonical 值。

// C03 — before
alternates: {
  canonical: "https://old.example.com/products/widget"
}

// C03 — after
alternates: {
  canonical: "https://www.example.com/products/widget"
}

检查生产构建与浏览器文档

1. 使用预期公开域名的配置执行生产构建。如果托管平台、middleware 或 CDN 会修改响应，还应检查实际部署的 URL。
2. 保存 HTTP 响应，检查 head 中 canonical 的完整 href、标签数量，以及是否有 Link 响应头指定另一目标。
3. 在浏览器开发者工具中查看渲染后的文档。下方表达式会列出标签及其位置。HTML 与 DOM 不一致时，应另行诊断。
4. 修改后重新检查，并覆盖商品页、嵌套路由和翻译页面。每条记录同时保存实际 URL 与预期目标。

Array.from(document.querySelectorAll('link[rel="canonical"]'))
  .map(link => ({
    href: link.getAttribute("href"),
    inHead: link.closest("head") !== null
  }));

C08 测试的是变量值，不是 Vercel 基础设施。Vercel 文档说明了 preview 默认的 noindex 行为，也列出了非生产分支使用自定义域名的例外。有关具体托管行为的结论应依据实际部署的响应头。

• Vercel：preview 索引规则

实验不能证明什么

结果仅覆盖一个已安装版本、静态元数据导出和本地生产服务器。我们没有测试 streaming metadata、Pages Router 或所有托管平台。canonical 符合预期，不代表 Google 一定选用它、索引页面或提升排名。Google 的规范化选择涉及多个信号；有权限时，应在 Search Console 中单独检查 Google 选择的 URL。

• Next.js 15 元数据文档
• Google：canonical URL 指引

数据、测试项目与复现步骤

2026 年 10 月 13 日补充复现实验：重新构建前，我们将完全一致的归档源码固定为 Git 提交。32 个 canonical HTTP 观察结果和 16 个浏览器 DOM 检查结果均与原始数据一致。下载包包含单独标注日期的复现证据；10 月 4 日的原始研究保持不变。

资料包包含预先固定的协议、源文件哈希、结果和可运行项目。采集脚本执行 HTTP 检查，浏览器检查是单独步骤。独立项目固定了直接依赖版本，但没有完整锁定所有间接依赖。

• 实测结果 · JSON
• 方法与复现步骤 · TXT
• 测试项目、采集脚本与原始证据 · ZIP

当问题涉及多个页面模板时

交给开发人员的记录应包含受影响 URL、实际 canonical、预期目标、对应配置和复查结果。如果问题跨越 layout、语言路由和部署环境，我们的 Next.js SEO 审计可以梳理依赖关系并确定实施优先级。

• Next.js SEO 审计：范围与交付内容
• Next.js 页面索引检查

如果元数据出现在 body，我们的 Next.js 九条件实验区分了原始 HTML 与浏览器 DOM，并结合 Google 文档检查 canonical 的位置。

• Next.js 元数据出现在 body：九种条件实测

• Google 收录：确定下一步排查方向