后台修改分类 URL Key 后保存成功，新 URL 404，旧 URL 也没有跳转。分类实体还在，问题发生在“分类路径—请求路径—Store”之间的 URL rewrite 生成链路。

先确认改的是哪个 Store View

分类 URL Key 可以有 store 级覆盖。默认范围改了，但某个 Store View 仍勾着旧的自定义值，新前台不会继承。确认分类属于当前网站使用的 Root Category，并在准确 store scope 查看 URL Key 与 URL Path。

查询 Rewrite 是否存在

SELECT url_rewrite_id, entity_id, request_path, target_path,
       redirect_type, store_id, is_autogenerated
FROM url_rewrite
WHERE entity_type = 'category' AND entity_id = 42
ORDER BY store_id, url_rewrite_id;

没有新 request_path，说明生成阶段失败或被插件跳过；有记录但 store_id 不对，属于范围问题；有正确记录仍 404，再查 Web server、store code 路由和缓存。不要手工插入一行就结束，下一次分类保存会再次覆盖。

重复路径会阻止生成

同一 Store 下 CMS 页面、商品、分类或自定义 rewrite 占用了目标 request_path，保存时应有冲突提示，但批量导入和旧扩展可能留下异常记录。先找出占用者，决定谁应该保留；不要直接删除未知 rewrite，可能影响线上入口。

旧 URL 是否生成 301

“Create Permanent Redirect for Old URL”决定修改时是否保留旧地址跳转。它不能修复新地址 404，只负责旧 request_path。SEO 上应确认旧地址一跳到新地址，避免 301 链和全部跳首页。

重新生成要使用支持的流程

核心版本并没有一个适用于所有 URL 的通用“reindex url_rewrite”命令。可在测试环境重新保存分类或使用当前版本/扩展明确支持的再生工具；执行前备份并检查规模。修复后测试新 URL 200、旧 URL 301、canonical 指向新 URL、Sitemap 更新，并在两个 Store View 分别验证。

层级路径会影响子分类

父分类 URL Key 改变时，配置可能要求重新生成所有子分类与商品路径。目录很大时保存超时，部分 rewrite 已更新、部分仍旧，便会出现局部 404。按父分类路径抽样子分类和商品，统计新旧 request_path 数量，不能只验证父页面。

Web Server Rewrite 仍要工作

数据库记录正确但请求没有进入 Magento，检查 Nginx/Apache 的 try_files、子目录 Base URL、尾斜杠和 store code。直接访问 target_path 能开并不能证明 SEO URL 路由正常。CDN 若缓存旧 404，修复后需要精确 purge，新 URL 的 404 TTL 不应过长。

为防止再次发生，可在分类保存或发布后运行 URL 健康检查：验证状态码、跳转次数、canonical 和 store 对应关系，并对重复 request_path 阻止上线。

不要用跳转首页掩盖 404

把所有旧 URL 统一 301 到首页会变成软 404，也丢失分类主题相关性。找不到一一对应的新地址时应保留明确 404/410；存在新分类时才做精确跳转。上线后从访问日志提取高频旧路径，逐条校验状态码与落地页。