服務器迁移、換 IP、換 CDN 或換主机商，表面上是运维動作，但蜘蛛看到的是另一回事：同一個 URL，解析结果變了、响應头變了、證书變了。如果切換過程粗糙，抓取日誌里就會出現连接超时、SSL 错誤、404 或 503。本文按迁移前、切換时、切換後三個阶段，整理一份偏站点运营视角的检查清單。
迁移前：把 TTL 和舊环境安排好
DNS 的 TTL 决定了解析记錄在各地递归服務器里能缓存多久。如果 TTL 是 24 小时，切換後部分蜘蛛可能仍訪問舊 IP，舊服務器一旦關机，抓取就會失敗。
- 提前 24 到 48 小时把主要记錄（A、AAAA、CNAME）的 TTL 調低，例如 300 秒或 600 秒，给切換留出缓冲。
- 確認新环境已经能完整响應：首頁、栏目頁、詳情頁、robots.txt、sitemap.xml 都能正常返回 200。
- 如果站点啟用 HTTPS，先在新服務器部署證书，检查證书鏈是否完整，避免部分客戶端报错。
- 不要只改根域名。带 www、不带 www、舊域名、移動端域名，都要列出来逐項確認。
切換时：用真實請求驗證，而不是只看控制台
DNS 控制台顯示“已生效”，不代表所有地区、所有递归都立刻拿到新记錄。切換窗口内，建议用多種方式驗證。
检查解析與响應头
- 用不同地区的公共 DNS 查询，確認返回的是新 IP 或新 CNAME。
- 對重要 URL 發 HEAD 或 GET 請求，看狀態碼、重定向鏈、响應時間，別只看浏览器缓存後的頁面。
- 检查 HTTPS 是否仍指向正确證书，尤其是使用 CDN 时，回源协议和證书容易配错。
驗證蜘蛛入口
robots.txt、XML 站点地图和 HTML 站点地图，是蜘蛛了解站点结构的重要入口。切換後逐項訪問：robots.txt 是否 200、里面是否誤寫了 Disallow、sitemap 是否指向新域名、頁面里的 canonical 和 hreflang 是否還指向舊地址。如果迁移伴随域名更換，舊 URL 到新 URL 的 301 要提前准备，並保持至少數月。
切換当天不建议同时做大規模改版、改 URL 结构或改 robots.txt。多個變量叠在一起，日誌會很难判断問题来自哪里。
切換後：用日誌和狀態碼收尾
解析生效後，观察服務器日誌和 CDN 日誌。重点看蜘蛛請求的狀態碼分布：如果 5xx 明顯上升，優先查新环境资源、資料库连接和防火墙；如果 404 上升，查是不是舊 URL 没有跳轉；如果 403 上升，查是否誤拦了蜘蛛 IP 或 UA。
- 保留舊服務器一段時間，只做 301 跳轉或静態响應，不要立刻释放 IP。
- 检查頁面内资源：CSS、JS、图片、字体是否仍引用舊域名，避免混合内容或額外重定向。
- 如果使用 CDN，確認缓存策略没有把舊頁面長期缓存，必要时刷新關键 URL。
- 观察抓取频次和收錄量變化，给搜尋引擎几周時間重新爬取和更新索引。
几個常见坑
- 只改 A 记錄，忘了 MX、CNAME 或子域名，導致部分功能不可用。
- 新服務器防火墙預設拒绝所有流量，蜘蛛請求被挡，但监控只看了本机。
- CDN 回源仍指向舊 IP，表面訪問正常，實际回源失敗或回源到舊站。
- HTTPS 證书只配了主域名，www 或子域名證书不匹配。
- 舊站直接關机，没有 301，也没有保留可訪問的過渡頁。
迁移不是一次性動作。把 DNS、證书、回源、跳轉和日誌观察拆成清單，逐項確認，比事後排查更省時間。蜘蛛的抓取窗口不會等站点准备好，但一個平稳的切換過程，可以让它少踩几個坑。