WooCommerce 佈景主題決策：從症狀歸因到驗收上線

週五晚上九點，促單貼文剛投出去，訂單通知卻遲遲沒有響。老闆自己拿起手機下單測試，結帳按鈕按下去沒有反應；回到後台翻更新紀錄，才看見佈景主題三天前自動更新了一個小版本。這類故事的結局通常只有兩種：一路急救到凌晨，或隔週咬牙換掉主題。不論哪一種，重點都相同：主題出事的時候，受傷的從來不是外觀，是正在進行的營業。

這種時候最不該做的決定，就是衝去買另一個看起來更漂亮的主題。症狀未必是主題造成的，可能出在外掛、資料或主機；就算確認出在主題，立刻換掉也未必是成本最低的解。有個觀念值得先放進腦裡：一款主題最貴的支出，常落在決定換掉它的那一天。挑主題等於簽下一份範本維護契約，主題覆寫了哪些商店範本、綁了哪套編輯工具，這份契約就會跟著商店好幾年。外觀三天就能換新，範本結構與編輯器綁定卻是長期條款。所以順序應該倒過來：先歸因，再選路線，付款之前驗收，上線之後分階段。

這套流程寫給兩種人：正在流血、急著找兇手的現任店主，以及準備開店、不想三年後推倒重來的人。流程本身不挑品牌，任何候選名單套進來都適用；具體哪幾款值得排進名單，站上另有一篇推薦清單專責處理，這裡不重複展開。先把感覺換成證據，預算才會花在真正約束你的地方。

快速重點：挑 WooCommerce 佈景主題前先做兩件事，用對照測試確認問題是否真的出在主題，再用商店的頁型、人力與預算把路線縮小。買之前同條件並排驗收，買之後分階段上線，每一步留下紀錄，決策就不會被 demo 的長相牽著走。

先劃清權責：主題管什麼、不管什麼

歸因的第一步，是知道主題的管轄範圍。把一個商店頁面拆開，主題實際管三層：範本層決定頁面長什麼形狀，商品、分類、購物車、結帳各有各的範本；樣式層決定它看起來什麼樣，字型、間距、顏色都在這層；行為層決定頁面起頭載入哪些資源，CSS 與 JavaScript 的多寡由它定調。購物車與結帳的功能邏輯大多由 WooCommerce 本體與外掛提供，主題的工作是把結果呈現出來。三層畫清楚，出問題時才知道該找誰。

這張責任地圖在兩個場合直接用得上。跟設計師溝通時，先講清楚要動的是範本層還是樣式層，前者動到結構、要留測試時間，後者多半用附加 CSS 就能完成；跟外掛開發者回報問題時，先說明症狀落在哪一層，對方才不用從零猜起。責任分得開，每一層才能分頭更新，這也是接下來整篇流程的地基。

「支援 WooCommerce」這幾個字，涵蓋的其實是兩種深淺不同的做法：一種是主題在範本層覆寫，把自己修改過的版本蓋在 WooCommerce 標準範本上；另一種只透過掛鉤與樣式接上 WooCommerce 的輸出，幾乎不動範本檔。前一種客製得深、責任也重，被覆寫的範本檔，往後每個 WooCommerce 版本都要由主題方跟著調整。想知道手上這款主題屬於哪一種，不必猜：後台的系統狀態報告會列出它實際覆寫了哪些範本檔，那份清單就是責任範圍的書面紀錄。這是一份持續履約的義務，所以看主題時，樣板數量與頁面截圖只是行銷數字，變更紀錄裡有沒有持續出現相容性修正，才是履約證明。

購物車與結帳還有一條容易踩錯的責任線：新版的購物車與結帳頁面可以由區塊提供，舊式做法則交給經典短代碼與範本輸出，兩套實作同時存在。檢查商店流程時要把兩條路分開驗證，先確認目前啟用的是哪一套，才不會把區塊版本的問題記到主題帳上，或反過來錯怪外掛。

頁面編輯器是最常被劃錯的一層。它不在主題的管轄範圍裡，而是把版面產出獨立成另一套工具；有些主題把編輯器綁在自己身上，有些開放搭配各家工具。三層全包的方案看起來省事，任何一層出事卻都會牽連整站，責任邊界也最難畫清楚。

這也是歸因不能憑直覺的背景。WooCommerce 在 W3Techs 追蹤的網站裡長期占有一席之地（依 2026 年中的查詢資料），圍繞它的主題與外掛組合數以千計，同一個症狀在不同組合裡可能有三種病因。商店頁的適配程度也有落差，同一款主題對文章頁與商品頁的投入常不成比例；文案裡的「完整支援」只是起點，判斷以自己商店頁面的實際輸出為準。

