自訂網站與WordPress比較：按內容更新、功能整合與維護能力取捨

自訂網站與WordPress比較：先讓兩種方案說出各自的前提

自訂網站與WordPress比較，第一個問題並非哪一種較「高級」，而是公司內容由誰更新、哪些流程要與其他系統接駁、日後由誰維護。假設一間九龍灣貿易公司需要職員每週更新產品，又要讓營運同事按客戶類型編排產品資料；如果只比較首頁設計，很難找到真正的差異。本文用兩種架構的問答，讓團隊先說清工作方法，再決定應如何採購。

這裏所說的自訂網站，是按實際需要設計資料欄位、編輯流程及程式功能的網站；WordPress 則指採用其核心系統並按需要選擇主題及外掛的網站。兩邊都可設計公司網頁，也都需要寄存、備份與管理。Black Media 提供網頁設計及程式編寫服務；本文不會把公司使用的特定網站系統誤當成 WordPress，亦不會假設所有客戶的後台都相同。

第一輪辯論：內容部門每天要做甚麼

WordPress 方：通用編輯流程先行

如果工作主要是撰寫文章、編輯一般頁面、管理圖片，現成內容管理方式可縮短摸索起點。編輯者要確認頁面是否能建立所需分類、預覽和修訂；使用主題與外掛時，還要測試它們互相更新後會否影響編輯畫面。不要只問能否「自己改文字」：職員能否在不誤刪導覽的情況下改頁面、上載圖片後是否保留替代文字、發布前能否找另一位同事覆核，才是具體工作。

自訂網站方：先把資料結構與權限設計好

如果每個產品有不同規格、批發資料、下載文件和對應行業，按工作流程建立欄位可以減少職員在自由文字框反覆複製資料。代價是要先定義欄位、角色與驗收方法。假設行銷職員只能修改展示文字，採購同事才能更改產品型號，管理權限和操作紀錄便要在開發前說清楚。後台訂得太死，也會令日後新增資料類型需要再開發，故宜預留哪些部分可由商戶自行調整。

如果網站仍在需求整理階段，先看網站設計項目的分工流程，把編輯者和審批者拉到同一次需求會議。平台選擇應回到可操作的工作任務，而不是只由老闆看外觀樣板決定。

第二輪辯論：功能接駁會否變成維護負擔

現成外掛並非「按安裝就完成」

WordPress 有外掛可處理不同需要，卻要檢查更新頻率、相容版本、資料存放方式、權限和停用後的後果。假設聯絡表單需要把查詢送往內部系統，選用現成工具前，先測試欄位對應、失敗後能否重送、重複提交如何處理，以及敏感資料會否留在不必要的位置。若三個外掛都能完成一半要求，組合起來的維護責任也須列在採購表內。

自訂功能也不是「一次寫好永遠不用改」

自訂程式可按需要明確處理資料驗證、外部系統接駁與權限，但第三方介面變動、作業環境升級、員工需求改變仍要維護。問開發方：哪部分有文件、日後怎樣測試變更、若原團隊不在場，新團隊能否找到資料表及主要流程？一個完全依賴個人記憶的系統，就算最初很貼合業務，日後的接手成本亦可能很高。

若原本的網站已有很多內容與搜尋入口，改平台時也要看改版的網址與內容交接；平台轉換並不自動保留舊文章、檔案連結或分類，搬移前要做資料對照。

第三輪辯論：誰負責更新與保安

WordPress 的共同責任要寫入工作表

核心、主題及外掛可能分別更新。負責人須知道何時備份、在哪裏測試更新、發現衝突後怎樣回復，以及誰檢查後台帳戶。即使設定自動更新，也不等於版面及功能經過驗收。先盤點管理員權限、外掛清單和不再使用的功能，再決定哪些更新可按程序安排、哪些需先進測試環境。這些問題可和網站保安檢查項目一起覆核。

自訂網站的升級責任同樣不能空白

自訂後台不一定要追隨 WordPress 外掛節奏，卻仍有 PHP、資料庫、第三方函式庫及伺服器環境的維護。合約應列出程式安全修正、功能修改和基礎設施更新各由誰負責。若供應商說「網站已交付」，商戶要追問日後報錯、登入權限和版本升級的處理渠道；只把整站放在網站寄存服務，不能代替對程式的維護安排。

• 列出擁有域名、原始程式、後台及寄存帳戶的角色。
• 列出核心或第三方元件更新前的備份與測試步驟。
• 訂出日常內容更改與程式變更的批准分界。
• 實際演練一次還原，確定網站和資料庫能一起回來。

第四輪辯論：價錢、時程怎樣比較才算同一基礎

