先给结论:路径大小写不一致时,不要靠“把 URL 改成小写”或“加一条重定向”草率收场,而要先确认服务器与 CDN 是否把大小写视为同一个资源,再把大小写映射规则固化成唯一入口。若同一份文件在 /Docs/Guide 和 /docs/guide 都能返回 200,索引申请就会把两个地址当成两个页面,后续的抓取、收录和权重判断都会分裂。
典型表现是:链接检查工具、站点地图和页面内链分别指向大小写不同的路径,而每个路径都能打开。此时团队里常出现两种理解。第一种认为“服务器不区分大小写,所以是同一个页面”;第二种认为“既然返回 200,就是两个独立页面,应当分别申请索引”。两种理解都能解释“页面能打开”,但只有一种能解释索引申请后出现的重复、覆盖或流量分散。
要区分它们,不能只看浏览器能否打开,而要看响应头和服务器行为。请求两个仅大小写不同的地址,记录状态码、Content-Location、Link rel="canonical" 以及最终渲染的规范链接。如果两个地址都返回 200 且各自声明自己为规范,那么它们就是两个事实上的独立资源;如果其中一个返回 301 或 308 指向另一个,则大小写差异已被统一。若服务器在 Linux 环境下区分大小写,而本地开发机不区分,就会出现“本地正常、线上分裂”的经典矛盾。
第一种解释是文件系统或 Web 服务器本身不区分大小写,因此两个路径指向同一 inode,返回内容一致。这种情况下,索引申请通常不会立刻出问题,但一旦迁移到区分大小写的环境,原来的链接就会 404,已申请的索引也会失效。
第二种解释是服务器区分大小写,但站点同时存在两份物理文件或两条路由规则,导致两个地址都返回 200。这时搜索引擎看到的是两个可抓取、可索引的 URL,索引申请会分别处理,造成重复内容或规范冲突。判断依据不是“内容看起来一样”,而是服务器日志中两个路径是否命中同一文件、响应头中的 ETag 与 Last-Modified 是否一致、以及是否存在指向对方的重定向。
curl -I 分别请求大小写变体,记录返回 200、301、308 还是 404。若全部 200 且无跳转,说明映射缺失;若一个跳转到另一个,说明映射已存在。rel="canonical"。若各自指向自身,索引申请会把它们当作不同页面;若都指向同一个首选地址,则分歧已收敛。这三个信号中,只要“状态码全 200 + 规范各自自指 + 内链混用”同时成立,就可以判断问题属于映射缺失,而不是服务器不敏感。反之,若存在 301 且规范统一,则问题已进入收敛阶段,只需清理残留链接。
确认映射缺失后,下一步不是逐个提交索引申请,而是先统一映射。常见做法是在服务器或 CDN 层配置规则,把非首选大小写形式 301 重定向到首选形式,并确保该规则覆盖所有目录层级。动作完成后,重新请求两个变体,确认一个返回 301、另一个返回 200,且 301 的 Location 指向首选地址。
这个动作会直接影响下一步:如果重定向生效,索引申请只需针对首选地址进行,站点地图和内链也应同步改为首选形式;如果重定向未生效或出现循环跳转,则说明规则顺序或匹配范围有误,应先修规则,而不是继续提交申请。假设一个站点把 /Docs/Guide 重定向到 /docs/guide,但内链仍大量使用 /Docs/Guide,那么每次抓取都会经过一次跳转,索引申请虽然最终能到达目标,但抓取预算会被额外消耗。此时应优先改内链,而不是反复提交索引申请。
映射统一后,还需要确认旧地址是否仍能访问、是否返回正确的状态码。若旧地址返回 404 而非 301,已索引的旧链接会直接失效;若返回 200 且内容重复,则映射并未真正统一。取舍点在于:是保留旧地址并重定向,还是彻底删除旧地址。若旧地址有外部链接或历史流量,保留 301 更稳妥;若旧地址从未被索引且无外链,直接删除并更新内链即可。
最后,把大小写规则写进项目约定,例如“所有 URL 路径统一使用小写,生成链接时强制转换”。这样后续的角色分歧就不再是“谁记得改”,而是“规则是否被执行”。索引申请只是验证手段,真正决定结果的是映射是否唯一、稳定、可核对。