服务器到期、机房线路变差、业务需要扩容，都会让迁移变成迟早要面对的事。迁移本身不难，难的是迁移期间搜索蜘蛛的抓取表现：有的站点几天就恢复，有的站点抓取量掉了两三周还回不来。差别通常不在运气，而在准备工作做得够不够细。
迁移为什么会影响到抓取
蜘蛛访问你的站点，依赖的是 DNS 解析出来的 IP。IP 一变，对蜘蛛来说就是一个新地址，它会重新评估：响应速度如何、是否稳定、内容是否与原来一致。这个过程里，任何一项变差，抓取频次都可能被压低。
- DNS 生效时间：TTL 设置过长，旧 IP 会在缓存里停留很久，部分蜘蛛仍去访问旧机器。
- 首字节时间：新机房线路差、带宽不足，TTFB 明显变长，抓取队列会往后排。
- 环境不一致：新服务器少了某个模块、伪静态规则没配好，出现大量 5xx 或 404。
- 证书与端口：HTTPS 证书没同步、只开了 80 没开 443，访问直接失败。
- 防护策略：新机器默认开了防火墙或 CDN 挑战，把蜘蛛挡在门外。
迁移前要准备好的几件事
- 把新机器环境按老机器的清单逐项对齐：Web 服务版本、运行环境、重写规则、字符集、时区。
- 提前把 DNS 的 TTL 调小（例如 300 秒），至少提前一天，让旧缓存自然过期。
- 确认证书可以正常签发和续期，不要等到切换当天才发现验证失败。
- 准备好回滚方案：旧机器至少保留一周不停机、不释放 IP。
- 备份数据库与站点文件，并实际验证备份能还原，而不是只打了个包。
切换当天的执行顺序
- 先用临时域名或绑定 hosts 的方式把新机器跑通，确认页面、图片、接口都正常。
- 在低访问时段切换 DNS，并记录切换时间点，方便后面比对日志。
- 切换后立即检查首页、栏目页、详情页在移动端与桌面端返回的状态码。
- 确认 robots.txt 没有被新环境覆盖成默认版本，站点地图能正常访问。
- 观察服务器日志里蜘蛛的访问是否正常，有没有出现 403、503 或连接超时。
迁移后的一段观察期
切换完成不等于结束。接下来几天重点看三件事：抓取量是否维持在原有水平、状态码中 5xx 的比例、以及页面响应时间。如果抓取明显下滑，先排查线路和防护规则，再看是不是 DNS 还没有完全生效。
有些情况需要主动推动一下：确认站点地图与关键入口地址在新环境下可访问，让 URL 发现渠道重新认识新环境。但要清楚，主动提交只是帮助发现，并不等于收录，也不该靠短时间大量推送来“催”。
迁移期间最忌讳两件事：一边切换一边改版，以及新旧两套环境同时对外提供不同内容。前者让问题没法定位，后者容易造成重复与混乱。
容易被忽略的细节
- 旧机器的定时任务、计划脚本还在跑，生成的文件和新机器互相覆盖。
- CDN 缓存里还留着旧内容，切换后出现新旧混杂。
- 邮件、短信等第三方服务白名单没加新 IP，导致通知失效。
- 日志目录权限变了，写不进去，出问题后没有记录可查。
把迁移当作一次常规的运维动作，而不是一次冒险：清单化准备、按顺序切换、留足回滚余地、事后认真看几天日志。抓取恢复得快不快，往往就取决于这些看起来很琐碎的准备。