不要把未定義的「網站一個」當成報價單位

比較兩份方案時，先用同一份需求列出頁面、內容遷移、語言、編輯權限、表單、外部接駁、SEO 基本設定、維護及培訓。現成主題方案可能初期設計較快，但若要改動大量版型或整合複雜工作流，仍有額外工作；自訂方案需要先分析和設計，卻不代表每個需求都必須寫全套獨立系統。先問哪些已包括、哪些以後另議，避免以價格高低直接推論方案好壞。

用實際操作而不是示範首頁作驗收

挑一篇文章、一件產品、一張查詢表單，讓同事完整建立、修改、預覽、發布及回退一次。若有多語言，檢查翻譯版如何建立、共用圖片和網址怎樣管理；若有不同人審批，檢查草稿是否會被一般編輯直接公開。將每項操作記成「誰做、在哪裏做、甚麼算完成」，才可將報價範圍和驗收條件對上。網站設計報價拆項可作整理範圍的延伸閱讀。

第五輪辯論：日後想換供應商，可以帶走甚麼

先問資料出口，再問外觀改得多美

內容屬於公司日常資產。決定網站方案前，問清文章、產品、客戶查詢及圖片如何匯出；資料匯出的格式能否重新使用；特殊欄位是否有說明。WordPress 和自訂系統都可以遇到資料被外掛或特殊結構綁住的情況，不能只根據平台名稱推斷可搬遷程度。測試一次樣本匯出，再看是否能在另一個環境重建，往往比口頭答應「將來可轉」可靠。

程式權限與授權範圍要事前寫明

自訂程式能否由其他開發者維護，涉及源碼取得、部署說明與第三方元件授權；使用 WordPress，也要查主題與外掛的合法使用、續期及帳戶誰持有。商戶應和供應商確認交付清單，並由內部保管必要帳戶，避免前任員工離開後誰都無法登入。另一方面，取得所有密碼卻無人知道如何更新，也未能真正減少風險。

• 請求一份可讀的內容與媒體匯出樣本。
• 核對域名、寄存、外掛或第三方平台由誰開立帳戶。
• 確認程式、設計檔與授權項目的交付和後續使用範圍。
• 安排新負責人按文件完成一次小修改，測試交接可行性。

替兩種方案做同一份「一天工作」實測

編輯一天從哪裏開始

請負責內容的同事先不看技術簡報，只拿着真實的工作清單操作：早上更改產品說明，中午批准一篇文章，下班前撤下已過期的活動頁。WordPress 方案若依賴多個外掛，測試每一步要進哪個畫面，誰可以按發布；自訂方案則要看能否清楚標示內容狀態，以及是否有草稿和正式版本的分界。把耗時與錯誤記下來，但別只用秒數作決定，因為新系統初次使用較慢是正常；重點是常做的工作經過培訓後，職員能否獨立而可靠地完成。

行銷和客服的任務也要一起測

行銷同事可能要複製活動頁、替換表單欄位並量度查詢；客服則要確認提交後有沒有通知、資料可否查找及刪除。若行銷部門每次改一段字都要請程式員，業務安排便容易受制於排程；反過來說，把所有欄位放給每人任意改，又可能令客服找不到原有的關鍵資料。測試時讓兩類同事各自完成一個真實任務，再交叉核對：新活動查詢能否從頁面進入正確的後台工作清單？

內容模型會影響往後每次改版

先選一類最複雜的內容作樣本

若公司有案例、招聘、技術文件、下載表格及商品型號，不妨挑最複雜的一種寫出資料欄位。列出標題、分類、簡介、發布日期、關聯服務與附件，注明哪些可重複、哪些只供管理員更改。用 WordPress 實作時要問相應內容類型是否由核心能力、主題或外掛提供；用自訂後台則要問新增欄位後既有內容會如何處理。當資料本來就有結構，全部塞進一個自由文字欄位，看似方便，日後排序、篩選、批量更新都可能變得麻煩。

不要讓搜尋入口依賴偶然的編輯習慣

網站編輯一旦要兼顧 SEO，便須知道網頁標題、描述、標準網址、分類與頁面正文由哪裏設定。WordPress 可由適用工具管理，但安裝工具不代表每頁欄位會自動寫得恰當；自訂後台若預留相應欄位，也要清楚顯示何時生效，避免多處同時覆寫。拿一篇舊文章與一篇新文章測試搜尋結果所需資訊，核對頁面有唯一標題、網址不會因改文字而無意變動，以及錯誤頁有合適處理。

多語言、權限與審批不是外觀選項

兩種語言的內容要各自有人負責

