先给结论:把路径大小写当成“同一资源的两种写法”来统一映射,而不是逐个改链接或只依赖重定向。前提是服务器或应用层能拿到原始请求路径,并且你能按目录或路由规则批量改写。对仍要保留的旧页面,统一映射到小写规范路径;确定要退出的,映射到 410 或 301 到替代页,再用百度缓存页面快照验证处理结果。
路径大小写差异通常有三种来源,处理方式完全不同。第一种是服务器文件系统本身区分大小写,比如 Linux 下 /News/2023/ 和 /news/2023/ 是两个不同目录,请求大写路径返回 404。第二种是应用路由不区分大小写,但内部生成链接时大小写混用,导致同一内容出现多个可访问 URL。第三种是 CDN 或反向代理做了路径归一化,回源路径被改写,但缓存键仍按原始大小写保存。
区分方法很直接:用 curl -I 分别请求原始大小写路径和全小写路径,比较返回状态码和 Location 头。如果两条路径都返回 200 且内容相同,说明应用层已经做了归一化,问题在缓存键或链接生成;如果一条 200 一条 404,说明文件系统或路由层没有统一。这个判断决定了下一步是改服务器配置还是改应用代码。
如果路径直接对应磁盘文件,优先在服务器层做映射。以 Nginx 为例,可以在 location 块里用正则把大写路径重写到小写,或者用 try_files 配合 lowercase 变量。但要注意:重写规则必须放在静态资源处理之前,否则请求已经被文件系统拒绝,重写不会生效。改完后用 curl -I 验证大写路径返回 301 且 Location 指向小写路径,再确认小写路径返回 200。
如果路径由应用路由动态生成,比如框架根据参数拼接 URL,那就在应用层统一出口。具体动作是找到所有生成链接的函数或模板,把路径部分强制转为小写,或者在路由匹配前对请求路径做一次 strtolower 归一化。后者的风险是可能改变参数值的大小写语义,所以只对路径段做处理,不要动查询字符串。改完后抽查几个典型页面,确认页面内链接和实际请求路径一致。
统一映射后,百度缓存页面快照是判断处理是否生效的一个观察点,但它不是唯一证据。如果快照里仍然显示旧的大写路径链接,可能是百度还没重新抓取,也可能是映射规则只对直接请求生效、对站内链接生成没生效。这时不要立刻断定映射失败,先检查页面源码里的链接是否已经全部改为小写。如果源码已改而快照未变,属于抓取和更新延迟,继续观察即可。
另一个合理解释是:百度缓存页面保存的是上一次成功抓取时的 HTML,路径大小写差异如果只影响部分资源(比如 CSS 或图片),快照里可能看不出问题,但实际渲染会受影响。所以验证时要同时看快照的文本内容和资源加载情况,不能只看快照里有没有出现大写路径。
面对旧系统或旧合作关系留下的页面,先按业务价值分两类。仍然有价值的页面,统一映射到小写规范路径,并确保站内所有入口链接都指向新路径。确定要退出的页面,不要只靠 robots.txt 限制抓取,因为抓取限制不等于索引移除;更可靠的做法是返回 410,或者 301 到最相关的替代页。如果旧路径和新路径只是大小写差异,301 到小写路径即可;如果内容已经不存在,410 比 301 更明确。
假设有一个旧专题页 /Old-Topic/Index.html,内容仍有价值,但站内链接大小写混乱。处理动作是:在服务器层把该路径的所有大小写变体 301 到 /old-topic/index.html,同时修改站内模板里生成该链接的代码。结果是百度缓存页面下次抓取时,快照里的链接和实际请求路径一致,后续排查其他页面时不会再把大小写差异误判为新问题。
上线后重点看三件事:服务器访问日志里大写路径的请求量是否下降、404 是否集中在未覆盖的变体上、百度缓存页面快照是否逐步更新为小写路径。如果大写路径请求量归零,不能单独证明映射正确,因为也可能是链接被移除或抓取减少;要结合 301 响应数和快照更新情况一起判断。如果发现某些大写变体仍然 404,说明映射规则覆盖不全,需要补充规则而不是回退整个方案。
最后提醒一点:站点地图里写小写路径不保证百度一定按小写抓取,HTTPS 也不保证路径映射不会出错。映射是否生效,最终要看服务器返回的状态码和页面内链接是否一致。把这两个证据固定下来,再决定是继续扩大映射范围还是只保留已确认有效的部分。