新展覽開幕前六週，行銷說「我們要開一個寵物展的網站」。
你心想：好，老流程：確認網域、DNS 設定等傳播、SSL 憑證等核發、裝 WordPress、裝外掛、調主題、把上一場展覽的廠商資料貼過來、LOGO 再上傳一次。（然後展覽日期改期，子站網址要換，DNS 又要等一次）
如果你的展覽公司每季要開三到四個新展，這個流程每年重複十幾次。不是不能做，而是每一次都在燒工時，而且這些工時完全沒有積累——下一季的展覽，一樣從零開始。
這篇講的就是怎麼把這個循環打破。其實工具都有了，差的只是架構設計。
🔧 第一步：用 NS Cloner 把建站時間壓到一天
NS Cloner（現在正式名稱是 WP Cloner）是專為 WordPress Multisite 設計的子站克隆工具，核心功能只做一件事：把一個已有的子站完整複製成一個新站，包含主題設定、外掛組態、頁面架構、選單結構、所有樣式設定，連 URL 都自動替換好。
實際操作流程是這樣的：先花時間建立一個「展覽範本子站」。這個子站不是真正的展覽網站，是你整理好的標準樣板——首頁版面、展覽介紹頁、廠商名錄頁、索票報名頁的架構都設好，外掛都裝好並調整完畢，主題色調和字型都設定好。這個範本只需要做一次，日後持續優化。
每次新展覽，在 Network Admin 後台選「NS Cloner」，指定範本子站，給新子站一個網址（如 `pet.yourdomain.com`），按下克隆。10 分鐘內你得到一個結構完全一樣的新子站，接著做三件事就能上線：換主視覺圖片和展覽標題、改展覽日期和地點資訊、匯入這場展覽的參展廠商資料。（是的，就這樣，沒有其他了。）
實際時間：克隆操作本身不到 10 分鐘，調整主視覺和展覽資訊大約半天，廠商資料匯入另一個小時。原本兩到三週的建站流程，壓縮到一到兩天。NS Cloner 免費版已支援 Multisite 克隆，Pro 版另外提供 WP-CLI 指令列支援，可以寫成腳本進一步自動化。
📂 廠商資料怎麼跨展覽共用？
這是展覽公司最需要解決的問題：同一家廠商，可能同時出現在婦幼展、寵物展、文具展三個子站。傳統做法每個子站都要分別建檔——公司名稱、簡介、聯絡方式、LOGO，每個展覽輸入一次。一年下來，重複輸入的廠商資料量非常可觀，更頭痛的是哪天廠商換了地址或更新了 LOGO，你要一個一個站去改。
廠商資料用 Custom Post Type（CPT）集中儲存在主站。把所有參展廠商建成一個「廠商庫」CPT，欄位包含公司名稱、簡介、聯絡資訊、歷年參展紀錄。每個展覽子站不需要自己建廠商資料，而是透過 WordPress 的 `switch_to_blog()` 函式，從主站的廠商庫查詢並顯示對應的廠商列表。廠商改了地址？主站改一次，所有展覽子站同步反映。這個做法需要在 must-use plugin 層級統一註冊 CPT，確保每個子站都認得這個資料類型。廠商數量龐大時，建議搭配 Redis object cache，避免每次跨站查詢重複載入選項、拖慢前台效能。
如果跨站查詢太複雜，也可以考慮 Simple Multisite Crossposting 外掛——在主站建立廠商資料時，勾選這場廠商要同步到哪幾個展覽子站，按發布，自動在對應子站建立副本。對不熟悉程式的行銷人員來說，這個介面更友善。
LOGO 和圖片用 Network Media Library（Human Made 開源）解決。安裝啟用後，全網路所有子站共用一個中央媒體庫。廠商 LOGO 上傳一次，任何展覽子站都可以取用，檔案不重複儲存，管理介面清楚乾淨。廠商更新品牌識別時，只要在中央庫更新一次，所有子站自動反映。
每季新展覽有大量新廠商要批次建檔時，用 WP All Import 從 Excel 或 CSV 一次匯入到指定子站，配合 WP-CLI 的 `–url` 參數指定目標子站，100 家廠商大約一小時可以完成，比手動逐筆建檔快上十倍。
⚡ Cloudflare API 自動化：新增子站，DNS 和 SSL 自動到位
在 WordPress 後台按「新增子站」的那一刻，Cloudflare API 同步觸發——DNS 紀錄建好、SSL 憑證啟用、WAF 規則套上——完全不需要手動進 Cloudflare 後台。
技術原理是 WordPress 的 `wp_initialize_site` hook——每次 Multisite 建立新子站，這個 hook 就觸發。在 must-use plugin 裡掛一段程式，hook 觸發時同步呼叫 Cloudflare API，自動執行以下四個動作：
建立 DNS CNAME 紀錄，讓新子站網址指向伺服器；啟用 Universal SSL，自動取得 TLS 憑證（Universal SSL 免費版涵蓋 `*.yourdomain.com` 這一層，展覽公司常見的一層子網域結構剛好在範圍內；若日後改用多層子網域結構，需升級至付費的 Advanced Certificate Manager）；套用既有的 WAF 防護規則模板；套用快取規則。
整個流程在後台靜默完成。展覽行銷人員看到的是：在 WordPress 後台按「新增子站」，幾分鐘內新的展覽網址就可以瀏覽（DNS 幾乎即時生效），SSL 憑證通常在 15 分鐘內啟用，什麼後台都不需要手動進。有沒有覺得這跟你現在的流程差很多啊。
對需要更正式 IT 治理的組織，進階選項是用 Terraform 把 Cloudflare 設定寫成程式碼，存進 Git repository。每次 DNS 設定或 WAF 規則的異動都有版本紀錄和審核流程，這是符合 ISO 27001 變更管理要求的做法。
🛡️ Multisite 的集中風險，怎麼管得住？
Multisite 有一個無法迴避的特性：所有子站共用同一個 WordPress 用戶資料庫和同一台伺服器。這意味著主站出問題，子站一起受影響；一個子站的外掛有安全漏洞，可能成為攻擊者橫向移動的跳板。
坦白說，這個風險是真的存在的。但「存在風險」跟「不能用」之間，有很大的距離——關鍵在於防護架構怎麼設計。
防護分三層，各自擋不同類型的威脅：
邊緣層用 Cloudflare Pro WAF。Cloudflare 的 WordPress 專用 Managed Ruleset 自動阻擋 wp-login 暴力破解、xmlrpc 攻擊、SQL Injection 和 XSS——這些都是 Multisite 共用用戶資料庫最怕的攻擊類型。Rate Limiting 設定每個 IP 的登入嘗試上限，Super Admin 登入頁面另外做 IP 白名單，流量還沒碰到伺服器就先被過濾掉大多數威脅。
主機層用 Imunify360。Imunify360 的 Virtual Patching 功能在 Multisite 場景特別有價值：當某個外掛出現已知漏洞，在官方修補推出之前，Imunify360 的規則庫已經先把這個攻擊向量擋掉。對「子站管理員可能不會立即更新外掛」的 Multisite 環境，這是一道很重要的緩衝。（說真的，展覽公司的行銷人員哪有時間盯外掛版本，這層的存在就是為了保護這種情境。）即時 PHP 行為分析不靠特徵碼，靠偵測異常執行行為來抓 webshell，這種做法對新型態攻擊更有效。
應用層做 WordPress hardening。在 `wp-config.php` 設定幾個關鍵參數：`DISALLOW_FILE_MODS` 禁止子站管理員自行安裝或更新外掛（只有 Super Admin 能做），`FORCE_SSL_ADMIN` 強制後台全程 HTTPS，`DISALLOW_FILE_EDIT` 關閉後台的主題和外掛程式碼編輯器。Super Admin 帳號限制在一到兩人，強制啟用兩階段驗證，帳號本身就不是容易被暴力破解的攻擊面。
最後一層是流程：ISO 27001 的變更管理要求每次異動都要有紀錄。每次新增子站、安裝網路啟用外掛、核心版本升級，都走簡單的變更流程，確保沒有任何操作是靜默發生的。對展覽公司的 IT 主管來說，這是能夠向老闆交代的控管機制。
這不代表 Multisite 沒有風險，而是說風險是可以管的——前提是防護架構從一開始就設計正確，不是上線後才補。
備份是所有防護層之外的最後底線。Multisite 的共用資料庫是所有子站的單一故障點，每日異地備份加上定期還原演練，是導入後的基本維運要求，不在「架好就沒事」的範疇裡。
讀完這兩篇，如果覺得情境滿符合的，建議先做一件事：把目前所有展覽站的清單拉出來，看看哪些頁面結構是重複的、哪些廠商跨站出現。這個盤點做完，要不要導入 Multisite 的答案幾乎自動浮現。有需要進一步討論架構細節或做正式評估，歡迎與 CTK Pro 聯繫。
- NS Cloner Site Copier – WordPress.org, 2025
- Network Media Library – Human Made, GitHub, 2024
- WP All Import WP-CLI Documentation – WP All Import, 2025
- Add multiple sites via automation – Cloudflare Developers, 2025
- wp_initialize_site hook – WordPress Developer Resources, 2025
- Cloudflare WAF Getting Started – Cloudflare, 2025
- Imunify360 Features – CloudLinux, 2025
- WordPress Multisite Security Best Practices – Kinsta, 2025
- WordPress Multisite Security Playbook – Pantheon, 2025
- Getting started with Terraform and Cloudflare – Cloudflare Blog, 2024
- Best Cloudflare WAF Rules for WordPress – FlyWP, 2025
- TT Cloudflare WPMU Plugin – WP Favs, 2024
註：所有數據與引述均截至 2026 年 4 月