責任邊界畫清楚之後，客製的存放位置就跟著有了紀律。字型、間距這類視覺調整放進附加 CSS，主題更新不會洗掉它；動到範本檔的修改，放進子主題而不是直接改父主題，否則下一次更新就會歸零；功能性與資料類的擴充，交給外掛而不是硬寫進主題。三個存放位置對應三種修改深度，每一層的維護責任與移轉成本都不同：附加 CSS 幾乎零負擔，子主題要跟著父主題的範本異動同步調整，寫進主題的客製則會在換主題那天全部清空。買主題之前先想清楚自己會用到哪一層，這份紀律也決定了將來換主題時，哪些資產可以無痛帶走。

訂單在流血，兇手是主題還是外掛？

直接講做法：完整備份之後，在測試環境把主題暫時切回 WordPress 內建的預設主題，再跑一次出事的流程。症狀消失，問題指向主題的範本層或樣式層；症狀還在，主角就不是主題，接著交叉停用可疑外掛，通常一輪就能把責任定格。歸因完成之前，任何換主題的衝動都是賭博。

用一個構建的示意情境走一遍。一間手作皮革配件的一人品牌店，促單貼文發出後，手機端結帳欄位擠成一團、按鈕點了沒反應，老闆第一個懷疑的對象是上週剛更新過的主題。對照測試的結果：切回預設主題，欄位依然重疊；停用表單外掛後畫面恢復正常。病因是外掛的樣式與主題的樣式互相覆蓋，主題只占了半份責任。要是當晚直接刷卡換主題，下一個檔期同樣的問題還會再上演一次。情境是虛構的，流程是可以照做的。

歸因時手上最好有一份症狀對照，能省下大量摸索，但要記得它給的是起查方向，不是判決書：按鈕點了沒反應、畫面沒有回饋，可能來自範本衝突，也可能是 JavaScript 拋錯、按鈕被浮動元件蓋住、快取吐出舊版頁面，先打開瀏覽器的主控台看有沒有錯誤訊息再往下查；欄位跑版、文字重疊，方向多落在樣式層；流程走到一半卡死、付款後訂單沒有成立，常出現在金物流外掛與前端的銜接處。三類症狀三個方向，先分類再動手，但分類只負責縮小範圍，定案仍要靠上一段的對照測試，不要一上來就全站重灌。

排查外掛時，對照一份整理過的 WooCommerce 必裝外掛清單能加快定位，哪種功能該交給哪個專職外掛，清單比記憶可靠。確認問題落在結帳欄位本身時，結帳表單的客製化做法提供欄位調整的幾條安全路徑；手機版的檢查項目，可以對照 購物網站的響應式設計原則逐項走一遍。

手機要擺在第一順位檢查，理由很簡單：全球網站流量有超過六成來自行動裝置（依 Statista 2026 年 4 月的統計），而結帳這一關在手機上又最脆弱。市場數字只負責排優先順序，你自己商店的裝置比例與流失數據，才是最終裁判。

實機走一遍的動作很土，卻最有效：用自己的手機從商品頁開始，加購、變更數量、套用優惠、填資料、付款，每一步都注意鍵盤彈出時畫面會不會跳、按鈕會不會被浮動元件蓋住、載入過程有沒有畫面停格。模擬器的縮放視窗測不出這些，指尖的真實手感才算數。

歸因結果要寫下來：做了什麼測試、症狀有無變化、指向哪一層。這份紀錄有兩個用處，向主題或外掛開發者回報時，可重現的資訊能大幅縮短來回；日後評估換主題時，它就是「問題是否真的出在主題」的直接證據，不用再猜一次。

你的店靠哪一頁賺錢，主題就該強在哪裡

路線選擇的第一個輸入，是商店的頁型結構。打開分析後台，看流量與訂單實際落在哪一種頁面，驗收的力氣就押在那裡，其餘頁面及格就好。三種常見結構，對應三種檢查重心：

1. 商品頁驅動：顧客從搜尋的長尾詞直接進到商品頁，商品頁的版面與標記就是收入命脈，主題對商品頁的著墨要最深，規格、評論、運費資訊的排版都要經得起檢查。
2. 分類頁驅動：顧客以逛與篩選為主，商品數量通常龐大，分類頁的承載量與篩選行為是重心，塞滿商品與篩選條件後還能順暢操作，才算過關。
3. 活動頁驅動：檔期著陸頁與內容頁扛轉換，編輯彈性是重心，首頁與活動頁要能快速改版，這時頁面編輯器的角色比主題本身更重，例如 用頁面編輯器做商品輪播之前的相容性評估，就屬於這一類功課。

