先把当时的情况摆出来。迁移时 301 只写在应用路由里，GET 请求正常跳新域，HEAD 请求直接落到默认 404。蜘蛛先用 HEAD 探活，一批内页被判死链，收录掉得比预期快。
把日志和配置对完，能解释这个现象的基本就这几处。跳转在应用层处理，HEAD 没进同一个中间件。还有一种是Nginx 只对 GET 配了改写规则。
不容易想到的是，边缘只缓存了 GET 的 301。还有一种情况，监控只测 GET 的状态码。
上来先用 HEAD 看状态码
curl -sI https://old.example.com/post/1 | head -1然后用 GET 做对比
curl -s -o /dev/null -w '%{http_code}\n' https://old.example.com/post/1再往下在 Nginx 层统一做 301
return 301 https://new.example.com$request_uri;复
查中间停过一次，把已经改的东西回滚干净，再重新来一遍。
同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
怎么算真的好了，看的是同一批现象。统一到 Nginx 后 HEAD 与 GET 都返回 301，蜘蛛探活不再落空，新域收录在五周内补回到迁移前的水平。
提醒一点。HEAD 和 GET 必须共用同一条跳转规则，否则探活通过、收录照样掉。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。