WordPress 主機：你實際付費買到的是什麼

WordPress 主機的售價從每月大約 3 英鎊一路排到好幾百英鎊，而價格帶兩端的方案，用來描述自己的措辭幾乎一模一樣。快。安全。有備份。有支援。真正能讓買家分辨它們的規格，也就是網站跑在哪個 PHP 分支上、背後是哪一種資料庫引擎、總共有幾層快取、其中又有幾層真的開著，通常並不出現在你被要求下單的那個頁面上。

這種缺席本身就是產品的一部分。「代管」是一個行銷分類而不是技術分類，沒有任何標準組織為它下過定義。兩家都用這個詞的服務商，可能在是否執行持久化物件快取、是否允許你保留自己的快取外掛、備份能不能離開他們的基礎架構、你究竟能不能開一個 shell 這些問題上完全不同。

以下寫的正是那些頁面略過的規格：WordPress 到底要求什麼，技術堆疊裡哪些部分真的影響網頁速度，代管主機加了什麼又悄悄拿走了什麼，以及每個級距現實的月費。

買 WordPress 主機時你實際付費買到的是什麼？ 四樣東西。一個符合 WordPress 自己公布基準的 PHP 版本與資料庫引擎。若干層快取，否則你得自己安裝與調校。營運工作，也就是更新、測試環境、備份與防火牆。以及應付無法快取請求的餘裕。形象網站幾乎不需要第四樣。商店或會員網站會把大部分預算花在那裡。

WordPress 主機是一個類別名稱，不是一份規格書

同一個類別內部的價格落差就是證據。兩個都掛著代管 WordPress 主機的方案，可以分別停在每月 20 英鎊與 250 英鎊，而行銷文案不會解釋這個落差，因為構成落差的東西文案根本沒提。

在便宜的那一端，你買到的是一台共享機器上的一塊切片，上面有一個 PHP-FPM 行程池、一層網頁快取與一個控制面板。在昂貴的那一端，你買到的是隔離的運算資源、持久化物件快取、測試環境、代管防火牆、一支會讀你錯誤紀錄的支援團隊，以及當一次核心更新弄壞版型時在合約上負責的人。

兩者都是正當的產品。問題在於買家看不出擺在面前的是哪一種，於是決策就交給了價格，以及依聯盟行銷佣金排序的評測網站。結果在兩個方向上都可以預料。形象網站落在它一輩子用不完的 150 英鎊方案上，而 WooCommerce 商店落在 5 英鎊方案上，然後在第一個忙碌的週六於結帳環節倒下。

出路是依四個問題選購，而不是依級距名稱：哪個 PHP 分支，有哪幾層快取，這個方案能吸收多少無法快取的請求，以及你離開時你的資料會怎麼樣。

WordPress 對伺服器的真實要求

WordPress 公布了一個需求頁面，它很短，而這正是它被略過的原因。請把它當作採購規格來讀，因為不符合它的方案，在討論效能之前就已經出局。

PHP 版本

WordPress 需求頁面把建議基準寫作「PHP 版本 8.3 或更高」。同一頁還帶著一條比建議更重要的警告：WordPress「仍可在 PHP 7.4 以上與 MySQL 5.5.5 以上執行，但這些版本已到官方生命週期結束，可能使你的網站暴露於安全漏洞之中」。

整個陷阱就在這一句裡。WordPress 不會因為 PHP 分支老舊就拒絕啟動。它照跑，看起來正常，然後安靜地坐在一個多年沒有收到安全修補的直譯器上。

資料庫

同一頁要求「MariaDB 10.11 以上或 MySQL 8.0 以上」。更舊的引擎仍能運作，這正是這麼多網站還留在上面的原因。WordPress 自己的使用統計顯示，大約每六個回報的安裝就有一個回報 MySQL 5.x 版本，遠低於寫明的下限，其中光是 MySQL 5.7 就占回報網站的約 12%。

後果不是網站會壞，而是你錯過了引擎層面的改進，而那些改進恰好作用在最難快取的工作負載上；同時你還背上一次遲早都得做的遷移。

HTTPS 與擴充套件