中文及英文頁面可能不在同一天更新，服務名稱也未必可以逐字直譯。需求表須說明各語言的草稿、發布與缺頁處理方式：英文版還未完成時，網站是暫時不顯示、顯示提示，還是連回中文？後台操作也要讓編輯者知道自己正在改哪個語言版本。無論使用現成多語言工具還是自訂資料結構，都先以一篇長文、一頁服務介紹與一個表單測試完整流程，避免只在導覽加入翻譯按鈕便宣稱完成。

批准流程要與人員分工相配

管理員可改網站設定，編輯者可改內容，負責財務的同事只需讀取訂單：這些權限不能以「大家共用一個登入」解決。要求候選方案演示建立新帳戶、撤銷離職帳戶、拒絕未獲授權的操作，以及必要的操作紀錄。WordPress 的標準角色可作起點，但功能擴充後仍要查額外權限；自訂後台則要明確設計權限和驗證，不可只把不能用的按鈕藏起來。

維護工作可以用一個月的時間表估算

把修正、編輯和基建分成三條線

假設某月有三篇文章要發布、一個表單欄位要修改、寄存環境有更新通知，這三件事可由不同人處理。內容編輯需檢查預覽與文字，功能修正要有測試與回復，環境更新須有相容性和備份確認。把每件事寫成工作單，列出可自行處理或要外包、批准人、驗收人及最遲要有結果的時間。這樣比較後續負擔會比問「一年維護費幾多」更準確，因為報價範圍未必包含同一種工作。

版本與依賴有了清單才能交接

WordPress 網站要知道核心、主題、外掛、特別設定的清單；自訂網站則要有語言版本、資料庫結構、外部介面、部署方法及必要的相容限制。兩邊都要有一份「上線後怎樣判斷功能正常」的簡單流程，例如提交不發真信的測試表單、抽查登入與文章。若某個部分只能由一人修理，先問文件可否補齊，或者能否把高風險工作移回可由一般團隊維護的做法。

比較報價時，也要列出沒有交付的部分

未包括內容與第三方服務，會影響真正上線

假設方案 A 包括網站版面但不包括文章整理，方案 B 包括後台培訓卻不處理舊頁轉址，直接比總額便像比較兩種不同商品。請供應商按同一份範圍逐項回覆：內容由誰提供，圖片誰有使用權，第三方服務需由誰開戶，是否含測試資料、使用手冊與交接時間。商戶亦要自行決定哪些範圍先上線，哪些留作第二階段，而非把不確定的需求通通塞進一句「之後再加」。

驗收紀錄可防止需求在口頭往返中消失

每個重要功能指定一個可觀察結果，例如編輯者按權限新增文章、客服收到有正確欄位的查詢、匯出資料與後台筆數對得上。記下測試資料及畫面，尤其是提交失敗、重複提交、舊頁開啟等不順利情況。若需求已改，雙方更新工作範圍及驗收項目，日後才可分清新需求和原本未完成的部分。選 WordPress 或自訂程式皆是方法，合適的驗收準則才讓採購不靠猜。

如何在會議上得出可執行決定

寫三個結論，而非逼自己投票選平台

會議結束可寫「現有工作可由哪種方法滿足」、「仍待測試哪項風險」、「誰要在何時交出資料」。例如產品欄位數目仍未確認，先請營運整理十件具有代表性的商品；若對外接駁的規格還未拿到，先向現有供應商索取文件。待事實齊全才比對方案，而不是因其中一方當場示範較流暢便匆忙決定。若現有系統仍可用，亦可評估先改善內容流程，再決定是否需要整站換架構。

將來如何證明選擇仍然合適

上線後約定定期回看幾件事：職員更新內容是否仍要繞路，修正功能是否需要多人接力，資料能否完整匯出，更新時是否經常影響頁面。若某些任務開始增加，先檢查能否調整欄位或權限，而非立刻宣告整套系統失敗。當管理工作量確實改變，再用原本留下的需求、實測及交接文件重新評估；這比以平台標籤決定下次改版方向更能節省溝通時間。

失敗情境能透露日常展示看不到的差異

圖片已上傳，卻在前台顯示不到

假設編輯者在後台看到檔案已存在，公開頁卻出現空白，先問圖片儲存在哪裏、輸出路徑怎樣生成、預覽和正式環境是否指向同一位置。WordPress 方案可能涉及媒體庫、主題輸出或快取；自訂網站可能牽涉檔案權限與指定欄位。供應商應展示如何查問題和回復顯示，而不是把所有錯誤都叫職員重新上載。若原圖由外部平台控制，還要釐清圖像失效時誰能提供替代內容。

