301重定向的做法就两条：WordPress装Redirection插件逐条配，或者改服务器配置文件（Apache是.htaccess）批量配。要改搜索结果里的页面URL，Google的建议是尽量用永久服务器端重定向。301和其他永久重定向不会造成PageRank损失，这是官方原话，但新URL替换旧URL要时间，中型网站可能要几周或更久。
真正花时间的不是写规则，是列清楚哪条旧URL对应哪条新URL。改版、换域名、换固定链接，任何一次URL变动都可能在搜索结果里留一堆旧地址。处理得利索，流量接到新页；处理得拖沓，旧地址一直挂在结果里，用户点进来先看一次跳转。
站内有一份Google SEO学习地图，从收录到结构化数据都串起来了，301是其中一环。
- 是什么：301是永久重定向，Googlebot会跟随，索引管线把它当作目标页应为canonical的信号。
- 官方推荐哪种：需要改搜索结果里的页面URL时，尽量用永久服务器端重定向。
- 两条做法：WordPress用Redirection插件逐条配；改服务器配置文件批量配。
- 要多久：中型网站几周或更久，Google才逐步用新URL替换旧URL。
这篇把301从判断到验证的动作讲完，包括两种配法、怎么测、出错回查和AI能接的部分，照着做就行。
本文目录
301和302到底差在哪，配错了会怎样
301和308都表示页面永久移动到了新位置，302是临时的。这两种在搜索结果里的表现不一样：永久重定向会在结果里显示新的目标地址，临时重定向还会显示来源页。
判断标准只有一条：这个跳转以后会不会撤回来。确定不撤，用301或308；只是想临时把用户送到另一个页面，用302，这样Google不受影响，旧URL可能还留在搜索结果里。
配反的代价很具体。明明要换掉旧页，用了302，结果里一直显示旧地址，用户点进去才跳到新页。反过来，只是临时活动页，用了301，活动结束想撤回来，又要再改一轮规则，中间还得盯着索引。
301对权重的影响，Google写的是301和其他永久重定向不会造成PageRank损失。这句话说的是不丢PageRank，没说排名照旧，也没给传递比例。302这块的细节站内有一篇专门讲，302重定向对权重的影响，可以对着看。
还有个容易被忽略的点：Google重定向一个URL时，会同时记录旧URL和新URL。换域名后，哪怕新URL已经被索引，结果里偶尔还会冒出旧地址。这是正常的，用户习惯新域名后会慢慢淡出，不用看到一次就回去改规则。
哪三种情况该上301：改版、换域名、改URL结构
站点迁移带来的URL变化包括：HTTP换成HTTPS、换域名、URL路径变化。这三类都该用301把旧地址接到新地址。
迁移之外，还有几种情况也用得上301：同一篇内容有多个URL，要统一到一个首选URL；两个站合并成一个；删掉的页面要把用户送到新的相关内容。删内容这条要分清：不是所有旧内容都迁到新站时，那些URL应该正确返回404或410，别硬301到一个不相关的页面。用户点进来发现货不对板，比看到404更糟。
Google给站点迁移的建议是一次只改一件事。先换域名，再改站点布局，别同一周里两件事一起上。出了问题，你不知道是域名解析、规则还是新模板的内链造成的。
动手前先做映射表，旧URL到新URL一条条列出来。找旧URL有几个入口：sitemap、服务器日志或分析软件、Search Console里的Links to your site、CMS后台。映射表里别漏了嵌入内容的URL：视频、图片、JavaScript和CSS文件。这些东西跟着页面一起搬家，漏了就是一片404。
换域名这种简单迁移，可以用通配符服务器端重定向，不必生成旧URL列表。路径结构也跟着变的，才需要逐条映射。
做法一：WordPress用Redirection插件逐条配
WordPress里最省事的是Redirection插件。装法不复杂：
- 下载redirection.zip
- 解压
- 把redirection目录上传到/wp-content/plugins
- 在插件管理页启用
- 打开Tools/Redirection页面配置选项
选它的理由很实在：不用懂Apache或Nginx，WordPress支持固定链接就能用它重定向任意URL。它可以配置成监控文章或页面固定链接变化，固定链接一改，自动创建到新URL的重定向。默认用WordPress管理所有重定向，也可以配置成自动保存到.htaccess由Apache处理。用Nginx的，可以把重定向导出成Nginx rewrite规则文件。
配的时候手动逐条填source和target。URL多的用正则，它能创建匹配任意数量URL的模式。查询参数可以精确匹配、忽略，或者传递到目标地址。固定链接结构变过的，输入旧结构就能迁移旧永久链接，支持多次迁移。
它还有一个适合排查的地方：会记录站点上所有404错误。404可以分组，显示该重点关注的位置，也能批量重定向。日志里能看到每条重定向的访客、浏览器、来源页，每条维护hit计数，日志能导出，也能搜索筛选。
配完不生效，先看日志里这条有没有命中。hit计数不动，说明请求根本没走到这条规则，去查source写没写对、规则顺序有没有被前面的拦住。再看404分组，把同类的批量指到新页。插件免费，没有付费版。
搬家换域名的时候，数据库里的旧地址也要一起替换，数据库替换加301就是处理这个的。固定链接本身怎么设，先看URL固定链接再动手。
做法二：在.htaccess里写规则批量跳
服务器端重定向的前提是有配置文件的访问权限。Apache下最简单的跳转用mod_alias，复杂的用mod_rewrite。Nginx用rewrite规则。其他Web服务器，问服务器管理员或主机商。
稳妥的做法是：改前备份.htaccess，规则一条条加，加完立刻测，别一次写一大坨。一次写十几条，出错你不知道是哪条引起的，只能全部注释掉重来。
做HTTPS跳转时，要加条件避免已经重定向的请求再跳一次造成循环。Apache下在跳转规则前加这一行：
RewriteCond %{ENV:REDIRECT_STATUS} ^$
没有这个条件，有些请求会在HTTP和HTTPS之间来回跳，浏览器直接报重定向次数过多。
有POST请求的域名慎用301。301可能把POST变成GET，表单数据和接口回调就丢了。需要保留请求方法时，考虑308。
平台做不了服务器端重定向，才用meta refresh兜底。Google把即时meta refresh当永久重定向，延迟的当临时重定向。JavaScript重定向只在服务器端和meta refresh都做不了时用，它依赖渲染，渲染失败Google可能永远看不到。这两个都只能兜底，别当首选。
配完怎么测：用命令行和浏览器各验一遍
配完先测跳转本身。用curl -I请求旧URL，看返回头是不是301 Moved Permanently，Location是不是新地址：
curl -I https://你的旧地址
再用curl -L -v跟随重定向，能看到整条跳转链。正常应该一跳到位，出现A到B再到C，就是多级跳转，要回去把规则直接指到终点。
不想用命令行的，打开浏览器开发者工具的Network标签，访问被重定向的URL，看第一个请求的Status Code是不是301，Response Headers里的Location字段对不对。这个方法直观，适合一条条核对。
跳转对了还不够，目标页必须返回200。跳过去是404或者500，等于把流量导到一个坏页面。先测目标页，再测跳转。
最后是Search Console。提交新sitemap，提交只是提示，不保证Google会下载，也不保证用它抓取。然后在索引报告里看旧URL是不是逐步被新URL替换。站内有一份技术SEO自查，可以对着把抓取、索引、跳转这几项过一遍。
301多久生效，哪些数要记住
没有确切天数。Google只给了量级，速度主要取决于URL数量和服务器速度。
| 项目 | 数 / 规则 |
|---|---|
| 新URL替换旧URL的时间 | 中型网站几周或更久，大站更久 |
| 迁移算完成的条件 | Googlebot至少访问旧站和新站每个URL一次，没有固定抓取频率 |
| 单个sitemap上限 | 50MB（未压缩）或50,000个URL，UTF-8编码 |
| Redirection门槛 | 免费，没有付费版；兼容PHP 7.4到8.5 |
别拿天数为难自己，也别把sitemap当保证。迁移后Googlebot的抓取率可能先临时下降，随后几天稳步上升，甚至高于迁移前，这属正常。迁移后Google会临时更密集地抓新站，服务器要留够资源，别在这时候限流把自己的新站挡住。
还有一条容易忽略：要认为站点迁移完成，Googlebot得把旧站和新站上的每个URL都至少访问一次。所以你能做的是把映射做全、把内链改对、把sitemap交上去，剩下的是等。
改完不生效，挨个查这几处
跳转链。A跳到B，B又跳到C，多级跳转拖慢速度，也容易在中间丢参数。用curl -L -v找出来，把规则直接指到终点，别让用户和Googlebot多跑一趟。
302误用。确定不回退却用了临时重定向，搜索结果里还显示旧页。改成301，再提交一次sitemap。
跳到404。目标页没上线，或者target写错。先测目标页是不是200，再回头查规则。目标页是404，跳转配得再对也没用。
漏改内链和外链。迁移后要把新站内部链接从旧URL改成新URL，减少对重定向的依赖。外链改不了，但站内能改的都改掉。改URL结构之前，先把网站URL结构定下来，别迁移完再改第二遍。
sitemap和抓取阻止。改完没提交新sitemap；开发阶段用robots.txt禁止全部抓取，或者用noindex阻止索引，开始迁移前必须移除。这两个不处理，跳转配得再对，新页也进不了索引。
插件故障。有用户反馈WordPress升级后开着Redirection，所有页面包括首页都跳到404，关掉插件就恢复。碰到这种先停插件，确认是不是插件引起的，再逐条排查规则。别在插件开着、全站乱跳的情况下继续加规则。
一个真实案例：全站上HTTPS时301踩的坑
2026年9月23日，一位做站的人发了一篇记录，写自己全站启用HTTPS的过程，那篇累计阅读4.6k。他在开头说，全站启用HTTPS的过程中遇到一个坑，记下来。
坑是重定向循环。全站上HTTPS，所有HTTP请求都要跳到HTTPS，规则没加条件，已经跳过的请求又被抓回来再跳一次。Apache下加RewriteCond %{ENV:REDIRECT_STATUS} ^$这一行，就是为了让已经重定向过的请求不再进规则。这跟上一节说的是同一件事，他是在真实站点上撞到的。
他还提了一点：有POST请求的域名不适合用301，要保留请求方法得考虑308。表单提交、接口回调这类请求，301会把方法改掉，数据就丢了。
301重定向哪些步骤能交给AI，哪些必须自己核
AI在这件事上接的是整理和起草，判断做不了。
- 把旧站sitemap或服务器日志里的URL列表交给AI，让它按路径规律生成旧URL到新URL的映射草稿，人工再逐条确认。
- 让AI把确认后的映射表转成Redirection可导入的CSV，或者转成Apache mod_rewrite、Nginx rewrite规则草稿。
- 让AI按跳转链、302误用、跳到404、漏改内链四类列一份上线前检查清单。
- 让AI把Search Console里旧URL的索引状态变化整理成对比表，标出还没切换的URL。
下面三条提示词是本文给的示例，不是官方模板，可以直接复制改：
「下面是我的旧URL列表和新URL列表，请按路径规律生成一一对应的映射表，输出CSV两列：source,target。不确定的标UNSURE，不要猜。」
「把这份source,target映射表转成Apache .htaccess的RewriteRule规则，每条规则加注释说明对应哪条映射，不要合并成通配符。」
「按这四类给我一份301上线前检查清单：跳转链、302误用、跳转到404、漏改内链和外链。每类给3条可执行检查动作。」
必须人做的有三个动作。在WordPress后台Tools/Redirection页面逐条填入或导入映射，确认每条source和target无误；在浏览器开发者工具Network标签或curl -I里看旧URL返回的状态码是不是301、Location是不是新URL；在Search Console的Sitemaps报告提交新sitemap，并在索引报告里看旧URL是否逐步被新URL替换。
AI把映射草稿和规则草稿整理好，省的是重复劳动。哪条URL该跳、跳到哪，得你自己定。猎者出海的AI Agent在整理资料、对照官方文档、出改稿单这类动作上能接一手，规则本身还是人来拍。
常见问题
301做了之后，搜索结果里的旧地址多久会换掉？
没有确切天数，Google只给了量级。速度主要看URL数量和服务器速度，把映射做全、内链改对、sitemap交上去，剩下是等。
永久重定向会不会把权重弄丢？
Google写的是301和其他永久重定向不会造成PageRank损失。排名会不会变是另一回事，这句话没承诺排名。
装了Redirection，还需要动.htaccess吗？
不用。它默认用WordPress管理所有重定向，也可以配置成保存到.htaccess由Apache处理，选一种就行。
换域名必须把旧URL一条条列出来吗？
路径结构不变的简单迁移，用通配符服务器端重定向就行，不必生成旧URL列表。路径也变了，才需要逐条映射。
页面删掉了，是301到别的页还是让它404？
旧内容还迁到新站，用301接到新地址。不再迁的内容，让那些URL正确返回404或410，别硬301到不相关的页面。
Redirection开着全站跳404怎么处理？
先停插件，看是否恢复。有用户反馈过WordPress升级后开插件全站跳404，关掉就正常。恢复后逐条排查规则，别在插件开着的情况下继续加。
发表评论