百度改版工具提示「链接多跳」，我们拿 128 条老链接重跑了一遍

先说结论：这不是 301 写错了，是百度从 http 入口抓，中间平白多一跳。要么让 http 直接跳新页，要么放弃改版工具，靠 301 等两到八周。

我们选了后面那条。下面把整个过程、数据和我们踩的坑都摊开，你可以照着自己的站核一遍。

我们报了什么错：126 条过，2 条被打回

11 月 2 日下午，我们把整理好的新旧 URL 对照表交到百度搜索资源平台的「网站改版」里，走的是「新旧 URL 对」那个标签，上传的是文本文件，每行一条，旧地址在前、新地址在后。

为什么要走这一步？因为老站是十几年前的 SSCMS 建的，URL 长这样：

• /channels/23.html（栏目页）
• /contents/23/1234.html（内容页）
• /ServiceList.aspx（早期 .NET 动态页）

新站换成 Astro + Strapi 之后，栏目结构重排过，这几类地址一条都留不下来。老站 sitemap 里被收录的有 76 条内容页，加上 26 个栏目页，栏目页又有 .html 和带斜杠两种写法，26 × 2 = 52，76 + 52，一共 128 条。

平台跑完的结果：126 条通过，2 条失败。失败原因只有四个字——链接多跳。点开错误详情，也没有更多信息，就这一句。

https 测着没问题，百度为什么说多跳？

这是当时最想不通的地方。

我们自己测的时候，命令是 curl -I 加老链接，返回 301，Location 指向新页面，干净利落，一条就能到。既然一条能到，多跳从哪来的？

问题在入口，不在规则。

百度蜘蛛手里存的是历史抓取记录，其中很大一部分是 http://www.ruibo.com.cn/contents/23/1234.html。而我们服务器上有一条全站规则：http 一律 301 到 https。于是蜘蛛实际走的路是：

http 旧链接 → 301 → https 旧链接 → 301 → 新页面

中间两次 301。百度官方那页说明写得很直白：非单级 301 跳转都算校验失败，其中明确列了「301 状态码和 301 状态码同时存在」这一种。

今天早上我们把 128 条又跑了一遍，两个入口分别测，结果是这样：

起点	跳数	最终状态	落点是否与映射表一致
https:// 旧链接	1 跳	128/128 返回 200	全部一致
http:// 旧链接	2 跳	128/128 返回 200	全部一致

落点全对，状态码全对，唯一的差别是多了一跳。这就解释了为什么 126 条能过、2 条不能：那 2 条恰好是被 http 入口抓到的，或者平台当时就是从 http 去校验的。

三条路，我们为什么选了最笨的那条？

看清原因之后，能走的路其实只有三条。

第一条，让 http 旧链接直接跳新页。 技术上不难，给老 URL 单独写一条 http 段的 location，优先级压过全站那条 http→https。但这台服务器上跑着六个站，http 强制到 https 是统一的规范动作，为了一个平台的校验去开特例，等于在标准流程里插一根钉子。下一个人改配置时看不懂，也可能随手覆盖掉。

第二条，只提交 https 形态的 URL 对。 这条等于没解决，因为失败的原因就是入口，绕开入口问题照旧存在。

第三条，不修工具，把 301 做扎实，等它自然生效。

我们选了第三条。理由很朴素：改版工具是加速器，不是通道，真正传递权重的是 301 本身；126 条已经通过，剩下 2 条的目标页（/research/ 和 /industries/government/）本身完全正常，只是入口形态不同；而动 vhost 的优先级，一旦出错影响的是全站 http 访问，风险面比收益大得多。

一句话：能通过 126 条，说明映射是对的。为 2 条去改全站规则，不值。

放弃改版工具，等于白做 301 吗？

不等于，但代价要说清楚，不然是自己骗自己。

改版工具的价值在于「提前告知」，让百度知道新旧页面的对应关系，把替换周期从「蜘蛛自己慢慢发现」压缩到几天。不做这一步，剩下的是常规路径：301 生效，蜘蛛重抓旧链接，拿到 301，更新索引。

行业里比较一致的预期是 2 到 8 周，前两三周索引量还可能继续往下掉。这一点得提前跟自己打好招呼，不然看到曲线往下走就慌，一慌就折腾，一折腾评估周期重新算，反而更慢。

我们给自己定的观察窗口就是两个月。两个月内不动结构。

老站 76 条收录页，301 是怎么一条条对上的

这里最省事的做法是全部跳到首页。我们没这么干，因为把所有旧链接都指到首页，是最容易被判成作弊的姿势，搜索引擎会认为你在糊弄它。

