死链接检测：路径大小写差异该保留、改写还是退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /074bfe8e8f85.html
📄
死链接检测：路径大小写差异该保留、改写还是退出
如果服务器或静态托管对路径大小写敏感，而站内链接、站点地图、重定向规则里混用了大小写，死链接检测会把同一目标拆成多个状态。处理这类问题的核心不是把全部链接改成小写，而是先确定哪个大小写形式是唯一规范，再决定保留、改写还是退出。若规范形式尚未确定，任何批量替换都可能把原本可访问的页面推入死链接。
先判断大小写差异有没有形成两个可访问目标
在 Linux 常见文件系统、部分对象存储和区分大小写的静态托管上，/Guide/SEO.html 与 /guide/seo.html 可以同时存在。此时两个地址都返回 200，检测工具不会报死链接，但站内可能已经把权重和点击分散到两个目标。反过来，如果服务器只保留其中一个文件，另一个形式返回 404，问题才是明确的死链接。
判断时不要只看检测工具的 404 列表。对同一路径的大小写变体分别请求，记录状态码、最终 URL 和响应内容是否相同。若两个变体都返回 200 且内容一致，优先视为重复目标；若只有一个返回 200，则另一个是失效入口。若两个都返回 200 但内容不同，属于更危险的情况，不能靠统一小写解决，必须先确认哪个是业务上正确的页面。
保留原大小写的适用条件
保留某个大小写形式，适用于它已经成为稳定入口、外部链接和站点地图大量引用它，并且服务器无法低成本做大小写不敏感映射的情况。例如历史内容目录一直使用 /Docs/API/，外链和用户收藏都指向这个形式，而底层文件系统区分大小写。此时强行改成小写，会让原有入口逐步失效。
保留不等于放任。需要把该形式写进规范链接、站点地图和站内导航，并让其他大小写变体通过重定向指向它。重定向规则要放在请求进入应用之前，且只处理明确的大小写变体，不要用通配规则把无关路径一并吞掉。完成这一步后，重新跑一次死链接检测，观察原 404 是否变成 301 再到 200，而不是直接消失。
改写为统一小写的适用条件
改写适用于大小写形式尚未被外部大量引用，或者站点本身运行在大小写不敏感环境，只是站点地图、内链和检测报告里写法不一致。此时把规范形式统一为小写，通常比维护多套重定向更简单。动作可以分三步：先导出所有含大写字母的站内 URL，再逐条确认对应小写目标返回 200，最后才替换站点地图和模板中的链接。
这里有一个假设例子：某目录下有 40 个页面，其中 12 个链接写成 /Product/A.html，实际文件是 /product/a.html。在大小写敏感服务器上，这 12 个入口会 404；在小写不敏感服务器上则正常。若站点未来会迁移到区分大小写的对象存储，就应把 12 个链接改写为小写并保留旧形式重定向。改写后如果检测报告里的 404 数量下降，但出现新的 301 链，说明映射生效，下一步应检查重定向是否形成多跳。
退出旧大小写形式前要确认的边界
退出意味着不再保留旧形式，直接让它 404 或返回 410。这个选择只在确认旧形式没有外部链接、没有用户收藏、没有历史流量入口，且站点地图和站内模板已全部更新时成立。只要还有一处外部引用，退出就会把可修复的入口变成死链接。
不能把“检测工具不再报告该 URL”当作退出正确的唯一证据。检测范围、抓取预算、robots.txt 限制和登录墙都会让某些 URL 不被发现。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。更稳妥的做法是保留一段时间的重定向日志，观察旧形式是否仍有请求；若请求持续存在，就继续保留映射，而不是按计划退出。
统一映射的可执行顺序
- 列出所有大小写变体，标记每个变体的状态码和内容是否与规范目标一致。
- 确定唯一规范形式，优先选择已有外部引用最多、内容最完整的那一个。
- 为其余变体建立精确重定向，避免用宽泛规则覆盖无关路径。
- 更新站内链接、站点地图和模板，使新产出不再混用大小写。
- 重新检测，分别记录 404、301 和 200 的变化，再决定是否扩大改写范围。
如果重定向后旧形式仍返回 404，先检查规则匹配顺序和服务器是否在重定向之前就做了文件查找；如果旧形式返回 200 但内容不同，说明存在两个真实目标，应回到第一步重新确认规范形式，而不是继续批量替换。
