網站重構 vs 重做完整決策框架：6 個訊號告訴你只要修補、5 個訊號該整個重做、4 條合約紅線——中小企業老闆 4-7 年舊網站升級不踩雷的最後一道關

我們最近幫一家做工業零件的中小企業客戶評估網站升級的時候，聽到一句話讓所有人愣住：「上次改版花了八個月、預算超支三倍，結果 Google 流量掉了四成。」這不是個案。

根據 Info-Tech Research Group 的研究，高達 80% 的網站重做專案無法交付可衡量的商業價值，根本原因在於決策者在「該修補還是全部重做」這個問題上走錯了第一步。更驚人的是，Forrester 的調查顯示 54% 的數位改造案失敗，是因為設計目標和業務目標從頭就沒對齊。

這篇文章的目的，是給中小企業老闆、IT 主管、採購評估者一份可直接套用的決策框架：6 個訊號告訴你只要修補、5 個訊號告訴你整個重做、4 條合約紅線讓你簽約前不踩雷。讀完之後，你應該能在 30 分鐘內判斷自己的網站屬於哪一類。

這個框架適用於 4 到 7 年以上的舊網站，也適用於你正在考慮換廠商、或是現有供應商說「要重做才能解決問題」但你半信半疑的情境。

先搞清楚「重構」和「重做」在技術上的真正差異

很多人把「重構」和「改版」混為一談，但在軟體工程的定義裡，兩者差距非常大。搞清楚定義，你才知道廠商報價時說的是哪一件事。

重構（Refactor）：保留現有架構與資料庫，對程式碼進行結構性優化。前台使用者看到的畫面可能幾乎沒變，但後台效能、可維護性、載入速度可以大幅改善。典型的重構作業包含：CSS 技術債清理、JavaScript bundle 拆分、圖片懶載入、伺服器端快取優化、資料庫查詢重寫。

重做（Rebuild）：從新的技術棧、新的資訊架構、新的 CMS 出發，重新建立整套系統。舊的程式碼不再使用，資料庫可能需要遷移，SEO 重定向規則要全部重設。這是一個新專案，不是舊專案的延伸。

介於兩者之間的「局部重做」也很常見：保留後台邏輯，換掉前台框架（例如從 jQuery 全站換成 React 元件化）。這種情況的技術複雜度和成本，通常比純重構高 40-60%，但比全站重做低 30-50%。

為什麼這個定義很重要？因為廠商說「要重做才能解決」的時候，你需要能問出：「重做是指換技術棧、換 CMS、還是只換前台框架？」這三個答案對應的預算跨度，從 20 萬到 200 萬都有可能。

6 個訊號告訴你：只要修補，不需要整個重做

以下 6 個訊號，任何一個符合，都代表你的網站還有可救的技術基礎，全部重做會浪費大量預算。

訊號一：核心業務邏輯仍然正確，只有前台速度差

如果你的後台訂單系統、會員登入、產品資料庫運作正常，只是前台 LCP（最大內容繪製）超過 4 秒，這是效能優化問題，不是架構問題。LCP 從 5s 優化到 1.5s，通常只需要圖片壓縮 + CDN 配置 + JS 延遲載入這三個動作，成本佔全站重做的 10-15%。

訊號二：設計風格過時，但資訊架構仍然清晰

使用者能找到他們需要的資訊，只是視覺語言停留在 2018 年的扁平設計風格。這是 UI 換皮問題，後台架構完全不需要動。換一套 CSS 框架或設計系統，通常 4-6 週可以完成。

訊號三：只有 1-2 個功能模組需要新增

你需要加一個線上預約系統、或是串接 LINE 官方帳號通知，但其他功能都運作良好。這是功能擴充，用模組化開發在現有架構上疊加即可，不需要重建整個平台。

訊號四：SEO 排名穩定，但某些頁面的 Core Web Vitals 紅燈

你的網站在 Google Search Console 有穩定的自然流量，只是部分頁面的 INP（互動到下一次繪製）或 CLS（累積佈局偏移）分數不佳。這是技術 SEO 修復問題，對頁面做針對性優化即可，搬家風險遠大於修復效益。

