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.68Ubuntu 20.04 自带版本即可无其他依赖# -sI 只取响应头-L 跟随重定向丢弃正文只看每一跳的状态码和 Locationcurl-sILhttp://example.com/product/valve-gate-1200|grep-iEHTTP/|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。把这条链画出来断点在哪里一目了然第1跳 302第2跳 302第3跳 301页面内 canonical 指向 http 副本爬虫请求 http://example.comhttp://www.example.comhttps://example.comhttps://www.example.com索引信号矛盾对照官方文档的说法搜索引擎期望的是协议迁移应该用单次 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.0Ubuntu 22.04 通过 apt 安装 # 证书Lets 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-age31536000 # always 参数保证 4xx/5xx 响应也带上这个头 add_header Strict-Transport-Security max-age86400 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 覆盖率报告抽样记录如下8月3日全站切换 HTTPS收录 18268月13日断点未修复跌入低谷收录 3988月20日Nginx 单跳修复 地址变更工具提交收录 6459月3日sitemap重新抓取完成收录 14329月24日基本恢复迁移前水平收录 1791收录恢复时间线GSC 覆盖率报告已编入索引页数覆盖率报告各分项的前后对比更能说明问题所在覆盖率报告分项迁移前7 月 28 日断点未修复8 月 13 日修复后第 6 周9 月 24 日已编入索引18263981791重定向错误611433已抓取尚未编入索引8721496已编入索引但被 robots.txt 屏蔽4412未找到404122614「重定向错误」从 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需安装 xmlstarletUbuntu 可用 apt install xmlstarletcurl-shttps://www.example.com/sitemap.xml\|xmlstarlet sel-t-v//urlset/url/loc\|shuf-n50/tmp/urls_50.txt# 对 50 条 URL 逐条走完整重定向链输出到基线文件whileread-rurl;doecho$urlcurl-sIL$url|grep-iEHTTP/|locationdone/tmp/urls_50.txt/tmp/baseline_before.txt# 迁移后重跑同一批 URLdiff 对比whileread-rurl;doecho$urlcurl-sIL$url|grep-iEHTTP/|locationdone/tmp/urls_50.txt/tmp/baseline_after.txtdiff/tmp/baseline_before.txt /tmp/baseline_after.txt通过标准迁移后每条 URL 输出里只出现 1 次 301 1 次 200无 302diff 结果里除了协议从 http 变 https跳数不应增加。2) 在 staging 环境完整模拟一次 301 链条并截图保存。上线前先在 staging 服务器上把 Nginx 配置按「单跳 301」标准配好用curl -sIL走一遍完整链条确认任意入口 URL 都一次跳到 https 终态。然后把curl -sIL的完整输出、浏览器地址栏的跳转过程、以及 F12 Network 面板里的重定向瀑布图各截一张图存进迁移文档。截图的意义在于迁移当天如果线上表现和 staging 不一致能立刻对照排查是配置差异还是环境差异。# staging 环境验证命令要求输出里只有 1 次 301 1 次 200curl-sILhttp://staging.example.com/product/valve-gate-1200|grep-iEHTTP/|location3) 提前导出全站内链中的 http 地址清单制定全局替换方案。迁移前用爬虫或脚本把全站页面源码里的http://开头的内链全部导出来按出现频率排序评估替换范围。这一步能提前暴露模板里写死的 http 地址避免迁移后站内爬行重走断链。替换方案分两层模板层在构建产物里全局替换把http://改成https://或协议相对地址//数据库层用 SQL 批量更新内容字段里的老地址。# 用 wget 镜像全站后grep 出所有 http 开头的内链需先安装 wgetwget--mirror--convert-links --adjust-extension\--page-requisites --no-parent\https://www.example.com/-P/tmp/site_mirror# 统计 http 内链出现次数按频率排序grep-rhoEhrefhttp://[^]/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.txtSitemap 行与规则均指向 httpssitemap 提交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 次 200Mixed Content 报错页面引用了 http 资源图片/CDN/脚本浏览器 F12 筛console搜blocked: mixed-content资源地址改 https 或协议相对//CDN 域名一并替换canonical 不一致页面 canonical 写 https站内链接却指向 httpgrep -rhoE relcanonical[^]* 页面源码统一 canonical 与最终 200 URL模板层全局替换内链HSTS 配置失误头未下发或周期过长用户端缓存错误结果curl -sI https://域名 | grep -i strict-transport先短周期max-age86400观察一周稳定后再提到一年回头复盘这次事故的根因不是技术难度而是迁移被当成「装个证书」的运维操作没有当成一次需要 SEO 视角参与的网站优化工程。凡是涉及 URL 结构、协议、域名变更的动作都应该在上线前用清单里的前五项做预演上线后 72 小时盯住 GSC 覆盖率报告——收录曲线是最诚实的验收标准。等收录和排名重新站稳之后再往生成式引擎优化Generative Engine Optimization, GEO方向做内容布局地基才算真正打牢了。如果你的迁移也遇到过覆盖率报告异常欢迎在评论区贴出你的报告截图和排查思路一起对表。参考与延伸谷歌搜索中心重定向与 Google 搜索301 与抓取行为官方说明—— https://developers.google.com/search/docs/crawling-indexing/site-and-page-redirectsGoogle Search Console 帮助网站地址变更工具使用条件与流程—— https://support.google.com/webmasters/answer/9370220Nginx 官方文档ngx_http_rewrite_module 的 return 指令—— https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#returnMDN 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、制造业官网收录