老 URL 换结构不换内容：目录站的 301 批次策略

2026-10-23 约 1,854 字预计阅读 5 分钟 yiyunkj

目录站改 URL 结构，通常不是因为想改，是因为之前的定得不好。比如早期为了省事用了 /cate.php?id=12，后来想换成 /design/ 这种可读路径；或者分类从两级改成三级，路径里要加一层。这类改动一旦上线，全站 URL 集体变更，处理不好就是一次小型事故。

目录站批量更换 URL 结构时的 301 分批策略与映射表落地步骤

图片来源：网络，版权归原作者所有，侵权请联系删除

官方给的那几条硬规矩

谷歌的网站迁移文档里有几条是明确的，先摆出来：

国内这边，百度搜索资源平台里也有对应的改版提交入口，规则细节以各自官方文档为准，别互相套用。

一次性切完有一个前提：你有把握映射表 100% 正确。目录站恰恰没有这个把握。条目是几年累积的，中间有手工改过的别名、有历史遗留的重复条目、有从旧系统导过来时编码出问题的地址，这些在数据库里不一定看得出来。

分批切的价值在于，第一批出问题的时候，后面九批还在旧地址上正常服务，不会全站一起挂。而且分批能让你看清每一类 URL 的实际表现，比如某类条目的 301 全部正常、另一类里有 8% 返回 404，这种问题在全量切换里会被淹没在噪音中。

分批的粒度建议按分类走，而不是按 ID 段走。按 ID 切你没有参照物，出问题定位不到；按分类切，哪个分类出问题一目了然，回滚也只需要回一个分类。

字段	说明
旧地址	完整 URL，含协议和域名，从站点地图和日志里导，不要从数据库拼
新地址	先留空，由脚本按规则生成后再人工抽检
类型	分类页 / 条目页 / 分页 / 标签页，不同类型规则不同
预期状态码	目标是 301；明确废弃的填 410，不要笼统填 404
来源	站点地图、服务器日志、外链工具导出，三份合并去重

第一列别偷懒。从数据库拼出来的 URL 和线上真实被抓取的 URL 经常不是一回事，大小写、结尾斜杠、历史参数都会造成差异。最靠谱的做法是把过去三个月的服务器日志里出现过的 200 地址全导出来，和站点地图、外链工具的结果合并去重，这份才是你要迁移的真实地址集合。

切之前。备份当前的服务端重定向配置；把这一批的映射表单独存一份；确认新地址已经能正常访问（返回 200，不是 404 也不是 302 到别处）。

切的时候。服务端写规则，能匹配规则的用规则（比如 /cate.php?id=12 到 /design/ 这种一对一关系写成一条 map），不规则的逐条写。注意顺序：精确匹配放前面，通配规则放后面，否则会被通配先吃掉。

切之后立刻做。批量请求这一批的旧地址，逐个检查状态码和最终落地地址。这一遍必须全量跑，抽样没意义，出问题的往往就是那几个特殊字符的地址。同时用网址检查工具抽查两三个重点页面，看抓取到的新地址对不对。

顺手改掉的。新页面上的 canonical 要指向新地址，别还写着旧的；之前为了防止提前收录加的 noindex（如果加过）要去掉；站点地图提交新的，旧的可以留着观察一段时间再撤；站内所有还指向旧地址的内链，按映射表批量替换。

条目列表的分页、筛选组合地址，在改结构时最容易出问题。常见的错法是：只给第 1 页做了 301，第 2 页之后全部 404。这些地址虽然大多不进索引，但用户和外链可能挂在上面，处理起来不复杂，规则里带上页码参数就行。

另一种错法是分页地址全部 301 到第 1 页。这么做等于告诉搜索引擎后面几页的内容没了，如果那些页本来有独立价值，就白丢一批。分页地址要么保留原结构映射过去，要么返回 404 或 410，别一锅端指向首页。

切完之后盯四周。前面一两周看抓取异常有没有涨、404 有没有异常增长；第三四周看新地址的收录量是不是在往上走、旧地址的展现是不是在往下掉。两个方向同时发生，说明迁对了。

只看到旧地址掉了、新地址没起来，通常是映射有问题或者新页面本身质量有问题（比如换了路径但内容也顺手改了）。这时候按分类回溯，找出没起来的那一批单独查。

URL 结构这东西，改一次代价不小，所以改之前值得多花两天把映射表做扎实。省下来的那两天，后面会用两个月来还。