Bricks Builder 教學：WordPress 視覺化編輯器

頁面編輯器把網站蓋得漂漂亮亮，版面精緻、動畫流暢，但一打開測速工具，分數紅通通一片，主機資源被吃光，手機端還要等上好幾秒才看得見內容。客戶不關心你拖了幾個區塊，他僅看到「我的手機為什麼開這麼慢」。

這幾年 WordPress 圈開始認真討論一個名字：Bricks Builder。它不單純是又一個拖曳式編輯器，它是一個把「主題」與「編輯器」綁在一起、直接輸出乾淨 HTML 與 CSS 的工具，輸出品質好到連工程背景的人願意幫它背書。我自己在挑頁面編輯器時，會把「輸出品質」排在「功能數量」前面，因為一個網站要活三五年，輸出凌亂的編輯器遲早會回來咬你。如果你正在考慮把網站交給 Bricks，或正在比較它與其他主流編輯器，這篇會給你完整的判斷框架與實戰流程。

快速重點整理
一、Bricks 是「主題＋編輯器」一體的工具，輸出貼近手寫的語意化標記。
二、它最大的優勢是全域 class 系統，讓你像寫 CSS 一樣重用樣式，省去每個區塊各自設定的麻煩。
三、效能是它最常被稱讚的特點，DOM 結構乾淨，適合在意 Core Web Vitals 的人。
四、它不適合完全沒碰過 WordPress 的新手，也不適合需要大量現成範本的流水線接案。

為什麼 WordPress 生態需要一個「新」頁面編輯器

WordPress 生態已有多種頁面編輯器，包括Elementor、Divi、Beaver Builder，以及 WordPress 核心的區塊編輯器（Gutenberg）與各類區塊外掛。評估 Bricks 時，應比較既有工作流程、輸出、範本生態、授權與維護需求。

答案在於「輸出」。早期那批拖曳式編輯器解決的是「讓不會寫程式的人也能做網站」這個問題，於是把重心放在視覺化、放在功能堆疊、放在範本數量。十年下來，它們確實做到了，副作用是輸出的 HTML 往往包了好幾層多餘的容器、載入了一整包樣式表與字體，即使是空白頁也沉重。當你的網站僅有三頁，這些負擔你感覺不出來；當網站長到幾十頁、開始衝搜尋流量、開始用手機瀏覽，輸出品質就會變成能不能留住訪客的關鍵。

頁面速度會影響使用者體驗，載入越久，訪客離開的機率通常越高（見 web.dev 的說明）。Core Web Vitals 是 Google 排名系統採用的小幅訊號之一，但好分數不保證排名或轉換提升。「編輯器輸出多乾淨」仍值得在意，因為多餘節點與資源可能增加維護和載入成本。

Bricks Builder 是什麼：一個把主題與編輯器揉在一起的工具

要理解 Bricks，你必須先打破一個觀念：它不是一個裝在既有主題上的外掛。Bricks 本身就是一個 WordPress 主題，僅是這個主題的主要工作在於提供一套視覺化編輯器讓你從零組版面，版面本身交給你決定。你裝了 Bricks，就會用 Bricks 的編輯器取代原本的主題外觀；你不會「在 Astra 上面裝 Bricks」，而是直接啟用 Bricks 當主題。

這聽起來像限制，其實是它效能乾淨的根源。Elementor 或 Divi 的編輯器必須在「任何主題」上都能跑，於是它們要處理大量相容性、要注入自己的樣式去覆蓋主題樣式，DOM 自然越疊越多。Bricks 主題與編輯器一體，它知道自己要輸出什麼，不需要預留一堆相容層，所以能輸出更貼近手寫的結構。這也代表它的升級路徑比較單純，因為它僅對自己的輸出負責，不會因為某個第三方主題改版就跟著壞掉。