訊號五：原始碼完整，且有詳細的技術文件

你擁有完整的原始碼所有權、版本控制記錄，供應商也留下了開發文件。這代表技術債可以被量化，修補計畫可以被評估，不需要從零開始重建。（如果你不確定自己是否擁有原始碼，可以先參考《客製化軟體原始碼託管》這篇的合約重點。）

訊號六：現有供應商有能力且有意願維護

供應商仍然能夠快速回應你的維護需求，且報價合理。這代表知識轉移成本低，繼續在現有基礎上優化是最有效率的選擇。換供應商還沒搞清楚要換什麼，是常見的踩雷起點。

5 個訊號告訴你：整個重做才是正確答案

反過來，以下 5 個訊號代表你的舊網站已經進入「技術債超出修復效益」的區間，繼續修補只是在燒錢。

訊號一：原始碼已遺失或無法取得

這是最常見的情境。供應商已消失、或以「系統版本太舊」為由拒絕交付原始碼。沒有程式碼就沒辦法重構，只能重做。這種情況下，重做預算應該包含一筆「原始碼託管」條款，確保下次不再發生同樣問題。

訊號二：核心框架已停止維護，且有已知安全漏洞

例如網站建立在已終止支援的 PHP 5.x 或 CodeIgniter 2.x 上，或是 CMS 版本超過 5 年未更新。這類系統不只是效能差，更是資安風險。每年受到 SQL injection 或 XSS 攻擊的網站中，超過 60% 運行已停止支援的框架版本。繼續修補等於在漏水的船上加固船艙，根本問題沒有解決。

訊號三：行動端轉換率長期低於桌機端 50% 以上

台灣行動裝置流量已超過 70%，如果你的網站行動端轉換率持續比桌機低 50% 以上，通常代表底層 HTML 結構是桌機優先設計，用 CSS 媒體查詢「貼皮」出來的 RWD 版本，無論怎麼調都有根本性的使用者體驗問題。真正的行動優先設計必須從 DOM 結構重新規劃。

訊號四：業務模式已根本改變，現有 IA 無法支撐新需求

你從 B2C 轉型 B2B、從單一產品擴展到多品牌、或從純展示型要轉型成電商＋會員中心的複合平台。這類需求代表資訊架構（IA）需要從根本重新設計，舊的頁面結構無法容納新的使用者路徑，強行修補會製造更多技術債。

訊號五：SEO 月自然流量連續 12 個月下滑，修補後無起色

如果你已經做過技術 SEO 優化、重寫 meta、修正爬蟲錯誤，但自然流量仍然持續下滑，可能是整體網站的 E-E-A-T（經驗、專業、權威、可信度）訊號不足，或是網站結構讓 Google 爬蟲無法正確理解內容層級。這種情況，重構無法解決，需要重新設計整體內容架構和技術架構。

4 條合約紅線：簽約前一定要確認的保護條款

無論你最後決定重構還是重做，合約紅線是避免最終結局悲劇的最後一道關。這四條紅線是我們在協助客戶審合約時發現的最高頻踩雷點。

紅線一：原始碼所有權必須明確歸屬甲方（你）

合約裡要清楚寫明：「乙方開發之所有程式碼、設計稿、資料庫結構，完工付款後著作財產權及所有權全部移轉予甲方。」沒有這條，你在法律上只有「授權使用」，供應商可以合法拒絕交付原始碼。更多合約細節可以參考《中小企業軟體開發合約退場機制》這篇的 6 個退場機制說明。

紅線二：SEO 重定向計畫必須寫入合約，並設定驗收標準

網站重做最常見的隱形損失：上線後自然流量掉 40%，因為供應商沒有做 301 重定向，舊頁面的 SEO 權重全部歸零。合約必須明確要求：「乙方須提交完整 URL 重定向清單，上線後 90 天內月自然流量不得低於改版前 90%，否則視為未達驗收標準。」

紅線三：效能 KPI 必須量化寫入驗收條件

「網站速度快」是廢話，「首頁 LCP ≤ 2.5 秒、行動端 PageSpeed Insights 分數 ≥ 85」才是可驗收的條件。沒有量化 KPI 的合約，遇到效能問題時雙方各說各話，你永遠處於下風。

