Next.js SEO 检查：诊断 URL 与元数据

进行 Next.js SEO 检查前，先确认项目使用 App Router 还是 Pages Router。对于 App Router，抽查静态路由、数据驱动路由和不存在的 slug，同时检查元数据、内容状态和响应行为。

对比不同路由类型的输出

读取静态页和动态页的标题、描述与 canonical。如果不相关路由共用同一标题，应检查父布局和 generateMetadata。localhost 或预览 canonical 则指向 metadataBase 或域名配置问题。元数据以流式方式提供时，应检查完整响应和 user-agent 行为；仅解析初始 head 的工具可能遗漏信息。

测试发布与缓存状态

选择一条修改过标题的记录，检查元数据和可见文本是否同时更新。如果其中一项过时，应排查缓存与失效机制，不要通过额外客户端组件标签掩盖问题。请求不存在的记录，检查未找到行为和 robots 输出。不要为测试而创建虚假生产内容；应在项目自动测试环境中复现边缘状态。

检查语言路由与发现信息源

从网站点击越南语和英语链接，对比自引用 canonical 与相互对应的替代链接。检查生产站点地图是否包含预览域名或草稿条目。将 robots 规则与重要公开路由比较。如果 HTML 爬虫无法复现 Google 渲染，应记录限制，并在根据不完整观察进行大范围配置更改前使用 URL 检查。部署后复测原样本组，同时验证数据新鲜度和元数据输出。

发布场景示例

示例场景：应用内导航显示新标题，但直接请求仍返回旧标题。更改元数据声明前，先对比两种访问方式、缓存数据和部署时间。读取相关 user-agent 的完整响应。底层记录尚未刷新时，不要再添加一个客户端生成的标题。复测另一条动态路由及商品译文，避免把本地导航变通方法报告为覆盖整次发布的服务端元数据修复。

执行检查并解读证据

将一个有代表性的公开 URL 提交到下方免费 SEO 检查工具。记录状态、标题、描述和 canonical，同时记录准确地址及检查时间。按负责的模板或配置归类重复问题，让一次针对性修复能够在多个页面上复测。字段缺失与有意排除需要不同的处理决定。

HTTP/HTML 审查观察的是公开响应。它不会登录平台、检查所有后台设置、复现所有客户端渲染行为，也不能证明 Google 已收录页面。要获取搜索引擎证据，应对比 Search Console URL 检查和后续抓取数据。发布并刷新缓存后，重新检查原始 URL，不要仅凭评分变化就认定根本问题已经解决。

工具与相关指南

• 阅读 Next.js 配置指南
• 检查公开 URL
• 检查重定向链

官方参考资料

• Next.js：元数据与 OG 图片
• Next.js：robots.txt
• Next.js：generateMetadata