网站首选域名设置：怎样形成可复用检查清单？把判断项、执行项和验收项分开
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /382d93980a43.html
📄
网站首选域名设置：怎样形成可复用检查清单？把判断项、执行项和验收项分开
把“网站首选域名设置”做成可复用检查清单，核心不是记住某个后台开关，而是把每次改动的判断依据、执行动作和验收信号固定成三组条目：先确认首选域名的唯一形态，再检查所有入口是否指向它，最后用可观察的响应结果验收。清单要能脱离具体项目复用，就必须写成判断条件加预期结果，而不是写成某一次操作的步骤记录。
先明确清单的适用前提
这套清单适用于已经上线、有稳定内容的站点，在原有基础上做首选域名收敛或调整。它不适合还没有确定主域名的全新项目，也不适合把多个业务品牌强行合并到同一域名的情况。使用前先回答三个问题：当前有哪些域名或子域能访问同一套内容；这些入口是否各自被外部链接引用；业务上是否允许其中一个入口长期作为唯一规范地址。如果第二个问题的答案是“有大量外链指向非首选入口”，清单里就要额外加入重定向与链接更新的检查项，而不是只改一个配置就结束。
判断项：确定首选域名形态
首选域名要固定到协议、主机名和是否带 www 三个维度，最终只保留一种组合。可以用下面的检查项逐条确认：
- 协议：站点是否已有可用的 HTTPS 证书，HTTP 访问是否已能重定向到 HTTPS。证书覆盖的主机名要与选定形态一致。
- 主机名：带 www 与不带 www 哪个更符合现有外链和品牌使用习惯。选择依据是外链分布和用户认知，不是哪个看起来更短。
- 路径与参数：首选域名只约束协议和主机部分，不负责解决重复参数问题，后者要单独处理。
- 历史入口：是否还存在旧域名、测试域名或已停用子域仍能返回内容。
判断结果应当写成一句可执行的话，例如“首选形态为 https 加不带 www 的主机名”。这句话是后续所有检查项的基准，清单里不要留“视情况而定”这类无法验收的表述。
执行项：把各入口收敛到首选域名
执行阶段的关键是让非首选入口返回指向首选地址的重定向，而不是返回内容副本。可复用的做法是先列入口清单，再逐项验证：
- 列出所有能访问同一内容的协议与主机组合，包括 HTTP、HTTPS、带 www、不带 www、旧域名。
- 对每个非首选组合配置重定向，目标地址使用首选形态，并保持原路径和查询参数。
- 检查重定向是否为单跳。多跳重定向会增加解析成本，也更容易在后续改动中出错。
- 确认站内链接、站点地图和规范链接标签都使用首选形态，避免页面内部继续指向非首选地址。
这里要区分“可能原因”和“已定位的原因”。如果发现某个入口没有跳转，可能是配置未生效，也可能是缓存仍在返回旧响应，还可能是该入口由另一台服务器处理。不要直接断言是配置写错，应先看响应头再下结论。另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两项不能替代首选域名收敛本身。
验收信号：用响应结果确认收敛完成
验收不看后台是否保存成功，只看实际响应。可以固定检查以下信号：
- 请求非首选入口时，返回的响应状态指向首选地址，且目标路径与请求路径一致。
- 请求首选入口时，直接返回内容，不再发生跳转。
- 页面源码中的规范链接标签与首选形态一致。
- 站内可点击链接不再产生跨主机跳转。
如果上述信号都满足，说明收敛在技术层面完成。若其中一项不满足，回到对应的执行项修正，而不是重复修改首选域名配置。HTTPS 只说明传输层加密，不保证站点没有其他漏洞，也不构成排名保证，因此它只能作为协议维度的检查项，不能当作整份清单的验收终点。
把清单变成可复用模板
要让清单在下一个项目直接使用，把每条写成“检查对象 + 判断条件 + 预期结果”三列，例如“非首选主机 + 请求任意路径 + 返回指向首选主机的同路径响应”。执行时只替换检查对象，判断条件和预期结果保持不变。每次项目结束后，把实际发现的例外情况补进判断条件，而不是补进操作步骤，这样清单才会随着经验积累变得更可靠，而不是变成某个项目的操作记录。
下一步可以拿当前站点做一次入口盘点：用同一路径分别请求 HTTP、HTTPS、带 www 和不带 www 四种组合，记录每个响应的状态与目标地址，再对照上面的验收信号找出未收敛的入口。