HTTPS 被列為「每個安裝都必需」，不是建議。到了 2026 年還把憑證當成付費加購項目的主機商，已經順便告訴了你這個方案其餘部分的水準。

除此之外，WordPress 主機手冊把 json 與 mysqli 列為必需，把 curl、dom、exif、fileinfo、hash、igbinary、imagick、intl、mbstring、openssl、xml 與 zip 列為強烈建議。有兩個值得在業務面前點名。沒有 zip，外掛與核心的更新封裝無法解壓。沒有 imagick，媒體上傳會退回較弱的影像函式庫，於是在任何人碰最佳化外掛之前，你的圖片品質就已經變差了。

PHP 版本是帳單上槓桿最高的一行

在主機商掌控的一切當中，PHP 分支的效果與成本比最好。在多數面板上它就是一個下拉選單。什麼都不用重建，什麼都不用遷移，一個本來就相容的網站就這樣開始跑在更快也更受支援的直譯器上。

它多年不變的原因是組織性的，不是技術性的。沒有人擁有它。當初做這個網站的團隊早已離開，主機商不會片面更動，因為一個廢棄外掛拋出致命錯誤就變成他們的責任，而業務端也沒有理由去想一個從來沒人給他們看過的數字。

所以，問一家候選主機商的第一個問題不是速度，而是這個方案預設跑哪個 PHP 分支、提供哪些分支，以及你能不能不開工單自己切換。一家只提供 WordPress 已不再建議的分支的主機商，等於同時回答了其餘所有問題。

在測試環境試，絕不要直接切正式站。從 PHP 7.4 遷到 8.3 的網站，通常會從無人維護的外掛冒出兩三條棄用警告，那才是真正的成本。請預留半天到一天的開發工時，我們在WordPress 開發者費率與該問的問題一文裡講得更細。

PHP 之爭的安全那一半

人們給出的升級 PHP 的理由是效能。真正重要的理由是安全，而且它是可以量測的，不是可以爭論的。

PHP 自己發布受支援版本時程。每個分支獲得兩年的主動支援，之後再有兩年只提供安全修補。截至 2026 年 9 月，PHP 8.2 處於僅安全修補狀態直到 2026 年 12 月 31 日；PHP 8.3 的主動支援已於 2025 年 12 月 31 日結束，之後僅安全修補直到 2027 年 12 月 31 日。PHP 8.4 的主動支援持續到 2026 年 12 月 31 日，安全修補到 2028 年 12 月 31 日；PHP 8.5 主動支援到 2027 年 12 月 31 日，安全修補到 2029 年 12 月 31 日。比這更舊的都已結束：PHP 8.1 於 2025 年 12 月 31 日結束，PHP 8.0 於 2023 年 11 月 26 日，PHP 7.4 於 2022 年 11 月 28 日。

把這些對照 WordPress 網站實際跑的東西。WordPress 統計頁面回報，約 38.8% 的安裝跑在一個完全生命週期結束的分支上，約 23.2% 仍停在 PHP 7.4 或更舊。只有約 36.4% 達到 WordPress 建議的 PHP 8.3 基準，另有 24.8% 停在 PHP 8.2 上，而它將在今年年底失去安全支援。

也就是說，多數 WordPress 網站跑的直譯器要麼已經收不到安全修補，要麼離那一天只剩幾個月，而幾乎每一例都只是一個沒人看過的主機設定。修正它的花費比一份外掛授權還低，所以我們的WordPress 安全強化清單把它列為第一步。

快取的層次，依一次請求遇到它們的順序

主機商提出的效能主張幾乎全是關於快取的主張，而幾乎每個買家都把它們聽成一個籠統的承諾。快取有四個不同的層，它們的次序固定，各自省下不同種類的工作。下面的順序就是一次請求穿過它們的順序，被前面某一層回應的請求永遠不會抵達後面的層。

邊緣快取，也就是 CDN

一次請求最先遇到的，是完全在你伺服器之外、位於靠近訪客的接取點網路上的快取。如果回應已經存在那裡，你的主機根本看不到這次請求。

