批量改 URL 并设置 301 重定向（Bulk URL Change 301）

即使域名不变，Google 也会把 URL 路径的变更视为一次网站迁移。Google 重新抓取期间，搜索流量通常会有波动：Google 表示，中等规模的网站可能需要几周或更长时间，新 URL 才会在搜索结果中取代旧 URL。所以只有在能带来长期收益时才批量改 URL：

• 旧 URL 有问题或会误导人。 例如 index.php?p=123 这样的地址、让常青文章显得过时的日期，或者与页面内容不再相符的 slug。
• 结构本来就要变。 换 CMS、合并博客或调整目录结构时 URL 无论如何都会变，不如在同一次迁移里把 slug 一起改好。
• 你在合并内容。 把几个单薄的页面合并成一个更有分量的页面。

不要只为了让 slug 短几个字符就改 URL。我们的 URL slug 长度最佳实践 解释了为什么已发布 slug 的长度很少值得为它做一次迁移。

Google 建议尽可能使用服务器端重定向。301 和 308 都是永久重定向；包括我们在内的大多数工具默认写 301。Google 还明确表示，301 和其他永久重定向不会导致 PageRank 损失，所以正确的重定向会把旧页面的信号传给新页面。

不知道的 URL 就没法重定向。请综合几个来源，因为每个来源都会漏掉一些：

1. XML 站点地图和 CMS 导出。 覆盖你知道自己发布过的页面。
2. 服务器日志和统计数据。 显示用户和爬虫实际请求的 URL，包括旧的变体。
3. Search Console。 「网页」报告和「链接」报告会显示已编入索引的 URL，以及其他网站链接到的页面。
4. 图片、PDF 和视频。 路径变了的文件同样需要重定向。

把所有 URL 放进表格的同一列，删除完全重复的行。保留原来的大小写，因为 URL 路径区分大小写：/Blog/Summer_Sale_2024 和 /blog/summer_sale_2024 是两个不同的 URL。

每个旧 URL 只能有一个目标，而且目标要尽可能贴近旧内容。

• 重定向到对应的页面。 文章指向同一篇文章的新地址，分类指向新的分类。
• 不要全部指向首页。 Google 提醒，把大量旧 URL 重定向到同一个不相关的页面（例如首页）会让用户困惑，还可能被当作软 404。
• 删掉的内容就让它消失。 如果页面已删除且没有替代页面，请返回 404 或 410，而不是把它重定向到不相关的地方。
• 合并页面是例外。 如果几个旧页面合并成了一个新页面，把它们全部重定向到这个新页面是正确的。

如果新 URL 还不存在，可以把每个旧 URL 对应到新页面的标题，让工具生成 slug。下面是重定向生成器在 旧 URL → 新标题（slug） 模式下的一份真实输入，路径前缀为 /blog/，网站地址为 https://example.com：

/blog/2019/05/10-tips-for-better-slugs -> 10 Tips for Better URL Slugs
/index.php?p=123 -> How to Bake Sourdough Bread at Home
/Blog/Summer_Sale_2024 -> Summer Sale, Up to 50% Off

使用默认设置时，生成器会把这些标题变成以下目标：

CSV 里有几百行？批量 CSV Slug 生成器 一次就能生成 slug 和重定向列。

按服务器能识别的格式写规则。下面是上述三条重定向的真实输出。

Apache（.htaccess）：

Redirect 301 /blog/2019/05/10-tips-for-better-slugs https://example.com/blog/10-tips-for-better-url-slugs
Redirect 301 /Blog/Summer_Sale_2024 https://example.com/blog/summer-sale-up-to-50-percent-off

RewriteEngine On
RewriteCond %{QUERY_STRING} ^p=123$
RewriteRule ^index\.php$ https://example.com/blog/how-to-bake-sourdough-bread-at-home? [R=301,L]

Apache 的 Redirect 匹配路径开头，但只匹配完整的路径段，而且区分大小写。规则按出现顺序处理，先匹配的生效，所以要把具体路径放在宽泛路径之前。Redirect 看不到查询字符串，所以 /index.php?p=123 需要用 RewriteCond 和 RewriteRule。目标末尾的 ? 会去掉旧的查询字符串。

Nginx：

