本文约 3,381 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：一款只做一件事、做了十五年的插件
Redirection（作者 John Godley）是 WordPress 官方目录里历史最久的重定向插件之一，从 2008 年活到现在。它不像 Rank Math 那样是某个大插件的一个模块，而是专做重定向：规则管理、404 收集、日志分析、甚至可以直接写 .htaccess 规则。
它的优势在于日志能力。Rank Math 的 404 监控只告诉你”哪个 URL 被访问了几次”，Redirection 的日志会记录来源 IP、User-Agent、Referrer、命中了哪条规则。当你需要判断”这些 404 到底是真实用户点进来的，还是爬虫在扫漏洞”的时候，这个差别是决定性的。
原理分析：四张表与两种执行方式
Redirection 在激活时会创建自己的数据表：
| 表名 | 作用 |
|---|---|
wp_redirection_items |
重定向规则本体 |
wp_redirection_groups |
规则分组（默认是”重定向”和”修改的页面”两组） |
wp_redirection_logs |
每次重定向命中的日志 |
wp_redirection_404 |
404 访问日志 |
执行方式上，Redirection 提供两种：
- WordPress 内部处理：请求进来后 PHP 查表匹配再
wp_redirect()，灵活、支持正则和分组，但每次都要启动 WordPress； - 服务器级（Apache
.htaccess/ Nginx）：在 Redirection → Options → Server 里可以选择生成服务器规则，性能最好，但只有 Apache 支持自动写入，Nginx 需要手动维护配置。
对绝大多数站点，内部处理 + 合理控制规则数量（几百条以内） 就够了，规则上万条再考虑服务器级方案。
另一个核心概念是分组。分组决定了规则的匹配顺序和适用对象：默认”Redirections”组放手工规则，”Modified Posts”组放插件自动监测到的固定链接变更（当你在文章编辑页改了 slug，Redirection 会自动加一条 301，前提是在 Options 里开启了监控）。
保姆级实操
第一步：安装与初始选项
安装启用 Redirection 后，会有一个简短的初始设置（Basic Setup），建议勾上”Monitor changes to WordPress posts”和”Keep a log of redirections”。
然后进 Redirection → Options → 404 Logs，设置：
- 404 Log Retention：建议 7 天或按条数限制（如 500 条）；
- Ignored User Agents：把自家爬虫、监控服务的 UA 加进去。
第二步：添加第一条 301
Redirection → Redirects → Add New：
- Source URL：
/old-page； - Target URL：
/new-page； - Group：Redirections；
- 保存后立刻用命令验证：
curl -sI https://mimangfei.com/old-page | grep -Ei '^(HTTP/|location:)'
第三步：正则重定向与捕获组
勾选”Regex”复选框后，Source 支持正则，Target 里可以用 $1、$2 引用捕获组。
Source: ^/news/(\d{4})/(\d{2})/(.*)$
Target: /archive/$1/$2/$3
再比如整站换域名（新旧域名在同一站点管理时不适用，仅示意路径映射）：
Source: ^/shop/(.*)$
Target: /store/$1
写正则前先用样例验证，避免误伤：
# 快速验证几条 URL 会不会命中规则
for u in /news/2023/05/hello /news/abc /shop/item-1; do
printf "%-28s " "$u"
curl -sI "https://mimangfei.com$u" | head -1
done
第四步：分析 404 日志
Redirection → 404s 页面能看到每条失效 URL 的访问次数、最后访问时间、来源。判断优先级的方法：
- 访问次数高 + 有 Referrer（来自别的站点）→ 优先处理，这是真实外部链接；
- 访问次数高但 Referrer 为空、UA 是扫描器 → 多是机器人，直接忽略；
- 路径里含
.env、.git、wp-login.php、xmlrpc.php→ 扫描行为，加入忽略。
# 直接从数据库统计最该处理的 404
wp db query "SELECT url, COUNT(*) AS hits FROM wp_redirection_404 GROUP BY url ORDER BY hits DESC LIMIT 20;"
第五步：定期维护数据库
# 清空 404 日志
wp db query "TRUNCATE TABLE wp_redirection_404;"
# 清空重定向命中日志（规则保留）
wp db query "TRUNCATE TABLE wp_redirection_logs;"
# 看看几张表各占多大
wp db query "SELECT table_name, ROUND(data_length/1024/1024,2) AS MB FROM information_schema.tables WHERE table_name LIKE '%redirection%';"
第六步：导出规则做备份
Redirection → Import/Export 支持导出为 CSV、JSON、Apache .htaccess、Nginx 配置。改版前导出一份 JSON 存好，是回滚最快的手段。
常见踩坑
- 规则太多导致每次请求都查表。几百条以内没问题，上万条要改用服务器级规则。
- 正则没转义。
/old-page.php里的.要写\.。 - 开了日志却没设保留期。
wp_redirection_logs几个月就能涨到几百万行，后台打开就卡。 - 和缓存插件冲突。缓存插件可能把旧 URL 的 404 响应缓存住，导致新加的规则不生效。加完规则清一次缓存。
- 案例：某站点用了两年 Redirection，某天后台突然打不开、前台 TTFB 从 200ms 涨到 3s。检查发现
wp_redirection_logs有 470 万行，wp_options里 Redirection 的配置项还写着日志保留”forever”。处理方式是先TRUNCATE两张日志表，再把保留期改成 30 天，性能立刻恢复。教训是日志必须设上限。 - Nginx 环境下 Server 模块不可用。Redirection 的服务器级规则只自动支持 Apache，Nginx 要导出配置手动粘，且规则变动时要记得同步。
- 改了文章 slug 但没自动生成 301。需要在 Options 里开启 post monitor 功能。
- Target URL 写成了相对不带斜杠。
new-page会被当成相对路径解析出错，写/new-page。
总结
Redirection 适合这三类场景：站点有上千条历史重定向需要精细分组管理；需要靠日志判断 404 的真实来源；想要一份可导出的、跨插件可移植的规则备份。如果你的需求只是改版时的几十条 301，Rank Math 自带的重定向管理器就够了，没必要多装一个插件。无论选哪个，两条纪律不变：正则上线前先用样例 URL 验证；日志必须设保留期。
改版前请务必先做好 WordPress 站点备份与迁移方案；重定向之外，Rank Math 重定向管理器使用教程 是另一种更轻的实现。
