后台保存商品时报 URL key for specified store already exists，最直接的反应是修改商品 URL Key。但有时换了一个完全不同的 Key 仍然失败，因为冲突对象不一定是另一个商品，也可能是分类、CMS、自定义 Rewrite 或旧的 301 记录。

先确定冲突发生在哪个 Store View

URL Rewrite 的唯一性通常与 request_path + store_id 组合有关。相同路径可以存在于不同商店，但不能在同一个 store 中同时指向两个目标。多商店编辑商品时，Default Config 看起来正常，某个 Store View 的覆盖值却可能仍是旧 Key。

保存前记录商品 ID、当前商店、URL Key 和预期完整路径。若启用了分类路径，还要把所属分类的 URL Path 计算进去，不能只查商品 Key。

直接查询 request_path 的占用者

SELECT url_rewrite_id, entity_type, entity_id, request_path,
       target_path, redirect_type, store_id, metadata
FROM url_rewrite
WHERE request_path IN ('sample.html','category/sample.html')
ORDER BY store_id, url_rewrite_id;

如果结果指向另一个有效商品或分类，应调整业务 URL；如果是旧 301，先确认该旧路径是否仍有外链和自然流量；如果指向已删除实体，才考虑作为孤立数据处理。不要看到冲突就直接删整张表，也不要去掉数据库唯一索引。

“为旧 URL 创建永久重定向”会保留历史路径

修改商品 URL Key 时，Magento 可以自动为旧地址生成 301。频繁改名后，历史路径会持续占用 request_path。若现在想把旧路径分配给另一商品，必须先决定旧流量应该去哪里，再修改或移除对应 Rewrite。

检查 Catalog SEO 中的“Create Permanent Redirect for URLs if URL Key Changed”，但不要为了解决一次冲突就全局关闭。是否保留历史重定向应由站点 SEO 策略决定。

分类路径和多分类分配会放大冲突

启用商品分类路径后，同一商品可能生成多个路径。两个分类具有相同 URL Path，或商品在移动分类后保留旧路径，都可能让保存过程批量生成时失败。查询同一 entity_id 的所有 rewrite，比较系统生成记录与自定义记录：

SELECT request_path, target_path, redirect_type, store_id, metadata
FROM url_rewrite
WHERE entity_type='product' AND entity_id=123
ORDER BY store_id, request_path;

第三方导入或 URL 模块可能绕过 Magento 服务直接插表，留下 metadata 不完整的数据。修复时应优先通过正式 URL Rewrite 服务重新生成，而不是拼 SQL 批量写入。

保存成功之后还要验证旧地址

处理冲突后，清理相关缓存并检查新 URL 返回 200、规范标签正确、旧 URL 按预期 301，且没有形成多跳或循环。再在同一 Store View 重新保存商品，确认冲突没有再次生成。真正解决的是 URL 所有权，而不是让一次保存勉强通过。