先给结论:如果服务器对大小写不敏感,而站内链接、站点地图或历史外链混用了大小写,就要以“实际返回200的那一个路径”为基准,把其余写法统一301到它;如果服务器对大小写敏感,则不能靠跳转掩盖,必须回到生成源头,让内容只在一个路径下可访问。判断依据不是百度是否已经收录,而是同一资源当前存在几种可访问写法、每种写法的状态码是否一致。
这一步决定后面是“映射”还是“改源”。用同一资源分别请求全小写、首字母大写、全大写三种写法,记录状态码、最终URL和响应内容长度。
不要只看浏览器地址栏,浏览器可能隐藏差异。用抓取工具或命令行请求,保留原始状态码。若三种写法返回内容相同但状态码不同,说明跳转链或重写规则不统一,先修规则再谈映射。
假设目录/News/和/news/都能打开同一篇内容,而站点地图只提交了小写版本。此时应把大写版本301到小写版本,而不是让两者都返回200。选择哪一个作为规范路径,取决于现有内链和站点地图中哪种写法占多数,以及哪个写法已经获得外部链接。不要因为“看起来更整齐”就选一个与现有链接结构相反的方向,否则会把已有信号引向新路径。
实施动作:在服务器配置或应用路由层增加大小写归一化规则,把非规范写法301到规范写法。动作完成后,下一步是重新抓取跳转链,确认每个旧写法只跳一次、不形成循环。如果跳转链超过一跳,说明还有中间规则在改写,需要先合并规则。
例外:如果某个大写路径已经被大量外链引用,而小写路径没有外链,强行把小写设为规范会浪费已有链接。此时可以反过来,把大写设为规范,但前提是站点地图和内链同步更新,避免继续产生小写写法。
服务器对大小写敏感时,404不是靠301能解决的,因为错误写法本身没有对应资源。常见来源有三类:内容管理系统自动把标题转成路径时保留了大写;开发环境用大小写不敏感的系统,上线后路径大小写与代码引用不一致;站点地图生成脚本与页面实际路径使用了不同的大小写规则。
排查动作:把站点地图里的URL与页面内链、面包屑、分页链接逐条比对,找出第一个出现大小写差异的位置。这个位置通常就是生成源头。修正源头后,再检查服务器日志中404的请求路径,确认错误写法是否停止产生。如果404仍在增加,说明还有未覆盖的生成入口,需要继续查模板或接口。
注意:robots.txt禁止抓取某个大小写变体,不等于该变体不会出现在百度中,也不等于索引移除。它只限制抓取,不保证移除。站点地图提交也不能保证收录,它只是告知存在哪些URL。把错误写法写进robots.txt反而可能让问题更难被发现。
多个角色对“哪个路径才是对的”有不同理解时,不要停留在口头争论。建一张对照表,字段包括:写法、状态码、最终URL、内容是否相同、出现在哪些位置(内链、站点地图、外链)。每个角色按自己负责的位置填写,最后用同一组请求结果核对。这样分歧就变成可验证的数据,而不是各自记忆。
假设一个短例子:运营认为/Product/A是正确路径,开发认为/product/a才是。对照表显示/Product/A返回200且被三条外链引用,/product/a返回200但只出现在站点地图中。依据“外链优先”的规则,应把/product/a301到/Product/A,并更新站点地图。这个假设说明的是比较方法,不是真实项目结果。
映射完成后,至少核对三件事:规范路径返回200且内容唯一;非规范路径返回301且指向规范路径;站点地图和内链不再产生非规范写法。如果其中一项不满足,先回到对应环节修正,不要急着提交新一轮站点地图。
百度最新收录的变化可能滞后,请求量或抓取量暂时归零也不能单独证明处理正确,它还可能受抓取配额、日志采样或服务器响应波动影响。更可靠的下一步是持续观察服务器日志中非规范路径的请求是否下降,以及规范路径的抓取是否稳定,再决定是否需要进一步调整内链或站点地图。