紅線四：資料遷移責任與還原保證

如果涉及資料庫遷移，合約必須寫明：「乙方負責將甲方既有資料完整遷移至新系統，遷移前須提交備份確認單，遷移後 30 天內發現資料遺失或錯誤，由乙方負責修復且不另行收費。」資料遷移踩雷的細節可以參考《中小企業客製系統資料遷移》這篇的 5 個階段說明。

成本試算：重構 vs 重做的真實數字差距有多大

很多老闆聽到「重構比較便宜」就點頭，但便宜是相對的。以下是一個典型中小企業官網的成本區間對照，供參考。

【重構方案】目標：LCP 從 5s 優化到 1.5s、行動端 RWD 修正、介面局部更新

技術 SEO 修復 + Core Web Vitals 優化：NT$30,000–80,000

前台介面更新（換設計系統，保留後台）：NT$50,000–150,000

行動端 RWD 結構調整：NT$20,000–60,000

合計：NT$100,000–290,000，工期 4-10 週

【重做方案】目標：新技術棧、新 CMS、新資訊架構、完整行動優先設計

需求分析 + IA 設計：NT$30,000–80,000

UI/UX 設計（線框稿到高保真稿）：NT$80,000–200,000

前後台開發 + CMS 建置：NT$200,000–600,000

資料遷移 + SEO 重定向：NT$30,000–80,000

測試 + 上線 + 教育訓練：NT$20,000–60,000

合計：NT$360,000–1,020,000，工期 12-24 週

重做方案的成本是重構的 3 到 5 倍，工期是 2 到 3 倍。這不代表重做「不值得」，而是你的決策需要清楚的業務 ROI 支撐：行動轉換率預估提升多少？SEO 月流量預估增加多少？客戶生命週期價值的變化是否足以覆蓋這筆投資？

如果你正在評估是否換到 SaaS 平台還是繼續做客製化，也可以參考《SaaS vs 客製化軟體比較》這篇更詳細的成本效益分析。

我們不認同的 3 個常見說法

在幫客戶做網站升級評估的過程中，我們聽過很多「行業共識」，但仔細一看都站不住腳。以下是我們最常反駁的三個說法。

迷思一：「重做才能拿回 SEO 排名」

這個說法本末倒置。SEO 排名的關鍵是頁面的 E-E-A-T 訊號、內容品質、以及技術健康狀態，這些全部都可以在現有網站上優化。網站搬家的過程反而是 SEO 最大的風險點——URL 結構改變、301 重定向沒做好、爬蟲重新索引的空窗期，每一個環節都可能讓你的流量在上線後 90 天內腰斬。我們的判斷是：除非現有技術架構讓 Googlebot 根本無法爬取內容（例如純 JavaScript 渲染的舊版 SPA），否則 SEO 問題的解方是技術修復，不是搬家。

迷思二：「重構比較便宜」

從報價單上看，重構起步價確實低很多。但如果你的技術債已經嚴重到一定程度，重構的工時可能超過重做。一個典型的「重構地獄」情境是：前人的程式碼沒有任何文件、全域變數滿天飛、CSS specificity 戰爭讓每次改一個按鈕就壞三個地方——這種情況下，每小時工時的重構成本比重做高出 50-200%。判斷標準應該是「技術債量化評估」，不是預感。我們在正式提案前，一定會先做程式碼健康度稽核。參考《中小企業軟體程式碼稽核》這篇的 6 項檢查清單可以幫你快速判斷技術債等級。

迷思三：「品牌升級就要重做」

品牌視覺升級（換 logo、換色系、換字型、換版型）和技術架構是兩件獨立的事。後台 CMS、資料庫、API 邏輯完全不需要跟著動。我們碰過不止一個案例，供應商說「品牌升級要連後台一起重做才能保持一致性」——這在技術上完全站不住腳，屬於銷售話術而非工程判斷。品牌升級的正確做法是：先做設計系統（Design Token），再把設計 Token 對應到現有前台元件，工期 4-8 週，成本是「全站重做」的 15-30%。

AI 時代的新考量：2026 年不能忽略的技術選型因素

