WordPress 更新与月度维护清单：在 SiteGround 上怎么更新才不出事

WordPress 站点出问题的原因，排第一的从来不是主机故障，而是更新。核心版本升级、插件互相冲突、主题改了模板、PHP 版本换了——每一项都可能让一个跑了三年的站点当场白屏。

但不更新更危险。绝大多数 WordPress 被挂马的案例，入口都是某个已知漏洞的旧版插件。所以问题不是"要不要更新"，而是"怎么更新才不出事"。

这篇讲的是在 SiteGround 上的一套可执行策略。

先分清三种更新，风险完全不同

WordPress 核心更新（低风险，建议自动）

核心的小版本更新（比如 6.7.1 → 6.7.2）是安全和 bug 修复，向后兼容性有保障，几乎不会破坏站点。大版本更新（6.7 → 6.8）引入新特性和 API 变化，插件生态需要时间跟进，风险明显更高。

策略：小版本开自动，大版本手动、等一周再升。等一周不是为了拖延，是让插件作者有时间发布兼容更新、让社区把踩坑报告发出来。

插件更新（中风险，必须分类处理）

插件是白屏和冲突的主要来源。按重要性分三类处理：

• 安全类、缓存类、SEO 类（如 SG Optimizer、SG Security、Yoast/RankMath）：这类插件的更新往往包含漏洞修复，优先级最高，看到就更新，但更新前确认有备份。
• 页面构建器、主题配套插件（Elementor、Divi 相关）：最容易出兼容问题，务必先在 Staging 测。这类插件的更新经常伴随模板渲染变化，前台可能直接错位。
• 小众/多年未更新的插件：更新前先看看最近一次更新是什么时候、 changelog 写了什么。如果一个插件三年没更新，问题不在"要不要升它"，而在"要不要换掉它"。

主题更新（中风险，容易被忽略）

商业主题的更新可能改动模板文件。如果你直接改过主题文件（没用子主题），更新会直接覆盖你的修改。这是最常见的"更新后样式全乱了"的原因。

正确做法：任何主题修改都放子主题里。已经直接改过父主题的，更新前先下载一份改动文件留存。

SiteGround 上的自动更新怎么配

Site Tools 里 WordPress 相关的自动化在两处：

Site Tools → WordPress → Instances 可以看到站点当前的 WordPress 版本、PHP 版本，以及自动更新开关。核心小版本更新可以交给平台自动处理——SiteGround 会在检测到安全版本时自动为你的站点更新，这类平台级自动更新是托管主机的价值所在，你不用守着后台点按钮。

Site Tools → WordPress → Autoupdate（插件/主题） 可以设置插件和主题的自动更新范围。建议只勾选你确认稳定的少数几个，不要把全部插件设成自动。原因很简单：自动更新意味着你没有测试环节，某个插件的坏版本会在你不知情的情况下上线。

一个折中方案：核心 + 安全类插件自动，其余手动批量更新，每周固定一个时间处理。

更新前必做的三件事

不管多小的更新，这三步不能省：

1. 做一次手动备份

自动备份是兜底，手动备份是你自己知道时间点的还原锚。Site Tools → Security → Backups 里可以立刻创建一份，也能从中恢复单个文件或整个站点。恢复流程细节见 备份与还原指南。

2. 记下当前版本号

核心版本、几个关键插件的版本号截图存一下。出问题时你需要知道"回到哪个版本"，而插件仓库的历史版本不好找。

3. 避开业务高峰

电商站别在大促当天更新插件，内容站别在推送刚发出去、流量正在进来的时候更新。选流量低谷时段，出问题影响面小。

用 Staging 把更新风险降到接近零

Staging 是 GrowBig 及以上套餐的功能，也是更新流程里最值得用的一环。逻辑很简单：在副本上先跑一遍更新，确认没问题再动生产站。

流程：

1. Site Tools → WordPress → Staging，创建生产站的副本（文件和数据库都会复制）；
2. 在 Staging 环境里执行全部更新——核心、插件、主题一次做完；
3. 检查关键页面：首页、文章页、产品页、结账流程、表单提交、后台各主要界面；
4. 看 Staging 的错误日志有没有新增 Fatal error 或 Deprecated；
5. 一切正常，回到生产站执行同样的更新；
6. 如果发现冲突，在 Staging 上逐个停用插件定位到罪魁祸首，再决定是等它修复还是换掉。

