先分清：維護、局部改善，定整體改版？
維護處理更新、備份及已知故障；局部改善針對一條已確認嘅閱讀或查詢路徑；整體改版則可能涉及資訊架構、版型、系統或資料整合。三者可以分階段做。換配色唔會自動解決收唔到表單，而轉用新 CMS 亦唔會自動令服務說明更清楚。
| 觀察到甚麼 | 先取得嘅證據 | 優先做法 |
|---|---|---|
| 客戶問緊已停止嘅服務 | 逐頁核對服務、地區、條件及聯絡資料。 | 先修正內容與相關連結，唔一定需要換系統。 |
| 手機查詢步驟有阻礙 | 實際完成一次正常、漏填及失敗重試路徑。 | 修正表單、標籤、回饋及遮擋問題。 |
| 只有部分頁面載入慢 | 分頁面類型及真實使用情境量度，找出慢嘅資源或流程。 | 先處理已確認瓶頸，再判斷是否涉及共用架構。 |
| 團隊無法更新核心資訊 | 讓實際編輯者試做一次更新，記錄卡住嘅權限、步驟或限制。 | 評估編輯流程、版型或 CMS；比較改善同搬遷成本。 |
| 新服務需要現有架構支援唔到嘅流程 | 列明資料、權限、分派、整合及驗收條件。 | 先做需求與技術評估，先決定局部擴充定重新製作。 |
一個可以喺內部會議使用嘅判斷方法
- 揀一條重要客戶路徑：例如「搜尋服務 → 閱讀範圍 → 提交需求 → 團隊收到」，唔以個人對首頁嘅喜好代替問題。
- 寫下可重現阻礙：用網址、裝置、步驟及截圖記錄；分清內容唔清楚、功能失效同跟進流程問題。
- 列出兩個可行方案：最小修正同較大改版，各自列交付物、依賴、維護、遷移及回退安排。
- 先處理急切故障：查詢收唔到或核心資料錯誤，唔應等整個設計項目完成先修。
- 約定驗收同觀測：先確認路徑能完成，再喺相近渠道、期間及指標定義下比較有效查詢，唔以新畫面上線當作成效提升。
呢個係決策工作方法，並非有研究驗證嘅評分模型。唔需要為每項問題打分，再用一個總分自動判定要花幾多預算。
示例：網站已用咗五年，是否一定要重做？
以下係示範情境，唔係客戶案例。一間服務公司嘅五年舊站仍可更新內容，手機查詢亦正常，但客戶經常誤解兩項服務嘅分別。第一個測試可以係重寫兩頁服務範圍、比較條件及下一步，再檢查查詢內容。若資料同流程問題已解決，網站年齡本身唔足以支持全站重建。
另一個同樣年齡嘅網站，如果無法支援新服務嘅分派流程，編輯亦長期無法維護內容，就需要比較擴充、替換部分系統與重新製作。判斷依據係受限嘅需求與持續成本，唔係年份相同就採用同一答案。
改版前應保留邊啲已經有效嘅資產？
先盤點現有網址、有用內容、主要流量入口、查詢路徑及可維護嘅元件。冇必要更改嘅有效網址可以保留；需要換網址時，另做對照與遷移計劃。若同時改網域、內容、網址及系統，之後會較難判斷變化來源。
每次檢視應帶甚麼資料？
- 目前服務及目標客群，連同已改變嘅合作條件。
- 主要頁面與查詢路徑嘅實測記錄，而唔只係全站平均數。
- 可取得時，帶同 Search Console 嘅頁面／查詢資料，以及後端成功收到、合資格查詢與成交定義。
- 編輯者完成更新所需步驟、維護限制與持續成本。
- 每項方案嘅負責人、交付物、依賴、回退方法與下次檢查觸發條件。
檢視頻率應配合服務變動及網站使用量。可在重要服務、品牌或系統需求改變時重做上述檢查；唔需要只為達到固定年期而全面更換網站。
常見問題
轉換率下跌就代表要改版？
先核對追蹤、渠道組合、流量意圖、查詢接收及銷售跟進。若分母或事件定義已改，兩個轉換率可能無法直接比較。找出可重現問題後，再選相應修改。
新網站會保證排名或 AI 引用增加嗎？
唔會。改版應有清楚功能及內容驗收；搜尋展示與引用仍取決於平台及其他因素。把可即時核對嘅可讀、可爬及可用，跟之後嘅曝光、點擊及詢盤分開量度。
決定要改版後，再準備交付資料
官方參考與更新說明
本文嘅決策表及示範情境為 ITOB Group 編輯整理，唔係客戶成果或固定改版週期標準。最後實質更新：2026 年 10 月 25 日。