它的編輯邏輯是「元素樹」。你在畫面上看到的每一個容器、每一段文字、每一張圖，都是元素樹裡的一個節點，有明確的父子關係。這跟 Elementor 那種「拖一個 section、裡面放 column、column 裡放 widget」的模型很像，但 Bricks 把節點單純化，僅有 Container（容器）與 Element（元素）兩大類，你用巢狀容器來組版，跳脫固定欄數 section 的框架。這個設計跟現代 CSS 的 Flexbox 與 Grid 邏輯一致，懂一點排版的人會上手很快，可以搭配我們寫過的 CSS Box Model 觀念一起看。常見的元素包含標題、文字、圖片、按鈕、圖示、分隔線、輪播、表單欄位等，每一種都是元素樹裡可以自由安插的節點，你不會被「這個 widget 僅能放在這個 section」之類的人為規則綁住。

Bricks vs Elementor vs Divi：給你一張能直接判斷的對照表

我不喜歡用「哪個最好」這種話術，因為答案永遠是「看你做什麼網站」。但一張對照表能幫你快速看出三者的取向差異。下面是我自己在選型時會看的幾個維度，內容是以官方公開資訊與社群長期回饋為基礎的概況，實際採購前請以官方網站公告為準。

從這張表你會看到一件事：Bricks 的強項是「輸出」與「樣式重用」，而 Elementor 與 Divi 的強項是「上手速度」與「範本生態」。如果你的網站是給自己或客戶長期維護、而且會衝搜尋流量，輸出品質的價值會隨時間放大；如果你做的是一次性活動頁、或是交付後客戶自己改不太動，那 Elementor 的便利性可能更實際。想看更完整的編輯器橫向比較，更詳細的寫在 主流頁面編輯器比較，而如果你更傾向用主題來解決版面問題，Astra 主題教學與Divi 完整教學則是兩條值得評估的路線。Divi 在 5.0 之後也做了不少結構瘦身，如果你的舊站本來就是 Divi，先評估升級到新版能不能解決效能痛點，往往比直接換編輯器更划算。

動手之前：安裝 Bricks 要先確認的四件事

很多人下單買 Bricks 之後就直接裝，結果在幾個地方卡住。我自己在裝任何會接管整站外觀的工具前，會先確認四件事，這幾項不僅適用 Bricks，也適用任何大幅改動版面的主題或編輯器。

1. 它是主題，不是外掛。你必須啟用 Bricks 取代現有主題。若目前用 Elementor 搭配 Astra，Astra 的主題層版型與設定不會繼續生效；Elementor 的頁面資料通常仍留在資料庫，相關內容能否正常顯示則要看 Elementor、頁面範本與相容性，不能一概說成不再渲染。請先在測試環境逐頁驗證並保留完整備份。
2. 準備一個子主題。Bricks 更新時你可能會想覆寫少量功能或加上自訂程式碼，這些都要寫進子主題，避免直接改主程式而被下一次更新覆蓋。官方文件有提供子主題範本，複製一份就能用，門檻不高。
3. 主機要符合官方需求。Bricks 官方目前列出的最低 WordPress 記憶體是 64 MB，建議值為 512 MB；PHP 最低版本很低，但正式站仍應使用 WordPress 與主機商支援的安全版本。512 MB 是 Bricks 的建議值，不是所有 WordPress 網站的一般最低需求（見 Bricks 官方需求頁）。
4. 確認你的授權類型。Bricks 目前同時有年度 Starter、Business、Agency 方案，以及 Ultimate Lifetime 終身方案；不是所有授權都採買斷。網站數與價格可能調整，購買前以Bricks 官方定價頁為準。

這四項確認完，再去走WordPress 快速設定流程，把固定連結、SEO 外掛、快取外掛這些基本功裝好，Bricks 才有一個乾淨的地基可以發揮。地基沒弄好就蓋版面，等於在軟泥上蓋房子，日後每一個外掛衝突都會被算到 Bricks 頭上，反而讓你誤判它不好用。

用「結構樹」而非「拖曳」來理解 Bricks 編輯器