頁型結構怎麼看出來？分析後台看三個地方就夠：電子商務報表裡，使用者在哪一頁完成購物，是商品頁直接結帳，還是繞經分類頁再回頭；到達頁面報表裡，新訪客第一眼落在哪種頁面；裝置報表裡，手機與桌機的行為差多少。三份報表交叉看，答案通常很清楚；看不出來的時候，代表商店還年輕、頁型還沒定型，這時選彈性高一點的路線，把選擇權留給未來的自己。

規模是把隱形的尺。demo 裡放六樣商品的分類頁，與兩千樣商品的分類頁是兩個世界；demo 測的是前排的演出，營運拚的是後台的承載。把候選主題放上自己的資料量再看一次，很多「看起來很快」的印象會當場改觀。

同樣用一個構建示意：一間 3C 周邊的中型商店，商品數突破一千之後，分類頁開始變慢，篩選條件一多，網址組合也跟著膨脹。這種症狀常被歸因給主機，實際量測後才發現瓶頸落在分類頁範本與篩選器的行為上。這個情境在討論搜尋時還會再出現一次，因為它的後遺症不止速度。

頁型結構沒有標準答案，數據說了算。別人的排行榜是從別人的頁型結構長出來的結論，套用之前，先確認你們靠同一種頁面賺錢。

誰來顧店決定編輯路線：綁在一起還是各自獨立

第二個輸入是人力。問一個問題就好：半年之後，這家店的版面主要誰在改？答案決定你站在三種關係的哪一邊。市面上的組合大致有三種：可以搭配外部編輯器的主題、獨立的外部編輯器、主題與編輯器綁在一起的一體化工具。三種都做得出漂亮的店，差別在日後的每一天。

把三種關係放上同一張桌子比較，取捨會清楚很多：綁定式把版面工具收進主題，日常編輯集中在一個介面裡完成，代價是版面成果與主題綁在一起，將來換主題時多半帶不走；開放式讓版面工具獨立於主題之外，替換的自由度高，代價是相容性要自己測、整合的責任要自己扛。判斷落在三個問題上：日常編輯主要在哪裡做、既有版面對哪個工具相依、改版或換主題時打算怎麼替換。答案偏向集中的工作流程就選綁定，偏向可替換的自由就選開放，這是取捨題，優劣沒有標準答案。

「帶不走」三個字值得展開，而且要展開得精確。綁定式工具做出來的活動頁，資料存在它自己的格式裡，換主題之後那些版面等於歸零重建；開放式工具則要再分兩種情況：用區塊編輯器排的版面，內容就存在文章本體裡，主題換了，內容與排版多半還在，頂多樣式重調；用 Elementor、WPBakery 這類編輯器排的版面，資料存在各家的專屬格式裡，編輯器持續啟用，主題更換通常不影響呈現，但若想換到另一套編輯器，版面不會自動互換，移植要靠人工。換句話說，帶不帶得走，取決於版面存在誰的格式裡。這個差異平常看不見，它只在你要離開的那一天顯形，所以簽約前先問「我的版面存在哪裡」，是這一節最想留下的一句話。

具體產品點到為止，夠辨識路線就好。官方的 Storefront 是經典架構的基線，樸素但與本體同步維護；Astra 走輕量框架路線，開放搭配各種編輯器，與 WooCommerce 的整合細節可以看 Astra 搭配 WooCommerce 的設定指南；Flatsome 自帶專屬的 UX Builder，商店版型開箱即用，是綁定式的代表；WoodMart 的做法略有不同，它提供自家的版面與標頭建構工具，編輯器開放搭配 Gutenberg、Elementor 或 WPBakery，屬於深度整合而不限於單一工具的電商專用路線，各自的細節有 Flatsome 操作教學與 WoodMart 設定教學可以深挖。名單裡還有誰值得考慮，交給推薦清單那篇，這裡只認路線、不認品牌。

經典與區塊的差異，是獨立於綁定或開放之外的另一條判準。區塊主題的商店範本可以在網站編輯器裡直接調整，經典主題依賴傳統的範本檔與設定面板，兩者編輯的位置不同，不能混為一談；經典主題的文章與頁面仍然可以使用區塊，只是沒有同一套商店範本編輯能力。誰負責改版，決定這條判準的權重：習慣在模板介面裡作業的團隊，與依賴範本檔開發的工程師，會得到不同的答案。