這一層省下的不只是運算，還有網路距離。曼徹斯特的訪客命中倫敦的邊緣節點，就避開了一次跨大西洋往返。對靜態資源來說它幾乎免費，永遠值得擁有。對 HTML 來說它很強大但有條件，因為你必須告訴邊緣哪些回應是私人的、絕不可共享。

整頁快取

第二層保存一個頁面算完的 HTML，於是 PHP 與資料庫不必再跑一遍。WordPress 主機手冊建議使用 NGINX 或 Varnish 這類反向代理，它「把輸出直接存進伺服器記憶體或硬碟」，並補上了決定這一層能否奏效的規則：「把所有已登入使用者排除在快取之外是個好主意，因為他們本來就該看到個人化內容。」

正是這一層讓廉價主機顯得體面。當它奏效時，訪客拿到的是一個檔案，而 PHP 版本、資料庫引擎與外掛數量對這次請求都不再重要，因為它們一個都沒有執行。

物件快取

第三層快取的是單筆資料庫查詢的結果與算出來的值。WordPress 預設自帶這一層，但它不是持久的。WP_Object_Cache 文件說得很直白：「預設情況下物件快取是非持久的。這表示存入快取的資料只存在於記憶體中，而且只在該次請求期間存在。」

讓它持久化，意味著透過一個 drop-in 把 Redis 或 Memcached 放到它後面，從而把一個每次頁面載入都要重建的快取，變成一個跨請求、跨訪客共享的快取。當頁面整體不再可快取時，正是這一層開始發揮作用，而它也是廉價方案裡最常缺席的一層。

操作碼快取

第四層是 OPcache，它把你的 PHP 檔案編譯後的位元組碼放進共享記憶體，讓直譯器不必在每次請求時重新解析與編譯。主機手冊寫道：「對於正式環境的 WordPress，建議為網頁請求啟用 OPcache，並依網站或主機平台的規模設定其大小。」

這帶來一個部署上的後果。因為 OPcache 持有的是編譯後的程式碼，一次部署必須重設它或讓改動過的檔案失效，否則伺服器會繼續跑上一個版本。一家說不清 OPcache 如何失效的主機商，就是那種外掛更新後好幾分鐘看起來什麼都沒發生的主機商。

為什麼形象網站在幾乎任何主機上都很快

順著這四層推下去，會得到一個讓主機產業不太舒服的結論。如果每位訪客都是匿名的、每個頁面都可快取，那麼整頁快取會回應幾乎全部流量，而它背後那台機器的規格幾乎不起作用。

所以，一個五頁的公司網站跑在 4 英鎊的方案上、配一層像樣的網頁快取，伺服器回應時間可以贏過一個臃腫網站跑在 200 英鎊方案上的成績。便宜那個在送檔案，貴那個在跑 PHP。

要盯的數字是首位元組時間，它本身並不是一項核心網頁指標。Google 的 Web Vitals 總覽把它歸入輔助指標，用來「診斷由伺服器回應緩慢引起的 LCP 問題」。那恰恰是主機商能控制的那一小片網頁速度。

WordPress 也大致同意，同意到把它寫進了核心。WordPress 6.1 新增的網站健康整頁快取檢測，會檢查「網站是否在使用整頁快取方案，以及回應時間是否可接受」，預設門檻是 600 毫秒。如果你號稱啟用了網頁快取卻仍高於這個值，那就是快取沒在運作，多加 CPU 也掩蓋不了。

所以對形象網站來說，升級主機通常是買錯了東西。讓它慢的更常是一張過大的主視覺圖、一個送出好幾百 KB CSS 的頁面編輯器，或者六種字重，這正是我們在Elementor 與客製佈景主題的比較裡給出的論點。

登入流量與 WooCommerce 打破了這個模型

上面的一切都假設網頁快取能夠回應。訪客一登入，這個假設就崩塌，主機的經濟學也隨之反轉。

WooCommerce 把這點寫得很清楚。它的快取指南要求你把購物車、我的帳戶與結帳頁排除在網頁快取之外，因為這些頁面「必須保持動態，因為它們顯示的是目前顧客與其購物車的專屬資訊」。它還列出必須繞過快取的 Cookie，包括 woocommerce_cart_hash、woocommerce_items_in_cart 與 wp_woocommerce_session_，並建議把 _wc_session_ 排除在資料庫快取之外。

