网站从HTTP改成HTTPS，SEO还要检查哪些地方？

真正需要避免的是：地址栏看着正确，用户却找不到原来那件产品或文件。下面用P7产品与说明书走完一条检查路径，读到哪种响应，就回到相应位置处理。仍在安装证书或解决基础混合内容时，先看WordPress SSL与HTTPS配置，本篇接着处理搜索入口和迁移信号。

HTTP产品页，应该到达哪一个HTTPS地址

先写下正式版本。例如，网站决定使用https://www.example.com，那么原来的产品/pumps/p7/和说明书/manuals/p7.pdf，都应有明确的新去向。不要只写一句“全部跳HTTPS”，却没有确认路径是否保留。

旧地址类型	预期去向	不能漏掉的检查
HTTP首页	正式HTTPS首页	www与非www是否统一
HTTP产品页	同一产品的HTTPS页	不要全部跳到首页
HTTP说明书	对应的HTTPS文件	下载内容与权限仍正确
带必要参数的地址	保留所需行为的正式地址	不盲目丢弃业务参数

这是一份教学映射，example.com不是本轮实测站点。真实项目应从地图、CMS、重要访问记录和外部引用中选样本，至少覆盖首页、栏目、产品、文章与下载等不同模板。Google网站迁移指南

如果迁移还包括www变化，测试各个旧入口能否到达同一正式版本。与此同时，先不要把原有产品路径也重命名；少改一个维度，出现异常时就少一组需要排查的原因。

用响应记录看懂跳转，而不只看地址栏

浏览器打开后只显示HTTPS，并不足以看清过程。它可能经过多次跳转，也可能由脚本带走。可以在开发者工具的Network保留记录后访问旧URL，查看文档请求的状态与Location。若浏览器记住HSTS，它还可能在发出HTTP网络请求之前先升级到HTTPS；看到这种内部升级，不能当作服务器已返回301或308。MDN的HSTS说明解释了这个区别，下面的只读请求用于另外核首个实际响应。

Windows也可以用下面的只读命令查看首个GET响应；把示例换成自己有权检查的实际地址：

curl.exe -sS -D - -o NUL "http://www.example.com/pumps/p7/"

希望看到的是服务端永久跳转，例如301或308，并且Location指向对应产品的新地址。再跟随跳转检查终点：

curl.exe -sS -L -o NUL -w "code=%{http_code} url=%{url_effective} redirects=%{num_redirects}\n" "http://www.example.com/pumps/p7/"

code是最终状态，url是最终地址，redirects是经过的跳转数量。这些命令没有证明页面内容正确；仍需打开终点，确认它真的是P7产品，而不是返回200的首页或拦截页。macOS、Linux使用curl时，可将丢弃输出的位置改为/dev/null。

拿P7地址走一遍，理想的教学响应如下。数字是用来读命令结果的示例，不是这个保留域名的实际响应：

HTTP/1.1 301 Moved Permanently Location: https://www.example.com/pumps/p7/ code=200 url=https://www.example.com/pumps/p7/ redirects=1

第一段回答“旧地址把请求送到哪里”；第二段回答“跟过去最终取得什么状态”。你还需要打开最终页确认P7内容，所以200与正确URL要一起看。

读到的结果	说明什么	继续改哪里
301到P7的HTTPS页，终点200	跳转路径符合本例映射	继续核页面信号与功能
301到HTTPS首页，终点200	请求成功，却丢掉产品对应关系	修重定向的路径映射
两个地址相互跳，无法到终点	跳转规则形成循环	按每次Location找出互相覆盖的规则
终点仍为HTTP	正式版本没有统一	查服务器、CDN或应用中的实际跳转来源

这样读完一条产品请求，就能判断该继续看页面内容，还是先回到路由。它不需要依赖SEO分数。

常见错误是先从HTTP跳HTTPS非www，再跳HTTPS www，最后又改一次斜杠。应在实际规则允许的情况下尽量直接到正式终点，而不是把每个旧规则不断叠加。若出现循环，先按每次Location查对应层，别同时改服务器、CDN和插件多个开关。Google重定向说明

页面已经加密，canonical和抓取规则仍可能指错

打开新产品页的源代码，查rel="canonical"。它应表达这张页面计划使用的正式版本，不应仍是HTTP地址。若后台字段已经改了，公开HTML却没变，检查字段覆盖、模板来源和缓存；继续手写第二条canonical通常不能解决冲突。