多花二十分钟，换的是"不会在客户下单的时候白屏"。Staging 的完整用法和配合 Git 部署的工作流，另有一篇详细写过：Staging 与 Git 工作流。

PHP 版本：更新的另一半

WordPress 更新只是一半，另一半是 PHP 版本。两者必须匹配：

• PHP 版本太老 → 新版 WordPress 和插件可能不再支持，且老版本 PHP 停止维护后没有安全补丁；
• PHP 版本太新 → 某些老插件用了被废弃的语法，报 Deprecated 甚至直接 Fatal error。

切换入口在 Site Tools → Devs → PHP Manager。建议的做法：

1. 新版本 PHP 发布后不急着切，等 2-3 个月让插件生态跟上；
2. 切之前先在 Staging 上试，重点看错误日志；
3. 切完在生产站观察几天，有异常随时在 PHP Manager 里切回原版本（秒级生效，不用等客服）；
4. 绝对不要跑在已经 EOL 的 PHP 版本上。

PHP 版本带来的性能差异是实打实的——同样的代码在新版本上通常更快、内存占用更低。这部分对资源消耗的影响见 资源限制全解析。

更新后出问题了怎么办

按症状对号入座，完整的排查手册在 网站故障自查指南，这里只讲更新相关的：

白屏（White Screen of Death）

八成是插件或主题冲突。最快的定位方式：用 File Manager 把 wp-content/plugins 目录改名（比如 plugins-off），站点会立刻恢复（所有插件失效但页面能打开）。然后把目录名改回来，逐个启用插件找出问题那个。

后台能进、前台报错

优先怀疑主题和页面构建器。切回默认主题（Twenty 系列）看前台是否恢复，能恢复就说明是主题或构建器的问题。

Allowed memory size exhausted

内存不够。可能是新版本的某个插件更吃内存，也可能是站点本身该升档了。临时可以在 wp-config.php 里提高 WP_MEMORY_LIMIT，但根因要查是哪个插件。

500 错误 + 日志里有 Deprecated

典型的 PHP 版本与插件不兼容。要么把插件更到最新版，要么在 PHP Manager 里把 PHP 降回上一个稳定版本。

彻底恢复不了

用之前那份手动备份还原。这就是为什么更新前一定要手动备份一次——自动备份的时间点可能在你更新之后，还原了也白还原。

每月十分钟的维护清单

固定每月做一次，比出事再补救省事得多：

• 看更新列表：核心、插件、主题各有多少待更新，按上面的分类决定自动还是手测；
• 跑一次手动备份，确认备份文件确实生成了；
• 翻 Error Log：Site Tools → Statistics → Error Log，重复出现的警告要处理，别攒着；
• 检查安全扫描结果：如果开了 SG Site Scanner，看有没有新增告警；平台自带的防护能力见 安全功能详解；
• 确认 SSL 证书有效：Let's Encrypt 是自动续期的，但偶尔会因为 DNS 变动导致续期失败；
• 测一次速度：用 PageSpeed 跑首页和一篇内页，和上月对比。分数掉了 10 分以上要查原因，优化手段见 速度优化实战；
• 清理：媒体库里没用到的大图、缓存目录、旧备份、失效的用户账号；
• 看一眼账单和到期日：域名和主机的续费日期，避免因为忘记续费导致站点下线。续费价格和自动续费设置见 续费价格全解析。

什么时候该找客服

自己排查超过半小时还没头绪，就该开聊天工单了。SiteGround 的支持是 24/7 在线，工程师可以直接看服务器日志，很多问题他们一眼就能定位。

沟通时用英文，把三件事说清楚就够了：做了什么操作（更新了哪个插件到什么版本）、现在的症状（前台 500，后台正常）、日志里的报错原文（直接粘贴）。客服响应速度和沟通技巧的实测见 客服与技术支持。

结语

WordPress 维护的核心不是"勤快"，是流程：备份 → Staging 测试 → 更新 → 观察 → 记录。这套流程走顺了，每次更新花的时间其实很少，但能把"更新导致宕机"的概率压到接近零。

如果你现在的站点还没有 Staging 环境，说明用的是 StartUp 档——GrowBig 开始才有这个功能。差价换一整套安全更新流程，对正经做业务的人来说很值。档位差异见 套餐对比页，或者从 SiteGround 官方优惠入口 直接开通，30 天内不满意可全额退款。

新手第一次配置站点，可以跟着 购买与建站教程 一步步走；对主机本身还有疑问，评测页 和 常见问题 里有更完整的说明。