決定走區塊路線的話，主題的角色會變薄、編輯器的角色會變重，區塊編輯器的外掛生態值得先逛一圈；決定走外部編輯器路線的話，頁面編輯器的整體比較能省下逐款試錯的時間。工具鏈的選擇，最終都回到同一個問題：半年後誰在顧店。

標價以外的帳單：授權範圍與支援期限

第三個輸入是預算結構。一款主題的真實成本等於四項相加：授權範圍、支援與更新期限、必要的擴充、自己的維護工時。標價只覆蓋第一項的門票，後面三項才是帳單的主體。採購前把四項攤開來算，結論常常和只看標價相差好幾倍。

必要擴充這一項，要在採購前就列出清單。把商店未來一年真的會用到的功能寫下來：願望清單、快速查看、比較表、多幣別、進階的欄位工具，逐項核對候選主題是內建、可用外掛補上、還是要買它自家的付費擴充。同一張清單貼著兩個候選各算一次總帳，標價的差距常常在這一步被翻轉；內建一堆用不到的功能，反而是另一種形式的浪費，載入與維護都要付利息。

授權範圍是最常被算錯的一項。依 Envato 在授權問答裡的說明，公開販售商品的商店，通常不會只因為商業用途就必須升級到 Extended License，Regular License 的涵蓋範圍比多數採購者以為的寬。要分開看的是兩件容易混淆的事：支援續期不等於更新下載權，也不等於新站點的授權。每款主題的條款逐份核對，續約之前把授權、支援與更新的邊界看清楚再刷卡。

維護工時是最容易被忽略的一項，換算方式很直觀：把未來一年預計花在版面上的小時數，乘上你的時間成本，加進總帳。時間比授權費稀缺的店主，整合度高的方案往往真的比較省；願意用學習曲線換長期彈性的人，前期多花的工時，就當成學費的一部分先記進帳裡。

免費與付費的判斷併在這裡談，因為它也是帳單的一部分：能通過整套驗收流程的免費方案，撐起一家正式營運的商店並不勉強；付費買的主要是支援與持續更新的保障。買之前的程序細節，主題市集的購買眉角整理過一輪；整體開站預算的拆解，可以對照 WordPress 架站費用的完整分析；免費版與付費版的界線怎麼畫，Astra Pro 的升級評測是一個具體示範。一體化方案的年費或一次性結構，簽之前把退場條件看清楚：停止續約之後，下載、支援與授權各留下什麼。

先別刷卡：把候選主題放上同台主機賽一輪

驗收的核心思想只有一句話：控制變因。同一台主機、同一份商品資料、同一套外掛清單，候選主題裝在同一個測試環境裡並排跑，量出來的差距才有意義。圖檔與快取設定也要固定，這兩項一變，量到的就不再是主題的差異。

方法本身不複雜：候選主題裝進測試環境後，分類頁、商品頁、結帳頁各量一輪，逐頁記下請求數、傳輸量、LCP、CLS 與 JavaScript 執行時間，每個數字量三次取中位數。同一份資料、多種頁型、逐頁診斷，差距落在哪一頁、由哪個資源造成，證據會自己說話。

紀錄表格每個候選一張，長相如下：

↔ 左右捲動檢視完整表格

量測欄位	分類頁	商品頁	結帳頁
請求數
傳輸量
LCP
CLS
JavaScript 執行時間

分數的定位也要先講清楚。依 Google 對頁面體驗的評估說明，Core Web Vitals 是排名系統眾多訊號之一，分數好不保證排名，內容相關性仍然排在前面；現行的指標定義與判準，以 頁面體驗文件為準。速度對生意的作用更直接，web.dev 整理的研究把載入時間與使用者的去留連在一起看。外部資料都只供定位，定案仍要回到自己站的量測與轉換數據。

工具的選擇按頁面類型分：公開的頁面用 PageSpeed Insights 跑，同時看實驗室數據與實際使用者數據；結帳這種需要登入或觸發交易的頁面，用本機開發者工具的網路與效能面板錄製，看每個請求的耗時與主執行緒的佔用。兩種工具的數字不要混著比，實驗室數據跟實驗室數據比，使用者數據跟使用者數據比，結論才不會打架。

