我在 Cloudways Site Manager 中加入了兩個 WordPress 應用程式作為今次評測，一個透過應用程式自己側邊欄內的 onboarding 畫面加入，另一個則透過位於帳戶層級的批量流程加入。
之後，我對四個外掛執行了一次真正的 Safe Update，建立了一個覆蓋兩個網站的共用自動更新排程，開啟了活動記錄，並在帳戶層級儀表板停留了足夠長時間，去理解同一項資訊在多個位置都會出現，而這件事為何比聽起來更重要。
Site Manager 取代了 Cloudways 早前一個名為 SafeUpdates 的附加元件。 了解 SafeUpdates 做不到什麼，幾乎就能解釋現有產品的所有設計決定。
SafeUpdates 全部都透過 SSH 運行，對於管理超過幾個網站的人來說，這帶來了一組特定問題：
管理二十個或以上 WordPress 安裝的代理商對 Cloudways 大意上表示，這工具在擴展之前都運作良好，但擴展本來就是他們選用 Cloudways 的整個原因。
Site Manager 正正是對這些回饋的直接回應。這個背景對閱讀餘下評測非常重要，因為它解釋了為何產品某些部分對仍然處於 Public Preview 的東西來說顯得異常成熟，也解釋了為何其他部分，例如你在第一天會遇到的 onboarding 步驟，仍然能看見縫隙。
有了以上背景，下一個問題就是範圍：這個工具實際可以涵蓋什麼。在深入 onboarding、更新和排程之前，先準確說明 Site Manager 的覆蓋範圍和不涵蓋什麼是值得的，因為誠實的答案比一個簡單的是或否更細緻。
所有可加入帳戶層級 Site Manager 的應用程式，無論是透過單一應用程式畫面還是透過 Integrations 之下的批量精靈，都來自已在我 Cloudways 帳戶內的伺服器。
畫面上沒有可以貼上外部託管安裝憑證的欄位，也沒有連接到其他主機上網站的連接器。
本次評測涵蓋的完整功能組合，Safe Update 的 staging clone、視覺回歸測試、活動記錄、批量排程，全部都位於這個原生、Cloudways 託管的層面內。
Cloudways 亦有推出一個免費 WordPress 外掛，同樣名為 Cloudways Site Manager，由 WP Remote 共同開發。
與原生儀表板不同，這個外掛可直接安裝到任何 WordPress 網站上，不論其託管在何處，意味著它可以把外部、非 Cloudways 網站帶入同一個集中式視圖的某個版本中。
不過，這確實是一個與原生儀表板不同的產品，而兩者之間的差距非常重要：
| 功能 | 原生 Site Manager（Cloudways 託管應用程式） | Site Manager 外掛（任何主機） |
|---|---|---|
| 集中式儀表板 | 有 | 有 |
| 核心、外掛、佈景主題更新 | 有 | 有 |
| Safe Update（staging clone + 視覺回歸） | 有 | 沒有 |
| 伺服器層級快取（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 完全不同的畫面，該畫面位於 breadcrumb 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。
一旦到了精靈畫面，整個流程不到一分鐘就完成，而且是一次過套用到我在第一步選取的每一個應用程式，不需要每個網站都重複選擇一次方案。
在經歷過這兩條路徑之後，以下這個發現改變了我對這個產品日常維護的看法。我把第二個 WordPress 應用程式加到同一台伺服器上，而那台伺服器已經有另一個應用程式正在由 Site Manager 管理。
我原以為新應用程式會自動出現，因為它就放在 Site Manager 已經認識的應用程式旁邊。但它沒有。帳戶層級儀表板的 “Total Apps on Site Manager” 數字一直不變，直到我手動把新應用程式走一遍 onboarding。
這是一個設計選擇，但它也是一個有營運成本的設計選擇：
Site Manager 分為一個真正有用的免費層級，以及一個 Pro 層級，後者解鎖了代理商真正會建立工作流程的功能。
| 功能 | Basic（免費） | Pro |
|---|---|---|
| Site Overview | 有 | 有 |
| 管理 Users、Themes、Plugins | 有 | 有 |
| Quick Updates | 有 | 有 |
| WordPress Single Sign-On | 有 | 有 |
| Centralized Dashboard | 有 | 有 |
| Safe Updates（staging clone + regression test） | 沒有 | 有 |
| Scheduled Auto Updates | 沒有 | 有 |
| Site Performance Monitoring | 沒有 | 有 |
| Activity Logs | 沒有 | 有 |
| Update History | 沒有 | 有 |
Basic 不是一個削減功能的試用版。它包括真正的網站總覽、無需進入 wp-admin 便可管理 users、themes 和 plugins 的能力、一鍵 WordPress single sign-on、Quick Updates，以及最重要的是中央儀表板本身。
Cloudways 並沒有把核心的 “一次過看見所有網站” 體驗設在付費牆後面。被收費限制的是，所有讓這個儀表板足夠可靠、可以不用人手看管就直接行動的功能。
Pro 在 Public Preview 期間目前可以免費使用，不論其標價為何，標價是每個應用程式每月 $3，超過五個應用程式後則降至每個應用程式 $2。
在假設 Pro 很便宜之前，這個折扣門檻值得先算一算：
| 管理網站數量 | Pro 成本（標價） |
|---|---|
| 3 個網站 | $9/月 |
| 5 個網站 | $10/月（$2/應用程式） |
| 10 個網站 | $20/月 |
| 25 個網站 | $50/月 |
| 50 個網站 | $100/月 |
以單一壞掉而且沒有備份的更新可能對客戶信任造成的代價來看，以上數字都算合理，但按每個應用程式計費代表賬單會隨你的組合一直線增長，而不是像某些競爭工具那樣在更高層級出現階梯式折扣。
在完成加入與定價之後，評測餘下部分會談日常實際使用起來是怎樣，先從一個值得理解的架構開始。
這是 Site Manager 設計中我花最長時間才真正弄明白的部分，而且介面本身完全沒有解釋。
這三扇門其實都通往同一個房間。單一應用程式視圖是給已經在特定網站裡工作、偶然看到有待更新項目的人用的。帳戶層級列動作則是給正在掃描整個組合，並決定立即對某一個網站採取行動的人用的。
排程標籤則是用來把人完全移出迴路。
在剛才描述的三扇門之中，這一節會涵蓋前兩扇，也就是單一應用程式視圖和帳戶層級列動作，因為它們都會打開同一個更新機制。
所有方案層級都提供 Quick Update。套用它只需幾秒：更新會直接安裝到 production，不會先做相容性檢查，也不會先建立備份。
Cloudways 自己的介面文字對這個取捨說得很坦白，提醒這項功能「如果更新不相容，可能帶來風險。」
在本次測試中，我沒有執行 Quick Update，所以無法親身描述它失敗時螢幕上實際會怎樣。這確實是本評測中的一個缺口，而對於我或任何其他沒有親自觸發失敗的人所作出的任何關於 Quick Update 失敗行為的說法，都應該保持適度懷疑。
Safe Update 才是 Pro 值回票價的地方，而且值得完整走一遍，因為整個過程比 「先備份，再更新」 更複雜。
以下是我如何觸發它的。從 Integrations → Site Manager 下的帳戶層級 Overview 表格，我找到有待更新項目的應用程式那一行，然後點擊該行末端的三點 Actions 選單。它打開了四個選項：WP-Admin、App Overview、Manage Updates 和 Manage Plan。我點了 Manage Updates。
之後會打開一個 modal，列出所有有待更新的外掛，我的情況有四個：Breeze、Elementor、Object Cache Pro 和 WP ULike，每個都以已勾選項目顯示，並列出目前版本以及將要更新到的版本。
列表下方有兩個單選選項：Quick Update 與 Safe Update，各自附有一行說明取捨。我選擇了 Safe Update，然後點擊 Proceed。
接下來打開的 modal 不再是一個單一進度轉輪，而是顯示一個會即時更新的分階段檢查清單。
Staging 環境：
Production：
我在 6:21 pm 開始執行，並在 6:27 pm 完成。四個外掛，連同完整的 staging 到 production 流程，共用了六分鐘。modal 本身的預期說明是這個過程「通常少於一分鐘」，但我的執行時間遠遠超出這個估計。
當你要在維護時段中對一批外掛執行 Safe Update 時，這個估計與實際時間之間的落差，值得按分鐘而不是按秒去規劃，尤其外掛數量增加時更是如此。
一則成功通知確認了結果，而且一完成，帳戶層級 History 標籤就把它記錄為 “On-Demand Successful: Plugins (4)”，並提供連結通往完整詳情。
能夠看到動作發生，然後立即又能指出一個永久記錄，這種把流程閉環的體驗，正是代理商需要的客戶可見證據，而 SafeUpdates 從來沒有給到。
這兩個設定都位於排程流程中，而不是即時更新畫面內，所以很容易被忽略：
這兩個預設值一起決定了一次無人看管的夜間更新執行，是讓你醒來只看到一個被標記的外掛留在佇列，還是讓整個網站因為某個不相容佈景主題而卡在更新中途。值得在把任何排程交給系統自動跑之前先檢查這兩項。
以上已涵蓋前兩扇門。這一節則涵蓋第三扇門：把人從流程中完全移除。Auto Updates 標籤位於同一個帳戶層級 Site Manager 頁面內，這裡就是「把很多網站當成一個來管理」這個賣點究竟能否成立的地方。以我的情況，它成立了。
以下是我如何設定的。從 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。
我點擊它後，卡片立即更新，沒有確認 modal，也沒有額外步驟。之後我再看一次 Integrations → Site Manager 下的帳戶層級 Manage Applications 表格，該應用程式的 Activity Logs 欄位已經由 Disabled 變成 Enabled，而且無需重新整理頁面。
這個功能屬於 Pro，存在的目的就是回答每個代理商最終都會被客戶問到的問題：誰改了什麼，又是在什麼時候改的？
如果沒有它，答案通常就會存在於 WordPress logging 外掛，寫入網站自己的資料庫，時間久了會膨脹，而且無法防止被竄改。把這份記錄放在 WordPress 安裝之外、放在 hosting 層，對任何面向客戶的工作來說，確實是更高一層次的信任。
在把完整功能、成本，以及粗糙之處都攤開之後，最後的問題只是它是否適合你的特定組合。
最明顯的對象是管理幾個、理想上是很多個 WordPress 網站的代理商或自由開發者，而且這些網站已經完全部署在 Cloudways 內，在這種情況下，一次壞掉的更新帶來的是客戶信任上的真實成本，而不只是個人不便。
對於混合組合的人來說，這只是一個部分適用的工具。免費的 Site Manager 外掛可以把外部網站帶入，用於基本監控和更新，但讓原生儀表板值得付費的功能，像 staging-based Safe Update、視覺回歸、活動記錄，仍然要等那些網站真正搬到 Cloudways 後才用得到。
對於單一網站擁有者來說，這根本沒有必要。免費層級在技術上是可行的，但整個產品本來就是為了解決組合規模的問題，而單一網站永遠不會產生這種問題。
是的，這個 site manager 值得採用，前提只有一個：你的網站本來就已經在 Cloudways 上。只要在這個界限內，Site Manager 就能兌現它的承諾，提供一個真正的跨應用程式儀表板、一條在碰到 production 之前先備份的 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 的 staging 複製、視覺回歸測試或伺服器層級快取。
Basic 方案免費，涵蓋網站概覽、用戶及外掛管理，以及 Quick Updates。Pro 版本則加入 Safe Updates、排程、效能監察和活動記錄，收費為每個應用程式每月 US$3，當有五個或以上應用程式時降至 US$2，並且目前在 Public Preview 期間可免費使用。
Quick Update 會在數秒內直接將變更套用到正式環境，無需備份或相容性檢查。Safe Update 會建立一個暫存複本，檢查相容性，更新每個套件，執行視覺回歸測試，並且只有在該測試通過時才會推送到正式環境。
係。新應用程式永遠唔會自動加入，即使佢哋被新增到一部已經有其他 Site Manager 應用程式運行緊嘅伺服器上。每個網站都需要自己嘅入門步驟，可以逐個進行，或者透過 Integrations 底下嘅批量精靈完成。