把它當成一份主機規格來讀，它說的話相當不客氣。在一家商店裡，帶來營收的頁面恰恰是網頁快取碰不到的頁面。目錄頁與商品頁可以為匿名瀏覽者快取。購物車與結帳不行，對任何人、任何時候都不行。

會員網站、學習平台、論壇，以及任何帶客戶專區的網站，情況完全一樣。工作階段 Cookie 一旦設定，多數快取外掛就徹底不再向該訪客提供快取過的 HTML，於是每一次點擊都在執行 PHP 並打到資料庫。正是在這裡，物件快取不再是最佳化而成為承重結構，也正是在這裡，廉價方案會以任何合成首頁測試都看不出的方式讓你受傷，詳見你的 WooCommerce 商店為什麼慢。

代管 WordPress 主機實際包含什麼

剝掉形容詞，代管主機會收斂成一組相當一致的營運工作。誠實地為這份工作定價是值得的，因為對一家沒有技術人員的企業來說，買它往往比自己做便宜。

更新

代管方案通常會自動套用核心更新，有時也管外掛更新，偶爾還會在前後做一次視覺回歸檢查。這裡有用的一點，是先弄清 WordPress 自己已經免費做了多少。

WordPress 多年來預設自動更新次要核心版本與翻譯檔，而且自 5.6 起，新安裝預設啟用自動更新，除非偵測到版本控制簽出，否則次要與主要核心版本都在內；既有安裝則維持舊行為。所以你付費買到的不是核心的次要更新，而是外掛更新、其中某個更新出問題時的回復，以及有人注意到它出了問題。

測試環境與備份

一鍵測試環境確實有價值，也確實很難自己搭。請用兩個細節而不是它存不存在來判斷：把測試環境推回正式站時會不會覆蓋線上資料庫，那會丟掉自複製以來收到的訂單與留言；以及測試站是否已被擋在搜尋引擎之外並禁止寄信。

防火牆與惡意軟體掃描

多數代管方案都在邊緣包含一層網頁應用程式防火牆與某種惡意軟體掃描。防火牆是實打實的價值，因為網路層的虛擬修補能在一個外掛漏洞被揭露到你完成更新之間買到時間。

掃描比聽起來弱。它通常偵測已知的惡意檔案特徵，也就是說能抓到大量流傳的感染，會漏掉針對性的入侵。請把它當成煙霧警報器而不是鎖，把強化工作留在自己這一側。

代管主機拿走了什麼

限制是沒人讀的那一半，而且通常比功能更有後果。它們的存在有站得住腳的理由，只是那些理由屬於服務商，不屬於你。

公開資料裡最清楚的例子是 WP Engine 的禁用外掛清單，它封鎖的是整類外掛而不是個別害群之馬。快取外掛被禁，因為它們「可能與我們平台內建的快取結構衝突」。備份外掛被禁，理由是它們「毫無必要地讓你的網站變臃腫」。相關文章外掛被禁，因為「對資料庫的消耗極大」。有已知漏洞的外掛被直接封鎖，與平台功能重複的外掛同樣如此。

其中每一條都是合理的工程決定。但它們合起來意味著：你的網站並不像你以為的那樣可以隨時搬走。如果你的建置依賴某個快取外掛的具體設定，那份設定不會跟著你走。

Shell 存取是另一個常見的缺項。不少代管方案完全不提供 SSH，或者只給一個沒有 WP-CLI 的受限 shell，於是換網域後做一次批次搜尋取代這樣的日常工作，就變成了一張支援工單。還有兩點會讓人吃虧：長時間執行的行程常被設上限，因此匯入 50,000 件商品必須分批；對外寄信也經常被封鎖或限速，前提假設是被入侵的網站會被拿去發垃圾郵件。

經不起測試的效能主張

主機行銷靠的是一小組主張，而它們在你追問究竟量了什麼的那一刻就散架了。