Bricks 的編輯器介面跟其他視覺化編輯器一樣有左側面板、中間畫布、右側設定，但真正決定你能不能用好它的，是你腦袋裡對「結構」的理解。多數人在 Elementor 裡養成的習慣是「我要一個兩欄區塊，於是拖一個三欄 section 再改成兩欄」，這是「從版面反推結構」。Bricks 鼓勵你反過來想「我要裝什麼內容、內容之間是什麼從屬關係」，然後用容器去描述這層關係。

左側的結構面板會即時顯示整頁的元素樹，每一層容器可以展開收合。你會看到「容器底下有容器、容器底下有標題與圖片」這種乾淨的階層，避開了 section、column、widget 三種節點混在一起的混亂。這聽起來抽象，但它帶來一個很實際的好處：當你要改響應式行為時，你是在調整「某個容器的排列方向」，而不是「某個 section 在手機要變幾欄」。前者是 CSS 的原生邏輯，後者是編輯器自己發明的抽象層，長期維護下來前者會穩定得多。

Bricks 的響應式控制綁定斷點，切到平板或手機斷點時可以調整該範圍的樣式。Bricks 預設是 desktop-first，較小斷點會繼承基礎斷點；僅有把最小斷點設成 base breakpoint 後，才會改成 mobile-first。不要在沒有改 base breakpoint 的情況下照 mobile-first 寫法操作（見 Bricks Academy 的響應式編輯文件）。

右側的設定面板是 Bricks 編輯器的另一個核心。點選任何一個元素，面板會根據元素類型顯示對應的設定分頁：排版、樣式、背景、邊框、動畫、條件顯示。其中「條件顯示」值得特別提一下，它讓你設定某個元素僅在特定情況出現，例如僅在登入使用者看得到、僅在某個文章類型顯示、僅在特定時間區間出現。這本來是要寫程式或裝額外外掛才做得到的事，Bricks 把它做成下拉選單，等於把開發者才碰得到的邏輯，下放給每一個會用編輯器的人。再搭配內建的 inline 編輯（直接在畫面上點文字改內容）、style 複製貼上（把一個元素的樣式整組套到另一個元素）、鍵盤快捷鍵，熟了之後組版面的速度會逼近你用簡報軟體排投影片的節奏，這是它跟舊一代編輯器拉開差距的地方。

全域 Class 系統：Bricks 最值得學、也最常被跳過的能力

如果你僅能從這篇文章帶走一個觀念，我會選這個：Bricks 的全域 class 系統。多數人第一次用 Bricks，會用直覺去點每個元素的間距、字體、顏色，按得很順手，但很快你就會發現整站有幾十個按鈕、幾十張卡片，它們的樣式各自獨立，想統一改主色就要點幾十次。這正是傳統編輯器的通病，而 Bricks 用一套很像 Tailwind 的 class 機制解掉了它。

做法是這樣：你在 Bricks 裡定義一個 class，例如 .btn-primary，把內距、圓角、主色、hover 狀態都設在這個 class 上。之後任何按鈕元素套上 .btn-primary，就會繼承全部設定；改一次 class，全站引用它的按鈕會一起更新。卡片、標題、區塊間距都同樣道理。這其實就是把 CSS 的重用觀念搬進視覺化介面，等於用 class 建立一份設計系統。

以律師事務所這類形象站為例，若把全部按鈕、卡片、區塊間距都套上同一套 class，日後要新增分所頁面時，複製範本、套用 class，很快就能組好交付。這不是什麼神奇功能，但當你把 class 想成「可重用的設計資產」，你對網站的維護成本會整個改觀。它也讓設計一致性有了一套可執行的機制，不再仰賴人工檢查每個頁面對不對齊。

class 系統還有一個進階用法值得提：組合。一個元素可以同時套多個 class，例如一個按鈕套 .btn-base（處理大小與圓角）再加 .btn-outline（處理描邊樣式），這樣你不用為每一種按鈕變體都建一個獨立 class，而是用少量基礎 class 組合出多種樣式。這套觀念跟 utility-first CSS 完全一致，熟悉 Tailwind 的人會馬上上手。如果你過去碰過設計 token 或 utility class 的概念，這套邏輯你會很熟悉，可以搭配 Sass/SCSS與基礎的 CSS 入門一起理解。就算你不會寫 CSS 也沒關係，Bricks 的 class 面板全部是圖形化設定，你僅是借用 CSS 的「重用」觀念，不需要碰一行程式碼。

