把全站500个URL从旧域名批量跳转到新域名这件事，出问题的从来不是"怎么批量生成规则"，而是301写成了302、跳转链中间多了一环、新旧URL对应关系对错了位，收录跌了60%排查三个月发现源头在Nginx里一行rewrite
去年帮一个电商站做域名迁移，从旧域名换到新品牌域名。全站500多个产品页、100多篇文章，URL结构完全不变，就是把域名从 oldshop.com 换成 newbrand.com。运维写了一条Nginx规则，五分钟搞定。三个月后，收录从1200掉到400多，Google流量腰斩。
排查了服务器日志、sitemap、结构化数据，一切正常。最后在Nginx配置文件里发现：整站跳转用的是302临时重定向，不是301永久重定向。搜索引擎认为"旧URL还活着，新URL只是临时的"，旧域名的权重一分钱都没传过去。一行代码，302换成301，两个月后收录和流量都回来了。这篇文章把批量页面跳转从"怎么生成"到"怎么不出错"完整拆一遍。
批量跳转出错的四个常见后果
| 1 | 权重归零——302不传递权重，换域名等于从零开始；301传递90%以上的权重，收录平滑过渡 |
| 2 | 跳转链过长——A→B→C→D超过3跳，搜索引擎中途放弃抓取，旧URL和新URL都丢了 |
| 3 | 新旧URL对应错位——旧文章A跳到了新产品B，用户点进去看到完全无关的内容，跳出率飙升 |
| 4 | 跳转循环——A→B→A→B……浏览器报错"重定向次数过多"，用户和蜘蛛都进不来 |
一、301、302、307到底怎么选，选错了就是另一个故事
HTTP重定向有三种状态码跟SEO相关，每种对应的搜索引擎行为完全不同。批量生成跳转规则之前，先把这三个码刻在脑子里：
| 状态码 | 含义 | 权重传递 | 搜索引擎行为 | 适用场景 |
|---|---|---|---|---|
| 301 | 永久重定向 | 传递90%+ | 将旧URL的排名和权重转移到新URL，索引用新URL替代旧URL | 域名迁移、URL改版、HTTP→HTTPS、删除页面指向替代页面 |
| 302 | 临时重定向 | 不传递 | 保留旧URL在索引中，新URL被视为临时展示，不继承排名 | 活动页跳转、A/B测试、临时维护页面 |
| 307 | 临时重定向（保持请求方法） | 不传递 | 同302，但POST请求也会保持POST方法跳转（302可能变成GET） | 表单提交后跳转、API临时迁移 |
301和302的误用是批量跳转最常见的事故
很多人以为"反正用户都能跳过去，301和302有什么区别"。但对搜索引擎来说，301 = "这个页面永久搬家了，请把老地址删掉用新地址"，302 = "这个页面暂时不在，老地址还留着，别动索引"。整站域名迁移用302等于告诉搜索引擎"旧域名还会回来"，搜索引擎就把旧URL留在索引里、新URL当临时页面，权重原地蒸发。批量生成跳转规则的第一条铁律：永久性变更必须用301，临时性跳转才用302。
二、三种批量生成跳转规则的方式，从手写到工具各有适用场景
"批量生成"听起来像是一个自动化工具一键搞定的事，但实际上根据场景不同，实现方式差很多。以下是三种主流方式：
方式一：通配符正则（一条规则覆盖所有）
整站域名迁移、HTTP→HTTPS、www→非www等场景。URL结构不变，只改域名或协议部分。
优点：一条规则搞定；缺点：无法处理URL结构也变化的场景
方式二：CSV批量逐条映射（精确一对一）
URL结构变了（如从/article?id=123变成/article/seo-tips/），需要新旧URL逐条对应。用CSV表格管理映射关系，脚本批量生成Nginx规则。
优点：精确可控；缺点：500条以上手动维护CSV很累
方式三：在线生成器（可视化配置）
用在线工具输入旧URL模式和新URL模式，自动生成Nginx/Apache/Cloudflare规则。
优点：零门槛；缺点：批量能力有限，复杂正则可能需要手动调整
现实中大部分场景是方式一（通配符）处理80%的URL + 方式二（逐条映射）处理剩下20%结构变化的URL。两种规则按顺序放，Nginx会从上到下匹配，精确规则放前面，通配规则放后面。
三、Nginx和Apache的批量跳转规则怎么写，直接给模板
以下是覆盖最常见场景的规则模板，直接改域名和路径就能用：
# ===== Nginx 重定向规则模板 =====# 场景1：整站域名迁移（old.com → new.com，保留路径和参数）server {listen 80;server_name oldshop.com www.oldshop.com;return 301 https://newbrand.com$request_uri;}# 场景2：HTTP → HTTPS 全站强制server {listen 80;server_name example.com www.example.com;return 301 https://$host$request_uri;}# 场景3：www → 非www（或反向）server {listen 443 ssl;server_name www.example.com;return 301 https://example.com$request_uri;}# 场景4：URL结构变化（旧格式 → 新格式）# /product.php?id=123 → /product/123/location /product.php {if ($args ~* "id=(\d+)") {set $product_id $1;return 301 /product/$product_id/;}return 404;}# 场景5：批量精确映射（逐条规则）# 精确匹配优先放前面，通配规则放后面location = /old-page-1.html { return 301 /new-page-1/; }location = /old-page-2.html { return 301 /new-page-2/; }# ... 更多精确规则 ...# 场景6：目录迁移# /blog/ → /articles/，保留子路径location /blog/ {rewrite ^/blog/(.*)$ /articles/$1 permanent;}# ===== Apache .htaccess 重定向规则模板 =====# 场景1：整站域名迁移RewriteEngine OnRewriteCond %{HTTP_HOST} ^(www\.)?oldshop\.com$ [NC]RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]# 场景2：HTTP → HTTPSRewriteCond %{HTTPS} offRewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]# 场景3：URL结构变化（逐条精确映射）Redirect 301 /old-page-1.html /new-page-1/Redirect 301 /old-page-2.html /new-page-2/# 场景4：目录批量迁移RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]# 场景5：删除的页面返回410（比404更明确）Redirect 410 /discontinued-product/批量生成精确映射规则的Python脚本
如果有一个CSV文件（old_url, new_url），用下面这个脚本批量生成Nginx规则：
import csvdef generate_nginx_rules(csv_file, output_file):"""从CSV批量生成Nginx 301重定向规则"""rules = []with open(csv_file, 'r', encoding='utf-8') as f:reader = csv.reader(f)header = next(reader, None) # 跳过表头for row in reader:if len(row) < 2:continueold_path = row[0].strip()new_url = row[1].strip()if old_path and new_url:rules.append(f"location = {old_path} "f"{{ return 301 {new_url}; }}")with open(output_file, 'w', encoding='utf-8') as f:f.write("# 批量生成的301重定向规则\n")f.write(f"# 共 {len(rules)} 条\n\n")f.write("\n".join(rules))print(f"已生成 {len(rules)} 条重定向规则 → {output_file}")# 用法：generate_nginx_rules('redirect-map.csv', 'nginx-redirects.conf')四、规则写完不等于完事，四步校验缺一不可
批量跳转最大的坑不是规则写不对，而是规则写对了但没有逐条验证。500条跳转里只要有5条指向了错误的目标URL、2条形成了跳转链、1条形成了跳转循环，搜索引擎就会在日志里留下大量异常信号。
校验一：状态码验证
用curl或浏览器开发者工具逐个抽检，确认返回的是301而不是302。整站规则上线前先在测试环境curl -I跑一遍，确保Location头里的新URL正确且状态码是301。
校验二：跳转链检测
A→B→C超过3跳，搜索引擎可能中途放弃。用Screaming Frog或Xenu批量爬旧URL列表，检查每个URL最终到达的页面、中间经过了几跳。超过2跳的红线就改。
校验三：循环检测
A→B→A的循环跳转会直接导致浏览器报ERR_TOO_MANY_REDIRECTS。在规则测试阶段必须用工具检测是否存在循环引用，一条循环规则就能让对应页面完全不可访问。
校验四：内容相关性
旧URL跳转到的新URL，内容必须高度相关。旧产品A跳到新产品B、B的内容和A完全无关——Google会认为这是软404，不传递权重。抽检10%的映射关系，确认新旧页面内容匹配。
还有一个容易被忽略的校验项：跳转后的新URL必须返回200。规则把旧URL指向了一个返回404的新URL，这种"301→404"的链是SEO灾难。用工具批量验证时，终点URL的状态码必须是200。
五、不同场景下的跳转策略，一个场景一条规则写法
| 场景 | 跳转类型 | 规则写法要点 | 上线后观察期 |
|---|---|---|---|
| 域名迁移 | 301 | 一条通配规则搞定。同时用Search Console的"地址更改"工具通知Google | 至少保留旧域名跳转6个月以上，直到新域名收录稳定 |
| HTTP→HTTPS | 301 | 全站强制跳转，同时设置HSTS头。sitemap里的URL全部改为https | 永久保持，不需要撤销 |
| www↔非www | 301 | 选一个作为规范域名，另一个301跳转过来。canonical标签保持一致 | 永久保持 |
| URL结构改版 | 301 | 逐条精确映射，不要用通配符。新旧URL必须内容相关 | 保留至少3个月，监控GSC索引覆盖率变化 |
| 删除页面 | 301或410 | 有替代页面→301；没有替代→返回410 Gone（比404更明确） | 301永久保留；410保留到Google不再抓取该URL为止 |
| 活动/促销页 | 302 | 活动结束后302跳回首页或分类页，等下次活动时再改目标 | 活动结束后及时更新跳转目标或移除规则 |
域名迁移有一个容易被忽略的细节：新旧域名同时在Search Console里验证所有权。Google的"地址更改"工具需要你同时拥有新旧两个域名的Search Console权限才能提交迁移请求。只在新域名上验证、旧域名没验证，这个工具用不了，迁移速度会慢很多。
六、批量跳转的三条红线，碰了就出事
红线一：批量跳转不相关的页面
把旧博客的文章全部301跳转到新网站的首页——这叫做soft 404。Google会检测到跳转目标内容与原URL无关，不仅不传递权重，还可能把跳转源头标记为软404。每篇文章必须跳转到内容最匹配的新URL，找不到匹配的宁可返回410。
红线二：跳转链超过3跳
A(旧文章)→B(旧域名)→C(新域名)→D(新文章)，4跳。Google官方建议跳转链不超过2跳，超过5跳直接停止追踪。如果你迁移了两次域名且每次都保留旧跳转规则，很容易形成3跳以上的链。每次加新规则前检查目标URL本身是不是也在跳转。
红线三：跳转规则和canonical标签打架
旧域名301跳转到新域名，但新域名页面的canonical标签指向了旧域名。搜索引擎收到的信号是"旧URL跳转到新URL，但新URL说我的规范版本是旧URL"——形成矛盾。跳转+canonical必须指向同一个方向，不能互相打架。
还有一个经常被忽略的点：内部链接也要同步更新。域名迁移后，网站内部的文章A链接到文章B的旧URL，用户点击会经过一次301跳转才能到达新URL。一次两次没问题，但如果全站有上千个内部链接还指向旧域名，搜索引擎每次抓取都要走一遍跳转，抓取预算被大量浪费。迁移完成后用工具扫描全站内部链接，把指向旧域名的全部替换为新域名。
七、多站批量跳转怎么统一管理，不同站点不同规则但共享验证流程
手里管着多个站的时候，每个站都可能遇到域名迁移、HTTP→HTTPS、URL改版等跳转需求。如果每次都从零写规则、手动验证，效率太低且容易出错。更好的做法是沉淀一套可复用的流程：
多站跳转管理方案
1. 规则模板库——把六种场景的Nginx/Apache规则模板存为一个文件，新站上线直接复制改参数。模板里301和302的颜色标注清楚，防止误用。
2. 统一CSV映射格式——所有URL改版都用同一个CSV格式（old_url, new_url, note），配套脚本自动生成规则+自动校验状态码。
3. 自动化测试流程——每次生成规则后，脚本自动curl所有旧URL，验证返回301、Location头正确、新URL返回200。不通过的不上线。
4. 监控看板——用UC建站系统的多站看板，统一监控各站的Search Console索引覆盖率变化。域名迁移后如果某个站的收录连续两周下降，看板上直接报警，不用手动逐个查。
批量跳转这件事，技术门槛极低——会写一行rewrite就能搞定全站跳转。但正是因为它太简单了，301和302的差别、跳转链的长度、新旧URL的内容相关性这些细节才更容易被忽略。一条规则的失误代价是整站收录清零，而这个失误只需要在生成规则时多花十分钟验证就能避免。
