两周之内，收录从 1800 页掉到 400 页。这是一家做工业阀门出口的制造业 B2B 官网在 2026 年 8 月初完成 HTTP 迁 HTTPS 之后的真实曲线——网站本身打得开，询盘表单也正常，但自然搜索流量掉了七成，团队第一反应是把锅甩给内容质量，排查了一周才发现真正的病灶在 301 重定向链条上。这篇文章把整个排查过程、断点位置、Nginx 修复配置和收录恢复时间线完整复盘一遍，末尾附一份可以直接照着执行的迁移检查清单。

一、事故现场：迁移后第二天收录开始跳水

先交代背景。这家公司官网大约 1900 个页面，其中三分之二是产品详情页和参数表，长期靠 Google 自然搜索带来海外询盘，做外贸的制造业同行都懂这条路对获客意味着什么。7 月 28 日的 GSC 覆盖率报告显示「已编入索引」1826 页，属于健康的稳态。8 月 3 日凌晨 2 点，运维把证书装好、Nginx 重载，全站切到 HTTPS，当时 curl 测了首页能 302 过去，浏览器打开也正常，就在工作群里宣布迁移完成。

8 月 5 日收录掉到 1710，有人说是波动。8 月 9 日掉到 905。8 月 13 日覆盖率报告里「已编入索引」只剩 398，「重定向错误」一项暴增到 1143。这个数字一出来，方向就清楚了：不是内容问题，是爬虫在重定向链条上迷路了。

收录掉了但排名没立刻掉的假象，是索引缓冲造成的。 已索引页面在缓存期内还能参与排序，等谷歌下一次全量重抓、发现页面拿不到终态，排名才会跟着塌。所以看到收录下降时越早动手，恢复越快——这也是为什么做网站优化的人把「迁移后 72 小时」当成观察窗口。

二、排查第一步：用 curl 把重定向链条走一遍

问题定位不需要什么高级工具，一条 curl 命令就能还原爬虫视角。当时的操作是拿产品详情页、栏目页、sitemap 里的随机 URL 各测一轮，跟踪完整跳转：

# 前置条件：本机装有 curl 7.68+（Ubuntu 20.04 自带版本即可），无其他依赖
# -sI 只取响应头，-L 跟随重定向，丢弃正文只看每一跳的状态码和 Location
curl -sIL "http://example.com/product/valve-gate-1200" | grep -iE "HTTP/|location"

# 输出还原出来是这样一条链，共四跳才到终态：
# 第 1 跳：http://example.com/product/xxx  → 302 到 http://www.example.com/product/xxx
# 第 2 跳：http://www.example.com/product/xxx  → 302 到 https://example.com/product/xxx
# 第 3 跳：https://example.com/product/xxx  → 301 到 https://www.example.com/product/xxx
# 第 4 跳：https://www.example.com/product/xxx  → 200 OK

四跳。更糟的是第一跳用的是 302 临时重定向，第二跳协议升级用的还是 302。把这条链画出来，断点在哪里一目了然：

