舊官網該局部改版還是整站重做？先分清是內容、版面還是系統問題

文章導讀

業務說客戶在官網找不到服務，行銷要辦活動卻沒有頁面可放，老闆用手機打開首頁，字擠成一團。會議開到最後，常有人說：「乾脆整個重做吧。」這些症狀聽起來都叫「網站舊了」，原因卻可能在完全不同的地方。有的只要重整內容，有的卡在後台資料；只換首頁照片和配色，兩種都解決不了。這篇把網站拆成五層，先找出卡住的是哪一層。

先別問要不要重做，先找出哪一層在卡

聽到「網站舊了」這句話，參考的做法是先問兩件事：是誰覺得舊？在哪一頁、做什麼事的時候覺得卡？

如果只是服務內容變了，資訊架構和技術都還撐得住，先重整內容比較合適。導覽、頁型、後台和程式如果互相牽制，只改文字，改沒幾頁就會撞到原本的邊界。局部改版和整站重做的差別，在於這次的修改範圍能不能切得乾淨。

用五個層次盤點舊官網

層次	主要觀察	常見影響
內容	服務說法、案例、文章與行動指引是否符合現在的業務	客戶看完仍無法理解差異或下一步
視覺與體驗	品牌一致性、閱讀層級、手機版與互動狀態	資訊難讀、重要按鈕不明顯、品牌感受落差
資訊架構	分類、導覽、網址、內部連結與轉換路徑	內容愈加愈亂，搜尋與使用者都難以找到
後台與營運	資料欄位、表單、會員、訂單與內容更新流程	同一筆資料重複輸入，例外靠人工補
技術基礎	版本相容、速度、資安、備份、主機與可維護性	改一處牽動多處，更新與擴充風險提高

這五層不必拆成五個專案。盤點是為了看問題集中在哪裡，彼此有沒有互相依賴。

盤點不需要你們進 WordPress 查外掛或程式。你們提供營運現況、客戶常反應的問題，以及內容和資料平常怎麼用。技術面的判讀，由維護團隊從頁面架構、功能版本、效能和資料逐層完成。

內容問題：資訊還準確，但說法已經過時

有些網站的技術和版型都還穩定，過時的是內容。公司多了新服務、客群變了、優勢也更清楚，首頁卻還把所有項目平均排開。案例不少，但沒有依產業或需求分類。文章一直在寫，卻沒有連回服務頁和詢問表單。這類問題從內容策略和頁面關係下手，通常不必拆掉底層。

內容重整要先回答幾個問題：主要寫給誰看？每一頁負責什麼任務？服務之間怎麼分層？案例要證明什麼能力？讀完之後，希望訪客做什麼？這些由你們決定。維護團隊再依這些決定，調整頁面模組、欄位、內部連結和搜尋結構，新內容才有合適的位置可以放。

網站經營多年，常會累積好幾篇主題相近的文章。直接刪掉，會失去原本的搜尋入口；全部留著，搜尋引擎和訪客又分不出哪篇才是重點。所以哪些合併、哪些保留、舊網址導去哪裡，要和內容盤點一起規劃。

視覺問題：品牌與手機體驗沒有跟上

視覺過時，問題常常不在顏色。標題層級不清、段落太寬、圖片比例混亂、按鈕樣式各自不同，都會讓內容變難讀。手機版如果只是把桌機版縮小，問題會更明顯。內容和導覽還合理的話，可以從視覺系統、頁型和不同螢幕尺寸的排版規則重整，既有資料和功能都留著。

我們檢查舊網站時很常看到，同樣是「聯絡我們」按鈕，不同頁面有三四種樣式。這類局部改版，關鍵在先定出共用規則，再套到各頁。規則分兩類：字級、留白、色彩和圖片比例這些基本設定，以及卡片、按鈕、表單這些元件在手機上怎麼排。規則定好，既有頁面能一起更新，之後新增的內容也不會又走樣。

頁面實作和版型調整，由維護團隊統一處理；你們提供品牌素材、內容的優先順序和審閱意見。這樣桌機、手機、速度和搜尋結構，都在同一套規則下驗證。

資訊架構問題：內容有了，使用者卻找不到

營運幾年下來，網站的內容通常不少，只是每次新增，都在選單上再多一個入口。服務和解決方案重疊，產業、產品與案例又各分一套，使用者不知道該從哪裡開始。搜尋引擎也看不出，哪幾頁才是主題的核心。

資訊架構重整，要處理三件事：

• 分類原則：用客戶問題、服務類型或產業當主軸都可以，但同一層選單只能有一套邏輯。
• 頁面關係：總覽頁、細節頁、案例和文章之間，要有上下游的連結。
• 網址與導覽：新架構上線後，每個舊入口都要有明確的去向。

後台與技術問題：營運開始被系統限制

限制一旦進到後台和技術基礎，換畫面只能暫時遮住問題。例如表單資料散在各人的信箱，會員身分和訂單狀態對不起來。同一段內容要在好幾個地方重複輸入，功能彼此打架，每次更新都擔心影響關鍵流程。這些要從資料、功能和相容性重新檢視。

技術盤點會看這幾件事：

• WordPress 核心、主題、功能模組和客製程式之間，怎麼互相依賴
• 資料表和欄位，還符不符合現在的流程
• 主機、快取和圖片，怎麼影響速度
• 備份能不能支援需要的還原情境

元件版本和特別處理，是維護團隊持續保管與更新的內部維運紀錄，你們不需要自己掌握這些技術細節。

底層還能維護的話，可以只重構表單、會員、購物車或資料交換這類局部功能。如果好幾個舊元件綁在一起，資料結構也不再適用，繼續往上疊，每次修改的影響範圍只會愈來愈大。到這一步，才需要考慮整站重整。

