网站迁移后收录下降怎么办？服务器响应、状态码与URL一致性检查

换服务器、换域名、换程序、改 URL 结构——这些迁移动作做完，最让人揪心的就是"收录掉了"。原来在搜索引擎里能搜到的页面，迁移后不见了，或者排名大幅下滑。收录下降的原因往往不止一个：可能是旧 URL 没有正确 301 到新地址，可能是迁移后服务器变慢导致抓取失败，可能是状态码异常，也可能是 robots.txt、sitemap 或 canonical 出了问题。任何一个环节出错，都会让搜索引擎"看不懂"你的站点。

这篇文章给出一套系统的检查清单：从 URL 一致性、301 规则、响应速度和状态码，到 robots/sitemap、canonical、内链，逐项排查，并给出恢复策略。读完你能对照清单给自己的迁移做体检，找出收录下降的具体原因并对症处理，而不是盲目重提交、反复折腾。

一、迁移后收录下降的常见原因

先把可能的原因列全，再逐项排查。

关键点：迁移导致的收录下降大多是"可修复的技术问题"，只要定位准、处理及时，收录通常能在一段时间内恢复。真正难挽回的是"长期 404 且没有 301"这类权重已经流失的情况，所以迁移后要尽快检查。

二、第一步：核对 URL 一致性

迁移后第一件事，是确认"新旧 URL 的对应关系是否成立"。同一个页面，迁移后能不能正确到达、地址是否唯一。

# 检查旧 URL 是否 301 到新 URL（示例）
curl -I http://old.example.com/old-page
# 期望：HTTP/1.1 301 Moved Permanently + Location: https://new.example.com/new-page

# 跟随跳转看最终落地是否正常
curl -I -L http://old.example.com/old-page | grep -iE '^(HTTP|Location)'

# 批量检查一批旧 URL（从旧 sitemap 或日志里取）
while read -r url; do
  code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
  loc=$(curl -s -o /dev/null -w '%{redirect_url}' "$url")
  echo "$code  $url  ->  $loc"
done < old_urls.txt

要确认三件事：旧 URL 返回 301（不是 302，更不是 404）、Location 指向正确的新 URL、最终落地页返回 200。任何一条不满足都要修。特别注意大小写、结尾斜杠、查询参数这些细节，搜索引擎把它们视为可能不同的地址。

如果迁移涉及大小写或路径结构变化，要用 rewrite 规则兜住：

# 把旧程序路径批量重定向到新路径，注意用 permanent(301)
server {
    listen 443 ssl http2;
    server_name old.example.com;

    # 旧文章路径 /post/xxx 迁到新域 /articles/xxx
    rewrite ^/post/(.*)$ https://new.example.com/articles/$1 permanent;
    # 兜底：其余路径整站 301
    location / {
        return 301 https://new.example.com$request_uri;
    }
}

风险提示：改 Nginx 配置前备份，改完 nginx -t 验证再 reload；批量 301 规则上线前，先小范围抽样验证，确认没有把正常页面也跳走。

三、第二步：检查服务器响应与状态码

搜索引擎爬虫对"响应慢"和"错误多"很敏感。迁移后若新服务器性能不如旧服务器，或配置有问题，会直接影响抓取和收录。

# 用爬虫 UA 测响应情况，对比迁移前后
curl -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  -o /dev/null -s -w 'code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://new.example.com/

# 从日志统计爬虫拿到的状态码分布（重点看 5xx/404 比例）
sudo awk -F'"' '/Googlebot|bingbot|Baiduspider/ {
  split($2,a," "); print a[2]
}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# 抓取失败（5xx/超时）的爬虫请求明细
sudo awk -F'"' '/Googlebot|bingbot|Baiduspider/ && $0 ~ / [5][0-9][0-9] /' \
  /var/log/nginx/access.log | tail -20

判断标准：爬虫请求应该以 200 为主；如果 5xx 或超时明显偏多，说明服务器扛不住爬虫或后端有问题，需要优化（参考第 062、069 篇）。如果旧 URL 大量返回 404 而没有 301，说明重定向没覆盖全，权重正在流失。

同时检查是否有跳转循环（curl -I -L 看跳转链）、HTTPS 证书是否匹配所有域名（含 www 和裸域）、DNS 是否已全网生效。这些都会导致部分爬虫抓取失败。

四、第三步：检查 robots.txt、sitemap 与 canonical

这三项经常在迁移时被忽略，但影响很大。

robots.txt：迁移后要确认没写错。最致命的是不小心 Disallow: / 把全站禁了。

# 拉取新站 robots.txt 检查
curl -s https://new.example.com/robots.txt

# 迁移后 robots.txt 示例
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /search?

Sitemap: https://new.example.com/sitemap.xml

