HTTP 迁 HTTPS 掉收录的排查清单：301 链条断点与站点迁移的完整复盘
适用读者：负责制造业或 B2B 企业官网运维的开发者；正在 Google Search Console（谷歌站长平台，下称 GSC）覆盖率报告里看到收录量腰斩、需要定位 301 重定向断点的人；准备做 HTTP→HTTPS 全站迁移、想提前避坑的技术负责人。
两周之内，收录从 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 跟随重定向，丢弃正文只看每一跳的状态码和 Locationcurl-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。把这条链画出来，断点在哪里一目了然：
对照官方文档的说法，搜索引擎期望的是协议迁移应该用单次 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 要走三到四跳才到终态，单页抓取成本翻了几倍，谷歌的策略是先降低整站抓取频率——于是已收录页面迟迟得不到重新验证，新页面更是进不了队列。
这组机制在 GSC 的爬取统计报告（旧版「抓取」报告，新版并入「网页索引编制」报告的「抓取统计」卡片）里能直接看到量化证据。以下是迁移前后每日抓取请求量的示意数据（示意数据：原文未留存 GSC 爬取统计截图，以下数值为基于收录曲线反推的合理估算区间，仅供理解量级）：
| 时间点 | 每日抓取请求量（示意） | 已编入索引页数 | 说明 |
|---|---|---|---|
| 迁移前（7 月 28 日） | 约 8000 次/日 | 1826 | 稳态，抓取效率高，单次请求即拿到 200 |
| 迁移后第 3 天（8 月 6 日） | 约 4500 次/日 | 1710 | 抓取量开始下滑，爬虫在重定向链上消耗预算 |
| 断点未修复（8 月 13 日） | 约 2000 次/日 | 398 | 跌至谷底，大量请求被 302/301 链消耗，有效抓取骤减 |
| 修复后第 6 周（9 月 24 日） | 约 7500 次/日 | 1791 | 单跳 301 恢复，抓取效率回升，请求量接近迁移前 |
这组数据直接对应收录从 1826 掉到 398 的过程：迁移前每天 8000 次抓取里，绝大多数能一次命中 200 页面，收录稳态维持在 1826；迁移后同一条 URL 要走三到四跳，爬虫每抓一个页面要发出 3~4 次请求才能拿到终态，单页抓取成本翻了几倍。谷歌的抓取预算分配策略是「先降频再观察」——每日抓取请求量从 8000 次降至 2000 次，意味着每天能完成的有效页面抓取从约 8000 个骤降到不足 600 个（2000 次请求 ÷ 平均 3.5 跳）。已收录页面排不进重新验证队列，新页面更是进不了抓取队列，收录自然从 1826 一路跌到 398。修复后单跳 301 让抓取成本回到 1 次请求 1 个页面，请求量回升到 7500 次/日，收录才跟着回升至 1791。
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 覆盖率报告抽样记录如下：
覆盖率报告各分项的前后对比更能说明问题所在：
| 覆盖率报告分项 | 迁移前（7 月 28 日） | 断点未修复（8 月 13 日） | 修复后第 6 周（9 月 24 日） |
|---|---|---|---|
| 已编入索引 | 1826 | 398 | 1791 |
| 重定向错误 | 6 | 1143 | 3 |
| 已抓取，尚未编入索引 | 87 | 214 | 96 |
| 已编入索引，但被 robots.txt 屏蔽 | 4 | 41 | 2 |
| 未找到（404） | 12 | 26 | 14 |
「重定向错误」从 1143 回落至 3 是链条修复的直接证据，「已编入索引」回到迁移前水平的 98% 左右，剩下几十页的差额是年度旧新闻页下架导致的正常损耗。自然搜索流量 9 月中旬回到迁移前区间，图片搜索流量因为 Mixed Content 修复加 CDN 域名替换，10 月初才恢复。
七、迁移前预演：上线前 72 小时该做什么
这次事故最痛的教训，是迁移被当成「装个证书」的运维操作，而不是一次需要 SEO 视角参与的网站优化工程。如果上线前 72 小时按下面四步做一遍预演，那 1143 个重定向错误大概率不会出现。这四步全部可以在 staging 环境或本地完成，不碰线上。
1) 用清单前五项对 50 条随机 URL 做全量 curl 预演，记录基线数据。迁移前先跑一遍「迁移检查清单」里的前五项（301 单跳直达、证书覆盖、内链协议、canonical 一致性、Mixed Content），把结果存成基线文件，迁移后再跑同一批 URL 对比。随机 URL 从 sitemap 里抽，覆盖首页、栏目页、产品详情页、参数表页四类：
# 从 sitemap 抽取 50 条随机 URL（需安装 xmlstarlet，Ubuntu 可用 apt install xmlstarlet）curl-s"https://www.example.com/sitemap.xml"\|xmlstarlet sel-t-v"//urlset/url/loc"\|shuf-n50>/tmp/urls_50.txt# 对 50 条 URL 逐条走完整重定向链，输出到基线文件whileread-rurl;doecho"===$url==="curl-sIL"$url"|grep-iE"HTTP/|location"done</tmp/urls_50.txt>/tmp/baseline_before.txt# 迁移后重跑同一批 URL，diff 对比whileread-rurl;doecho"===$url==="curl-sIL"$url"|grep-iE"HTTP/|location"done</tmp/urls_50.txt>/tmp/baseline_after.txtdiff/tmp/baseline_before.txt /tmp/baseline_after.txt通过标准：迁移后每条 URL 输出里只出现 1 次 301 + 1 次 200，无 302；diff 结果里除了协议从 http 变 https，跳数不应增加。
2) 在 staging 环境完整模拟一次 301 链条并截图保存。上线前先在 staging 服务器上把 Nginx 配置按「单跳 301」标准配好，用curl -sIL走一遍完整链条，确认任意入口 URL 都一次跳到 https 终态。然后把curl -sIL的完整输出、浏览器地址栏的跳转过程、以及 F12 Network 面板里的重定向瀑布图各截一张图，存进迁移文档。截图的意义在于：迁移当天如果线上表现和 staging 不一致，能立刻对照排查是配置差异还是环境差异。
# staging 环境验证命令，要求输出里只有 1 次 301 + 1 次 200curl-sIL"http://staging.example.com/product/valve-gate-1200"|grep-iE"HTTP/|location"3) 提前导出全站内链中的 http 地址清单，制定全局替换方案。迁移前用爬虫或脚本把全站页面源码里的http://开头的内链全部导出来，按出现频率排序，评估替换范围。这一步能提前暴露模板里写死的 http 地址，避免迁移后站内爬行重走断链。替换方案分两层：模板层在构建产物里全局替换（把http://改成https://或协议相对地址//），数据库层用 SQL 批量更新内容字段里的老地址。
# 用 wget 镜像全站后，grep 出所有 http 开头的内链（需先安装 wget）wget--mirror--convert-links --adjust-extension\--page-requisites --no-parent\"https://www.example.com/"-P/tmp/site_mirror# 统计 http 内链出现次数，按频率排序grep-rhoE'href="http://[^"]+"'/tmp/site_mirror\|sort|uniq-c|sort-rn>/tmp/http_links_report.txt4) 在 GSC 里提前完成四份资源的验证，避免迁移当天手忙脚乱。这次迁移涉及 http/https、带 www/不带 www 共四份资源，全部要在 GSC 完成验证。验证方式用 DNS 验证最省事——在域名解析里加一条 TXT 记录即可，不用动服务器。四份资源分别是：http://example.com、http://www.example.com、https://example.com、https://www.example.com。迁移前把四份都验证通过，迁移当天才能直接用「地址变更」工具，不用临时等验证。
操作路径：GSC 首页 → 添加资源 → 输入域名 → 选择「DNS 验证」→ 复制 TXT 记录 → 到域名解析服务商后台添加 → 回 GSC 点「验证」。四份资源重复这个流程，全部显示「已获验证」即可。迁移当天进入旧资源http://www.example.com→ 左侧「设置」→「地址变更」→ 选择新资源https://www.example.com→ 提交。
七、迁移检查清单
把这次踩过的坑浓缩成一张可执行的表，做 HTTP→HTTPS 迁移时逐行打勾：
| 检查项 | 验证方式 | 通过标准 |
|---|---|---|
| 301 单跳直达 | curl -sIL <随机 URL>抽测 50 条 | 输出仅 1 次 301 + 1 次 200，无 302 |
| 证书覆盖全域名 | 检查证书 SAN 列表 | 裸域名、www 域名均在列，链完整 |
| 内链协议 | 全站导出模板，搜索http:// | 站内链接 0 条以 http 开头的地址 |
| canonical 一致性 | 源码抽查 + 网址检查工具 | canonical 与最终 200 页面 URL 完全一致 |
| Mixed Content | 浏览器控制台 F12 筛 console | 无blocked: mixed-content报错 |
| HSTS 配置 | curl -sI https://域名 | 返回 Strict-Transport-Security 头，短周期起步 |
| robots.txt | 访问/robots.txt | Sitemap 行与规则均指向 https |
| sitemap 提交 | GSC 站点地图页面 | 新 sitemap 状态「成功」，旧 sitemap 保留 30 天 |
| 地址变更工具 | GSC 旧资源 → 设置 | 提交成功，状态「进行中」 |
| 网址检查抽测 | GSC 实时测试重点页 | 显示新协议 URL 为规范地址 |
常见错误与排查速查表
把迁移中最容易踩的 5 类症状、对应原因、快速诊断命令和修复要点浓缩成一张速查表，遇到问题时按行对照：
| 典型症状 | 可能原因 | 快速诊断命令 | 修复要点 |
|---|---|---|---|
| 收录骤降 | 重定向链过长或 302 未收敛，抓取预算被消耗 | curl -sIL <URL> | grep -iE "HTTP/|location" | 收敛为单跳 301 直达 https 终态，删掉历史 rewrite 叠加 |
| 重定向错误暴增 | 多跳链被谷歌标为「重定向错误」，旧规则未清理 | curl -sIL <URL>数跳数，GSC 覆盖率报告看分项 | 只留return 301，验证输出仅 1 次 301 + 1 次 200 |
| Mixed Content 报错 | 页面引用了 http 资源（图片/CDN/脚本） | 浏览器 F12 筛console，搜blocked: mixed-content | 资源地址改 https 或协议相对//，CDN 域名一并替换 |
| canonical 不一致 | 页面 canonical 写 https，站内链接却指向 http | grep -rhoE 'rel="canonical"[^>]*' <页面源码> | 统一 canonical 与最终 200 URL，模板层全局替换内链 |
| HSTS 配置失误 | 头未下发或周期过长，用户端缓存错误结果 | curl -sI https://域名 | grep -i strict-transport | 先短周期max-age=86400观察一周，稳定后再提到一年 |
回头复盘，这次事故的根因不是技术难度，而是迁移被当成「装个证书」的运维操作，没有当成一次需要 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、制造业官网收录
Web Docs：混合内容（Mixed Content）的拦截规则—— https://developer.mozilla.org/zh-CN/docs/Web/Security/Mixed_content
关键词：SEO、网站优化、301重定向、HTTPS迁移、Google Search Console、技术SEO、制造业官网收录
