www域名配置改版或迁移时应核对什么-交付前逐项检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /500c08ff78e7.html
📄
www域名配置改版或迁移时应核对什么-交付前逐项检查清单
改版或迁移时核对www域名配置，核心是确认三件事：用户和搜索引擎最终到达的主机名是否唯一且可访问，旧地址是否以正确方式指向新地址，站内资源与站点声明是否全部跟着新域名走。多人协作时，把这三件事拆成可勾选的检查项，每项写清查什么、怎么查、结果说明什么，就能减少返工。
先确定主域名：带www和不带www只能留一个
查什么：确定www.example.com与example.com哪个是规范主域名，另一个做301跳转。
怎么查：用命令行请求两个地址，观察状态码和Location响应头，例如curl -I http://example.com与curl -I https://www.example.com。再在浏览器分别打开，看地址栏最终停在哪个主机名。
结果说明什么：如果两个地址都返回200且内容相同，说明存在重复主机名，需要指定一个为主并让另一个301过去。如果跳转链出现A→B→C多跳，说明配置叠加，应压缩为一跳。如果跳转目标仍指向旧域名，迁移就没有完成。
核对协议与证书覆盖范围
查什么：HTTPS是否在带www和不带www两个主机名上都可用，证书是否覆盖实际使用的主机名。
怎么查：分别访问https://www.example.com和https://example.com，查看证书详情中的主题备用名称。再用curl -I确认HTTP是否301到HTTPS。
结果说明什么：证书只覆盖其中一个主机名时，另一个会出现证书警告，用户和抓取都可能中断。需要说明的是，HTTPS只保证传输加密，不代表站点没有漏洞，也不直接等于排名提升，它只是迁移时必须可用的基础条件。
检查站内引用是否全部指向新域名
查什么：导航链接、图片、脚本、样式表、canonical标签、结构化数据中的URL是否还残留旧域名。
怎么查：抓取若干代表性页面源码，搜索旧域名；对全站可做一次爬取，导出内部链接列表，筛选出指向旧主机名的条目。canonical要逐个模板抽查，确认指向的是当前规范主机名。
结果说明什么：如果canonical仍写旧域名，等于告诉搜索引擎规范版本在别处，新域名难以被当作主版本。如果图片或脚本仍从旧域名加载，旧域名一旦下线，页面就会出现资源缺失。多人协作时，这一项最容易因为模板未同步而漏掉。
处理旧地址与站点级声明
查什么：旧URL是否301到最接近的新URL，robots.txt与站点地图是否反映新结构。
怎么查：抽取旧站有代表性的URL，逐个请求，确认返回301且目标页面主题对应。检查robots.txt是否误屏蔽了新目录；检查站点地图中的URL是否为新域名。
结果说明什么：旧地址返回404或跳转到首页，会丢失原页面积累的信号，应尽量一对一映射。robots.txt的抓取限制不等于可靠的索引移除，屏蔽抓取和让页面从索引消失是两回事。站点地图不保证收录，它只是提交候选URL的渠道，最终是否收录由各搜索引擎自行判断，需要分别核查。
交付前的协作检查项
- 列出全部需要改的主机名与协议组合，标注期望状态码和跳转目标，作为验收依据。
- 指定一人负责DNS与证书，一人负责应用层跳转，一人负责内容与模板，避免同一项被重复改或无人改。
- 上线后按清单逐项请求验证，记录实际状态码与跳转链，与预期不一致的当场回退或修复。
- 保留旧域名解析至少一个迁移周期，确认无残留流量和引用后再评估是否停用。
下一步：把上面每一项做成一张带“预期结果”和“实际结果”两列的表格，在迁移当天由执行人填写、由另一人复核，未通过的项目不进入下一阶段。