我们的做法是按老站的栏目标题，一个个归到新站的对应位置。几个真实例子：

老地址	301 到
/channels/23.html	/services/rebuild/
/channels/24.html	/services/ai-solution/
/contents/18/116.html	/research/content-ops/
/ServiceList.aspx	/services/
/sitemap.xml	/sitemap-index.xml

128 条按目标分布是：服务类 50 条、案例类 34 条、研究类 24 条、行业类 16 条、联系页 2 条、关于页 2 条。

你会发现一个特点：大部分是「多对一」。老站 50 条服务页，最后并到 6 个服务页上。这是内容站改版常有的情况，老站当年一个服务拆成十几页写，新站整合成了一页讲透。

补 301 时踩的两个坑

坑一：带斜杠的写法掉到首页去了。

老站的链接有好几种形态：.html、带斜杠、还有 _2 这种分页。我们第一版正则只写了 \.html$，结果 /channels/23/ 这种没有后缀的，全落到兜底规则上跳去了首页。

改法是把正则写成 ^/channels/(23|27)(_\d+)?(\.html|/)?$，把 _2 分页和无后缀两种形态一起盖住。改完再逐条测，128 条才全对上。

坑二：文件名打错一个字母，规则静默不生效。

我们把记录写成 ruipo-old-urls-301.conf，实际文件名是 ruibo-old-urls-301.conf，多打了一个 p。include 那一行指向一个不存在的文件，nginx 不报错，页面照常打开，只是规则一条都没生效。

现象特别迷惑人：配置改了，reload 也做了，老链接还是 404。最后靠 nginx -T | grep old-urls 才看出来根本没用上。

所以现在改完 nginx 配置，我们固定三步：nginx -t 先验语法，nginx -T | grep 关键字 确认规则真被加载，再 curl -I 抽三条实测。少一步都可能白干。

现在怎么自查：三条命令

不用装任何工具，你自己的站也能按下面对一遍：

第一条，看第一跳对不对。

curl -I https://你的域名/老地址.html

返回 301、Location 指向正确的新页，就算过。指向首页的，基本要重写。

第二条，看跳了几跳。

curl -s -o /dev/null -L -w "%{http_code} %{num_redirects}\n" http://你的域名/老地址.html

输出里的数字就是跳数。1 是好，2 要留意，3 以上就该动手合并了。这一条最关键——很多人只测 https 入口，全绿，一提交就挂，就是漏了 http 这一侧。

第三条，确认规则真的加载了。

nginx -T | grep -c 你的规则文件名

数出来是 0，说明 include 没生效，别再往下查了，先解决这个。

还有什么没解决

有一条我们还在盯：官方文档里除了「链接多跳」，还列了「多跳一」，意思是多条旧链接跳到同一条新链接。

我们这份映射里这种情况不少，50 条老服务页并到 6 个页面，天然就是多对一。这次平台没报出来，不代表以后不报。如果哪天规则状态从「改版完成」退回「校验失败」，第一个要查的就是这条。

另外，老站还有一批 .aspx 动态页，我们只补了最常见的 ServiceList.aspx。这段时间看日志，如果发现别的 aspx 还在被蜘蛛抓、还在 404，就按同样格式往规则文件里加一条，然后走一遍上面那三步。

接下来两个月盯什么

三件事，每周五花十分钟：

1. 用 site: 查收录量，和上周比，记在表里，不要凭印象
2. 看服务器日志里 /channels/、/contents/ 的命中数是不是在减少，减少了说明蜘蛛在消化 301
3. 抽 5 条老 URL 重测跳转，确认规则没被谁改掉

两个月后如果还是大面积没替换，再考虑把栏目页的目标换成更具体的子页面重新提交。那是下一步的事，现在折腾只会打乱节奏。

什么情况下别学我们

我们的做法有前提，不适合所有站，说清楚免得你照错。

老站外链多、单页权重高的，别放弃工具。 行业门户、电商、有大量外部转载的站，一条重要页面的权重可能顶我们十条，这种站值得为入口问题专门改一次配置。

URL 一对一映射清晰的站，工具通过率本来就高。 一页对一页，新旧结构差不多，改版工具几乎一次过，成本很低，没理由不用。

我们这种以多对一为主的内容站，工具的收益本来就有限。 50 条并成 6 条，本来就不可能一页页替换，最后还是要靠栏目级的 301 承接。

判断标准其实就一句：这个站的权重是靠几十条页面分散撑着，还是靠几个栏目整体撑着。 前者修入口，后者修 301。我们属于后者，所以选了慢的那条路。

如果两个月后收录恢复得不理想，我们会把这轮的曲线和数据再写一篇，好的坏的都放出来。