一个商品改过几次 URL Key 后，旧链接先跳到中间地址，再跳到新地址，某些 Store View 甚至进入循环。后台 URL Rewrite 数量不断增长，直接执行“全部删除后重建”看起来痛快，但历史外链、广告链接和搜索引擎已经收录的地址可能一起失效。

我会先选一个具体商品，把它在所有 Store View 的 rewrite 完整拉出来：

SELECT url_rewrite_id, entity_type, entity_id, request_path,
       target_path, redirect_type, store_id, is_autogenerated
FROM url_rewrite
WHERE entity_type = 'product'
  AND entity_id = :product_id
ORDER BY store_id, url_rewrite_id;

先区分“当前主路径”和“历史跳转”

redirect_type = 0 通常是当前可访问路径；301/302 是历史或人工重定向。先画出 request_path 到 target_path 的图，确认有没有 A→B→C、A→B→A，或者两个实体争用同一 request_path。不要只按 request_path 去重，因为不同 Store View 可以合法拥有同名路径。

目标是让重要旧地址一步跳到最终 canonical URL，而不是经过多层。对仍有外链、流量或订单邮件引用的旧地址保留 301；从未上线、没有引用的生成错误记录才适合删除。

为什么重新保存商品后问题又回来

检查 Catalog URL 配置、是否在 URL 中包含分类路径、是否为旧 URL 创建永久重定向，以及第三方 SEO 模块的 observer/plugin。批量导入若每次都重写 url_key，也会持续制造历史记录。

分类层级变化会产生更多组合路径。一个商品属于几十个分类时，开启分类路径会显著扩大 rewrite 数量。先确认业务是否真的需要这套路径策略，不能一边批量删、一边让配置继续生成。

清理时给自己留回滚和验证窗口

先备份目标记录，只按明确的 entity_id、store_id 和路径集合修改。生产大表上避免一条 DELETE 扫全表，按主键分批并观察锁。清理后通过标准索引/保存流程重建当前路径，不要手写 target_path 猜内部路由。

验收清单包括：新地址 200；重要旧地址一次 301 到新地址；不存在循环；canonical 指向最终地址；各 Store View 留在自己的域名和语言；站点地图只包含当前 URL。最后从访问日志统计一周仍被请求的旧路径，再决定是否继续保留。SEO 安全的关键不是 rewrite 表有多干净，而是用户和爬虫能稳定到达唯一最终页面。