「快 20 倍」幾乎從不說明基準。比什麼快，在哪個頁面上，帶哪些外掛，在多大並行下？沒有這四點，這個數字只是兩個未命名的量之間的比值。

「無限頻寬」就擺在同一張表裡的月訪問量額度旁邊。反正頻寬很少成為 WordPress 網站的瓶頸。瓶頸是並行的 PHP 執行能力，而方案通常壓根不提它。

「99.9% 可用性」聽起來是絕對的，其實不是。在一個三十天的月份裡，它允許大約 43 分鐘的停機。三個九是共享主機的正常水準，四個九每月只允許約四分鐘，兩者的差別就是不便與無人察覺之間的差別。請讀清楚沒有達標時那份補償實際賠什麼，這個題目我們在有意義的可用性 SLA裡單獨處理過。

最後一個主張最常見也最有誤導性：一張在快取過的首頁上跑速度測試的截圖。它量的是網頁快取，不是主機，而網頁快取恰恰是各家大同小異的那個元件。

如何正確地測試一家主機

測試主機並不難，但必須走真正讓伺服器幹活的路徑。依序五步。

第一，測一條不走快取的路徑。附加一個唯一的查詢字串來穿透網頁快取，或者請求一個從不快取的頁面，例如購物車或帳戶頁。如果你造不出一個會執行 PHP 的請求，那你量的是一台檔案伺服器。

第二，重複它。單次請求什麼也說不出變異，而變異正是廉價主機露餡的地方。至少取 20 個樣本，並讀第 75 百分位數，這是 Google 在實地資料裡使用的統計量。

第三，從訪客所在的位置測。在伺服器隔壁的資料中心量到的回應，不是你在里茲的顧客收到的回應。

第四，在並行下測。同時發出 10 到 20 個無法快取的請求。這是唯一能暴露 PHP 工作行程耗盡的測試，而工作行程耗盡正是促銷期間放倒商店的東西。

第五，同類相比：同一個 PHP 分支、同一組外掛、同一個佈景主題、同樣的內容量。一次在換主機的同時也換掉外掛堆疊的遷移，對兩者都什麼都沒證明。如果你想把這套流程跑在一個真實網站而不是候選主機上，那正是WordPress 效能稽核在做的事。

主機真正能影響哪些核心網頁指標

核心網頁指標是主機主張與搜尋排名最容易被混為一談的地方，所以有必要說清楚伺服器究竟能影響哪一項。

一共三項，在頁面載入的第 75 百分位數上評估，並依行動裝置與桌機分別統計。Largest Contentful Paint 衡量載入，2.5 秒及以內為良好，2.5 秒到 4.0 秒之間需要改善，超過 4.0 秒為不佳。Interaction to Next Paint 衡量回應性，200 毫秒及以內為良好，到 500 毫秒為需要改善，超過則為不佳。Cumulative Layout Shift 衡量視覺穩定性，0.1 及以內為良好，到 0.25 為需要改善，超過則為不佳。First Input Delay 已被淘汰並由 INP 取代，INP 在 2024 年成為正式的核心網頁指標。

主機直接影響的只有其中一項。伺服器回應時間是 LCP 的一部分，所以一家把它削掉 400 毫秒的主機商，就為每一位訪客的 LCP 削掉 400 毫秒。在一台慢主機上，這可能就是通過與不通過的差別。

它對 CLS 幾乎沒有作用，那來自沒有尺寸的圖片與載入過晚的字型；對 INP 作用也很小，那由主執行緒上的 JavaScript 主導。規則是：如果 LCP 為不佳，而你未快取的伺服器回應高於 WordPress 標出的 600 毫秒，那麼主機是問題的一部分。如果回應很寬裕而 LCP 仍然不佳，問題就在頁面裡，我們的2026 年如何通過核心網頁指標指南才是更該花預算的地方。

備份，以及沒人核對的那部分

除了最便宜的方案，每個方案都在宣傳備份。而買下它的人幾乎沒有誰去問那些真正決定備份值不值錢的問題。

有沒有人真的還原過一次

NCSC 在其小型組織指南裡說得很直白：做完備份之後，「重要的是你知道如何還原它，並檢查它是否包含你全部的重要資料」。沒有測試過的備份是一種信念，不是一項控制措施。

