我将两个 WordPress 应用接入了 Cloudways Site Manager 用于这次评测，一个是通过应用自身侧边栏里隐藏的上手界面接入的，另一个是通过账户级别的批量流程接入的。
从那里开始，我对四个插件执行了一次真实的 Safe Update，创建了一个覆盖两个站点的共享自动更新计划，开启了活动日志，并花了足够多的时间待在账户级仪表盘里，去理解同一条信息会出现在多个位置，以及为什么这点比听起来更重要。
Site Manager 取代了 Cloudways 之前名为 SafeUpdates 的插件功能。 理解 SafeUpdates 做不到什么，就能解释当前产品几乎所有的设计决策。
SafeUpdates 全部通过 SSH 运行，这给管理超过几个站点的人带来了一套非常具体的问题：
管理 20 个或更多 WordPress 安装的代理机构告诉 Cloudways 的意思是：这个工具在规模化之前很好用，但扩展才是他们使用 Cloudways 的全部原因。
Site Manager 正是对这些反馈的直接回应。这个背景对于阅读后面的评测很重要，因为它解释了为什么产品的某些部分对于仍处于 Public Preview 的工具来说显得异常成熟，也解释了为什么另一些部分，比如你在第一天就会遇到的上手步骤，仍然能看到一些缝隙。
有了这个背景，接下来要问的是范围：这个工具到底能覆盖什么。在深入讲解入门、更新和计划之前，先准确说明 Site Manager 覆盖什么、不覆盖什么是很重要的，因为诚实的答案比简单的“是”或“否”要细致得多。
无论是通过单个应用界面，还是通过 Integrations 下的批量向导，所有可注册到账户级 Site Manager 的应用，都是来自我 Cloudways 账户中已经存在的一台服务器。
界面里没有可以粘贴外部托管安装凭据的字段，也没有连接运行在其他主机上的站点的连接器。
本次评测中涉及的完整功能集——Safe Update 的暂存克隆、可视化回归测试、活动日志、批量计划，全都运行在这个原生的、Cloudways 托管的层级里。
Cloudways 还发布了一个免费的 WordPress 插件，同样名为 Cloudways Site Manager，由 WP Remote 共同开发。
与原生仪表盘不同，这个插件可以直接安装到任意 WordPress 站点上，不管它托管在哪里，这意味着它可以把外部、非 Cloudways 的站点纳入某种版本的统一视图中。
不过，它和原生仪表盘确实是不同的产品，而两者之间的差距很重要：
| 功能 | 原生 Site Manager（Cloudways 托管应用） | Site Manager 插件（任何主机） |
|---|---|---|
| 集中式仪表盘 | 是 | 是 |
| 核心、插件、主题更新 | 是 | 是 |
| Safe Update（暂存克隆 + 可视化回归） | 是 | 否 |
| 服务器级缓存（Varnish、Redis、Cloudflare） | 是 | 否 |
| 活动日志 | 是（Pro） | 不等同 |
| 成本 | 免费（Basic）/ 付费（Pro） | 免费 |
该插件还会在启用时禁用 WordPress 自己的自动更新，这是 Cloudways 为避免远程管理冲突而做出的有意选择。
Cloudways 对插件路线的态度很明确：它更像是一个过渡方案，而不是最终目的地；如果你想要完整栈、自动备份、一键 staging、Cloudflare 集成和托管缓存，官方建议的最佳实践是把外部站点迁移到 Cloudways，而不是长期远程管理它。
对于一个完全托管在 Cloudways 上的代理机构而言，这些都无关紧要。对于那些仍然在别处运行少数几个站点的人来说——而我多年接触的代理机构里，大多数都至少有几个这样的站点——这个插件确实是一个用于基础监控和更新的真实选项，只是不能替代原生仪表盘的功能。
范围问题已经说明之后，接下来就是实际操作：把一个 WordPress 应用纳入管理。Cloudways 提供了两种进入原生 Site Manager 的方式，而这两种方式并不同样适合完成这件事。
下面是我第一次到达这里时的具体过程。从 Cloudways 首页仪表盘，我点击进入我的服务器，再进入服务器上的 WordPress 应用，这会把你带到该应用的 Access Details 页面。
那里的左侧边栏列出了 Access Details、Staging Management、Monitoring、Application Security、Domain Management，接着是 Site Manager，旁边标有 “New” 标签。点击它会直接进入一个标题为 “Simplify App Management with Site Manager” 的界面，整个界面只针对这一个应用，Basic 和 Pro 两个计划卡片并排显示。
我点击了 Get Pro。这时事情开始出问题。
界面切换到 “Subscribing to the Site Manager Plan…”，并显示了一条说明，表示 Cloudways 正在安装插件并同步站点数据，这可能需要几分钟，具体取决于应用大小。
它运行了大约两分钟，然后失败，返回一条红色错误通知：“Please delete existing plugin and install again.” 我之前并没有安装过任何插件，所以这条信息本身并没有告诉我到底出了什么问题。
我第二次点击了 Get Pro，还是在同一个计划页面上，什么都没改。那一次成功了。它运行了大约三分钟，并以绿色成功通知结束，确认我已经订阅了 Site Manager 计划，随后我进入了该应用的 Site Manager Overview 页面，插件数量、主题数量、性能评分以及 Manage Updates 表都已加载并准备就绪。
只要你要管理的站点超过一个，这条路径就值得使用，而且下面就是我如何找到并使用它的具体过程。
从 Cloudways 首页仪表盘，左侧导航有一排图标：Home、Flexible、Autonomous、Integrations 和 Agency Partners。我点击了 Integrations。这会打开一个卡片面板，其中包括 Site Manager（标有 “New”）、Application Migration、DNS Made Easy、CookieYes 以及 Equalize Digital Accessibility Checker 等。
点击 Site Manager 卡片后，我进入了一个与路径 1 完全不同的界面，它位于面包屑 Integrations → Add-Ons → Site Manager 下，并带有自己的标签页：Overview、Manage Updates、Auto Updates、History。
这个 Overview 页面才是真正的指挥中心。它显示账户级统计信息：Total Apps on Site Manager、Apps on Free Plan、Apps on Pro Plan、Apps with Auto Updates，下面还有一个 Manage Applications 表，列出所有已经接入的应用。
要继续添加，我点击了表格右上角的 Add Apps to Site Manager。这会打开一个两步向导：
列表上方有一条说明，表示它会排除 staging 应用、已停止服务器上的应用，以及任何已经运行旧版 SafeUpdates 插件的应用。我勾选了想要添加的应用，然后点击 Select Plan。
一旦进入向导页面，整个流程不到一分钟，而且它一次性作用于我在第一步中勾选的所有应用，不需要每个站点重复选择计划。
现在我已经通过两条路径都接入过应用，下面这个发现改变了我对这个产品日常维护方式的看法。我又在一台已经有 Site Manager 正在管理另一个应用的服务器上新增了第二个 WordPress 应用。
我原本以为这个新应用会自动出现，因为它就摆在 Site Manager 已经认识的应用旁边。结果没有。账户级仪表盘里的 “Total Apps on Site Manager” 计数没有任何变化，直到我手动把新应用完成接入。
这是一个设计选择，但也是一个有运营成本的设计选择：
Site Manager 分为一个真正能用的免费层和一个 Pro 层，后者解锁的是代理机构真正会围绕其建立工作流的功能。
| 功能 | Basic（免费） | Pro |
|---|---|---|
| 站点概览 | 是 | 是 |
| 管理用户、主题、插件 | 是 | 是 |
| 快速更新 | 是 | 是 |
| WordPress 单点登录 | 是 | 是 |
| 集中式仪表盘 | 是 | 是 |
| Safe Updates（暂存克隆 + 回归测试） | 否 | 是 |
| 计划自动更新 | 否 | 是 |
| 站点性能监控 | 否 | 是 |
| 活动日志 | 否 | 是 |
| 更新历史 | 否 | 是 |
Basic 不是一个阉割版试用。它包含真正的站点概览、无需进入 wp-admin 就能管理用户、主题和插件的能力、一键 WordPress 单点登录、Quick Updates，以及尤其重要的集中式仪表盘本身。
Cloudways 没有把核心的“把所有站点放在一个地方查看”体验锁在付费墙后。被锁住的是让这个仪表盘足够可信、可以在不持续盯着它的情况下直接操作的那些功能。
Pro 目前在 Public Preview 期间可免费使用，不论其标价如何，标价是每个应用每月 $3，当你的应用数量超过 5 个时降到每个应用 $2。
在假设 Pro 会便宜扩展之前，最好先算清楚这个折扣门槛：
| 管理站点数 | Pro 成本（标价） |
|---|---|
| 3 个站点 | $9/月 |
| 5 个站点 | $10/月（$2/应用） |
| 10 个站点 | $20/月 |
| 25 个站点 | $50/月 |
| 50 个站点 | $100/月 |
这些数字与一次损坏且没有备份的更新可能带来的客户信任损失相比都不算离谱，但按应用计费意味着账单会随着你的站点组合线性增长，而不是像某些竞争工具那样在更高层级出现阶梯式折扣。
在完成接入和定价之后，接下来这部分评测将从日常使用的实际感受开始，先讲一个值得理解的架构。
这是我花最久时间才真正搞清楚的 Site Manager 设计部分，而界面本身并没有对此做任何说明。
这三个入口其实都是通往同一个房间的三扇门。单个应用视图适合已经在某个站点内工作、顺手看到待更新项目的人。账户级行操作适合正在浏览整个站点组合并决定立即处理某个站点的人。
计划任务标签页则是为了把人从流程中完全移除。
在刚才说的三个入口中，本节覆盖前两个，也就是单个应用视图和账户级行操作，因为它们打开的是同一个更新机制。
每个计划层级都提供 Quick Update。执行它只需几秒：更新会直接安装到生产环境，不会先做兼容性检查，也不会先创建备份。
Cloudways 自己界面中的说明很诚实，提醒这项操作“如果更新不兼容，可能会带来风险。”
我没有在这次测试中运行 Quick Update，所以无法亲自描述失败时屏幕会怎样。这是本次评测中的一个真实缺口，对于任何没有真正触发过失败的人——包括我在内——关于 Quick Update 失败表现的说法都应该持保留态度。
Safe Update 才是 Pro 价格的价值所在，而且值得完整说明，因为这个过程比“先备份，再更新”要复杂得多。
下面是我具体如何触发它的。从 Integrations → Site Manager 下的账户级 Overview 表格中，我找到那个有待更新项目的应用行，点击了该行末尾的三点 Actions 菜单。它打开了四个选项：WP-Admin、App Overview、Manage Updates 和 Manage Plan。我点击了 Manage Updates。
这会打开一个模态窗口，列出所有有待更新的插件，我这里有四个：Breeze、Elementor、Object Cache Pro 和 WP ULike，每个都以已勾选条目显示，并标注当前版本以及将要更新到的版本。
列表下方有两个单选项：Quick Update 和 Safe Update，每个都配有一行关于取舍的说明。我选择了 Safe Update，然后点击 Proceed。
接下来打开的不是单一进度转圈，而是一个实时更新的分阶段清单。
Staging environment：
Production：
我在 6:21 pm 开始运行，6:27 pm 完成。对于 4 个插件，在完整的 staging 到 production 循环中用了 6 分钟。这个模态窗口本身提示预期“通常少于一分钟”，而我的运行时间远远超过了这个估计。
如果你要在维护窗口里对一批插件运行 Safe Update，最好按分钟而不是按秒来安排，尤其是插件数量增长时，这个标注时长和实际时间之间的差距值得提前考虑，而不是到时候才惊讶。
成功通知确认了结果，而它一结束，账户级 History 标签页就把它记录为 “On-Demand Successful: Plugins (4)”，并提供了通向完整详情的链接。
这种形成闭环的体验——看着一个操作发生，然后立刻能够指向一条永久记录——正是代理机构向客户证明的那种东西，而 SafeUpdates 从来没有提供过这一点。
这两个设置都在计划流程里，而不是在按需更新界面里，所以很容易被忽略：
这两个默认设置共同决定了无人值守的夜间更新运行，最终是只会让你醒来看见一个被标记、待处理的插件，还是会让整个站点因为某个不兼容主题而卡在更新中途。值得在把任何计划交给无人值守之前先检查一下。
前两个入口已经讲完。本节讲第三个：把人从流程中彻底移除。通过同一个账户级 Site Manager 页面进入的 Auto Updates 标签页，是“把多个站点当作一个来管理”这一卖点最终能不能成立的地方。就我的测试而言，它成立了。
下面是我具体的设置过程。从 Integrations → Site Manager，我点击了顶部标签行里的 Auto Updates 标签页。
在尚未安排任何计划时，页面显示一个空状态，“No Auto Updates Schedule”，以及一个按钮：Set Auto Update Schedule。
点击它会打开一个向导，“Set Auto Update Schedule”，一次性引导完成以下步骤：
随后打开第二个界面，“Create Auto Update Schedule”，涵盖：
点击底部的 Set AutoUpdate Schedule 会保存设置，并一次性应用到我在第二步中选择的所有应用，不需要为每个站点重复配置。
前面说的三个入口和更新机制讲的是“怎么做”。最后这个功能讲的是“证据”：一份独立于更新流程本身的、永久记录发生了什么的日志。
下面是我如何把它开启的。
从那个应用自己的 Site Manager Overview 页面——也就是通过路径 1 订阅后会进入的那个页面——在性能环旁边有一张名为 “Activity Logs are Disabled” 的卡片，下面有简短说明和一个按钮：Enable Activity Logs。
我点击它后，卡片立即更新，没有确认弹窗，也没有额外步骤。紧接着查看 Integrations → Site Manager 下的账户级 Manage Applications 表格，该应用的 Activity Logs 列已经从 Disabled 变成 Enabled，而且不需要刷新页面。
这个功能属于 Pro，它存在的意义是回答每个代理机构最终都会被客户问到的问题：谁改了什么，以及什么时候改的？
如果没有它，这个答案通常只能依赖 WordPress 里的日志插件，而那类插件把数据写在站点自己的数据库里，时间一长会膨胀，而且无法防止篡改。把这份记录放在 WordPress 安装之外、放在托管层里，会给任何面向客户的业务带来实质上不同层级的信任感。
在完整功能、成本和粗糙边界都摆出来之后，最后的问题就是：它是否适合你的具体站点组合。
最明显的适用对象是 管理多个、最好是很多 WordPress 站点的代理机构或自由开发者，并且这些站点 全部已经托管在 Cloudways 上。在这种情况下，更新失败会带来真实的客户信任成本，而不是仅仅是个人的不便。
对于一个混合站点组合的人来说，它是 部分适用。免费的 Site Manager 插件可以把外部站点纳入基础监控和更新，但让原生仪表盘真正值得付费的那些功能——基于暂存的 Safe Update、可视化回归、活动日志——在这些站点真正迁移到 Cloudways 之前都无法使用。
对于单站点用户来说，它根本是 不必要的。免费层理论上可用，但这个产品的全部存在意义就是解决站点组合规模化的问题，而单个站点不会产生这种问题。
是的，Site Manager 值得采用，前提只有一个：你的站点已经托管在 Cloudways 上。在这个边界之内，Site Manager 确实兑现了承诺：一个真正的跨应用仪表盘、一个在触碰生产环境前会先备份的 Safe Update 路径，以及把更新当成全局动作而不是逐个登录处理的批量计划。
超出这个边界，它只是一个更轻量的工具，并附带明确的迁移导向。最适合它的，是正在把客户站点整合到 Cloudways 上、并需要一个地方来证明发生了什么以及什么时候发生的代理机构。
| Description | Expert Review |
|---|---|
| 托管型 WordPress 主机，提供高速、安全和免烦恼更新。 | Read Wordpress Hosting Review |
| 灵活的高性能云托管，具有可扩展的资源和可靠性。 | Read Cloud Hosting Review |
| 专为企业通信需求量身定制的安全高效电子邮件托管。 | Read Email Hosting Review |
| 优化的Magento托管，提供快速速度和增强的电子商务性能。 | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
是的。Cloudways Site Manager 是一款原生附加组件，可集中管理已托管在你 Cloudways 账户中的 WordPress 应用的更新、性能监控和活动日志。另有一款独立的免费配套插件，为托管在任何位置的 WordPress 网站提供轻量级监控和更新功能。
不是通过本次评测中测试的原生仪表盘进行的，因为它仅限于已托管在 Cloudways 上的应用。一个免费的插件，同样名为 Cloudways Site Manager，并由其与 WP Remote 共同开发，可以将外部站点纳入核心、插件和主题监控及更新，但不包括 Safe Update 的暂存克隆、可视化回归测试或服务器级缓存。
Basic 版本是免费的，涵盖站点概览、用户和插件管理以及快速更新。Pro 版增加了安全更新、计划任务、性能监控和活动日志，价格为每个应用每月 3 美元，当达到 5 个或更多应用时降至 2 美元，并且目前在公开预览期间可免费使用。
快速更新会在几秒内直接将更改应用到生产环境，没有备份或兼容性检查。安全更新会创建一个预发布克隆，检查兼容性，更新每个包，运行可视化回归测试，并且只有在该测试通过时才推送到生产环境。
是的。新应用永远不会自动加入，即使它们被添加到已经运行其他 Site Manager 应用的服务器上也是如此。每个站点都需要自己的入门步骤，无论是单独进行，还是通过 Integrations 下的批量向导进行。
HostAdvice.com在完全独立于任何实体机构的情况下提供了专业的网络主机评价服务。我们的评论不偏袒、诚实而且对所有的评论都以相同的审查标准进行。
我们的收入是从我们从评论的公司那里收取得来的。但相关的服务及产品的补贴并不影响我们评论的方向及结论，也不会影响我们对特定主机公司的排名。
所收取的补偿金包括：账户采购成本、测试成本和支付的相关版税等。