顏色變數與設計 token：把品牌規範寫進 Bricks 裡

跟 class 系統相輔相成的，是 Bricks 的全域變數機制。一個網站會反覆出現的東西不僅有按鈕樣式，還有顏色、字體、間距、斷點。Bricks 讓你把這些值定義成變數，例如主色定義為一個色票變數、次色定義成另一個，然後在 class 或元素設定裡引用變數，避免把色碼直接寫死在各處。當品牌藍需要調深時，改動一個變數值，全站引用它的地方就會一起更新，這就是設計 token 的核心價值。

這套做法的好處在規模化之後才會完全顯現。一個五頁的形象站，你硬寫色碼也活得下去；但當網站長到幾十頁、有部落格、有服務列表、有 case study，沒有變數系統的話，改一次主色會變成跨頁面的尋寶遊戲。Bricks 把顏色、字體、間距都做成可引用的變數，等於鼓勵你從一開始就用 token 的邏輯組織樣式。這也跟現代設計系統的趨勢一致，大型品牌網站的設計規範幾乎都是用 token 描述，而不是逐一列出每個元素的數值。

Bricks 的 Color Manager 可以為 light、dark 等 theme 定義不同色值，前端切換通常透過元素上的 data-brx-theme 屬性與自建切換控制。官方文件沒有保證會自動依作業系統偏好切換；若需要 prefers-color-scheme 行為，要自行實作並測試（依 Bricks Academy 的 Color Manager 文件）。

從零蓋一個響應式首頁：容器、間距、斷點的完整流程

講了這麼多觀念，落實到一個首頁到底是怎麼走的？我把一個典型的首頁拆成可重複的流程，你照著這個節奏走，幾乎能套用在任何類型的形象站。

1. 先畫骨架，再填內容。在 Bricks 裡先拉出頁面的主要容器：Hero 區、服務列表、案例展示、行動呼叫。這階段不要管配色字體，僅管每個容器擺在哪、彼此是上下還是左右關係。這步等於先決定版面配置的骨架，骨架歪了後面再怎麼裝潢都救不回來。
2. 用 Flexbox 或 Grid 描述排列。每個容器選擇排列方向，子容器是橫排、直排、還是網格。Bricks 把這些控制做成下拉選單與勾選，你不用寫 CSS，但懂 Box Model 會讓你預測得更準，尤其是內距、邊距、邊框三者如何疊加影響最終尺寸。
3. 間距用變數或 class 管理。不要每個容器手動輸入 24px、32px。先在主題設定或 class 裡定義幾組間距（例如 sm、md、lg），全站統一引用，這樣節奏才會一致。一致的間距節奏，是業餘版面與專業版面最明顯的差距之一。
4. 切到手機斷點檢查。桌機看起來沒事的橫排，到手機通常要改成直排。在 Bricks 切到手機斷點，把該轉直的容器轉向，確認觸控點擊範圍夠大，按鈕之間不會誤觸。這一步省掉的話，手機使用者會默默承受，然後默默離開。
5. 把重複的樣式收斂成 class。首頁骨架跑順之後，回頭把重複出現的按鈕、卡片、標題樣式抽成 class。這個動作愈早做，後續新增頁面愈輕鬆，因為你已經在為未來的每一頁預備好零件。

這五步走完，你得到的不僅是一個首頁，而是一套可以複製到其他頁面的設計資產。行動呼叫（CTA）區塊的設計邏輯，可以參考我們的 CTA 設計指南；如果你做的是單頁式活動頁，登陸頁教學會更貼近你的情境，那裡會談到單頁網站在節奏與轉換上的特殊考量。

樣板與動態資料：設計一次，全站套用

形象站真正難的不是首頁，是內頁。當你的網站有五十篇文章、二十個服務頁、十個案例頁，你不可能每一頁都手動排版。Bricks 用兩個機制解掉這件事：樣板（Templates）與動態資料（Dynamic Data）。

