迁移掉抓取，往往不是切换那一秒的问题

蜘蛛对入口页的信任，来自一段时间的重复抓取记录：同一个 IP、相近的响应速度、稳定的状态码和内容结构。迁移会一次性改动其中好几个变量，蜘蛛的调度自然变得保守，抓取量短期下滑属于正常现象。真正要防的，是下滑之后长期回不来——那通常不是迁移本身，而是迁移过程中把别的东西也弄坏了。

先分清你属于哪种迁移

• 只换服务器，公网 IP 不变：影响最小，通常是同机房内换机。
• 换服务器也换 IP：最常见，需要走完整流程。
• 换 IP 且换机房或地区：影响最大，蜘蛛到新 IP 的网络路径变了，延迟和稳定性都要重新验证。
• 换域名或换二级域：这已经不是迁移，而是重建，入口页积累的抓取记录基本清零。

前三类可以按迁移来处理，第四类请按新站上线来规划预期。

迁移前：把清单和日志先收好

迁移最怕的是事后对不上账。切换之前，至少整理出四样东西：

• 入口页清单：URL、所用模板、上次更新时间。
• 目标页清单：每个入口页分别指向哪些目标页。
• 最近 7 到 14 天的访问日志：蜘蛛抓取总量、状态码分布、来访最频繁的 IP 段。
• 当前 DNS 解析的 TTL 值。

建议提前 24 到 48 小时把 TTL 调低，比如降到 300 秒甚至更短。TTL 决定了旧解析还能存活多久，也决定了你的切换窗口有多宽。很多人忽略这一步，结果切完之后旧 IP 上的请求还会持续很久，日志看起来像是"蜘蛛没跟着走"，其实只是缓存还没过期。

并行期：新环境先跑通，再动解析

在改 DNS 之前，让新服务器先能正常对外服务，用临时域名或本地 hosts 去访问，逐项确认：

• 入口页返回 200，不是重定向链条或软 404。
• HTTPS 证书链完整，没有中间证书缺失，不会在部分客户端报错。
• 首字节时间与旧环境接近，没有明显变慢。
• 页面内容与旧站基本一致，入口页到目标页的链接仍然可点。
• 服务器没有对蜘蛛 UA 做额外拦截，也没有被安全策略挡住。

迁移期间最容易犯的错，是顺手把模板也改了。一次只动一个变量，出问题时才知道该回退哪一步。

切换：能分批就别一次切完

如果入口页数量多，可以按模板或按目录分批切换，先切一批观察一两天。这样做的好处是，一旦新环境有问题，受影响的只是部分入口页，还能对照旧环境的日志判断问题出在哪。切完之后，重点看旧 IP 上是否还有残留请求，以及新 IP 是否开始出现蜘蛛访问。

换域名的情况要单独看

301 能把一部分信号带到新域名，但入口页本身的抓取节奏是从零开始的。旧域名如果还能保留，建议继续在线一段时间并保持可访问，而不是切完立刻关停。对新域名的抓取量，前期不要用旧站的数据去对标。

迁移后重点观察什么

• 蜘蛛抓取总量是否在合理时间内回到迁移前水平。
• 状态码里是否出现 403、404、5xx 增多的迹象。
• 来访 IP 段是否与迁移前一致，有没有出现陌生来源。
• 目标页是否还被持续访问，还是只剩入口页在被抓。
• 服务器负载与响应时间是否稳定，没有因为蜘蛛集中来访而抖动。

留一条回滚的路

旧环境不要在新环境稳定之前就关掉或释放 IP，建议至少保留一到两周。DNS 回切本身很快，但如果旧服务器已经下线、证书已过期、入口页文件已被覆盖，回滚就无从谈起。回滚预案里要写清楚：什么指标触发回滚、由谁操作、回切后多久观察一次。

几个常见错误

• TTL 没提前调低，切完发现旧 IP 还在持续接收请求。
• 迁移和改模板、改链接结构同时进行，出问题无法定位。
• 新环境上线后没有验证证书和重定向，蜘蛛拿到的是异常页面。
• 旧环境立即销毁，失去对照数据和回退余地。
• 迁移后只看抓取总量，不看状态码和响应时间。

小结

蜘蛛池迁移的核心不是"搬得快"，而是变量一次只改一个、每一步都有对照。把清单和日志准备好、把 TTL 提前压低、让新环境先跑通再切解析、切完至少保留两周回滚窗口，抓取量的波动通常是可以接受的；反过来，图省事一次性全改，才是真正难收拾的局面。