www域名配置，遗留系统无法改模板时有哪些可行调整边界
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /aa970aa3e560.html
📄
www域名配置，遗留系统无法改模板时有哪些可行调整边界
可行调整边界取决于服务器与网关层是否仍可改，而不是模板层是否可改。如果遗留系统只输出不带 www 的绝对链接，但反向代理、重写规则或响应头仍可动，那么能在不碰模板的前提下把 www 与裸域收敛到同一套 URL；如果连网关配置也被冻结，剩下的只是有限补救，不能假装等价于一次干净的 www 域名配置。
条件一：反向代理或 Web 服务器配置仍可改时，优先做外部收敛
这是更值得投入的路径。判断依据很简单：找一条页面里由模板生成的绝对链接，看它是否在到达浏览器前经过网关。如果经过，网关就有机会改写 Location、Link 和正文中的主机名。
实施动作上，先选定一个规范主机名，例如统一保留 www。然后在反向代理层做三件事：把裸域 301 到 www；把 www 上对旧裸域绝对 URL 的引用重写为 www；对无法安全改写的响应体保持原样，只记录。完成这一步后，再抓取一批含绝对链接的页面，核对重写是否只影响主机名，没有破坏路径、查询串和片段。这个核对结果决定下一步：如果重写稳定，就可以继续处理站点地图和 canonical；如果不稳定，就应停止扩大重写范围，退回只做跳转。
这里有一个常被忽略的例外：如果遗留系统在 HTML 里用 JavaScript 拼接主机名，网关的文本重写可能改不到，或者改出语法错误。此时判断标准不是“有没有改”，而是“改后页面是否仍能正常渲染”。不能正常渲染，就说明这条边界已经到顶。
条件二：网关与模板都冻结时，只能做低风险补救
这种情况下不要承诺彻底解决。可做的通常只有：在入口层保留裸域到 www 的跳转；在可访问的响应头里补上规范提示；把站点地图和内部提交入口统一指向 www。动作之后要看的是跳转链是否只有一跳、目标是否稳定返回同一主机名。如果跳转链出现多跳或落到错误路径，下一步应优先修跳转，而不是继续加 canonical。
需要明确的是，robots.txt 的抓取限制不等于可靠的索引移除，它只约束抓取行为，不能替代规范收敛。站点地图指向 www 也不保证收录，它只是提供发现线索。因此在这条路径上，合理目标是减少分裂信号，而不是保证旧 URL 立刻消失。
- 可验证依据：同一路径在裸域和 www 下返回的 HTML 是否只有主机名不同。
- 可验证依据：跳转响应是否只发生一次，且最终主机名唯一。
- 可验证依据：站点地图中的 URL 主机名是否与规范主机名一致。
两种条件的分界证据：看响应头与正文谁先暴露主机名
如果响应头里的重定向目标已经可控，而正文里的绝对链接不可控，说明处在条件一与条件二之间。此时应把可改的部分先做完，把不可改的部分登记为已知残留。判断下一步是否继续投入，可以看一个假设例子：假设站内有 200 条含绝对链接的页面，网关重写后只有 30 条仍指向裸域，那就值得继续排查这 30 条是否来自同一类模板片段；如果重写后仍有 180 条指向裸域，说明重写规则覆盖面不足，继续加规则前应先确认规则匹配范围。
另一个分界证据是 HTTPS。启用 HTTPS 并不保证安全无漏洞或排名提升，它只影响传输层。在 www 域名配置里，如果证书只覆盖其中一个主机名，跳转就会在证书校验阶段失败。此时应先补证书覆盖范围，再谈跳转收敛。
实施后的验证与停止条件
完成任一条件下的调整后，按以下顺序验证：先请求裸域，确认返回 301 且目标为 www；再请求 www，确认返回 200 且页面内容与预期一致；再抽查正文中的绝对链接，确认主机名统一。若抽查中发现链接仍指向裸域，先判断它来自模板、数据库还是外部注入，再决定是否继续在网关层补规则。
停止条件也需要提前写明：当继续重写会改变路径、查询串或页面语义时，就应停止，把剩余问题记录为遗留系统限制。把抓取量或请求量下降单独当作处理正确的证据并不充分，它也可能来自抓取预算变化、临时故障或外部链接减少。只有跳转链、主机名一致性和页面可渲染性同时成立，才说明这次 www 域名配置调整达到了可交付边界。
