域名修改之后，解析生效和收录更新并不会同步

解析生效和收录更新，这两件事从来就没同步过。域名修改完之后，你在本地刷新几十遍，浏览器已经能看到新站了，搜索引擎那边还拿着老域名的记录在爬。不是谁出了错，两套系统走的就是两套时间。改完第二天就去查 site，查不到就慌了神，这种我见得多。

域名修改的时间线和收录的时间线，压根不是一条

域名修改动的是 DNS 记录，这条线上跑的是 TTL。A 记录一改，权威 DNS 那边立刻就变了，可递归 DNS 手里还揣着旧值，得等 TTL 过期才肯再去问一次，这中间的迟钝期你按秒算是算不明白的。TTL 设成 600 秒，理论上十分钟全网转过来，实际上运营商那层缓存、公司出口那台老设备、你自己电脑里的解析缓存，一层一层叠上去，拖个半天一天都不稀奇嘛。

本地那关最容易骗自己。

我一般先 ipconfig /flushdns 刷一遍本机，Linux 上就 systemctl restart systemd-resolved，然后再 dig +short 你的域名 A。看到新 IP，只说明你这台机器通了，别人通不通还不知道呢。想看看公网那边什么状态，指定 DNS 再问一次：dig @8.8.8.8 你的域名 A。两个结果不一样，那就老实等呗，急也没别的办法。

DNS解析生效了，搜索引擎那边还没收到消息

搜索引擎那边是另一套节奏。它手里有一批待抓的 URL 排着队，什么时候轮到你那个页面？没人能打包票。真轮到了，抓到的如果是 301，它会记下来。可索引里把主域名换成新的，还得再走一遍流程。这中间隔着的不是几小时，是几天到几周不等。各家搜索引擎的抓取和更新节奏都不一样，具体多久，以官方说明和真实日志为准。我给不了准数啊。

页面这边早就搬完了，它那边还认老域名是正主，于是新域名迟迟不进索引，老域名反倒继续有流量，你会以为是好事，其实两边都在半空中。

两套钟表，各走各的。

所以头几天拿 site 结果当判决书，是最容易自己吓自己的。

域名修改最容易漏掉的一步：旧域名别急着下线

老域名解析一停，301 就断了。搜索引擎顺着老 URL 过来，只拿到一个连不上的地址，之前攒下的那些信号就跟着断在半路上，前面几个月攒的那点东西全白搭。我一般让老域名挂着 301 至少跑几个月，服务器上老的 vhost 留着，只写一条跳转规则，然后去 access log 里盯着：grep ” 301 ” access.log | tail -n 20。你会发现爬虫的 UA 还在这儿持续地来，说明这条路还活着；等来的次数肉眼可见地稀了，再考虑撤吧。

别慌着解绑。

有个小坑得提一句：老域名的证书别到期了不管。301 也是 HTTPS 请求，证书掉了直接报错，爬虫一样过不去，那时候你翻日志只看到握手失败，还得绕一圈才想起来是证书的事呢。

为什么有人改完当天就换过来了

这种例子确实有。别拿它当标准就好。站点页面少、抓取频次高、老域名本来就没多少索引量，搜索引擎很快就翻篇了；反过来，几万条 URL 的老站，队列里排着队呢，慢慢磨吧。你看到的「当天生效」，说白了，多半只是那条 DNS 恰好没赶上缓存，或者你查的本来就是自己浏览器里的结果，不代表索引真换了。

收录这边能做的事，实在有限

新域名的 sitemap 重新提交一遍，站内链接全量换成新域名（这步经常有人只改首页就收工，内页还指着老地址），能沟通的外链让站长换成新域名，后台要是有域名更换或者改版的提交入口就用上。老实说，剩下的就是等。没有哪个按钮按一下索引就跟着换，谁跟你说有，那他要么在卖东西，要么自己没操过盘。

急也急不来。

这段时间别顺手改别的。标题、结构、URL 规则一起动，出了波动你根本分不清是哪件事引起的，我吃过这亏，只能一条一条往回倒，多花了一倍的工夫。忍几天，手别痒，不然容易翻车。

跟域名修改绑在一起的几件杂事

备案信息要跟着变，流程和材料各省通信管理局要求不一样，以官方页面说明为准；企业邮箱的 MX、SPF 记录如果原来绑在老域名上，记得补上；CDN 的回源地址、统计代码里的站点标识、支付和登录的回调白名单，凡是写死域名的位置都得翻一遍，不然就是给自己埋雷。这些东西不出错的时候没人想起，一出错就是「网站能打开但登录不了」这种怪毛病，查起来还特别绕呢。

漏一个都够忙半天。

域名修改这件事，本质上是两条线一起开工：一条在 DNS 上跑，几个小时到一天；一条在搜索引擎的抓取队列里排队，几周都算正常。你手里能捏住的只有前一条，后一条只能把路铺好——301 挂着、链接换干净、sitemap 交上去，剩下的顺其自然就好。真发现收录掉了，先看 301 还在不在，再去日志里看爬虫还来不来，别第一反应就往「被惩罚」上想。