2026 年的網站技術選型，有三個 AI 驅動的新因素值得你在決策時一起納入考量。

因素一：GEO（生成式引擎優化）對頁面結構的要求

ChatGPT、Perplexity、Google AI Overview 這類 AI 搜尋引擎，爬取和引用內容的方式和傳統 Googlebot 不同。它們更偏好有清晰語義結構的 HTML（適當的 heading 層級、FAQ schema、HowTo schema），以及可以被直接引用的短段落答案。如果你的舊網站是一大塊沒有語義結構的文字牆，這是值得在這次升級中順手修正的點——但不需要為此重做整個網站，語義結構優化可以在重構階段完成。

因素二：Edge Function + 靜態生成正在成為效能主流

Next.js 的 App Router、Nuxt 3 的 Nitro、Astro 的島嶼架構——這些 2024-2025 年成熟的框架，讓「靜態生成 + 動態功能按需載入」成為中小企業網站的最佳實踐。如果你的網站需要重做，這個方向值得認真評估，因為它同時解決效能（靜態頁面接近 0 TTFB）和維護成本（CDN 部署，不需要管伺服器）兩個問題。

因素三：CMS 的 AI 輔助內容工作流

現代 Headless CMS（Payload CMS、Sanity、Strapi）正在快速整合 AI 寫作輔助、自動 SEO 建議、圖片 alt 自動生成等功能。如果你預計未來兩年要大量產出內容，CMS 的 AI 工作流支援度值得列入評估標準。這個考量不會改變「重構 vs 重做」的判斷，但會影響「重做要選哪套 CMS」的決策。想了解更多 AI 輔助決策，可以參考《中小企業 AI 軟體供應商盡職調查》這篇的 12 項評核重點。

實戰決策流程：中小企業老闆 30 分鐘自我診斷步驟

以下是一個可以在 30 分鐘內完成的自我診斷流程。你不需要技術背景，只需要能找到幾個數字。

步驟 1：確認原始碼狀態

向現有供應商要求提供原始碼（即使只是確認它存在）。如果供應商拒絕、或無法在 48 小時內回應，這本身就是一個警訊。原始碼若無法取得 → 直接進入「重做評估」流程。

步驟 2：跑 Google PageSpeed Insights

進入 pagespeed.web.dev，輸入你的網站首頁和最重要的一個產品/服務頁，記下行動端的 LCP 數字和總分。LCP < 2.5s 且分數 ≥ 75 → 技術基礎還 OK，問題可能在內容或設計。LCP > 4s 或分數 < 50 → 需要進一步判斷是技術債還是架構問題。

步驟 3：查 Google Search Console 流量趨勢

進入 Search Console，看過去 12 個月的「網站點擊次數」趨勢。持續成長或持平 → SEO 基礎健康，不建議搬家。連續 12 個月下滑超過 20% 且已確認無演算法更新因素 → 需要更深度的 SEO 技術稽核。

步驟 4：問自己兩個業務問題

問題 A：「未來 3 年的業務模式，現有網站架構能支撐嗎？」如果你預計新增電商、多語言、會員中心等根本性的功能，答案大概率是否定的。

問題 B：「如果現有網站速度提升到業界標準、視覺更新，我的業務目標還有沒有缺口？」如果效能和視覺解決後業務目標就達到了，重構就夠了。如果你需要的是全新的使用者路徑和轉換漏斗設計，才需要考慮重做。

完成這四個步驟後，你應該能夠清楚分類：純重構（步驟 1-4 全部指向技術修補就夠）、局部重做（步驟 4A 需要新功能但現有架構可延伸）、全站重做（原始碼遺失、或步驟 4 顯示業務模式根本改變）。

如何評估供應商的提案是工程判斷還是銷售話術

當廠商說「你的網站需要全部重做」，你可以用以下問題測試他們的提案是否有工程依據。

問題一：「你有看過我們的原始碼嗎？」

沒有看過原始碼就建議重做的廠商，是在賣感覺，不是在賣工程判斷。一個負責任的技術評估，至少要包含：程式碼結構概覽、技術棧版本確認、第三方套件的維護狀態、已知安全漏洞掃描。可以要求廠商提交類似《程式碼稽核標準》的檢查清單作為評估依據。

