如何让 WordPress 将 .php URL 重定向为无扩展名地址？

2026-11-06数据阿明

结论

可以将已知的旧地址（例如 /page/test.php）重定向到对应的无扩展名地址（/page/test），再由 WordPress 的固定链接规则处理目标地址。不过，去掉 .php 只会改变 URL。目标路径仍需对应 WordPress 能识别的页面或自定义路由，否则仍会返回 404。

你提供的 .htaccess 规则会尝试将所有以 .php 结尾的路径重定向到去掉扩展名后的路径。规则没有限定旧 URL 的范围，也没有避开 WordPress 的内部重写或站点已有的规范化重定向，因此可能与服务器或 WordPress 中的其他规则冲突。仅凭这段规则，无法判断具体是哪条配置导致了循环。

Apache 配置

如果要处理的是 /page/ 下的旧地址，可以先使用限定范围的规则，并将它放在 WordPress 自动生成的固定链接规则之前：

RewriteEngine On
RewriteRule ^page/(.+)\.php$ /page/$1 [R=301,L,NE]

# WordPress 固定链接规则放在此规则之后

这样，/page/test.php 就会重定向到 /page/test。将 page/ 替换为实际需要迁移的路径范围。目标地址必须对应已存在的 WordPress 页面、文章或已配置的路由。

不建议用同一条规则重定向全站所有 .php 地址。WordPress 和其他程序可能需要继续执行某些 PHP 入口，例如 wp-login.php 或 wp-admin/admin-ajax.php。如果确实要覆盖更多地址，应明确迁移范围，并排除仍需执行的脚本和特殊端点。

Nginx 配置

Nginx 不读取 .htaccess，需要在站点的 server 配置中添加规则。如果旧地址限定在 /page/，可以使用类似配置：

location ~ ^/page/(.+)\.php$ {
    return 301 /page/$1;
}

将规则放入正确的 server 配置块，并检查它与现有 location 规则的匹配关系。配置的具体位置和规则优先级取决于当前站点设置；修改后，应先检查配置是否有效，再重新加载服务。

排查重定向循环和 404

先用临时的 302 验证映射是否正确，确认无误后再改为 301。浏览器会缓存永久重定向，排查时可以用无痕窗口或命令行请求，避免旧缓存干扰。
检查响应中的 Location，确认重定向链是否在 .php 地址和无扩展名地址之间来回跳转。
检查目标地址能否直接由 WordPress 的固定链接规则处理。如果 /page/test 没有对应内容或路由，重定向成功后仍会显示 WordPress 的 404 页面。
确认 WordPress 固定链接规则以及站点的 home、siteurl 配置与实际域名和安装路径一致。如果 WordPress 安装在子目录中，重定向目标也要保留正确的子目录路径。

不要把服务器返回 404 的请求一概改写到 index.php 来掩盖问题。先确认 URL 映射符合预期，再让目标路径进入 WordPress 的正常路由。