請詢問服務商還原如何啟動、對你這種規模的網站要多久，以及還原資料庫是否也會還原上傳目錄。然後在你真正需要它之前，在測試環境上做一次。要留意的失敗形態是：還原回來了檔案卻沒有資料庫，或者還原「成功」了卻悄悄丟掉自複製以來產生的一切。

保留期與頻率

每日備份加七天保留聽起來很慷慨，直到你想清楚一個 WordPress 網站實際是怎麼出事的。被塗改的網站幾小時內就會被發現。而一次安靜地往舊文章裡注入垃圾連結的入侵，往往幾週後才被發現，那時保留下來的每一份副本都已經含有注入。

對任何商業網站來說，三十天是更實用的下限，另外單獨留一份月度副本是很便宜的保險。商店還需要依訂單量來定資料庫備份間隔，因為丟掉四小時的訂單與丟掉四小時的部落格編輯，不是同一類問題。

副本放在哪裡，以及以什麼格式

NCSC 的另一個要點是：仍然連在正式系統上的備份並不算分離。存放備份的裝置「不使用時不應保持與你的裝置相連」，因為凡是能攻陷來源的東西也構得到它。套到主機上，一份存在同一個帳戶裡、只能透過同一個面板還原的備份，與它所保護的對象共享同一種命運。

格式是同一個問題更隱蔽的版本。如果讀取備份的唯一方式是服務商自己的還原按鈕，那你拿到的是一個便利功能，而不是一份可攜的副本。檢驗標準是：你今天能不能下載一份純 SQL 傾印與一個檔案封存檔，讓一位稱職的開發者可以在別處把它架起來。如果不能，遷移就不再是技術決定，而變成一場談判。

資料放在哪裡，以及為什麼這對英國買家重要

主機決策就是資料保護決策，而對一家英國企業來說，問題不是這家公司登記在哪裡，而是個人資料存放在哪裡、誰構得到它。

英國資訊委員辦公室 ICO 的國際傳輸指南給出了三步判斷。如果英國 GDPR 適用於你的處理活動，發起傳輸的是你，而接收方是一個獨立法律實體，那麼你正在進行一次受限傳輸。ICO 明確指出，這些規則「適用於所有受限傳輸，即使是小規模、不頻繁的傳輸」，並涵蓋每一個處理個人資料的組織，「包括獨資業者與自僱人士」。

也要注意什麼算作傳輸。ICO 把傳送個人資料與讓英國境外的組織「能夠存取」這些資料都算在內。一支能進你後台的境外支援團隊，或一份複製到另一個區域的異地備份，都可能各自符合這個定義。

每一次受限傳輸都必須由三樣東西之一涵蓋：目的地的英國適足性認定，適當的保障措施如國際資料傳輸協議、附錄或具拘束力的企業規則，或者某項例外。當你依賴保障措施時，ICO 還要求一份傳輸風險評估，證明傳輸之後保護水準沒有實質降低。這些都不會讓境外主機變得不可用，只是讓它成為一個需要留下文件的決定，而在遷移之前留文件，遠比遷移之後或在一次資料主體查閱請求進行中留文件便宜。

一份處理者協議該寫些什麼

你的主機商是處理者，你是控制者，所以書面合約不是選配。ICO 列出了合約必須包含的內容，其中四條可以直接讀作對主機商的提問。

首先是次處理者。依第 28 條 (3)(d)，處理者未經你的授權不得聘用另一個處理者，必須把打算進行的變更告知你以便你提出異議，並且必須把同等義務施加到整條鏈上。落到主機上，那就是 CDN、備份目的地、郵件轉送與底層雲端服務商。請索取清單。

其次是安全。第 28 條 (3)(c) 要求措施符合第 32 條，而 ICO 把這些措施說得很具體：加密與假名化，處理系統的韌性，「在發生事故時回復對個人資料存取的能力」，以及「定期測試與評估這些措施有效性的流程」。這就是把還原演練寫進了法律，而不是寫進一篇最佳實務文章。