什麼情況適合局部改版

問題集中、能和其他層清楚分開，就適合局部改版。像是更新服務內容、調整品牌視覺、重排首頁的轉換路徑。新增一種共用頁型，或擴充某個表單流程，也屬於這一類。網址、內容資料和技術基礎都還健康時，留下能用的部分，要搬移的東西變少，這一期的預算也能集中。

• 內容已變，架構仍可承接

  服務名稱與說法需要更新，但主要分類、網址與頁型仍然合理。

• 視覺不一致，資料功能穩定

  需要建立新的設計系統與手機版規則，表單、會員或商品資料不必重建。

• 單一流程需要擴充

  例如新增資格審核、報名條件或購物車規則，而其他功能仍有清楚邊界。

局部改版，工序一樣要做足。動手前，維護團隊會先評估這次修改會碰到哪些樣板、欄位和程式，快取與追蹤事件會不會受影響。接著建立退回點，完成實作，再做回歸確認。範圍能切得精準，靠的是前置判斷做得清楚。

什麼訊號代表要整站重整

需要整站重整，通常是因為當初的設計前提已經不成立，和網站用了幾年沒有必然關係。例如公司從單一服務變成多品牌、多客群，原本的分類和網址接不住。或是手機流量變成主體，舊版型做不出一致的體驗。又或者網站從展示用途，走進會員、交易或系統整合，原本的資料模型開始限制營運。

另一個明顯的訊號，是改一層就會弄壞另一層。想調整導覽，得重做好幾個樣板。想保留文章，欄位卻各不相同。想更新功能，又被舊主題或客製程式綁住。表單和追蹤，也沒辦法完整驗證。這時候一處一處補，結構只會更難理解。整站重整可以先把新規則定好，再依序搬移。

整站重做，也用不著每件事都從零開發。標準的內容，繼續交給 WordPress 核心和成熟模組；客製設計用在品牌與資訊體驗，客製外掛留給真正不同的營運規則。這次要重整的，是架構和責任邊界。

重做不是歸零：哪些資產要延續

改版時最該保護的，是那些已經在運作的關係。網址連著搜尋結果、外部連結和使用者的書籤。文章、案例和圖片，承載著品牌內容。表單、商品、會員與訂單，連著日常營運。分析與轉換事件，則讓改版前後還有資料可以比較。

盤點舊站時，我們很常看到追蹤碼寫在舊版型裡。版型一換，轉換事件跟著消失，改版前後的數字就沒辦法比較。下面幾件事，是你們內部可以先準備的：

• 哪些網址印在名片、型錄或廣告上，你們內部有一份清單。
• 哪些文章、案例和商品資料要留下、哪些可以整併，內部已經有共識。
• 表單、會員和訂單遇到例外時，平常怎麼處理，負責的同事說得出來。
• 改版前後要比較哪些數字，例如詢問數或訂單數，內部已經選好。
• 切換前後有沒有活動、檔期或收件窗口異動，內部已經排進時程。

網址的轉向對應、資料欄位的盤點，以及新舊欄位怎麼對應，由維護團隊在改版規劃時先界定清楚，免得上線才發現少了必要的資料。營運資料需要時，可依專案範圍以通用格式匯出提供；頁面樣板、功能模組和客製前端這些開發成果，則依約定授權網站使用。

把改版做成可控制的轉換過程

不論局部還是整站，改版都要有一段製作與驗證的時間，而且不影響正式站運作。維護團隊先建立一個可控的環境，整理內容與資料，完成頁型和功能，再照關鍵情境測試。確認沒問題，才安排切換，並處理快取與搜尋設定。上線後，維護團隊會持續觀察表單、錯誤網址、流量和轉換事件。

• 界定問題層與成功條件

  你們說明這次要改善的營運問題，維護團隊把它轉成內容、體驗、資料和技術的範圍。

• 決定保留、調整與重建

  一層一層判斷哪些資產可以沿用、哪些要建立新規則，免得把舊問題一起搬過去。

• 先完成架構與樣板

  先用共用頁型、欄位和元件打好一致的基礎，再實作各頁、搬移資料。

• 用真實情境驗證

  拿你們實際的詢問、會員、訂單和內容流程來測，靜態畫面只是其中一部分。

• 切換後持續維護

  上線後，版本更新、備份與資安、速度與 SEO，還有異常處理，都持續跟著新架構走。

整個過程裡，你們負責提供正確的內容、商業規則和審閱決定。技術這一段，由維護團隊執行：

• 頁面編排、外掛與程式設定
• 資料處理與測試
• 上線切換和後續的版本管理

分工清楚，改版的討論就能專心在成果上，你們也不必承擔技術操作。

我們怎麼判斷改版範圍

評估一個舊網站，可以先看三樣東西。第一是搜尋資料裡，還在帶來流量和詢問的網址，這份清單決定了哪些入口不能斷。第二是頁面怎麼組成：用共用樣板組起來的網站，換視覺可以從樣板改起；每一頁各自手工排版的網站，改一個按鈕樣式，常常得一頁一頁改遍全站。第三是請負責上稿的同事，實際更新一次文章或商品，看流程卡在哪一步。

三樣看完，再來談要局部優化、分階段重整，還是整站改版。舊站底層還健康，我們不會為了換外觀擴大工程；好幾層已經卡住營運，也不會只用一張新首頁蓋過去。

改版是你們依業務檔期發起的專案。版本更新、備份、速度與 SEO、異常處理，則是另一條線。新網站上線後，這條線由年度維護代管接著跑，不論這個月有沒有要改東西，都持續在做。

常見問題