你把 /blog/old-post/ 迁到了 /blog/new-post/，把新页的 canonical 改成自指，然后等。三周过去，Google 搜索结果里仍然是旧 URL。URL 检查给出的结论是：Indexed, though Google selected a different canonical than user — canonical: /blog/old-post/。标签改了，怎么没有任何效果？
因为 <link rel="canonical"> 是提示，不是命令。Google 会把它和其他半打信号一起加权，单凭一个 canonical 标签很难翻盘。修复方式不是”再把 canonical 改得更显眼一点”，而是把其他所有信号同步到位。
先判断你属于哪种情况
情况 1：没有从旧到新的 301
怎么发现：
curl -sI "https://yourdomain.com/blog/old-post/" | head -1
# HTTP/2 200 <-- 旧 URL 仍直接返回 200，没有重定向旧 URL 依旧能直接打开。新旧两页都在线、都 200，唯一差别是新页有一个指向自己的 canonical 标签。
原因：大多数”换 URL”的操作只改 canonical，旧路由依然在线服务。Google 看到两个相似内容的活页：一个已经有几个月的收录历史、内链积累、外链积累；另一个除了一个 canonical 提示什么都没有。旧的赢。
修复：从旧到新加一条 301。作为合并信号，它的强度大约是 canonical 的 10 倍，Google 几乎不会忽略 301。
// Vercel: next.config.js
module.exports = {
async redirects() {
return [{ source: "/blog/old-post", destination: "/blog/new-post", permanent: true }];
},
};// Firebase Hosting: firebase.json
{
"hosting": {
"redirects": [
{ "source": "/blog/old-post", "destination": "/blog/new-post", "type": 301 }
]
}
}部署完验证：
curl -sI "https://yourdomain.com/blog/old-post/" | head -1
# HTTP/2 301情况 2：站内内链还指着旧 URL
怎么发现：搜索代码库。
rg -l '/blog/old-post' src/
# 列出所有仍然引用旧 URL 的文件sitemap、相关文章、面包屑、文中互引、导航——任何一处还指向旧 URL，都在给”旧 URL 才是真的”加权。
原因：URL 迁移很难一次扫干净，CMS 富文本字段、手写 markdown、自动生成的分类页等地方常常漏。
修复：批量替换。
# 找出所有引用
rg -l '/blog/old-post' src/
# 替换（macOS sed）
rg -l '/blog/old-post' src/ | xargs sed -i '' 's|/blog/old-post|/blog/new-post|g'
# 校验
rg '/blog/old-post' src/
# （空）然后在 Search Console → 链接 → 内部链接里，新 URL 的链接数会在下个抓取周期上升。
情况 3：sitemap 还列着旧 URL
怎么发现：
curl -s https://yourdomain.com/sitemap.xml | grep old-post
# 旧 URL 仍在 sitemap 里sitemap 是 Google 判断”站长希望哪条 URL 被收录”的强信号之一。sitemap 说 A、canonical 说 B 时，sitemap 那一项会偏向 A。
原因：迁移是临时手改，sitemap 重新生成那一步没触发。
修复：重新生成 sitemap，新 URL 必须出现、旧 URL 必须消失。然后在 Search Console → Sitemap 里重新提交。
情况 4：旧 URL 有外链而新 URL 没有
怎么发现：Search Console → 链接 → 外部链接。对比两个 URL 的外链数。如果旧有 50 个引用域、新只有 3 个，Google 会大幅倾向旧 URL 的权重。
原因：外链是几年积累的。换 URL 等于从零开始，即便内部信号已全部迁移，旧 URL 的外链权重仍把它活活撑住。
修复：情况 1 的 301 会把绝大多数外链权重转给新 URL，这是最快的办法，没有更快的。对最有价值的几个外链，可以发邮件请对方更新链接。
情况 5：新页内容比旧页薄
怎么发现：两页对开浏览。数字数、对照 H1、H2 结构。如果新页是个短桩、或者结构与旧页差异很大，Google 会把它们当作两个不同的页面，而不是改了 URL 的同一页。
原因：改版时有人重构了 URL，新模板砍掉了侧栏、相关链接、页脚信息等。
修复：这是最慢的一种。要么把新页内容补到不输旧页，要么接受这次合并需要更长时间（8–12 周）。
情况 6：你做对了所有事，Google 只是慢
怎么发现：301 已上线、内链已迁移、sitemap 已清理、URL 检查显示”URL 已收录到 Google”，但 site:yourdomain.com/blog/old-post 仍然有结果。
原因：Google 的 canonical 合并不是瞬时的。所有信号已指向新 URL 之后，旧 URL 仍会在索引里停留数周，等 Google 确认这是一个长期变更。
修复：等 4–12 周。急用的话可以用 Removals 工具临时屏蔽 6 个月。
最短修复路径
按命中率排序：
- 从旧到新加 301 → 70% 的情况。唯一最强的信号。
- 全站更新内链 → 20% 的情况。301 修外部权重，内链修内部权重。
- 重新生成并提交 sitemap → 8% 的情况。化解”站长说 X、页面标签说 Y”的拉扯。
- 等 4–12 周 → 剩下 2%。前三步做干净后，时间会替你把余下部分处理完。
验证清单
修完后逐项核对：
# 1. 旧 URL 已 301
curl -sI "https://yourdomain.com/blog/old-post/" | head -1
# 期望：HTTP/2 301
# 2. 新 URL 是 200 且自指 canonical
curl -s "https://yourdomain.com/blog/new-post/" | grep canonical
# 期望：<link rel="canonical" href="https://yourdomain.com/blog/new-post/">
# 3. sitemap 列新不列旧
curl -s "https://yourdomain.com/sitemap.xml" | grep blog/old-post
# 期望：（空）
curl -s "https://yourdomain.com/sitemap.xml" | grep blog/new-post
# 期望：<loc>https://yourdomain.com/blog/new-post/</loc>
# 4. 没有指向旧 URL 的内链
rg "/blog/old-post" src/
# 期望：（空）然后到 Search Console → 对新 URL 做 URL 检查 → “申请编入索引”。
预防建议
- 换 URL 是四步迁移、不是一步改标签：(1) 部署新 URL，(2) 从旧加 301，(3) 全站改内链，(4) 重新生成 sitemap。少一步，canonical 修改就白搭。
- 所有 URL 从一个
urlFor(slug)helper 生成，改名只动 slug 映射。 - 不要为了好看而改高流量 URL——过渡期会损失 4–12 周排名。
- CI 跟踪 canonical / sitemap / 内链一致性：sitemap 里有的 URL 但没有内链、或者页面 canonical 与 sitemap 条目不一致，构建失败。
FAQ
Q：为什么不直接 410 删掉旧 URL？ A：410（Gone）会告诉 Google 把这条 URL 从索引里彻底丢掉，旧 URL 积累的外链权重也跟着丢。301 能把绝大部分权重转到新 URL。除非旧页确实没有替代品，否则用 301。
Q：多久后可以判定 canonical 修改失败？ A：4 周是看到变化的最低线；8 周是完整切换的常态；12 周后所有信号（301、内链、sitemap、内容）都对、Google 仍显示旧 URL，多半是哪里出了问题——通常是 301 链路断了，或者 CDN 缓存间歇性返回旧页。
Q：能加速重抓吗？ A：用 URL 检查的”申请编入索引”对新旧 URL 都点一遍，Googlebot 一般几小时内来抓。但 canonical 决策的重新评估还是周级，无法强制。
Q：只改了 canonical 没加 301，Google 会不会自己换？ A：有可能，但概率很低。没 301 时两页都活着，Google 没有强信号去合并。如果新页随时间积累了更多内链，Google 可能翻盘——但仅靠 canonical 标签太弱，加上 301 是正经办法。
Q：新 URL 显示”Indexed, though Google selected a different canonical than user”，这条 URL 还在索引里吗？ A：在——Google 的索引里有这一页，但排名信号（PageRank、外链等）被算到 Google 选定的那个 canonical 上，不是你声明的这条。用户搜索时落地的也是 Google 选的那条。完整诊断流程见 “Duplicate, Google chose different canonical than user”。
相关阅读
- Canonical 写错：3 种典型与修复
- “Duplicate, Google chose different canonical than user”
- 换域名后 canonical 仍指旧域名
- Alternate page with proper canonical tag
- 分页 canonical 的常见误区
标签: #SEO #排查 #排查 #结构化数据 #Canonical