加快百度收录：文件路径大小写差异引发问题时怎样统一映射
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /3ef73babbb63.html
📄
加快百度收录：文件路径大小写差异引发问题时怎样统一映射
先给结论：如果同一份内容在服务器上存在大小写不同的两套路径，而站内链接、站点地图、重定向规则各写各的，百度可能把它们当成不同 URL 分别抓取，权重和抓取配额被摊薄。解决办法不是把所有链接改一遍，而是先确定服务器文件系统是否区分大小写，再决定用 301 统一映射，还是用规范化标签加站点地图收敛。
先判断服务器是否区分大小写，这决定映射方向
Linux 环境下 /News/2024/ 和 /news/2024/ 通常是两个不同目录，能同时返回 200；Windows 和部分 macOS 默认不区分，两者指向同一文件。这个差异决定了你的处理动作。
- 区分大小写：必须选一个规范形式，其余变体 301 过去，否则每个变体都是可抓取的独立 URL。
- 不区分大小写：服务器层面只有一份内容，但站内链接写法不一致仍会制造多个 URL 表象，需要靠规范化标签和站点地图收敛。
判断方法很直接：在服务器上创建 /Testcase/ 并放一个文件，再请求 /testcase/。返回 200 说明不区分，返回 404 说明区分。这一步不做，后面所有映射方向都可能是错的。
两种条件下的不同选择
条件一：服务器区分大小写，且两套路径都已返回 200
这是最需要处理的情况。选择依据是看哪一套已经被百度抓取过、有外链指向。假设你发现 /News/ 在日志里被频繁抓取，而站内导航大量写成 /news/，此时应把 /news/ 定为规范形式，因为它符合小写惯例，改造成本更低。
实施动作：在服务器配置中为每个大写变体写一条 301 规则，指向对应的小写路径。改完后抓取一次原大写 URL，确认返回 301 且 Location 指向小写版本，而不是 302 或直接 200。这一步的结果决定下一步：如果 301 生效，接下来只需清理站内链接；如果仍返回 200，说明规则顺序被更宽泛的重写规则覆盖，要先调整规则优先级。
条件二：服务器不区分大小写，但链接写法混乱
这时不需要写 301，因为服务器根本不产生两套内容。选择依据是看百度实际抓取了哪些变体。假设日志显示 /About/ 和 /about/ 都有抓取记录，说明百度把它们当成了两个入口。
实施动作：在每个页面的 <link rel="canonical"> 中写死小写规范 URL，同时把站点地图里的 URL 全部统一为小写。改完后观察日志中大写变体的抓取是否逐步减少。这个结果影响下一步：如果减少，说明收敛生效；如果没减少，检查是否仍有内链或外链指向大写形式，因为 canonical 是提示而非强制指令。
统一映射时最容易漏掉的三类入口
站内导航和文章正文链接通常会被想到，但下面几类经常被遗漏，导致映射不完整。
- 站点地图文件本身：sitemap 里如果混用大小写，等于主动向百度提交多个变体。注意，提交站点地图不保证收录，它只是声明期望的规范形式。
- robots.txt 中的路径声明：如果只屏蔽了小写路径，大写变体仍可被抓取。robots.txt 的抓取限制不等于可靠的索引移除，被屏蔽的 URL 仍可能因外链出现在索引中。
- 历史重定向链：旧规则可能把大写跳到另一个大写，形成链条。应保证每条链只有一跳，直接指向最终小写 URL。
一个假设例子：映射前后的判断路径
假设某站点在 Linux 服务器上有 /Product/A1/ 和 /product/a1/ 两个可访问路径，站内导航用大写，站点地图用小写，外链两者都有。处理前，百度日志显示两个路径都在被抓取。
第一步，把 /Product/A1/ 301 到 /product/a1/。第二步，把导航和站点地图统一为小写。第三步，一周后检查日志中大写路径的抓取量。如果抓取量下降但未归零，合理解释包括外链尚未更新、百度缓存了旧链接、或重定向规则未覆盖带参数的变体，不能仅凭抓取量下降就断定映射已完全生效。此时应继续核查外链和带参数 URL，而不是停止处理。
例外：不能一刀切映射的情况
有些路径的大小写本身承载区分意义，例如区分用户 ID 或区分不同语言版本。这类路径不应强行统一为小写，而应在服务器层面确保它们各自返回独立内容，并在站点地图中分别声明。判断标准是：两个变体是否返回实质不同的内容。如果内容相同，统一映射；如果内容不同，保留区分并各自规范化。
另外，如果站点同时存在 HTTP 和 HTTPS 的大小写变体，要先把协议统一，再处理路径大小写，否则重定向规则会互相干扰。HTTPS 本身不保证安全无漏洞，也不保证排名，它只是映射链条中的一环。