location = /blog/2019/05/10-tips-for-better-slugs { return 301 https://example.com/blog/10-tips-for-better-url-slugs; }
if ($request_uri = "/index.php?p=123") { return 301 https://example.com/blog/how-to-bake-sourdough-bread-at-home; }
location = /Blog/Summer_Sale_2024 { return 301 https://example.com/blog/summer-sale-up-to-50-percent-off; }

location = 是精确匹配，所以 /Blog/Summer_Sale_2024/extra 不受影响。请把这几行放进对应的 server 块。

Cloudflare 批量重定向（CSV）：

example.com/blog/2019/05/10-tips-for-better-slugs,https://example.com/blog/10-tips-for-better-url-slugs,301
example.com/index.php,https://example.com/blog/how-to-bake-sourdough-bread-at-home,301
example.com/Blog/Summer_Sale_2024,https://example.com/blog/summer-sale-up-to-50-percent-off,301

CSV 不能有表头行，含逗号的 URL 必须用双引号括起来。Cloudflare 的源 URL 不能包含查询字符串，所以第二行会匹配所有对 /index.php 的请求，不管参数是什么。如果你有多个 ?p= 形式的 URL，请改在源服务器上用 Apache 或 Nginx 规则处理。

重定向链是指重定向的目标又被重定向：/old-a → /old-b → /new-c。Googlebot 最多跟随 10 次跳转，但 Google 建议直接重定向到最终目标；做不到时，跳转次数最好不超过 3 次，并少于 5 次。重定向链会增加延迟，而且并不是所有浏览器都会跟随很长的链。

旧的重定向列表和新列表叠在一起时，就会出现链。比如下面四行：

/old-a -> /old-b
/old-b -> /new-c
/x -> /y
/y -> /x

生成器会标出这三处有问题的行。开启 拉平重定向链 后，输出是：

Redirect 301 /old-a /new-c
Redirect 301 /old-b /new-c
Redirect 301 /x /y
Redirect 301 /y /x

前两行已经变成直接重定向。/x → /y → /x 是一个循环，永远无法到达终点，也就无法拉平。生成器会保留这两行让你看到，并对第 3、4 行显示「重定向循环」警告。部署前先确定哪个 URL 才是真正的页面，再删掉另一条规则。

重定向负责接住其他网站上的旧链接。你自己能控制的地方都应直接指向新 URL：

• 内部链接：导航、正文和模板里的链接。
• 规范标签：每个新页面都应有指向自身的 rel="canonical"。
• 多语言页面的 hreflang 标注，无论写在 HTML 里还是站点地图里。
• XML 站点地图：列出新 URL。Google 的网站迁移指南还建议提交一份旧 URL 的站点地图，这样你就能看到旧 URL 随着新 URL 取而代之而逐渐退出索引。
• 广告、邮件和社交资料里指向旧页面的链接。

Search Console 的「地址更改」工具只适用于从一个域名或子域名迁移到另一个。同一域名下只改路径时不需要它。

测试整份列表，不要只抽样。下面的 Bash 脚本读取 old_url,expected_url 格式的行，检查每个旧 URL 是否返回指向预期地址的 301，以及目标是否返回 200：

#!/usr/bin/env bash
# usage: ./check-redirects.sh redirects.csv   (lines: old_url,expected_url; no header)
fail=0
while IFS=, read -r old expected; do
  expected=${expected%$'\r'}
  read -r code location < <(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")
  final=$(curl -s -o /dev/null -w '%{http_code}' "$expected")
  if [[ $code == 301 && $location == "$expected" && $final == 200 ]]; then
    echo "OK   $old"
  else
    echo "FAIL $old -> $code $location (target $final)"; fail=1
  fi
done < "$1"
exit $fail

然后用 Search Console 的「网址检查」工具查看几个重要 URL，确认 Google 能看到重定向。

• 重定向至少保留一年。 Google 建议尽可能长时间保留，一般至少 1 年，让所有信号都转移到新 URL。永久保留也没问题。
• 关注 Search Console。 在「网页」报告里检查新出现的 404 和软 404 错误，并对比两份站点地图：旧 URL 站点地图中已编入索引的页面应逐渐降到零，新 URL 站点地图中的数量则应上升。
• 接受一定的波动。 Google 重新抓取期间排名可能变动。中等规模的网站需要几周或更长时间是正常的，大型网站会更久。

[ ] 这次修改有长期收益（不只是短几个字符）
[ ] 已从站点地图、CMS、日志、统计数据和 Search Console 收集旧 URL
[ ] 每个旧 URL 都映射到最接近的新页面；已删除的页面返回 404/410
[ ] 没有把大量 URL 重定向到首页
[ ] 已为正确的服务器生成规则（Apache、Nginx 或 Cloudflare）
[ ] 带查询字符串的 URL 在源服务器上处理
[ ] 没有链（每个旧 URL 直接指向最终 URL），也没有循环
[ ] 内部链接、规范标签、hreflang 和站点地图都已更新
[ ] 每条重定向都已测试：301 指向预期 URL，目标返回 200
[ ] 新页面上没有残留 noindex 或 robots.txt 屏蔽
[ ] 重定向至少保留 1 年；持续关注 Search Console

先用 批量 CSV Slug 生成器 从标题表格生成新的 slug，再把新旧 URL 粘贴到 301 重定向生成器，得到带重定向链和循环检查的 Apache、Nginx 或 Cloudflare 规则。如果标题不是英文，请先阅读 多语言 Slug 音译指南；什么样的 slug 才算好，请看 URL Slug SEO 指南。WordPress 站点要换固定链接结构，见 WordPress 固定链接指南。

• Google 搜索中心：Redirects and Google Search
• Google 搜索中心：Site moves with URL changes
• Google 搜索中心：HTTP status codes and Google's crawlers
• Apache HTTP Server 2.4：mod_alias Redirect 指令
• nginx：location 指令
• Cloudflare：Bulk Redirects CSV file format