本文约 3,972 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：换了 HTTPS，收录反而掉了一半
全站迁 HTTPS 看似只是加个证书，实际涉及 URL 体系的根本变化——每个页面的规范地址都变了，等价于一次全站迁移。常见事故是：证书装上、后台设置改了，但文章正文里的图片还是 http://，数据库里的旧链接没替换，重定向写了 302，Search Console 里 HTTP 属性没重新提交站点地图。结果排名短期波动，混合内容导致部分浏览器显示不安全标识，用户信任度下降。
原理分析：迁移的本质是 URL 变更
Google 把 HTTPS 迁移视为站点迁移的一种。搜索引擎需要重新抓取全部 URL、重新评估规范地址、把原有链接信号转移到新地址。转移是否顺利取决于三点：
| 要素 | 正确做法 | 错误做法 |
|---|---|---|
| 重定向类型 | 301 永久重定向 | 302 临时重定向 |
| 重定向链 | 一次跳转到位 | http→www→https 多级跳转 |
| 内部链接 | 直接指向 https | 内部仍指向 http 再跳 |
| canonical | 指向 https 版本 | 仍指向 http |
| 资源协议 | 全站 https 或无协议 | 混用 http 资源 |
关于排名影响，Google 早已把 HTTPS 列为轻微的排名信号，迁移本身在正确执行的前提下不会导致长期损失，短期波动（数天到两周）属正常。真正的损失来自执行错误：302 重定向、重定向链过长、混合内容、站点地图未更新。
HSTS（HTTP Strict Transport Security）能强制浏览器使用 HTTPS，减少一次跳转，但一旦下发 max-age 较长的策略，回退会很麻烦，建议先用较短的 max-age 验证，确认无误后再延长。
保姆级实操
步骤一：部署证书并验证
先确保证书链完整（含中间证书），用命令行确认：
openssl s_client -connect mimangfei.com:443 -servername mimangfei.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -dates -subject
curl -sI https://mimangfei.com/ | head -5
步骤二：配置单一 301 跳转
把 http→https 与 www→非 www 合并为一次跳转，避免重定向链：
server {
listen 80;
listen [::]:80;
server_name mimangfei.com www.mimangfei.com;
return 301 https://mimangfei.com$request_uri;
}
server {
listen 443 ssl http2;
server_name www.mimangfei.com;
ssl_certificate /etc/letsencrypt/live/mimangfei.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mimangfei.com/privkey.pem;
return 301 https://mimangfei.com$request_uri;
}
server {
listen 443 ssl http2;
server_name mimangfei.com;
ssl_certificate /etc/letsencrypt/live/mimangfei.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mimangfei.com/privkey.pem;
add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
location / {
try_files $uri $uri/ /index.php?$args;
}
}
步骤三：改 WordPress 站点地址
在后台「设置 → 常规」里把两处 URL 改为 https，或用 wp-cli 批量改（多站点需加 --network）：
wp option update home 'https://mimangfei.com'
wp option update siteurl 'https://mimangfei.com'
wp cache flush
步骤四：替换数据库中的历史 http 链接
用 wp-cli 的 search-replace，先在测试环境或用 --dry-run 预演：
wp search-replace 'http://mimangfei.com' 'https://mimangfei.com' \
--all-tables --precise --dry-run
wp search-replace 'http://mimangfei.com' 'https://mimangfei.com' \
--all-tables --precise
注意 --all-tables 会处理序列化数据，不要用简单的 SQL REPLACE 去改 post_content，那会破坏序列化字段。
步骤五：修复混合内容
扫描剩余 http 资源引用：
# 列出仍指向 http 的资源
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://mimangfei.com%' AND post_status='publish';" --skip-column-names
# 前端验证：抓首页找混合内容
curl -s https://mimangfei.com/ | grep -o 'src="http://[^"]*"' | sort -u
主题文件里硬编码的 http 地址要一并改掉：
grep -rn "http://mimangfei.com" wp-content/themes/ wp-content/plugins/ --include="*.php" --include="*.css" --include="*.js"
步骤六：更新 canonical、站点地图与 Search Console
确认 canonical 已指向 https；重新提交站点地图；在 Search Console 中把 https:// 作为新的域名属性添加并验证（HTTP 与 HTTPS 是独立属性）。同时使用「更改地址」工具仅适用于域名变更，协议迁移通常不需要。
步骤七：监控索引与抓取
迁移后前两周每天看「网页索引」报告的已索引数量与「抓取统计」报告：
-- 对比迁移前后每日索引量与抓取量
SELECT date,
SUM(CASE WHEN metric='indexed' THEN val END) AS indexed,
SUM(CASE WHEN metric='crawled' THEN val END) AS crawled
FROM gsc_daily_stats
WHERE date BETWEEN '2026-04-01' AND '2026-04-30'
GROUP BY date
ORDER BY date;
常见踩坑
- 用 302 跳转，Google 无法确认永久迁移，信号转移缓慢。
- 跳转链过长（http→https www→https 非 www），浪费抓取预算并拖慢速度。
- 用 SQL 直接
REPLACE改post_content，破坏序列化数据导致小工具丢失。 - 只改了后台设置，正文图片仍是 http，浏览器显示「不安全」。
- HSTS 一上来就设
max-age=31536000，出问题无法回退。 - 案例：某站点迁移时先在 CDN 层做了 http→https 的 302，源站又做了一次 301，形成三重跳转链。两周内索引量下降 41%，清理跳转链后三周才恢复。
- 忘记在 Search Console 新增 HTTPS 属性，导致新地址的数据一直没被监控。
总结
HTTPS 迁移的正确顺序是：证书与跳转 → 后台站点地址 → 数据库替换 → 混合内容修复 → canonical 与站点地图 → Search Console 验证与监控。判断迁移是否成功的标准是：所有 http URL 一次 301 到最终 https 地址、页面无混合内容、canonical 与站点地图均为 https、索引量在两周内回到迁移前水平。HSTS 先短后长，wp-cli 替换前先 --dry-run。如果站点同时在做多语言，迁移后要一并检查 hreflang 部署 里的 URL 是否已同步为 https；抓取层面的变化可用 服务器日志分析 跟踪；若迁移后流量异常，按 算法更新流量波动分析 的归因顺序先排除技术因素。