測試環境的取得不難：多數主機商的方案附一件式 staging 功能，按個鈕就能複製一份正式站；沒有這個功能的，用備份外掛把站搬到子網域或本機環境，一樣能做。環境的重點在「同規格」三個字：PHP 版本、資料庫與正式站相同，量出來的數字才有搬回正式站的意義。

進測試環境之前，還有一道低成本初篩：看候選主題的出廠重量。到它的 demo 站打開開發者工具，看原始載入的 CSS 與 JavaScript 有多大、有沒有載進一堆用不到的函式庫、畫面外的商品圖有沒有延遲載入。起步就重的主題，後續優化只能救回一部分，這樣的候選在並排測試裡通常也會自己現形。

並排測試別漏掉無障礙這一項，它跟速度一樣藏在主題的骨子裡。用鍵盤把商品頁、購物車與結帳走一遍，看焦點是否清楚可見、會不會被浮動元件蓋掉；檢查商品圖有沒有替代文字的輸入位置、按鈕與價格的顏色對比是否足以辨識。這些檢查與 WCAG 的原則同源，逐項對照即可，不必另學一套標準。主題在 demo 裡看不出這些細節，裝上自己的內容實測才見真章；而無障礙問題的修改成本落差很大：樣式層的小調整救得回來，範本層的結構性障礙就要直接列入淘汰條件。

並排測完、留下某個候選之後，速度的補救工程才登場：網站速度優化的完整做法與 Core Web Vitals 的 SEO 觀點涵蓋主題之外的變因，快取外掛與 圖片優化工具是補救層的兩件標配。順序別顛倒，先量測、後補救，才知道補救有沒有效。

搜尋引擎看得到你的商品嗎

主題對「被找到」的影響，集中在標記輸出、麵包屑、標題層級與可抓取的連結。這幾件事在換主題時都可能變動，也是換題之後搜尋波動的主要來源。檢查不需要精通 SEO，逐項看實際輸出即可。

標記從實際輸出檢查。商品頁的 Product 標記可能由 WooCommerce 本體輸出，也可能被 SEO 外掛接手，主題再插手時，最容易出現同一商品多份標記互相衝突。把代表性的商品頁丟進 Rich Results Test，核對實體、欄位與警告；通過測試只代表取得部分顯示資格，Google 不保證顯示複合式搜尋結果，更不承諾排名。

麵包屑由主題或 SEO 外掛擇一輸出就好，兩套同時輸出只會增加混淆。標題層級看語意順序：商品名稱是主標題，描述、規格、評論往下展開，層級有序、輔助科技讀得順，就及格；機械式地數有幾個標題標籤，沒有診斷價值。

可抓取的連結這一項，看的是主題產生連結的方式。篩選器若用 JavaScript 動態產生網址，搜尋引擎可能抓不到篩選後的結果；分頁若用無限捲動，要確認有對應的分頁連結可以遵循。這些行為在 demo 裡看不出來，要裝上自己的商品與篩選條件才會現形，這也是驗收流程堅持用自己資料的原因之一。

篩選與分頁是另一個靜默的變因。回頭看那間 3C 周邊商店：篩選條件排列組合出大量參數網址，搜尋引擎逐一抓回，索引裡慢慢堆滿內容幾乎相同的頁面。這種情況先別急著談處罰，優先順序是顧好索引狀態與重複網址的管理，讓每種網址的行為可以預測。主題在這裡的責任，是提供可預期的網址與連結結構。

把每個檢查各做一遍的時間成本，大約是一個下午。順序建議從標記開始，它最依賴工具、最容易客觀判讀；接著看麵包屑的輸出者，檢視原始碼搜 BreadcrumbList，確認只有一份；標題層級用瀏覽器的大綱檢視或讀者模式掃一遍，順不順一眼可辨。檢查結果照樣留紀錄，換主題之後才有比對的基準。

換主題前後，把首頁、分類頁、商品頁與結帳頁的原始碼各存一份，換完逐頁比對標記與標題有沒有少、有沒有撞。更細的商品頁優化，商品頁 SEO 手冊有完整流程；描述與規格怎麼拆進頁籤、對標記與可讀性的影響，可以看 自訂商品頁籤的做法。

換題手術的前置訊號與兩段式上線

什麼訊號出現，才值得承擔換題的風險？四個：主題長期未更新，且相容性無法確認；WooCommerce 每次升級都反覆出事；控制變因之後，效能瓶頸確認來自主題；現有架構撐不住新的營運需求。訊號要看證據，證據藏在維護軌跡裡：最近更新日期、變更紀錄裡有沒有持續出現 WooCommerce 相容修正、支援討論區是否仍有回應。沒有「超過幾年就一定換」的絕對門檻，兩個極端都別走：小瑕疵先用附加 CSS 或專職外掛解決，別為了逃避換題而無限補丁。

