很多人用 Next.js 做站点时，会把 trailingSlash 打开，让 URL 统一带 /，看起来更规范。但实际在 SEO 场景里，这个配置如果没有和服务器重定向、canonical、sitemap 一起配套，很容易直接把搜索引擎“搞懵”。
我最近就因为这个问题，遇到了一次 Bing 已抓取但迟迟不收录 的异常。
问题现象
页面可以正常访问：
example.com/image-to-pdf/
但 Bing 站长工具显示：
-
已抓取
-
允许索引
-
页面提取成功
-
但 Canonical 为空
-
长时间不进入结果页
而 site 查询始终不出现该页面。
排查过程
先用 curl 看响应：
curl -I https://example.com/image-to-pdf
返回：
308 Permanent Redirect
Location: /image-to-pdf/
Next.js 在开启：
trailingSlash: true
时默认使用 308 重定向。
问题在于：
-
sitemap 里是不带
/ -
canonical 是不带
/ -
OG:url 不带
/ -
实际访问被 308 跳到带
/
等于搜索引擎同时看到两个“永久版本”。
对 Google 来说通常能自己合并，但 Bing 会进入“规范 URL 决策延迟”。
真正的坑点
很多人以为：
308 = 301 = 永久重定向 → SEO 一样
理论上是这样，但在实际抓取日志里能看到：
Bing 对 301 的 canonical 归并速度明显更快。
尤其是新站 + 新页面组合时差异更明显。
正确做法（必须六处一致）
我最后按下面方式统一：
1️⃣ sitemap 全部使用带 /
2️⃣ canonical 全部带 /
3️⃣ OG:url 带 /
4️⃣ 内部链接带 /
5️⃣ IndexNow 提交带 /
6️⃣ nginx 改为 301 重定向到带 /
nginx 规则示例：
rewrite ^([^.]*[^/])$ $1/ permanent;
验证方式
修复后做三步验证：
-
curl 看是否 301 → 带
/ -
查看页面源码 canonical
-
站长工具实时抓取测试
一个实际案例页面
我在排查时测试的真实页面：
最初就是 slash 版本混用导致 Bing 迟迟不选 canonical，统一后开始进入索引队列。
结论
Next.js 的 trailingSlash 本身不是问题，问题是只改框架，不改 SEO 层：
-
URL 规范
-
canonical
-
sitemap
-
server redirect
这四层必须一致，否则搜索引擎会把它当成“结构不稳定站点”。
对 Google 影响小，对 Bing 影响非常明显。
