Baiduspider抓取，文件路径大小写差异引发问题时怎样统一映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ShapBot/0.1.0
🔗 /2ba37373c1b3.html
📄
Baiduspider抓取，文件路径大小写差异引发问题时怎样统一映射
如果同一份文件在服务器上只存在一种大小写形式，而站内链接、站点地图或重定向却给出另一种大小写，Baiduspider抓取时就会把两种写法当成两个地址分别请求。统一映射的核心不是改百度，而是让服务器对同一资源的所有大小写变体返回同一个规范地址：要么全部301到唯一小写路径，要么让文件系统本身不区分大小写并保持链接一致。前者适用于Linux等区分大小写的环境，后者只适用于文件系统本身不区分大小写的环境，两者不能混用。
先看矛盾：样本正常，规模化后却出现例外
小规模检查时，抓取日志里某个页面的路径大小写与链接一致，返回200，看起来没有问题。当页面数量增加、模板复用、编辑手工录入链接或站点地图由脚本生成后，开始出现同一资源被两种大小写分别请求的情况。这时常见的两种解释是：
- 解释一：服务器把不同大小写映射到了不同文件或不同规则。例如存在
/Guide/Page.html与/guide/page.html两个实体，或重写规则只匹配了其中一种写法，另一种落到404或默认页。 - 解释二：服务器最终返回同一内容，但中间经过了额外跳转或软404。大小写变体先返回301、302，或返回200但内容为空、为错误页，Baiduspider抓取记录里仍会留下该变体的请求痕迹。
这两种解释不能靠“日志里有请求”来区分，因为请求存在只能说明被访问过，不能说明返回的是有效内容。
用响应头和最终地址区分两种解释
要区分上述解释，需要对同一资源的大小写变体分别发起请求，并记录状态码、Location头和最终响应体。判断依据可以归纳为：
- 如果变体返回301且
Location指向唯一规范路径，属于可接受的统一映射，下一步应检查站内链接和站点地图是否也使用该规范路径。 - 如果变体返回200但响应体与规范路径不同，说明服务器把两种写法映射到了不同内容，需要先消除重复实体，再谈统一。
- 如果变体返回404、403或软404，说明链接或映射规则存在缺口，应回到生成链接的模板或脚本中修正，而不是只改服务器重定向。
- 如果变体返回200且内容相同但没有跳转，说明服务器同时接受两种写法，短期内可访问，长期会分散抓取预算和规范信号，应补上301。
这里有一个假设例子：某站点在Linux服务器上只部署了 /news/list.html，但导航模板输出 /News/List.html。请求后者可能返回404。此时先修模板，让输出统一为小写，再对历史外链保留301。如果先加一条不区分大小写的重写规则，而不修模板，新页面仍会继续产生大小写不一致的链接，问题会反复出现。
统一映射的两种成立条件
选择哪种统一方式，取决于服务器环境和链接来源：
- 301到唯一小写路径成立的条件：服务器文件系统区分大小写，且能够配置重写规则；同时站内链接、站点地图、canonical标签都指向该小写路径。动作是配置规则并回归检查模板输出，结果是Baiduspider抓取时只会稳定请求一个地址，后续排查日志时噪声更少。
- 保持文件系统不区分大小写成立的条件：服务器或存储层本身不区分大小写，且所有链接生成环节不依赖大小写来区分资源。动作是确认没有两个仅大小写不同的文件共存，结果是无需额外重定向即可访问，但一旦迁移到区分大小写的环境，原有链接可能集中失效，因此迁移前必须补做映射检查。
两种方式不能直接照搬：在不区分大小写的环境里验证通过，不代表迁到区分大小写的环境后仍成立；反之，在区分大小写的环境里加一条全局忽略大小写的规则，也可能把原本不同的资源错误合并。
动作与下一步：先修来源，再补映射
可执行的顺序是：先导出站内链接、站点地图和重定向规则中出现的路径，按大小写分组，找出同一资源对应多个写法的条目；再修正模板、CMS字段或生成脚本，使新输出统一；最后对已经存在的外部链接和旧地址补301。这个顺序的原因是，只补301而不修来源，会持续产生新的变体；只修来源而不补301，旧变体仍会返回404或重复内容。
完成修正后，下一步不是立刻断言抓取问题已经解决，而是继续观察日志中大小写变体的请求是否减少，并确认这些请求的响应是否已变为301或404。请求量归零本身不能单独证明处理正确，也可能是该路径暂时没有被访问；需要结合响应码和最终地址一起判断。robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此统一映射只能解决地址不一致，不能替代对索引状态的单独检查。