flowchart LR
    A[爬虫请求 http://example.com] -->|第1跳 302| B[http://www.example.com]
    B -->|第2跳 302| C[https://example.com]
    C -->|第3跳 301| D[https://www.example.com]
    D -->|页面内 canonical 指向 http 副本| E[索引信号矛盾]

对照官方文档的说法，搜索引擎期望的是协议迁移应该用单次 301 直达 https 终态。链上每多一跳，抓取预算（crawl budget）就多消耗一份，谷歌抓取器对单链路的跳数有上限，超长的链条直接被标成「重定向错误」——覆盖率报告里那 1143 个错误就是这么来的。老站历史上叠过好几层改版规则，运维这次迁移没有清理旧规则，而是往 server 块里追加了两条新的 rewrite，典型的规则叠罗汉。

三、两个连带断点：内链残留 http 与 Mixed Content

链条本身修好之前，还有两个次生问题要同步记下来，它们让修复变得更急迫。

内链残留 http。 抽查了 20 个页面源码，发现模板里面包屑、侧边栏推荐位写死了 http:// 开头的完整域名地址，站内爬行时每条内链都要重走一遍那条四跳链。谷歌爬虫站内发现新页面的效率被砍掉一大截，这直接拖慢收录恢复。

Mixed Content 被浏览器拦截。 产品参数页里几张设备实拍图引用的是 http:// 的老 CDN 地址，Chrome 控制台一片 blocked: mixed-content 报错，图片全部不加载。图片加载失败对 B2B 官网是双重伤害：页面渲染不完整影响使用体验，同时这些图片在图片搜索里原本是有排名的，等于又丢一条流量入口。复制几个典型 URL 到浏览器地址栏手动跑一遍，加上 F12 面板筛 console，十分钟就能把这类问题全暴露出来。

原理与机制剖析：收录为什么会腰斩

把现象翻译成搜索引擎的工作机制，收录腰斩其实是三个机制叠加的结果。

抓取预算的重新分配。 每个站点每天分到的抓取次数有限。迁移前爬虫抓 1 次就能拿到 1 个 200 页面；迁移后同一条 URL 要走三到四跳才到终态，单页抓取成本翻了几倍，谷歌的策略是先降低整站抓取频率——于是已收录页面迟迟得不到重新验证，新页面更是进不了队列。

重定向信号的衰减。 302 对搜索引擎的含义是「临时搬走，旧 URL 仍参与排名」，301 才是「永久搬家，权重转移」。这条链里协议升级用了 302，谷歌会把 http 和 https 当成两个仍独立存在的站点来对待，权威信号无法归并到新协议域名上，旧索引里的页面又被新协议的重复内容稀释，索引器权衡之下大批量移除了「拿不到终态」的记录。

canonical 与内链的矛盾信号。 页面 canonical 标签写着 https，站内链接却指向 http，抓取器收到两套互相打架的规范化信号。规范化（canonicalization）出错的典型后果就是索引不确定性——这正是 SEO 事故里最难排查的一类，因为它不出报错日志，只体现在覆盖率报告的趋势图上。

四、修复：Nginx 单跳 301 与 HSTS 配置

定位清楚了，修复方案就一条主线：让任意入口 URL 都在一次跳转内到达 https 终态。修改后的完整 Nginx 配置如下：

# 运行环境：Nginx 1.24.0（Ubuntu 22.04 通过 apt 安装）
# 证书：Let's Encrypt 通配符证书，certbot 2.6.0 签发，含 example.com 与 www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    # 80 端口只做一件事：单跳 return 到 https 终态
    # 禁止在这里再做任何 rewrite 叠加，return 直接终止本次请求
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # 裸域名统一 301 到 www 终态，依然只跳一次
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
    # HSTS：首次上线先给短周期观察一周，稳定后再提到 max-age=31536000
    # always 参数保证 4xx/5xx 响应也带上这个头
    add_header Strict-Transport-Security "max-age=86400" always;
    # 模板内链全部改成协议相对或以 https 开头的完整地址，杜绝站内再走 80 端口
    # （这一步在构建产物里全局替换，不在 Nginx 层兜底）
    root /var/www/site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

return 和 rewrite 的差别在这里值得说一句：return 301 直接返回响应，不再进入后续匹配流程；而 rewrite 只是改写 URI，还会继续走 location 匹配，旧的叠加规则一旦没删干净就容易出现意外跳转。这次修复把三个 server 块里所有历史 rewrite 规则全部删掉，只留 return。

改完的验证命令和之前一样，要求任意入口 URL 走 curl -sIL 输出里只出现一次 301 加一次 200。HSTS 按注释里的节奏先压到一天周期，观察一周无回滚诉求后提到一年——HSTS 是浏览器侧的强制策略，一旦全量下发且配置有错，用户端会缓存住错误结果，所以第一次上 HSTS 保守一点不吃亏。

五、GSC 操作：地址变更工具与 sitemap 重新提交

服务器侧修完只是半个动作，剩下半个要在 GSC 里完成，否则重新抓取的触发要等搜索引擎自己排期。

地址变更工具的用法有前置条件：新旧两份资源都必须在 GSC 完成验证（这次迁移后 http 和 https、带 www 和不带 www 共四份资源都要有），且新资源上 301 已生效。操作路径是进入旧资源 http://www.example.com，左侧「设置」里找到「地址变更」，选择新资源 https://www.example.com 后提交。协议变更严格说属于「网站移动」里的同域名场景，官方文档建议这类迁移同样走这个工具——提交之后旧资源的抓取请求会优先导向验证新地址，实测比干等快得多。

sitemap 的处理分三步：先在旧资源里确认旧 sitemap 的 301 指向新地址；再在新资源提交 https://www.example.com/sitemap.xml；旧 sitemap 保留 30 天，等覆盖率报告稳定后再删除。中间还发现 robots.txt 里的 Sitemap: 行还写着 http 地址，一并改掉——这个文件经常是迁移遗漏的角落，顺手把 Disallow 规则复核了一遍，确认没有把新协议路径误伤。

修复后第 3 天用「网址检查」工具对 50 个重点页面做了实时验证，全部返回「网址是 https://www.example.com/xxx 的备用网址」，说明规范化信号已经归一。

六、收录恢复时间线与前后对比

修复是 8 月 18 日上线的，之后的时间线用 GSC 覆盖率报告抽样记录如下：

timeline
    title 收录恢复时间线（GSC 覆盖率报告，已编入索引页数）
    8月3日 : 全站切换 HTTPS : 收录 1826
    8月13日 : 断点未修复，跌入低谷 : 收录 398
    8月20日 : Nginx 单跳修复 + 地址变更工具提交 : 收录 645
    9月3日 : sitemap 重新抓取完成 : 收录 1432
    9月24日 : 基本恢复迁移前水平 : 收录 1791

覆盖率报告各分项的前后对比更能说明问题所在：

「重定向错误」从 1143 归位到 3 是链条修复的直接证据，「已编入索引」回到迁移前水平的 98% 左右，剩下几十页的差额是年度旧新闻页下架导致的正常损耗。自然搜索流量 9 月中旬回到迁移前区间，图片搜索流量因为 Mixed Content 修复加 CDN 域名替换，10 月初才补齐。

七、迁移检查清单

把这次踩过的坑浓缩成一张可执行的表，做 HTTP→HTTPS 迁移时逐行打勾：

回头复盘，这次事故的根因不是技术难度，而是迁移被当成「装个证书」的运维操作，没有当成一次需要 SEO 视角参与的网站优化工程。凡是涉及 URL 结构、协议、域名变更的动作，都应该在上线前用清单里的前五项做预演，上线后 72 小时盯住 GSC 覆盖率报告——收录曲线是最诚实的验收标准。等收录和排名重新站稳之后，再往生成式引擎优化（Generative Engine Optimization, GEO）方向做内容布局，地基才算真正打牢了。如果你的迁移也遇到过覆盖率报告异常，欢迎在评论区贴出你的报告截图和排查思路，一起对表。

参考与延伸

• 谷歌搜索中心：重定向与 Google 搜索（301 与抓取行为官方说明）—— https://developers.google.com/search/docs/crawling-indexing/site-and-page-redirects
• Google Search Console 帮助：网站地址变更工具使用条件与流程—— https://support.google.com/webmasters/answer/9370220
• Nginx 官方文档：ngx_http_rewrite_module 的 return 指令—— https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return
• MDN Web Docs：混合内容（Mixed Content）的拦截规则—— https://developer.mozilla.org/zh-CN/docs/Web/Security/Mixed_content

关键词：SEO、网站优化、301重定向、HTTPS迁移、Google Search Console、技术SEO、制造业官网收录