2026 WordPress 多站點伺服器能放多少個網站？

WordPress 官方於 2026 年 10 月 6 日發布 7.1.3 維護與安全更新。這個版本節點提醒管理者：多站點部署不是設定完成就不再變動的容量問題。沒有適用所有專案的固定網站數量；低負載展示站可共用資源，交易或高負載站則應按峰值、故障影響與權限需求分開配置，並以小規模測試決定何時拆分。

負責多個 WordPress 內容站的站長，可用本文判斷集中託管是否合適，而不依賴沒有測試依據的網站數量承諾。
跨境電商技術負責人，可檢查交易站與內容站同機時的資源競爭和故障範圍。
替多個客戶維護網站的團隊，可依站點權限、執行環境及備份責任規劃隔離。

最後更新於 2026 年 10 月 22 日；版本資訊核對自WordPress 官方發布公告，功能與權限依 WordPress、PHP 及 Nginx 官方文件核對。

先釐清要計算的是哪一種「網站」

「網站數」可能指網域、WordPress 安裝，或同一個 WordPress 網路中的子站；三者不代表相同的維護方式，也不能直接換算成容量。

計算對象	實際代表什麼	容量判斷時要注意
網域或子網域	指向網站的名稱，可由 Nginx 依網域名稱分流	多個網域不等於多個獨立執行環境；Nginx 的 server_name 文件說明如何依請求主機名稱選擇伺服器設定
獨立 WordPress 安裝	各站有自己的設定、外掛與檔案結構	分開安裝方便維持站點差異，但仍要檢查作業系統使用者、PHP 執行程序和資料庫帳號是否真的分開
WordPress Multisite 網路	在同一個 WordPress 安裝中管理多個子站	統一管理不等於硬體或安全隔離；須確認網路管理員與單站管理員的權限邊界

WordPress 官方將 Multisite 說明列為一個網路管理多個網站的功能。它適合需要共享核心、佈景主題或外掛管理方式的場景，但不應因為控制台裡能新增子站，就假設每個子站有獨立的作業系統、PHP 或資料庫資源。

2026 WordPress 多站點伺服器的容量，按負載而非站數決定

「一台伺服器能放多少個 WordPress 網站」沒有可靠的通用答案。站點所用外掛、資料庫查詢、圖片處理、快取命中情況及同時進行的後台工作都會改變資源需求；即使硬碟尚有空間，CPU、記憶體或資料庫也可能先成為瓶頸。

站點場景	常見資源波動	建議的初步安排
企業展示與形象網站	以頁面讀取為主，更新操作較少	可先共用主機資源；逐站記錄 PHP、資料庫與檔案占用，再觀察忙時變化
內容網站	搜尋、排程工作、圖片處理及快取失效可能造成短時負載	以流量較高時段的系統監控和存取紀錄作基準，分批增加請求測試
WooCommerce 或 API 站	結帳、庫存更新與 API 請求會增加資料庫寫入及突發負載	先與一般內容站分開 PHP-FPM pool、執行帳號和資料庫帳號，再測試交易流程
多客戶代管	外掛版本、管理權限和故障責任各異	按客戶與風險設定權限；若客戶間的故障影響不可接受，應考慮進一步拆分

低負載站集中部署，可能減少重複更新、備份與巡檢工作；相對地，一次錯誤更新、排程堆積或設定變更也可能波及多個站。這是集中部署的維護成本，不會反映在硬碟剩餘容量裡。

按站點情境分配 PHP 與資料庫資源

一台伺服器能放多少個 WordPress 網站？

可執行的答案是：先取得各站在真實忙時的資源曲線，再決定是否加入下一批站點。平均流量不能代表尖峰；背景排程、站內搜尋、圖片縮圖生成、快取失效及管理員同時操作，都可能使負載突然升高。

WordPress 的排程工作可能在頁面請求期間觸發，官方 Cron 文件說明其執行方式。因此，不要只以訪客數或首頁載入狀況判定容量，也要在測試中涵蓋預定發布、訂單更新等實際工作。

低負載內容站：共用前先盤點各站

先分開記錄各站使用的 PHP 版本、外掛、資料庫大小、上傳目錄增長，以及忙時 CPU、記憶體和磁碟使用變化。若網站有頁面快取、物件快取或 CDN，可把它們列為待驗證的調整項；快取命中率、頁面類型及回源行為不同，不能把某一站的改善效果直接當成其他站的容量保證。

集中維護也有代價：若多個站共用相同外掛版本或部署流程，操作錯誤可能同時影響它們。部署前先在測試環境確認更新流程，並確定回復方式及站點負責人，避免把「操作次數減少」誤認為「故障風險消失」。

WooCommerce 與 API：先劃出資源和故障邊界

