当CMS、CDN、电商模块或旧合作方各自都能输出绝对网址时,唯一责任方应当定为“最终响应层中负责拼接canonical与站内链接的模板层”,而不是后台配置面板最多的那套系统。判断方法很直接:用curl -I取回一个页面的最终响应,看响应里出现的绝对网址由谁拼接;谁最后改写HTML中的链接,谁就是责任方。若两套系统都声称负责,就先冻结其中一套的输出,观察另一套是否仍能独立产生完整网址。
选一个仍被旧系统维护、但内容仍有价值的页面,例如旧产品详情页。把它的最终HTML保存下来,搜索所有以http开头的链接。逐条标记来源:模板头部、正文编辑器、评论模块、推荐位、站点地图生成器。标记完成后,你会看到同一页面里可能混着三套规则:一套输出首选域名,一套输出旧域名,一套输出相对路径。
此时不要急着全站替换。先确认哪套规则出现在<link rel="canonical">、<a href>和站点地图这三处。canonical和站内链接通常由同一个模板层生成,站点地图可能由独立任务生成。如果站点地图仍输出旧域名,而页面canonical已指向首选域名,说明至少有两个责任方,需要先合并。
责任方的定义不是谁配置了域名,而是谁在最终响应中写入了绝对网址。按下面的顺序检查:
这个动作的结果会直接影响下一步:如果关闭CDN改写后旧域名消失,问题在边缘层,改一处规则即可;如果旧域名仍然出现,说明源站模板或旧模块仍在生成,必须继续向源站追溯。
旧系统或旧合作关系退出时,不必一次性删除全部输出。可以按“是否影响唯一责任方”分三档处理:
这里有一个常见误判:把旧系统的抓取限制写进robots.txt,就以为旧网址不会再被处理。robots.txt只限制抓取,不等于可靠的索引移除;已经进入索引的旧网址仍可能被展示。因此,旧系统退出时,更可靠的动作是让页面返回正确的canonical或重定向,而不是只依赖抓取限制。
假设某站点主模板输出https://www.example.com,旧商城模块输出http://shop.example.com,两者同时出现在同一产品页的推荐位和canonical中。先不要同时修改两处,否则无法判断哪套规则在生效。
第一步,只修改旧商城模块,让它输出相对路径/product/123,主模板保持不变。第二步,重新取回页面,确认canonical和推荐位链接是否都变为首选域名下的绝对网址。若推荐位仍出现旧域名,说明还有第三处输出,例如前端JavaScript拼接或CDN边缘改写。第三步,继续定位第三处,直到同一页面中所有绝对网址只由一个模板层生成。
这个顺序的价值在于:每次只改一个输出点,才能把“谁负责”从猜测变成可验证的事实。若一次改多处,后续再出现旧域名时,无法区分是遗漏还是新规则。
确定唯一责任方后,把它写成三条可执行检查项,交给后续维护者:
完成这三项后,再处理旧内容。对仍有价值的旧页面,保留其正文和图片,把网址输出权交给责任方;对无价值的旧页面,停止生成HTML并设置重定向。此时再检查站点地图和canonical是否一致,才能判断旧系统是否真正退出网址生成环节。