再查robots meta与HTTP头是否遗留noindex。测试迁移时临时限制索引，正式开放后却忘记移除，会让“网页能打开”与“网页可被索引”产生差别。若某些客户页本来就不公开索引，不要因为迁移把它们的限制一并撤掉。

robots.txt也要从HTTPS正式主机读取。旧协议、旧主机和正式地址不是一个可以随意互换的检查位置。尤其不要在旧HTTP入口用抓取屏蔽来“清理旧索引”，否则Google可能无法取得旧地址上的迁移跳转。

跳转、canonical和地图都能提供信号，但它们不是三个同样强度的开关。方向一致，才容易让读者和搜索系统理解你保留的是哪个版本。Google规范网址说明

从产品图走到询价，找出仍在用HTTP的资源

迁移后，导航、正文、面包屑和模板中的链接应尽量直接去HTTPS最终页，不长期依赖旧地址跳转。这样既少一次等待，也减少后续排错时的混乱。

修改来源不一定都在文章正文。主题页脚、页面构建器、SEO插件、产品数据和CSS背景中都可能写着旧协议。检查P7时，可以从同一条路径走一遍：产品图、规格、说明书、询价按钮。这样能找到真正影响用户的旧资源，而不是只统计替换了多少字符串。

混合内容还可能来自字体、脚本、嵌入组件和表单端点。浏览器自动升级了某些图片请求，也不代表所有不安全请求都已经解决。查看Network与控制台，确认资源实际取得的地址及是否被阻止。

WordPress中的某些配置带序列化结构，不适合直接在数据库里全文替换。需要批量处理时，按旧图片与域名替换方法找到合适工具，先试跑、保留恢复办法，再核真正的前台输出。

在GSC里观察正确资源，不提交地址更改

域资源通常覆盖同一域名的不同协议与子域范围；网址前缀资源则按所选前缀区分。若过去只查看HTTP前缀，现在要观察HTTPS页面，应确认使用了相应的新前缀或覆盖它的域资源。旧资源和旧数据先保留，不必为了界面整洁立即删掉。

更新实际生成的站点地图，让它列出计划索引的HTTPS规范URL，再在正确资源中提交。地图“成功”只说明提交被读取或处理，不代表所有URL已经完成替换。

普通HTTP→HTTPS不要使用“地址更改”工具。Google官方明确把它列为不适用场景。真正换域名时再按域名迁移与地址更改教程处理，两类操作不要混用。地址更改工具适用范围

抽查重要HTTPS页的网址检查记录，留意抓取时间、声明规范与Google所选规范。实时测试看到的是当前可取页面，已有索引记录可能仍来自迁移前；不能在刚改完几分钟后，因旧记录还在就重新切换规则。

什么时候可以认为迁移稳定了

拿一条旧产品地址开始，检查首响应、最终URL、页面内容和询价动作；再用一篇文章及一份PDF重复。手机与未登录访问也要包含在内，避免只在管理员缓存状态下正常。

发现问题时，把它归回实际位置：错误Location查路由和跳转规则；公开canonical仍旧查模板或覆盖字段；下载失败查文件地址与访问；表单提交异常查端点和安全限制。一个“HTTPS异常”的笼统任务，很难让接手人知道先改哪里。

修改公共模板后，抽查不同内容实例，尤其是有旧自定义字段、旧下载按钮或复杂组件的页面。留存本次配置差异和可恢复版本；若必须回退，回退的是具体改动，而不是长期让HTTP、HTTPS都各自返回可索引副本。

这轮可以得到很具体的记录：“P7旧地址永久到达P7 HTTPS页，canonical一致，PDF正常下载，手机询价成功；另一模板的旧图片待修。”它比一句“已开小锁、迁移完成”更接近真实状态。

迁移稳定以后，旧入口仍应保留

Google建议迁移跳转尽可能长期保留，一般至少一年。来自旧邮件、外部文章和收藏的访问，可能在迁移很久以后才再次到达。自己的高频链接则应主动更新到最终地址，减少长期跳转。

观察时把新旧页面、日期和发布版本分开。旧HTTP展示减少、HTTPS增加可能符合迁移过程，但一次点击下降也可能同时受需求或其他内容变化影响。先查具体URL是否仍可用、信号是否一致，再判断要不要继续修改。

迁移后的检查可以接到谷歌SEO学习路径中的索引监测。保留原内容的稳定访问，再分别处理其他内容问题。