結帳、庫存寫入和 API 請求通常比純內容頁更依賴資料庫狀態。即使使用相同的 WordPress 核心，交易站也不宜直接套用展示站的容量估算。至少要為不同業務設定獨立執行使用者、PHP-FPM pool 與資料庫帳號，並在測試時觀察結帳及資料更新期間的資源波動。

但 PHP-FPM pool 並不是完整的安全隔離機制。PHP 官方文件介紹 pool 的執行設定與使用者配置，並未將其定義為能取代作業系統層隔離的安全邊界；若客戶間權限敏感、資料風險較高，或單站故障會造成重大損失，應採用更明確的執行環境拆分，而不是只增加 pool 數量。

注意：多個 PHP-FPM pool 可以協助分配執行使用者與程序設定，但不能單獨保證不同網站的檔案、核心或系統資源完全隔離。

Multisite 與多套安裝，按管理責任選擇

維護方式	適合的管理情況	主要限制
WordPress Multisite	多個子站需要共用核心管理，且外掛與佈景主題由統一團隊控制	網路管理員掌握較廣的設定權限；不同子站未必能自行安裝所有外掛
多套獨立安裝	客戶、業務或外掛需求不同，需要分開更新與管理	安裝與更新工作較多；若檔案權限、PHP 使用者或資料庫帳號仍共用，不能視為充分隔離

WordPress 官方的網路管理員與站點管理權限說明及角色與功能權限文件可用來核對誰能管理網路設定、外掛與個別站點。選擇 Multisite 時，先確認各團隊是否接受共用核心更新及網路管理權限；選擇多套安裝時，則逐站確認檔案、執行使用者和資料庫帳號，而不是只依資料夾名稱判斷隔離程度。

從基線到拆分：依里程碑驗證容量

盤點、測試、判斷：逐項完成

[ ] 盤點站點：列出網域、WordPress 安裝方式、外掛與佈景主題、資料庫使用情況、主要流量時段，以及每站的業務重要性。
[ ] 建立基線：在正常營運時記錄 CPU、記憶體、磁碟空間、資料庫活動、PHP 錯誤及請求回應時間；將每個指標對應到實際站點或服務。
[ ] 檢查權限：確認 PHP 執行使用者、檔案擁有者、資料庫帳號和管理員角色；對不同客戶的網站，不要因共用伺服器就共用管理憑證。
[ ] 準備測試環境：使用自有站點或隔離的測試副本，按真實頁面、搜尋、表單、排程及交易流程逐步增加請求。不要直接在營運站以不受控的壓力測試代替容量評估。
[ ] 找出第一個瓶頸：查看尖峰時段的 CPU、記憶體、資料庫延遲、磁碟空間與錯誤紀錄；區分單一站點問題和多站共用服務問題。
[ ] 決定是否拆分：若某站持續擠壓其他站、故障影響範圍超出可接受程度，或權限需求無法在現有架構妥善維護，就先拆出該站再重新測試。
[ ] 安排成長餘裕：記錄流量高峰與內容增長的趨勢，定期重跑相同測試；不要把目前未出現瓶頸當作未來容量保證。

測試記錄應保留請求類型、執行時段、資源變化和錯誤，而不只留下單一「同時訪客」數字。這樣在增加新站、更新外掛或改變快取設定後，才能比較同一工作負載下的差異。

獨立伺服器建站：先對照已知規格，不換算成站點承諾

共享 VPS 或雲端執行個體可以適合負載輕、部署短期，或需要彈性調整的專案；但共享資源、CPU 爭用及計費項目可能讓長期忙時容量較難以單一規格判斷。獨立伺服器可提供整機獨享的資源，但硬體規格同樣不能直接換算成可承載的 WordPress 網站數。

CloudUDP 的產品資訊列有 32 核心／64 執行緒處理器、128GB 或 256GB記憶體，以及 2 × 1TB NVMe 硬碟；頻寬選項為 250 Mbps、1 Gbps 或 2 Gbps，均為不限流量。以上是硬體與網路選項，不是網站數量、並發量或效能承諾，應依CloudUDP 方案頁核對當前產品表，再以實際工作負載測試。

若部署 WordPress，也要確認安裝及連線方式與團隊能力相符；可先閱讀伺服器連線指南，並將更新、備份、監控及故障處理列入自己的維護計畫。此類工作不應預設由伺服器規格自動解決。

如果目前使用的共享主機或 VPS 已出現鄰居資源競爭、CPU 配額限制、流量計費難以預估，或無法按站點規劃執行環境，且網站負載長期穩定，CloudUDP 的 AMD 獨立伺服器可作為集中部署的候選方案；若專案只是短期測試、負載很輕或需要按需快速擴縮，則不必為了網站數量而急著改用整機。採購前先整理站點類型、忙時資源與隔離要求，再依產品表選擇方案，並用上述測試流程驗證；CloudUDP 不提供固定可承載網站數的保證。