sitemap：里面的地址必须是新域名、新 URL，且返回 200。仍指向旧域名的 sitemap 会把爬虫引到错误的地方。

# 检查 sitemap 里的 URL 是否都可达
curl -s https://new.example.com/sitemap.xml | grep -oE '[^<]+' | sed 's///' | head -20

canonical：每个页面的 必须指向自己（正确的新 URL），不能残留旧域名。canonical 指向旧域会导致搜索引擎认为"真正的页面在旧域"，把权重传错地方。

# 检查页面 canonical 标签
curl -s https://new.example.com/new-page | grep -i 'rel="canonical"'

还要注意 robots meta 标签（）别遗留 noindex。迁移时复制模板最容易把测试环境的 noindex 带到生产。

五、第四步：检查内链与站内跳转

站内链接如果还指向旧地址，会形成"爬虫跟着旧链走 → 遇到 301/404"，既浪费抓取预算，也可能让新页面得不到发现。迁移后要做全站链接替换或依赖 301 兜底。

# 找出页面里仍指向旧域名的链接
curl -s https://new.example.com/ | grep -oE 'https?://old\.example\.com[^"]*' | head

# 抽查若干页面的内部链接是否指向新域
for p in / /about /articles; do
  echo "== $p =="
  curl -s "https://new.example.com$p" | grep -oE 'href="[^"]*"' | grep -c 'new\.example\.com'
done

最佳实践是：站内链接全部改成新地址（不留旧链），旧地址靠 301 兜底外链和用户书签。这样爬虫走站内永远是 200 的新地址，效率最高。

六、恢复策略与提交

排查并修复问题后，要让搜索引擎尽快感知，加速恢复。

第一，到各搜索引擎的站长平台提交新站。主流搜索引擎都提供"站点验证 + 提交 sitemap + 地址变更"的工具。如果换了域名，用"地址变更/改版工具"告知迁移，这是加速收录迁移最直接的方式。

第二，提交新的 sitemap。确保 sitemap 只包含新地址、返回 200 的有效页面，并在 robots.txt 里声明位置。

第三，主动请求抓取。对重要页面可以用站长平台的"提交 URL/抓取诊断"功能，让爬虫尽快来抓。

第四，监控爬虫抓取日志（就是本文第三节的命令），观察修复后爬虫的 200 比例是否上升、5xx/404 是否下降。这是判断恢复效果的直接证据。

第五，保持耐心。收录恢复需要时间，取决于站点规模和搜索引擎的重抓节奏，通常不是改完立刻见效。迁移期间避免再做其他大幅改动，减少变量。

一个额外提醒：迁移最好在流量低峰期进行，并保留旧服务器/旧域名一段时间（至少数周到数月）以承接 301，别迁移完就把旧站关掉，那样外链和用户书签会全部失效。

七、迁移前后检查清单

常见问题

Q：旧 URL 用 302 跳转可以吗？
不行。迁移要用 301，表示"永久移动"，才会传递权重。302 是临时跳转，搜索引擎会保留旧 URL 索引、不传权重，收录迁移会很慢甚至失败。

Q：改完 301 收录什么时候恢复？
取决于站点规模和抓取节奏，通常需要数天到数周。可以用爬虫日志观察 200 比例上升、404 下降来判断恢复进展，别期待立刻见效。

Q：canonical 还写着旧域名会怎样？
搜索引擎会认为真正的页面在旧域，把权重和收录信号指向旧域，导致新域收录下降。必须把 canonical 改成新地址（即页面自身 URL）。

Q：robots.txt 误 Disallow 全站怎么快速发现？
直接 curl https://新站/robots.txt 看有没有 Disallow: /。也可以用站长平台的 robots 测试工具验证某 URL 是否被禁。发现后立即修正并重新提交。

Q：旧服务器迁移后要保留多久？
建议尽量久（数周到数月），用于承接 301 和外链。贸然关停旧站会让旧外链、用户书签全部指向失效地址，损失难以挽回。

总结

迁移后收录下降大多是技术问题，常见原因有：旧 URL 未 301、响应变慢、状态码异常、robots/sitemap 出错、canonical 指向旧域、内链断裂、DNS 或证书问题。

第一优先检查 URL 一致性：旧 URL 必须 301 到新 URL、Location 正确、落地页 200，注意大小写、结尾斜杠和查询参数。

再检查服务器响应与状态码：用爬虫 UA 实测 TTFB，从日志统计爬虫 5xx/404 比例，排查跳转循环、证书和 DNS。

别忘了 robots.txt（防误 Disallow 全站）、sitemap（新地址且可达）、canonical（指向自身）和站内链接（全指向新域），以及遗留的 noindex。

恢复策略：站长平台提交新站与 sitemap、使用地址变更工具、主动请求抓取、持续监控爬虫日志；旧站保留足够长时间承接跳转，迁移后避免再做大幅改动。