第三是退出。依第 28 條 (3)(g)，合約結束時處理者必須依你的選擇刪除或返還全部個人資料，並刪除既有副本。一家備份無法離開其平台的服務商，除了實務問題之外還有合約問題。第四是稽核，依第 28 條 (3)(h)，你有權取得證明合規所需的資訊，以及他們的認證與報告。

各個級距，以及它們在英國的價格

四個級距涵蓋了幾乎每一個 WordPress 網站，而級距之間的界線由無法快取的負載劃定，不是由流量劃定。下面的區間是英國買家通常每月支付的金額。它們是類別區間而不是任何單一廠商的價目表，所以請把它們當作對報價的合理性檢查，而不是報價本身。

共享主機，每月 3 到 15 英鎊

對可快取的形象網站完全夠用，一旦有人登入就是真正的差價值。你和看不見的鄰居共享 PHP 容量，所以咬人的是負載下的變異而不是平均值。先查 PHP 分支，因為生命週期結束的直譯器最集中的就是這一級。

代管 WordPress，每月 20 到 400 英鎊

內容網站與小型商店的正確預設選項。你買的是更新、測試環境、防火牆、持久化物件快取與一支支援團隊，代價則是上文那些限制。20 到 100 英鎊這一段涵蓋一個流量中等的單站。再往上，你通常是在為更多網站、更多訪問量或更多 PHP 工作行程付費。

VPS 或雲端自建堆疊，15 到 120 英鎊外加代管費

一個不算大的雲端執行個體每月 15 到 120 英鎊，但機器是便宜的那部分。總得有人給作業系統打修補、調反向代理、執行物件快取與處理備份，把這份工作買進來每月還要再花 150 到 600 英鎊。當無法快取的負載真實存在，或者你的堆疊有代管平台禁止的需求時，它就值這個錢。

客製基礎架構，每月 400 英鎊起

多區域部署、高並行活動、嚴格的資料落地要求，或者一種 WordPress 只是眾多元件之一的架構。主機不再是一次產品選擇，而成為建置的一部分，這也正是我們在網站開發專案裡對待它的方式。

依無法快取的請求而不是依網頁瀏覽量估容量

主機方案依月訪問量出售，因為那是買家認得的數字。它對容量規劃幾乎沒用，因為十萬次快取過的匿名網頁瀏覽幾乎不花什麼成本，而一萬次登入狀態的瀏覽就能壓垮一台小伺服器。

真正重要的數字是並行的無法快取請求數，而算式很簡單。一個 PHP 工作行程一次處理一個無法快取的請求。所需工作行程數大約等於尖峰每秒無法快取請求數乘以以秒計的平均 PHP 回應時間。每秒 20 個無法快取請求、每個 400 毫秒，大約需要八個工作行程才跟得上，而你還想再留出至少一半當餘裕。

所以請提兩個方案頁面回答不了的問題：這個方案跑幾個 PHP 工作行程，單一行程的記憶體上限是多少？這兩個數字都存在，而且通常都不公開。你直接問，支援一般會告訴你，而這個答案比頁面上所有基準測試加起來更能說明這個方案。

然後誠實地估算你自己這一側。數一數處於登入狀態的工作階段比例，取最忙那一小時而不是平均值的結帳與帳戶流量，以及你的外掛在背景產生的 admin-ajax 或 REST 流量，後者在分析工具裡看不見，在伺服器紀錄裡卻非常顯眼。

外掛數量與內容產出量都是主機決策

網站內部有兩樣東西決定了它需要多少主機資源，而這兩樣通常被當作內容決策，由從來看不到帳單的人來定。

第一是外掛堆疊。每一個啟用的外掛都會增加每次請求都要載入的自動載入選項、因為 WordPress 的 cron 不是真正的 cron 而在訪客請求上觸發的排程事件，以及每次頁面建置的查詢數。一個有快取的形象網站上三十個外掛還活得下去。一家什麼都快取不了的商店上三十個外掛，意味著結帳的每一步都要執行三十個外掛。WordPress 核心對這從什麼時候開始咬人有個粗略判斷：持久化物件快取的網站健康檢測建議，一旦網站越過諸如 2,000 篇文章、2,000 個使用者或 600 個自動載入選項這樣的門檻，就啟用物件快取。

