先给结论:路径大小写差异造成的内链失效,通常不是“改一条链接”能解决的,而是需要在站点输出层建立一份大小写统一映射,让同一资源只有一种规范路径。判断该不该做映射,关键看两件事:服务器是否区分大小写,以及内链是手工写死还是由模板、CMS、脚本生成。若服务器区分大小写而大小写形式混用,映射就是必要的;若服务器本身不区分,映射仍有价值,但优先级低于修复生成规则。
常见情形是:页面上指向 /Product/A 和 /product/a 的链接都能打开,肉眼检查“没有死链”,但抓取与索引表现却像两个页面。直觉会认为“能打开就没问题”,实际却可能出现链接信号被拆到不同 URL 形态上。要区分两种解释:
还有一种容易被忽略的中间态:服务器区分大小写,但其中一种写法被重定向到另一种。重定向能缓解用户访问,却不会自动让所有内链都改写成规范形式,后续新增链接仍可能继续产生大小写混用。
不要凭页面能否打开下结论,按下面顺序取证:
curl -I 分别请求大小写不同的同一路径,记录返回的状态码与 Location 头。若两者都返回 200 且没有重定向,偏向解释二;若一种返回 301/308 指向另一种,说明已有重定向但生成规则未统一。这里要提醒一个反直觉点:抓取量或某一路径的请求量下降,不能单独证明大小写处理正确,也可能是抓取预算转移、页面改版或屏蔽规则变化。只有状态码、重定向目标和生成规则三处证据一致,才能确认映射已经生效。
映射不是逐条替换链接,而是确立一条规则并让所有输出遵守。建议顺序如下:
一个假设例子:某站点资源实际路径为 /Docs/Guide,模板却输出 /docs/guide。若服务器区分大小写且无重定向,两个地址可能各自返回内容;若加了 301,用户能到达,但内链仍写着非规范形式。此时只加 301 不够,还要改模板,否则每次新增页面都会重复同一问题。这个例子的数字与场景均为说明方法而设,不代表任何真实站点数据。
如果服务器本身不区分大小写,且实测两种写法返回完全相同的响应、没有重定向分叉,那么全站映射的收益有限。此时更值得先查的是:内链锚文本是否重复、链接是否由前端脚本延迟插入、以及是否存在参数或尾斜杠差异。这些因素也可能造成类似“能打开但信号不集中”的现象。
另外,robots.txt 的抓取限制不等于可靠的索引移除;即使屏蔽了某种大小写路径,已存在的 URL 形态也可能继续以其他方式出现。HTTPS 也不保证路径映射正确,它只解决传输层问题,不解决路由与生成规则问题。不同搜索引擎对大小写与重定向的处理细节须分别核查,不能用一个平台的表现推断全部。
可执行的下一步是:先对同一资源的两种大小写写法做一次状态码与重定向对照,再决定是补重定向、改生成端,还是两者都做。这个动作的结果会直接决定后续工作量——若只有重定向缺失,改动集中在服务器配置;若生成端也在输出混用写法,就必须把模板与路由一并纳入修改范围,否则映射只能 temporary 生效。