客服說沒有收到客人提交的資料

表單畫面顯示成功，不代表電郵或內部系統已收到資料。驗收時用虛構資料提交，核對網站有否儲存必要的查詢紀錄、寄件失敗是否可見、重試會否產生重複工單。無論選哪種架構，商戶都應知道查詢在系統中走過哪幾站，遇上故障由誰查寄件紀錄、由誰向客人跟進。只用一封成功測試電郵作證據，難以覆蓋真實營運的例外。

訂製邊界可用「必須」「可以遲些」劃開

首批功能先求可操作且可交接

商戶可以將功能分成首日必須、上線後優先，以及仍待驗證三類。職員要能發布服務內容、收妥客人查詢、找到必要的編輯權限，屬於首日必須；複雜的自動化推薦或跨平台同步若規則尚未確認，則不宜在合約裏用籠統一句硬寫進去。這種分法不只方便估工作，也能測出供應商是否了解核心流程。若一個外掛已充分處理某項小功能，沒有必要因為選了自訂網站便重新寫一套；若現成工具無法安全滿足特定權限，也不應為了選 WordPress 而迴避需求。

交付不等於停止對話

網站上線後，由誰收集編輯同事的意見、誰決定是否新增欄位、誰測試在手機上的顯示，都應留有渠道。對於 WordPress，新增外掛前先核對現有設定會否衝突；對於自訂系統，提出新欄位前先問舊資料怎樣顯示與匯出。將每次功能變更記入一份簡短的變更清單，列出理由、測試與負責人，待下一次改版便能知道系統為何會變成今天的樣子。

最後一張選擇卡：把優缺點寫在自己的情況上

若公司日常只需維護幾頁服務資料和文章，並已有熟悉 WordPress 的職員，可先檢查現成編輯方式能否處理權限與表單；若公司最重要的是特殊商品資料、複雜審批和內部系統接駁，就以資料模型與維護交接作主要評估。這些都是假設的決策路徑，不代表任何平台必然達到相同效果。每個選擇都要有實際操作樣本、交付清單與後續責任。需求不明確時，先花時間畫出一個完整的客人查詢及內容更新流程，往往比先買一套系統更能釐清工作。

比較兩份樣本時，應請供應方說明哪個需求是靠核心功能、哪個靠額外組件，哪個必須開發。對最常操作的內容頁實際練習，試著改圖片、撤回一篇文章及匯出幾筆產品資料，再記錄哪一步要靠技術人員。若外部接駁仍未確定規格，先標記待確認，不要把模糊需求填成「支援整合」便當已完成評估。

另請負責未來維護的同事看交接文件。他能否指出伺服器設定在哪裏、出錯時先看甚麼、可否復原一份備份？若答案不清楚，兩種方案都要先補文件。網站交付時，公司需要的不只是能進後台的帳戶，也包括能判斷問題、找到負責人和安排下次更新的能力。

另外，把網站內容和功能分別交給負責編輯與客服的同事驗證，要求他們說出改動後哪一步比以前容易、哪一步仍要靠別人協助。若測試時發現操作繞路，先追查權限、欄位及指引，無須立即推翻整個平台選擇。

常見問題

WordPress 網站一定比自訂網站較難維護嗎？

不能單憑名稱判斷。WordPress 須管理核心、主題與外掛；自訂網站也要維護程式、資料庫和作業環境。比較時問清組件清單、更新與備份程序、測試環境及實際負責人。如果兩邊都沒有人手管理，風險不會因選擇某個名字而消失。

自訂網站能否讓員工自己更新內容？

可以，但須在需求階段寫出員工要改的具體項目與權限。某些網站只需更新文章及頁面，另一些要大量處理商品型號、文件和批量資料。先安排職員試做一輪，才知道欄位、預覽和發布審批是否足夠。

已經用 WordPress，還能改成自訂後台嗎？

可以評估，先盤點現有內容、分類、媒體、網址及外掛產生的資料，確定哪些必須保留。新系統要有對應欄位，舊網址更需制定處理方法；如需搬站，預留對照與上線測試，不能直接重畫頁面便刪掉舊站。

決定前，用一份業務任務表走完整個流程

自訂網站與WordPress比較的合理結果，可能是現成方式已滿足工作，也可能是先設計清楚資料與權限才值得自訂。把三件最常做、三件最怕出錯的工作交給候選方案試做，並寫明維護、內容匯出和交付責任，較能看出差別。如要一起檢視公司網站的功能與後台工作，可先整理實際操作問題，與 Black Media 討論網頁設計範圍，或經聯絡頁提交工作流程供評估。