WordPress安装SSL证书，要先让主机上的HTTPS地址能正常访问，再修改网站地址、清理旧资源链接和设置跳转。最后还要验证登录、询盘与自动续期。顺序很重要：证书尚未部署成功，就先把后台地址改成HTTPS，可能把自己挡在登录页面外。
日常说的“SSL证书”，现在实际用于TLS连接。对站长来说，先把两件事分开：主机负责向浏览器出示有效证书，WordPress负责输出正确的网站地址与内容。安装一个处理HTTPS的插件，并不当然意味着这两件事已经完成。
以下针对自托管WordPress单站。主机托管、多站点、反向代理的配置入口不同；涉及服务器规则时，应按实际架构操作，不能把别人的配置整段贴进自己的站点。
开始前，把要切换的入口和恢复办法记下来
不要只记录首页。至少选一篇旧文章、一个产品或服务页面、登录页，以及一个真正会提交数据的表单作为验收样本。记录它们当前是否正常，切换后才知道新出现的问题来自哪里。
| 项目 | 需要记下什么 | 为什么要先查 |
|---|---|---|
| 正式域名 | 是否以www为主，哪些旧入口要跳转 | 证书必须覆盖实际接受HTTPS连接的域名 |
| WordPress地址 | 后台两项地址，以及是否安装在子目录 | 修改协议时不能顺手删掉原路径 |
| 代理与缓存 | CDN、主机缓存、插件分别负责什么 | 后面出现旧链接或循环跳转时能定位 |
| 恢复入口 | 主机面板、文件访问、数据库备份与负责人 | 后台打不开时仍有修复渠道 |
| 业务样本 | 登录、保存、询盘或测试订单 | 首页打开不代表业务能运行 |
先保存文件与数据库备份，并确认恢复方式。备份是为了应对具体变更；如果切换后已经收到新订单或询盘，不能随手恢复旧数据库，把新数据一起抹掉。可以提前按照WordPress备份与恢复检查恢复边界。
例如，你最终使用https://example.com/，但也接受https://www.example.com/并跳转到前者。那么www也需要有效证书：浏览器会先完成TLS连接，才有机会读取跳转响应。不能用“这个地址只是跳转”解释证书错误。
在主机部署证书，先验HTTPS，再动WordPress
使用托管主机时，通常在站点的SSL或安全设置中选择域名并启用证书。核对是否包含需要的主机名、是否自动续期，以及主机要求DNS指向哪里。等待面板显示成功后，直接访问HTTPS地址，查看浏览器显示的域名、有效期和信任状态。
面板成功与实际访问成功要同时成立。如果访问仍显示域名不匹配，可能请求到了另一台服务器，或者www没有包含在证书里。证书过期、缺少中间证书、访问到错误虚拟主机，也不能通过修改WordPress地址解决。先让主机确认443端口实际提供的证书。
自管服务器可以使用支持ACME的客户端申请证书，但申请、安装到正确站点配置、自动更新是三个环节。验证方式要与环境匹配：
- HTTP-01通过域名下的指定HTTP路径验证，使用80端口。检查DNS、网络入口和挑战路径是否能到达验证文件；普通网站页面打开不等于挑战路径没有被代理或规则拦截。
- DNS-01通过DNS TXT记录验证，可用于通配符证书。自动续期需要可靠的DNS更新方式；若每次都依赖人工加记录，就应明确谁来维护，不能默认它会自动运行。
域名有A与AAAA记录时，也要确认它们没有把验证请求带到不同且未配置的环境。DNS自动化凭据应只授予所需权限，按客户端和DNS提供商文档配置。Let’s Encrypt挑战类型说明
启用CDN的网站还要分别检查“浏览器到CDN”和“CDN到源站”。前者显示正常，不足以证明后者配置正确。具体接入与回源检查可参考WordPress CDN配置。不要为了消除提示，把回源验证长期降为不验证证书。
调整网站地址，保留已有域名与安装路径
HTTPS访问正常后，进入“设置 → 常规”，检查WordPress地址和站点地址。普通根目录安装的两个值通常相同；WordPress核心安装在子目录、前台从根目录显示时，两者可能不同。这次如果只切协议，就保留原有域名和路径，只把对应HTTP改为HTTPS。
例如原WordPress地址是http://example.com/wp，站点地址是http://example.com，不要因为看到教程里的两个地址相同，就把/wp删掉。它们各自表达的位置不同。WordPress常规设置说明
字段无法修改时，查看是否由WP_HOME或WP_SITEURL常量控制，或由托管环境统一管理。不要在后台和配置文件里各改一套不一致的值。改后重新登录，检查编辑与预览地址，确认没有跳回HTTP。
反向代理可能让访客以HTTPS连接，但WordPress收到的内部请求看起来仍是HTTP。此时强制HTTPS容易产生循环。需要由维护者正确传递并识别协议，且只信任受控代理提供的头信息，不能随便信任所有客户端传来的字段。WordPress HTTPS与反向代理说明
清理混合内容，查到具体资源的保存位置
页面地址变成HTTPS，不代表里面的图片、CSS、字体和脚本都已经改好。打开代表性页面的浏览器控制台和Network面板，记录仍请求HTTP的具体URL，以及由哪段HTML、样式或脚本发起。
浏览器对部分混合内容会尝试升级，对另一些会阻止。页面暂时看起来正常，也可能只是浏览器帮忙升级了图片地址。应该修正站点输出，而非把“我这里能显示”当成清理完成。MDN混合内容说明
| 发现的旧链接 | 优先修改的位置 | 改后再查什么 |
|---|---|---|
| 正文内旧图片URL | 文章内容或相关媒体引用 | 原文输出与真实请求是否HTTPS |
| 页面构建器背景图 | 对应组件设置及生成的样式文件 | 重新生成后是否仍被旧缓存覆盖 |
| 字体、CSS或脚本 | 主题、插件配置或自定义代码 | HTTPS地址本身是否可用 |
| 外部HTTP资源 | 原提供方或替代资源 | 不要仅改协议后留下404或证书错误 |
大量本站旧URL需要替换时，先备份并在副本演练。WordPress数据库可能有序列化数据，普通SQL文本替换可能破坏数据长度；可以由维护者用理解这种数据的工具处理。WP-CLI示例先做预演：
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
这是占位域名，执行前替换成准确旧地址，并确认命令在正确站点目录运行。--dry-run只显示预计修改，不写数据库。审查涉及的表和条目数，确认范围后再安排实际变更。自定义表、多站点或不同前缀可能需要另行确定范围；不要为了“彻底”直接扩大到整个数据库，也不要全局把所有http://改掉。该工具支持序列化数据处理，但仍不能代替变更前的范围审核。WP-CLI search-replace文档
完成后按实际工具重新生成样式，清理应用、主机与CDN中相关缓存。然后退出登录再检查一次，避免只看到管理员绕过缓存的结果。
统一旧入口，检查跳转链与搜索信号
内容已经能通过HTTPS正确运行，再在主机或边缘层设置HTTP到HTTPS的永久跳转。尽量由一个明确位置负责，避免主机、CDN、插件都各自重写，排错时不知道哪条规则在起作用。
测试时要带路径：http://example.com/product-a/应到对应HTTPS产品页，不应全跳首页。www与非www也应归到约定版本。查看实际重定向链，确认没有HTTP与HTTPS来回跳、域名来回跳，或先经过多个中间地址。
本站在2026年10月9日的一次公开检查，可以示范怎样记录“路径有没有丢”：
| 检查项 | 本次实际结果 |
|---|---|
| 输入 | 协议 http:// ＋ yaiseo.com/install-ssl-wordpress/，两段连写 |
| 第一次响应 | 301，目标为同路径的HTTPS地址 |
| 访问目标 | https://yaiseo.com/install-ssl-wordpress/ 返回200 |
| canonical | 仍是该HTTPS文章地址，没有变成首页 |
这是单条公开入口的观察，不包含主机证书部署、全部子域和下次自动续期。换成自己的网址时，分别记录旧文章、产品页和其他实际入口。
如果出现循环，先查代理是否正确识别协议和各层目标是否相互矛盾；如果提示证书无效，则回到证书部署；如果只有某张图片不显示，则检查资源。它们表现都可能是“HTTPS后坏了”，修复位置却不同。
如果证书连接正常，提醒却明确说网页有恶意内容或欺骗行为，应查看Google安全问题及清理后复核，继续更换证书不能清掉页面感染。
随后检查站内链接、canonical和站点地图是否指向HTTPS版本，确保新页面可以被抓取，测试环境的noindex或访问限制没有遗留。Google把协议变更视为URL变化的一种，迁移后需要重新抓取处理；不要期待切换当天所有搜索展示立即变动。Google网站迁移说明
HTTPS入口统一后，再用WordPress页面SEO输出检查核对标题、canonical和索引指令；连接加密与页面能否被正确理解，需要分别验收。
用真实业务完成切换验收
至少完整走一遍：匿名打开旧文章和服务页，进入登录页，登录后保存一次草稿，打开预览，再从匿名窗口提交一条标记清楚的测试询盘。检查提交记录、通知收件以及回复地址。遇到邮件问题，可沿表单提交、发送与收件排查继续定位。
如果站点连接支付、OAuth或外部回调，也要核对对方保存的站点地址和允许的回调地址。不要在这一步直接制造真实交易；使用服务提供方的测试流程，验证原有业务链仍然成立。
可以给每个阶段留一条简单证据：证书域名与到期时间、最终HTTPS地址、没有相关混合内容报错的样本页面、跳转结果、测试询盘记录。以后发现某个旧页面仍有HTTP图片时，就能修复具体遗漏，而不用再次盲目重做整次切换。
自动续期要检查到“实际使用了新证书”
首次证书有效，只能证明今天能用。长期维护还包括定时任务是否运行、域名验证是否仍能完成、续期后服务器是否加载了新文件。换DNS、加防火墙或调整挑战路径，都可能影响后续续期。
托管用户应确认由主机负责续期，并明确失败通知到哪个邮箱。自管Certbot环境可以按照官方文档使用certbot renew --dry-run测试续期流程；这并不等于已经完成正式生产续期。需要重载服务的环境，还应正确配置并验证部署动作。Certbot续期说明
最有用的交接记录包括：证书负责方、验证方式、通知接收人、当前到期日，以及续期后从外部看到的新有效期。服务器磁盘上出现新证书，但入口仍提供旧证书，问题并没有解决。
HSTS建议等HTTPS稳定、所有涉及的子域与恢复方案都确认后再评估。浏览器记住策略期间会强制使用HTTPS；删除服务器配置并不能立即消除已有客户端的记忆。includeSubDomains还会扩大到子域，不适合作为安装证书时顺手全开的选项。MDN HSTS说明
常见问题
免费证书够普通企业站使用吗？
正常签发、受浏览器信任且正确部署的免费证书，可以用于普通企业站的HTTPS连接。选择时还要看自动续期、域名覆盖和维护支持。付费与否不能代替部署验收，也不直接说明网站内容或业务可信。
已经安装HTTPS插件，还要去主机操作吗？
先看插件具体负责什么。有的只处理地址、跳转或混合内容，有的会与托管服务集成。最终仍需要实际入口提供有效证书。以HTTPS访问和证书检查结果为准，不能只看插件启用状态。
改地址后进不去后台，应该立刻恢复整个数据库吗？
先通过主机入口核对地址值、证书和代理协议识别。若只是地址或重定向配置错误，通常应针对该处修复。全库恢复可能覆盖切换后新增的数据，只有明确恢复范围与数据影响后才采取这种操作。
自动续期测试通过，就不必再关注证书了吗？
仍需要失败通知与到期监测。测试证明当时的流程可运行，不保证以后DNS、网络或部署配置不变。至少确认一次真实续期后公开入口使用了新证书，并让明确的维护者持续接收异常提醒。