樣板讓你定義「某一類頁面要長怎樣」。你可以建一個「服務頁樣板」，指定它套用在所有服務類型的頁面上；你也可以建 header、footer、single post、archive 這種全站層級的樣板，把整站的外觀都交給 Bricks 管理。這跟傳統「改主題檔案」的做法不同，你全部在視覺化介面裡完成，不需要碰 PHP 模板。對不熟 WordPress 主題架構的人，這等於把門檻降到「會用編輯器就會改全站外觀」。

動態資料則讓樣板裡的內容「跟著每一頁變」。你在服務頁樣板裡放一個標題元素，把它綁定到文章標題欄位；放一個圖片，綁定到特色圖片。這樣同一個樣板套用到二十個服務頁，每一頁顯示的是各自的標題與圖片，你若在後台編輯內容，版面自動帶出來。Bricks 原生就支援這套綁定，也跟 Advanced Custom Fields、Meta Box 這類自訂欄位外掛整合得很順，讓你可以把報價、規格、地點這類結構化資料當成欄位管理。想理解這背後的內容架構觀念，可以看我們整理的網站結構與 SEO，把樣板與網站資訊架構一起想，才不會做出好看卻難用的目錄。

這兩個機制加起來，把「全站一致性」這件本來很耗人工的事，變成設計一次就好的工作。你做愈多頁，這套投資回報愈高。一個實務建議：樣板不要一次到位，先做最小可用版本上線，實際編幾篇內容之後，你會更清楚哪些欄位需要、哪些排版要微調，再回頭迭代樣板，這比閉門造車做一個大而全的樣板更有效率。

Bricks 跟 WooCommerce：把商品頁與結帳流程交給它

Bricks 不僅是形象站工具，它對 WooCommerce 也有完整支援，這對做電商的人是關鍵。WooCommerce 是目前全球市佔最高的電商平台之一，根據 W3Techs 的統計，它在所有使用內容管理系統的網站中佔有相當高的比例（依 W3Techs 的統計，2026 年 6 月）。這代表「編輯器能不能好好處理 WooCommerce」是很多人選型時的硬指標。

Bricks 的 WooCommerce 整合讓你用同一套元素樹邏輯去設計商品頁、購物車、結帳頁。你可以用容器重新排列商品圖、價格、加入購物車按鈕、相關商品的相對位置，避開佈景主題預設版面的綁手綁腳。更重要的是，這些設計一樣可以套 class、一樣可以做成樣板，整個商品目錄的視覺一致性因此能被控制。對一個有幾百個 SKU 的商店來說，這件事的價值遠大於「首頁做得漂不漂亮」。一個能讓商品頁快速載入、行動呼叫明顯、結帳流程少一道阻礙的版面，對轉換率的拉抬往往比任何行銷活動都直接，而 Bricks 給你的就是這種從結構著手的掌控力。

如果你過去是用其他 WooCommerce 編輯器在做電商頁面，Bricks 提供的是另一種較貼近 HTML 結構的做法；實際輸出與速度仍要用相同頁面內容比較。響應式電商頁面的設計重點可以參考我們的 RWD 電商設計整理。若商品頁轉換率是核心，商品資訊、操作流程與量測結果，會比首頁動畫更值得優先處理。

效能與 Core Web Vitals：Bricks 為什麼能輕

效能是 Bricks 最常被點名的原因，而它之所以輕，不是因為魔法，是因為前面提到的幾個設計選擇一起發揮作用。主題與編輯器一體，省掉相容層；元素樹單純，DOM 不會被多餘容器撐大；全域 class 取代每個元素各自帶樣式，樣式表體積可控；沒有預載一整包用不到的字體與圖示。這些都是工程上可解釋的理由，不是行銷話術。

為什麼這件事值得你花力氣顧？因為頁面速度直接影響使用者是否願意留下。Google 在 web.dev 的說明中明確指出，載入時間增加會拉高跳出率、降低轉換，這在行動裝置上尤其明顯。Bricks 讓你在「視覺化做版面」與「輸出貼近手寫」之間不必二選一，這是它相對其他編輯器的真實價值，也是它能在效能敏感的 SEO 圈累積口碑的根本原因。