確定要換，先在測試環境完整重建一次商店，把商品、分類、金物流與自訂版面都驗過一輪再談切換。安裝、啟用與閒置主題的清理，照 主題安裝與切換的完整流程走即可，這裡不複述點擊路徑。

手術的順序照官方建議最穩：先完整備份，再於測試環境把新主題的安裝、設定與交易流程驗過一輪，確認無誤後選離峰時段在正式環境套用，套用當天把購物車、結帳、付款與通知逐項再檢查一次。部署時保留正式站最新的訂單與客戶資料，不能用測試資料庫整包覆蓋；上線後的幾週，用改版前可比較期間的轉換、錯誤與搜尋數據盯著，異常才有基準可比。

監控的指標抓四組就好：訂單轉換率與結帳完成率，看生意有沒有受傷；前台錯誤與伺服器紀錄，看技術有沒有破洞；Search Console 的索引狀態與點擊，看搜尋端有沒有異常；自然搜尋帶來的營收，看整體體質。每組都拿改版前可比較期間的數字當基準，季節波動要先扣掉，別把週期當事故。

上線的紀律是把變因拆開：第一次切換只動主題，版面樣式盡量貼近原本的長相，讓營收與結帳流程的數據先穩定下來；確認交易與搜尋端都沒有異常，第二次才做設計改版。兩種變更分兩次上線，哪一次出問題，責任範圍就清楚，排查也才有起點；一口氣全改，連後悔都找不到對象。

備份是整場手術的保險，方案不用花哨，要的是排程可靠、還原演練過。備份外掛的選擇提供橫向比較，UpdraftPlus 的備份教學把設定與還原走了一遍。動手之前備份跑完、還原路徑確認過，這條底線沒有例外。

舊主題的退場也要處理乾淨。切換完成、確認一切穩定之後，把不再使用的主題與其配套外掛移除，一方面減少更新與安全的負擔，一方面避免日後混淆哪一套範本在線上。移除之前，把它的授權範圍、購買紀錄與客製內容的位置記進同一份文件，這份文件就是這次換題手術的結案報告。

一頁決策卡：把感覺換成可勾選的條件

把三個經營條件與淘汰條件收斂成一張卡，決策現場直接對照，不需要每次重新辯論：

↔ 左右捲動檢視完整表格

經營條件	你的情況	優先考慮的路線	不能讓步的紅線
頁型重心	訂單多從商品頁進來	商品版面與標記扎實的路線	Product 標記單一無衝突
頁型重心	顧客以逛與篩選為主	分類承載量經得起資料量	滿檔的分類頁仍順暢可用
頁型重心	檔期活動頁扛轉換	編輯彈性高的組合	改版不依賴單一工程師
維護人力	一人顧店、求快求省	整合度高的一體化或專用主題	更新與支援仍在滾動
維護人力	有團隊、常做活動頁	開放式框架加外部編輯器	版面成果可攜出
預算結構	時間比授權費稀缺	少組裝、整合度高的方案	支援期限與退場條件透明

這張卡的用法，是跟候選名單搭配，不是取代名單。名單交給 WooCommerce 主題推薦清單那篇，它的職責是買之前把候選過一遍關卡；這一篇的職責是營運中商店的歸因、路線、驗收與換題工程。兩篇各司其職，先把條件勾出來，再帶著名單去比對，順序顛倒就容易變成看圖購物。

想比的範圍更大的人，WordPress 主題的整體對照把電商以外的網站類型也納進來；連開店平台都還沒定的人，先到 電商平台比較把前置決定做完再回來挑主題，路才不會白走。

回到週五晚上那通事故。它真正教的事，是每一個環節都要留下證據：歸因有紀錄，路線有條件，驗收有數據，上線有階段。一套主題最貴的成本，常出現在決定換掉它的那天，而那天會不會來、來的時候有多痛，取決於簽下這份範本維護契約之前，你看清楚了哪些條款。把流程走完，任何名單上的名字，都會從一張漂亮截圖變成一組可以檢驗的數字。

如果這套流程走起來卡住了，Whoops 可以陪你把對照測試與並排驗收實際跑一遍，把換題風險拆成可控的步驟；卡關的時候，歡迎來聊聊。