分类从 /men/shoes 改成 /shoes，开启“为旧URL创建永久重定向”后，浏览器提示重定向次数过多。curl跟踪发现旧地址301到新地址，新地址又被某条历史重写或Nginx规则301回旧地址。只清缓存不会改变url_rewrite表里的关系。

先把跳转链完整打印出来

curl -sS -I https://example.com/men/shoes
curl -sS -IL --max-redirs 10 https://example.com/men/shoes | grep -iE 'HTTP/|location:'

分别请求是否带尾斜杠、是否带.html、HTTP与HTTPS、www与非www，避免把域名规范化循环误判成Magento分类循环。

查询两个request_path的记录

SELECT url_rewrite_id,entity_type,entity_id,request_path,target_path,redirect_type,store_id,is_autogenerated
FROM url_rewrite
WHERE request_path IN ('men/shoes','shoes')
   OR target_path IN ('men/shoes','shoes')
ORDER BY store_id,url_rewrite_id;

系统生成的旧URL重定向通常request_path=旧路径、target_path=新路径、redirect_type=301。若还存在request_path=新路径指回旧路径的自定义记录，就形成闭环。多Store下同一路径可各有一条，查错store_id会以为数据没有问题。

再检查Web服务器和扩展

  • Nginx/Apache是否有旧SEO迁移规则
  • CDN Redirect Rule是否把新路径改回旧路径
  • SEO扩展是否维护独立的redirect表
  • Store Code加入URL后是否重复拼接或剥离
  • 尾斜杠规则是否与Magento suffix规则打架

用响应Header判断每一跳由哪一层产生。Magento跳转通常带应用层特征；CDN或Nginx可能在请求到达PHP前完成。

安全修复方式

先导出涉及entity_id和store_id的重写记录。删除或禁用那条错误的自定义反向重定向，保留旧到新的单向301。对于大量脏数据，优先修正生成来源后重建URL Rewrite；不要每天用SQL删表。

bin/magento indexer:reindex catalog_url
bin/magento cache:clean full_page

部分Magento 2版本没有独立catalog_url索引器，以 indexer:info 为准。修改分类URL key并保存，也会触发对应重写生成。

SEO验证清单

  • 旧URL只跳一次并最终200
  • 新URL直接200，不再返回301
  • canonical指向新URL
  • Sitemap只包含新URL
  • 各Store View跳转到自己的域名和路径
  • 带查询参数的旧链接按需要保留参数但不形成循环
修301循环时不要一上来关闭所有旧URL重定向。正确目标是保留单向迁移链，而不是让历史外链全部404。