不過我要誠實說，Bricks 輕不代表你裝完就自動拿高分。真正的 Core Web Vitals 成績，還取決於你的圖片有沒有壓縮、有沒有設定快取、有沒有減少第三方腳本。Bricks 給你一個乾淨的底，剩下的基本功你不能跳過，該裝的快取外掛、該做的圖片最佳化、該追蹤的指標都不能少。完整的優化流程可以搭配 Core Web Vitals 與 SEO、網站速度的實戰拆解，以及WordPress 快取外掛這幾篇一起看，把 Bricks 的乾淨輸出加上正確的最佳化策略，成績才會穩。可以把 Bricks 想成幫你把地板墊高的那一塊，但它不會替你把天花板撐起來，天花板還是要靠你自己的優化紀律。

Bricks 生態圈：哪些外掛能搭、哪些要小心

一個編輯器好不好用，除了本身功能，還要看它的生態圈。Bricks 的生態雖然比不上 Elementor 那種十幾年累積的規模，但核心的幾類整合已經相當成熟，足以撐起一個正經的形象站或電商站。

第一類是自訂欄位外掛。Advanced Custom Fields（ACF）與 Meta Box 都跟 Bricks 動態資料整合良好，這是做服務頁、案例頁、任何需要結構化資料的網站時必裝的組合。你可以把規格表、價格、地點、營業時間都做成欄位，在 Bricks 樣板裡綁定，內容與版面徹底分離。這套組合也是從傳統主題遷移過來時，最值得先建好的基礎建設。

第二類是 SEO 與快取外掛。Rank Math、Yoast 這類 SEO 外掛跟 Bricks 沒有直接衝突，能正常運作；快取外掛則建議挑支援延遲載入、能與頁面優化相容的。把 WordPress 必裝外掛整體盤點一次，會幫你釐清哪些是地基、哪些是裝飾。

第三類要小心的是其他會注入前端資源的視覺化外掛。如果你同時啟用另一個popup外掛、另一個表單外掛、另一個動畫外掛，等於又在 Bricks 的乾淨輸出上疊了別人的樣式表與腳本，效能優勢會被侵蝕。Bricks 自己就內建 popup、表單、輪播這些功能，能用的盡量用它原生的，減少疊加。這個「能原生就原生」的紀律，是讓 Bricks 維持輕量的關鍵，也是它跟其他編輯器最大的使用習慣差異。

至於學習資源與範本來源，官方的 Bricks Academy 提供了從入門到進階的教學影片，社群也有第三方設計師販售範本包與子主題，數量雖然比不上 Elementor 那種十年累積的規模，但品質普遍不錯，因為能在這個生態存活下來的範本作者，多半自己也講究輸出品質。挑範本時我會建議先看它的 DOM 結構與 class 用法，截圖美不美反而是次要考量，因為一個套了層層巢狀容器的範本，會把你一開始選 Bricks 的理由（乾淨輸出）抵消掉。把範本當成起點就好，進 Bricks 之後拆掉多餘結構、收斂成自己的 class，這才是讓範本真正為你效力的用法。也因為 Bricks 的社群偏向注重工程品質的開發者與設計師，你在社群論壇與 Discord 頻道裡問問題，往往能得到比較結構化、比較接近原生 CSS 觀念的回答，這對願意把基本功練起來的人是加分環境。

三種情境我會直接勸你別用 Bricks

我不想把 Bricks 講成萬靈丹。從不同類型網站的實務情況來看，有三種情境我會直接勸退，因為硬上僅會讓你痛苦。

第一種，完全沒碰過 WordPress 的人。Bricks 的元素樹與 class 系統對懂一點排版的人是助力，但對連「裝外掛、設固定連結」都還陌生的人，它會把學習曲線拉得太陡。這類朋友我會建議先從更視覺化、範本更完整的工具入門，把 WordPress 基本功練熟，或直接考慮 AI 網站建立工具這類降低門檻的方案，等你知道自己要什麼了再回來看 Bricks。