第二是內容產出量。修訂版本預設無上限地堆積，媒體庫會長成數以萬計的檔案、每個還帶好幾個產生尺寸，兩者都會撐大資料庫與備份時間窗。一個連續五年每天發布的網站，和同樣設計但每月發布一次的網站，是實質不同的主機問題，而方案頁面絲毫反映不出這一點。在為一次遷移報價之前，WordPress 開發者該做的是稽核這個建置，而不是稽核這個方案。

依序做選擇

依這個次序走一遍，決定通常會自己浮現。先確定你的流量裡有多大比例無法快取，因為這一個數字就決定了你的級距。確認 PHP 分支與資料庫版本達到公布的基準，因為在這裡不合格的方案無論價格如何都出局。確定哪些快取層已包含、哪些必須你自己提供。問清楚備份放在哪裡、是什麼格式、你今天能不能下載一份。然後閱讀處理者條款中關於次處理者、資料位置與合約終止時刪除的部分。走完這一切之後，價格才開始有意義，因為在那之前你比較的根本不是同一種產品。

Mecanik 把這件事做成任何遷移之前的一項固定工作，通常與一個網站開發專案並行，並透過我們的WordPress 開發者外包服務把它接成長期支援。如果你在權衡這個平台本身要往哪裡走，我們關於WordPress 7.0 與進入核心的 AI 用戶端的文章是這篇的合適伴讀。

常見問題

在英國 WordPress 主機應該花多少錢？ 這幾乎完全取決於你的流量有多少可以被快取。只有匿名訪客的形象網站，在共享主機上每月 3 到 15 英鎊就足夠。內容網站或小型商店通常屬於代管 WordPress 主機，每月 20 到 100 英鎊，忙碌或多站方案會升到 100 到 400 英鎊。登入流量很重的商店或會員網站通常需要 VPS 或雲端堆疊，機器每月 15 到 120 英鎊，若由別人代管則每月再加 150 到 600 英鎊。

代管 WordPress 主機值得多花的錢嗎？ 如果你沒有維運人員，那就值得，因為你買的是更新、測試環境、備份、防火牆與一層本來要你自己設定的持久化物件快取。代價是真實的限制。服務商常態性地封鎖快取外掛、備份外掛與資料庫消耗大的外掛，往往不給 shell 存取，對長時間執行的行程設上限，並封鎖對外寄信。請在簽約之前而不是之後，把這些限制對照你的建置核對一遍。

2026 年 WordPress 需要哪個 PHP 版本？ WordPress 建議 PHP 8.3 或更高。它在 PHP 7.4 以上仍能執行，但那些分支已到生命週期結束，不再收到安全修補。PHP 8.1 於 2025 年 12 月 31 日結束，PHP 8.0 於 2023 年 11 月 26 日，PHP 7.4 於 2022 年 11 月 28 日，而 PHP 8.2 處於僅安全修補狀態直到 2026 年 12 月 31 日。約 38.8% 的 WordPress 安裝仍在回報一個完全生命週期結束的分支。

更好的主機能改善核心網頁指標嗎？ 三項裡只有一項，而且只是間接的。伺服器回應時間是 Largest Contentful Paint 的一部分，所以更快的主機會為每位訪客降低 LCP。它對 Cumulative Layout Shift 幾乎沒有作用，那來自沒有尺寸的圖片與載入過晚的字型；對 Interaction to Next Paint 作用也很小，那由主執行緒上的 JavaScript 主導。如果你的伺服器回應已經很寬裕，剩下的問題就在頁面裡。

為什麼我的 WooCommerce 商店在號稱很快的方案上卻很慢？ 因為真正要緊的頁面無法快取。WooCommerce 要求購物車、我的帳戶與結帳保持動態，並為已登入的購物者設定繞過網頁快取的工作階段 Cookie。你首頁上的速度測試量的是一個快取過的檔案，而結帳在每一次請求上都在執行 PHP 並打到資料庫。一家商店真正買的是應付無法快取請求的容量，而不是那個快取過的首頁數字。