問題二：「如果只做重構，你的最低可行方案是什麼，預期改善的 KPI 是什麼？」

願意提出重構替代方案並給出量化 KPI 的廠商，代表他們真的在解決你的問題，而不是在最大化合約金額。如果廠商只給重做報價、不提重構替代方案，這是一個值得警惕的訊號。

問題三：「如果我 2 年後想換廠商，交付物包含什麼？」

這個問題會立刻揭示廠商是否在設計「廠商鎖定」。負責任的廠商應該能夠清楚列出：原始碼 Git repository、設計檔（Figma 或 Sketch）、部署說明文件、資料庫備份流程、API 文件（如有串接第三方）。如果廠商說「這些要另外收費」或語焉不詳，請直接在合約裡寫清楚，或考慮換一家。退場機制的合約細節，可以參考《客製化軟體合約退場機制》這篇的完整說明。

IT 主管或行銷主管在這個決策中的正確角色

很多中小企業的 IT 主管或行銷主管在網站升級決策中處於一個尷尬位置：老闆要他們「評估」，但他們自己也不確定標準在哪裡。以下是一個務實的建議。

行銷主管的核心評估指標：SEO 自然流量趨勢、行動端 vs 桌機端轉換率差距、Google Analytics 的使用者行為路徑（哪個頁面跳出率最高、轉換漏斗在哪裡斷掉）。這些數字應該是向老闆提出建議的核心依據，而不是「感覺網站很舊」。

IT 主管的核心評估指標：框架版本和 EOL 時間表（End-of-Life，即停止安全更新的日期）、SSL 和套件更新的維護難度、現有後台的 API 可延伸性。如果 IT 主管無法在 2 小時內回答「我們網站用的框架版本是什麼、它的 EOL 是何時」，那就是技術文件嚴重缺失，應該先要求供應商補足文件，再談升級方向。

採購評估者的核心任務：確認合約四條紅線都在，並要求廠商提供過去 3 個同類型案例的交付物清單，具體問「交付了哪些文件和程式碼」，作品集截圖只是最低門檻。如果想深化採購評估能力，《外包採購決策指南》這篇提供了更系統化的框架。

四種常見情境的建議方向

以下四種情境是我們評估過最常見的中小企業網站升級案型，提供方向性建議供參考。

情境 A：5 年舊網站、WordPress 最新版、原始碼完整、LCP 3.8s、SEO 流量持平

建議方向：重構。做效能優化（圖片 WebP、快取、CDN）+ 視覺更新（換佈景主題或升級設計系統），不需要動後台。預算範圍 NT$80,000–200,000，工期 4-8 週。

情境 B：7 年舊網站、供應商失聯、原始碼遺失、PHP 5.6、SEO 流量下滑 30%

建議方向：重做。技術棧已無法安全維護，原始碼取不到，繼續修補的成本已超過重做成本。在重做合約中必須加入原始碼託管條款和 SEO 重定向計畫。

情境 C：4 年舊網站、原始碼完整、行動端轉換率比桌機低 65%、預計未來加入電商功能

建議方向：局部重做。前台行動優先架構需要重建，但後台業務邏輯可以保留並延伸電商模組。預算中間段，工期 12-16 週。

情境 D：6 年舊網站、原始碼完整、SEO 流量穩健、但品牌視覺大幅更新需求

建議方向：重構 + 設計系統更新。後台完全不動，前台換設計 Token，這是成本效益最好的選擇。不要讓「品牌升級」被廠商包裝成「需要重做整個後台」。

延伸閱讀：相關決策框架

如果你正在評估更廣泛的系統升級決策，以下幾篇文章可以幫助你建立更完整的框架：

SaaS vs 客製化軟體：2026 年比較指南 — 從成本結構和彈性角度評估系統選型

客製化軟體原始碼託管完整指南 — 保護你的程式碼資產

中小企業系統資料遷移 5 個階段 — 平台切換不遺失資料的完整 SOP

AI 軟體供應商盡職調查 SOP — 12 個評核重點幫你選對廠商