第二種，是重度依賴現成範本市場的接案團隊。Elementor 與 Divi 累積了較大的範本生態，適合需要快速組裝大量網站的工作流程；Bricks 的強項則較偏向自行建立設計系統。實際效率仍取決於團隊既有資產與交付方式，沒有絕對優劣。

第三種，網站已經被 Elementor 或 Divi 深度綁定、而且運作良好。如果現有網站效能還過得去、客戶也滿意，我看不到為了換編輯器而承擔遷移風險的理由。換編輯器是大事，不是小修，沒有明確痛點就不要動，這是我對任何「要不要重練」問題的鐵律。把那個力氣拿去做內容、做 SEO，報酬率通常高得多。

從 Elementor 或 Divi 遷移：降低痛苦的實務做法

如果你評估過痛點，確定值得遷移，這裡有幾個能降低痛苦的原則。先說結論：Bricks 不會自動把 Elementor 或 Divi 的頁面轉成自己的結構，你幾乎等於重新組版面，差別在於內容（文字、圖片）還在資料庫裡不用重打。這也是為什麼遷移前值得先釐清Elementor 新舊版差異，確認原本的痛點是編輯器本身，還是只是還沒升到新版，免得重新組了一次版面卻沒解決真正的問題。

第一個原則是「分頁搬，不要全站一起搬」。挑一個流量最低、最不關鍵的頁面當實驗，把它的結構用 Bricks 重新組一次，跑順了再往下個頁面走。這個過程你會摸熟 Bricks 的操作節奏，也會發現哪些 class 要先建好。全站一起搬聽起來有效率，出錯時卻會讓你找不到問題出在哪一頁。

第二個原則是「先建 class，再組頁面」。遷移之前先把整站的按鈕、標題、卡片樣式定義成 Bricks class，等於先把設計系統搬過來。這樣每組一個新頁面都能重用 class，省下重新設定的時間，也比較容易維持視覺一致。

第三個原則是「保留舊站當對照」。遷移期間讓舊站繼續在原網址跑，新版本先放在測試環境或子網域，逐頁對照內容沒漏、版面沒歪、表單能送出，確認無誤再切換。這個紀律聽起來慢，卻是避免上線當天出包的唯一可靠方法。如果你是整個 WordPress 環境都要重練，從零架站那篇的流程可以當藍圖，搭配一份完整的 SEO 對照清單，例如WordPress SEO 完整指南，確保遷移過程沒有漏掉任何會影響排名的設定。

你的下一步行動方案

看完這篇，與其把結論記在腦裡，不如立刻做一件具體的事。我給你一個四步行動方案，照著走一次，你就會知道自己到底適不適合把網站交給 Bricks。

1. 盤點現狀。把你目前網站的測速報告、Core Web Vitals 成績、主機資源用量列出來，先量化痛點。沒有量化，你無法判斷換編輯器值不值得，憑感覺做這種決定通常會後悔。
2. 開一個測試站實作。不要在正式站上直接換 Bricks。開一個測試環境，把一個你最熟的頁面重新組一次，實際感受元素樹與 class 系統，再決定要不要往下走。
3. 定義你的設計系統。把按鈕、標題、卡片、間距整理成一份 class 清單，外加顏色與字體的變數，這是 Bricks 能不能幫你省下長期維護成本的關鍵，也是你網站設計一致性的地基。
4. 評估長期成本。把授權費用、學習時間、預期帶來的效能改善與維護效率一起算進去，再做決定。工具是投資，不是衝動購物，能用三五年的東西值得多花一週想清楚。

Bricks Builder 不是唯一答案，但它確實代表了 WordPress 頁面編輯器往「輸出品質」靠攏的一個方向。當你把網站當成會陪伴你三五年的資產來看，乾淨的輸出、可重用的設計系統、穩定的效能，這三件事的價值會隨時間複利累積。願你選到那個讓你五年後回頭看仍然慶幸的工具。