改版上线三天收录掉一半:百度网站改版工具与规则配置的正确用法
适用读者:负责企业官网改版的工程师和站长;已经给旧 URL 配了 301 重定向,但没在百度搜索资源平台提交过改版规则,最近发现收录和排名一起往下掉,想搞清楚这两件事到底各自管什么、怎么配合。
8 月 12 日上午,做工业设备的老周给我打电话,声音有点急:官网改版上线才三天,百度收录从 4200 掉到 1900,核心词「变频柜定制」的排名直接翻车清零。他第一反应是服务器出问题了,我让他把日志发过来一看,301 返回码全部正常,蜘蛛也照常在抓。这事儿跟服务器没关系,问题出在他只做了跳转,没在百度搜索资源平台配改版规则。三个星期后收录回到了 4100 左右,排名也陆续回来。这篇把整个过程拆开复盘一遍,重点讲百度「网站改版」工具的规则配置,以及 301 和改版规则怎么分工。
收录掉一半,锅不在 301
先说结论:301 重定向只解决抓取层的跳转,解决不了索引层的记录迁移。

老周这次改版把目录结构全动了。原来的产品页在 /products/ 下面,改版后按行业拆成了 /solution/、/case/ 两个目录,新闻从 /news/ 挪到了 /insights/。技术外包给旧 URL 全量配了 HTTP 301(Permanent Redirect,永久重定向),curl 抽测了几十个旧链接,返回码都对。按他的理解,权重会跟着 301 慢慢转移,等等就好。
搜索引擎优化(Search Engine Optimization, SEO)的整条链路分三段:抓取、索引、排序。301 只作用在抓取这一段——蜘蛛顺着旧链接过来,收到 301,转向新地址,这一步没问题。但索引库里的记录是以 URL 为键的,旧 URL 的索引记录不会因为一个 301 就自动改成新 URL。百度官方给这套场景准备的解决工具,就是搜索资源平台里的「网站改版」功能,它做的事情是把旧 URL 的索引记录和评估信号迁移到新 URL 上,走的是平台内部的正式流程,比等 301 自然传导快得多,也稳得多。
没配改版规则会发生什么?百度自己的说法是旧网页会在一段时间内保留索引,但实际观察里,大量旧 URL 返回 301 之后,蜘蛛抓旧地址的频率会快速衰减,旧索引记录逐步失效,新 URL 又因为缺少承接的评估信号,进索引慢、排名低。收录掉一半就是这么来的——旧的一批在退场,新的一批还没顶上。
机制剖析:为什么 301 顶替不了改版规则
这一节展开讲平台侧的运作逻辑,理解了这个,后面配置的时候不容易犯迷糊。
百度的索引体系里,每个被收录的 URL 是一条独立记录,带着自己的抓取历史、内容质量评估和链接信号。排名的计算很大程度上挂在这些记录上。改版换 URL,等于换了键名,旧键下的所有积累对百度来说不能「猜」要不要搬过去——搬错了是把垃圾页的信号带给新页,搬慢了就是老周看到的那种排名清零。
改版规则在这里起的作用,相当于向百度提交了一份有官方背书的映射表:这些旧 URL 和那些新 URL 是同一批内容,请把索引记录对应迁移。平台收到规则后会做校验,抽查新旧 URL 对,确认新地址确实返回 200、内容确实相关,然后分批执行迁移。这个过程在站点的抓取配额(抓取预算)之外,不受蜘蛛抓旧 URL 频率衰减的影响。
用一张图把两条路径摆在一起看:
flowchart LR
A[旧 URL 索引记录] --> B{改版后}
B -->|只配 301| C[蜘蛛抓旧地址收到 301]
C --> D[抓旧地址频率衰减]
D --> E[旧索引记录逐步失效]
B -->|301 + 改版规则| F[平台校验新旧 URL 对]
F --> G[索引记录按映射批量迁移]
E --> H[新 URL 从零积累收录与排名]
G --> I[新 URL 继承评估信号]
H --> J[收录下降 排名清零]
I --> K[收录持平 排名缓慢回升]
配齐规则之后,抓取侧和平台侧的协作时序是这样的:
sequenceDiagram
participant S as Baiduspider
participant P as 搜索资源平台
participant I as 索引库
Note over S: 按旧名单抓 /products/95.html
S->>S: 收到 301,跟随跳转到新地址
S->>P: 上报抓取结果(含跳转链)
P->>P: 抽查规则样本,验证旧 301 新 200
P->>I: 规则生效,下发批量迁移指令
I->>I: 旧 URL 记录与信号迁移到新 URL
Note over I: 迁移期间新旧记录短暂并存
I-->>S: 新 URL 进入正常抓取调度
只配 301 的那条路不是走不通,是走得太慢、抖动太大。对流量本来就不大的企业官网来说,抖这一下可能就是两三个月的自然搜索流量归零,白费劲。
三种粒度的改版规则,按目录结构选
百度改版工具支持三种规则粒度:目录级、正则、页面级。选哪种取决于这次改版动了什么。
| 规则类型 | 适用场景 | 配置成本 | 老周案例里的用法 |
|---|---|---|---|
| 目录级 | 旧目录整目录搬到新目录,文件名不变 | 最低,填新旧目录即可 | 不适用,目录还做了拆分 |
| 正则 | 旧目录下的 URL 按规律映射到多个新目录 | 中等,要写对捕获组 | 产品页按行业拆分,用这条 |
| 页面级 | 零散页面各自对应,无规律可循 | 高,逐条填 | 十几个旧专题页,逐条指定 |
老周这次的情况,/products/ 下 300 多个产品页按应用行业拆进了 /solution/heating/、/solution/chemical/ 等子目录,页面和旧 URL 之间有编号规律,正则刚好能覆盖。/news/ 到 /insights/ 是整目录平移,目录级规则一条搞定。零散的旧专题页走页面级。同一个改版可以提交多条规则,粒度不必统一。
正则规则最容易踩的坑是写得太宽。下面这段是当时校验映射用的脚本,依赖 Python 3.11(Windows 与 Linux 均可运行,无第三方包):
# validate_mapping.py -- Python 3.11,无第三方依赖
# 用途:上线前抽验「正则改版规则」的映射覆盖与误伤情况
import re
# 旧产品页规则:/products/编号.html -> /solution/行业/编号.html
# 注意:捕获组只捕获数字,不要写成 (.*) 那种吞一切的写法
rule = re.compile(r"^/products/(\d+)\.html$")
# 行业归属表:编号区间映射到新目录(与数据库里的产品表保持同步)
industries = {
range(1, 181): "/solution/heating/", # 1-180 号产品归供暖行业
range(181, 301): "/solution/chemical/", # 181-300 号产品归化工行业
}
def map_url(old: str) -> str | None:
# 先过正则这道门,没过门的旧地址直接放弃
m = rule.match(old)
if not m:
return None # 不匹配规则,返回 None 而不是硬套
pid = int(m.group(1))
for rng, prefix in industries.items():
# 遍历行业区间表,命中哪个区间就去哪个新目录
if pid in rng: # 命中行业区间才生成新地址
return f"{prefix}{pid}.html"
# 走到这里说明编号超出已知区间,多半是产品表没同步
return None # 编号超出已知区间,说明规则有缺口
# 抽测:一个正常映射、一个应拒绝的越界编号
print(map_url("/products/95.html")) # 期望 /solution/heating/95.html
print(map_url("/products/999.html")) # 期望 None,暴露规则缺口
写 (.*) 这种宽正则的后果,是规则校验阶段百度抽到的样本对不上内容,整条规则被打回,或者更糟——校验通过但把不相关的页面配到了一起,迁移完成后新页面上挂着错误的评估信号,后期排查起来非常费劲。
301 和改版规则的分工,别指望一方包办
配置改版规则有个前置条件:新旧 URL 之间必须有真实的 301。规则是「告诉」百度对应关系,301 是百度校验时实际要去验证的东西,两个缺一不可。
当时 nginx 的配置(nginx 1.24,Ubuntu 22.04)长这样:
# /etc/nginx/conf.d/site.conf -- nginx 1.24
# 旧产品目录按编号分流到新行业目录,301 必须返回 301 而非 302
# map 在 server 之外定义,按 $uri 算出行业前缀,复用在多个 location 里
map $uri $industry_prefix {
# default 必须留空串,未匹配的旧地址交给后面的兜底分支
default ""; # 未匹配时留空,走兜底
# 区间用正则硬编码了产品编号边界,改产品表记得同步改这里
~^/products/(?:[1-9]\d?|1[0-7]\d)\.html "/solution/heating/";
~^/products/(?:1[89]\d|2\d\d)\.html "/solution/chemical/";
}
server {
# 产品页重定向:命中映射表才跳,避免所有旧页一锅端
location ~* ^/products/ {
if ($industry_prefix != "") {
return 301 https://www.example.com$industry_prefix$uri_last_segment;
}
return 301 https://www.example.com/insights/; # 兜底归到新频道首页
}
# 新闻目录整目录平移:目录级规则对应的服务端跳转
location /news/ {
return 301 https://www.example.com/insights/$is_args$args;
}
}
nginx 的 map 与正则捕获在真实项目里要按实际目录拆细,上面是结构示意。关键在于跳转和规则要一一对应:改版规则里写的映射,服务端必须真的这么跳;服务端跳转的目标,规则里必须真的这么写。两边对不上,校验直接失败。
sitemap 同步更新,别让两份名单打架
老周外包做的另一件半吊子事情是 sitemap。改版上线一周后,站点地图(Sitemap)里还躺着 3000 多条旧 URL,蜘蛛每天照着名单去抓旧地址,抓到的全是 301。这不是抓取配额被严重浪费了,等于每天用旧名单提醒百度「这个站还是旧的」。
改版期间的 sitemap 只应该放新 URL,旧 URL 的发现渠道交给改版规则和 301。具体动作就三步:改版上线当天生成新结构的 sitemap 并重新提交;robots.txt 检查一遍,确认新目录没有被历史规则误伤屏蔽;死链用一个简单的抽样脚本过一遍,404 超过预期就先修再提规则。蜘蛛的抓取路径是 sitemap、站内链接、外链几路合流,任何一路还在大范围指向旧地址,迁移就会被拖慢。
新旧 URL 混用是老周站点后来才暴露的问题:模板里面包屑导航的「首页」链接还硬编码着旧路径,新页面里有 4% 的内链指向旧 URL。百度在迁移过程中会把这些当成新页面对旧 URL 的引用信号,来回打架。全站链接替换这种看似体力活的检查,改版 checklist 里得占一行。
收录恢复的三周时间线
配齐规则之后的样子,按周记录如下,给正在等恢复的人一个参照。
- 第 1 周:改版规则校验通过,平台显示「规则生效中」。蜘蛛对新 URL 的抓取量明显上来,日志里
/solution/目录的 Baiduspider 请求数从日均 200 涨到 1400。收录还在低位,这周别慌。 - 第 2 周:平台「网站改版」页面里迁移条目开始走动,旧 URL 记录批量转入新 URL。site 语法查询能看到新旧地址交替出现,收录曲线从 1900 爬回 3200 左右。
- 第 3 周:迁移基本完成,收录回到 4100 上下。「变频柜定制」回到搜索结果第二页,「化工变频柜厂家」重新进前三页。长尾词的恢复明显滞后于收录,排序信号的重建比索引迁移慢半拍。
时间线上有三个节点值得标出来:规则提交后的校验抽查(通常两三天)、迁移启动(一周内)、排名回升(两周以后)。每一步都依赖前面一步是真的完成了,中途反复改规则反而会重启整个流程。
改版上线 checklist
把这次踩坑总结成一张表,下次改版照着过一遍:
| 检查项 | 上线前 | 上线当天 | 上线后一周 |
|---|---|---|---|
| 301 全量覆盖 | 旧 URL 逐目录抽测返回码 | 全量 curl 扫一遍 | 日志里 301 命中率复查 |
| 改版规则提交 | 规则脚本校验映射 | 平台提交,等校验 | 确认「规则生效」状态 |
| sitemap | 按新结构预生成 | 重新提交 sitemap | 核对旧 URL 是否清干净 |
| robots.txt | 确认新目录未屏蔽 | 线上版本比对 | 无异常即可 |
| 站内链接 | 模板硬编码链接清理 | 全站内链指向新 URL | 抽样复查混用比例 |
| 死链 | 404 清零或配兜底跳转 | 监控 404 曲线 | 异常 404 当天处理 |
| 平台数据 | 记录收录与排名基线 | 上线后每日记录 | 对比基线判断抖动幅度 |
改造前后的实际数据摆在一起,能看出规则配置到底值不值这半天工夫:
| 指标 | 改版前 | 改版后三天(未配规则) | 配规则后三周 |
|---|---|---|---|
| 百度收录量 | 4200 | 1900 | 4100 |
| 核心词排名 | 首页第 2 位 | 100 名开外 | 第 2 页回升中 |
| 日均自然搜索流量 | 640 IP | 210 IP | 580 IP |
| 蜘蛛抓取错误率 | 0.4% | 11%(大量 301 链) | 0.9% |
常见的配置错误,一个一个排掉
复盘里最有价值的是别人的错误,这几类都在真实站点上见过:
- 正则写太宽。 前面已经展开过,
(.*)一把梭是重灾区。正确姿势是捕获组只包需要的部分,配一段抽测脚本,正样本和负样本都要测。 - 新旧 URL 混用。 模板里的硬编码链接、老文章里的站内引用、CDN 缓存的旧页面,都是混用来源。混用期拖得越长,迁移越慢。
- 规则提交后又频繁修改。 校验中的规则被删掉重提,流程整个重来。提交前在测试环境把映射核对清楚,提交后就让它跑完。
- 只管规则不管死链。 有些旧页面在新站里确实没有对应页,这类该 404 就 404,配到不相关的新页面上是给自己埋雷。
- 拿改版规则当收录问题的万能药。 收录下降的原因不止改版一种,先在搜索资源平台的抓取诊断和流量数据里确认掉收录的时间点和改版上线时间对得上,再动手配规则。
误区澄清:301 配完就等,等不来收录
最常见的误区就是把 301 当成收录保护的完成时。301 是传输层的礼貌动作,改版规则才是索引层的正式迁移申请,两个是配合关系,谁也替不了谁。企业官网改动不大、目录结构原样保留的,可以只做 301 观察两周再决定;凡是动了目录层级的,改版规则应当在上线当天就提交,别给自己留三周的空窗。
往远了说一句,这条抓取、索引、排序的链路,是传统 SEO 的主场;生成式引擎优化(Generative Engine Optimization, GEO)关心的是内容怎么被 AI 搜索整理后引用出去,入口逻辑不一样,但地基是同一个——站点结构混乱、收录不稳的站,两边都吃不上红利。传统 SEO 这套改版迁移的功夫,短期内还省不掉。
正在准备改版的,或者卡在收录恢复半路上的,欢迎评论区把你的目录结构和规则写法贴出来一起看。
参考与延伸
- 百度搜索资源平台「网站改版」工具入口与规则说明:https://ziyuan.baidu.com/
- HTTP 301 状态码的语义定义,RFC 7231 第 6.4.2 节:https://datatracker.ietf.org/doc/html/rfc7231
- Google Search Central 关于站点迁移的官方文档(思路可对照参考):https://developers.google.com/search/docs
SEO、网站优化、百度搜索资源平台、301 重定向、改版规则、收录恢复、sitemap