改版或迁移时,域名注册服务需要核对的核心是:域名的所有权、解析控制权、续费状态和迁移后的解析生效情况。换句话说,不是看网站页面是否打开,而是确认“这个域名归谁、由谁管、还能用多久、解析指向哪里”。任何一项不清楚,都可能在多人协作中造成返工,甚至出现旧站下线、新站打不开的局面。
域名注册服务负责的是域名本身的注册、续费和域名服务器(NS)设置;网站托管负责的是页面文件、数据库和服务器环境。改版或迁移时,常见误区是把“网站搬家”等同于“域名搬家”。实际上,多数情况下域名不需要转移注册商,只需要修改解析记录,把流量指向新服务器。
因此核对时要先确认迁移范围:
范围不同,核对清单不同。多人协作时,建议在任务开始前把范围写成一句话,避免有人改解析、有人改 DNS、有人动注册商,最后互相覆盖。
域名所有权以注册商后台的注册人信息为准。改版或迁移前,应确认当前域名在哪个注册商账号下、注册人邮箱是否可访问、账号是否开启了双重验证。如果域名由前任员工、外包公司或旧代理商持有,必须先完成账号交接,再谈迁移。
可执行的检查项:
验收信号是:团队中至少两人能独立登录注册商后台,且注册人邮箱可正常收信。只有一人掌握权限,属于高风险状态。
迁移前应导出当前 DNS 解析记录,包括 A 记录、CNAME 记录、MX 记录和 TXT 记录。MX 记录关系到企业邮箱,TXT 记录可能涉及域名验证,漏掉任何一条都可能导致邮件中断或服务验证失败。
TTL(生存时间)决定解析记录的缓存时长。迁移前可以适当调低 TTL,让新旧解析切换更快生效。但要注意,TTL 调低后需要等待原 TTL 过期才真正生效,不是立即改变。
检查项:
*),迁移后是否会误指向旧服务器。验收信号是:在迁移后的不同网络环境下查询域名,解析结果一致指向新目标,且邮件收发正常。
改版或迁移时,robots.txt 容易被误用。robots.txt 的抓取限制不等于可靠的索引移除:它只是告诉爬虫不要抓取某些路径,已经收录的页面仍可能出现在搜索结果中。如果目标是让旧页面退出索引,应使用合适的移除方式,而不是只改 robots.txt。
站点地图不保证收录。提交站点地图只是帮助搜索引擎发现 URL,是否收录还取决于页面质量、抓取情况和重复内容等因素。
HTTPS 不保证安全无漏洞或排名。迁移后应确认证书覆盖新域名、证书链完整、HTTP 能正确跳转到 HTTPS。不同搜索引擎对协议和跳转的处理支持情况须分别核查,不能假设一致。
检查项:
验收信号是:新站主要页面可被抓取,旧地址正确跳转,证书无浏览器警告。
多人协作最容易返工的环节是“谁改了什么没有记录”。建议在迁移前建立一张核对表,每项写明负责人、操作时间、操作前状态和操作后状态。解析记录、注册商权限、证书和跳转规则分别由不同人确认,避免同一人既操作又验收。
假设一个场景:团队把旧站迁移到新服务器,A 负责改解析,B 负责改跳转。如果 A 改了解析但 B 还没配置新站跳转,访问者可能看到默认页或错误页。这不是域名注册服务本身出错,而是交付顺序没有约定。适用条件是:只要涉及两人以上操作,就应约定“先配新站、再改解析、最后验跳转”的顺序。
下一步可以直接做一件事:打开域名注册商后台,导出当前解析记录和到期日,交给另一位同事复核。两份记录一致,再开始迁移操作。