網站改版怎麼進行：改版訊號、範圍界定與上線切換計畫
「官網看起來有點舊了，是不是該改版？」這個念頭多半來自直覺，但改版是一個會牽動搜尋排名、業務流程與內部作業的專案。
失敗的改版通常不是設計不好看，而是範圍沒界定清楚：做到一半才發現要搬幾百篇文章、表單通知要重接、金流要重新申請、還有一堆沒人記得存在的舊頁面。這篇把改版拆成可以照著走的階段，讓你在動工前就知道自己簽下的是多大的一件事。
什麼時候真的該改版
改版的理由要能說出具體損失，而不是「看膩了」。常見的真實訊號有這幾種：
- 內容已經對不上業務：網站上還掛著兩年前的服務項目，主力業務反而找不到頁面。
- 行動裝置體驗明顯落後：手機上要放大才看得清楚、表單填到一半跳掉、載入等太久。
- 內容更新要靠廠商：改一行字都得發信請人處理，內部完全沒有自主權。
- 架構擋住了新需求：想加會員、想串接內部系統、想做多語系，現有平台做不到。
- 安全性跟不上：使用的系統或套件已停止維護，無法再取得安全更新，這屬於必須處理的類型，判斷方式可以參考企業網站資安基本功。
反過來說，如果問題只是視覺風格陳舊、或某幾頁排版不理想，那是局部優化，不需要整站重做。把小問題升級成大專案，是預算被吃掉的常見原因。
先界定目標與範圍，再談設計
改版最該先回答的不是「要長什麼樣」，而是「改完之後，哪一件事會變好」。
建議把目標寫成可以驗證的句子，例如：讓潛在客戶在三次點擊內找到服務說明並送出詢問、讓行銷同仁可以自行發佈文章不必找廠商、讓現有的報價流程從電話改成線上表單。目標寫得越具體，後面爭論版面時就越有依據。
接著界定範圍。實務上建議明確寫出三個清單：
| 清單 | 內容 | 為什麼重要 |
|---|---|---|
| 這次要做 | 頁面、功能、要搬的內容、要串的系統 | 報價與時程的基礎 |
| 這次不做 | 明確排除的項目 | 避免後期無止境追加 |
| 下一階段再做 | 有價值但不影響上線的項目 | 讓想法有地方放，不擠進當期 |
第三個清單常被忽略，但它非常有用——當有人提出新點子時，你不必否決，只要放進「下一階段」，專案就不會被逐步撐大。
把這三份清單寫清楚，其實就完成了需求文件的骨架。完整的寫法可以看軟體需求怎麼寫，那篇提供非工程師也能照著填的結構。
盤點現有內容與功能
這是最無聊、也最容易被跳過的一步，而跳過的代價通常在上線前一週才浮現。
內容盤點要做的是把現有網站的每一個網址列出來，逐筆標註：保留、改寫、合併、或刪除。同時記下每個頁面的實際價值——有沒有人在看、有沒有帶來詢問、是不是法規要求必須存在（例如隱私權政策）。
功能盤點要列出網站目前實際在做的事，包括那些看不見的：表單送出後寄給誰、有沒有串接分析工具、有沒有排程寄送的通知、有沒有其他系統會打進來取資料。這類「隱形功能」最常在改版後失蹤，而且通常是業務端先發現。
素材盤點則是圖片、影片、字體、圖庫的授權狀態。舊站用的素材未必能沿用到新站，字體與圖庫的授權範圍尤其要確認。
盤點的產出是一份試算表，它同時也是內容遷移與後續驗收的依據。
設計與開發的階段怎麼走
改版專案的健康作法，是讓每個階段都有可以確認的產出，而不是等到最後才看到成品。
資訊架構先做：決定選單怎麼分、哪些內容歸在一起、網址怎麼長。這一步決定使用者找不找得到東西，也決定後面的搜尋表現。
線框與視覺設計接著做，先確認版面結構與操作流程，再處理視覺風格。設計稿確認後才進開發，能避免大量返工。
開發與迭代階段，建議用固定節奏產出可操作的版本。NETVANA 的作法是以兩週為一個 Sprint，每個週期結束提供可操作的 Demo，讓你在真實環境裡提前體驗，而不是靠看圖想像；完整的階段劃分可以看軟體開發流程。
測試與驗收不只看畫面，還要包含跨裝置相容性、表單流程、後台操作、以及效能。效能的驗收指標怎麼訂，可以看網站速度優化指南。
如果這次改版也要換後台系統，選型是另一個獨立題目，四條路的取捨整理在CMS 內容管理系統怎麼選。
內容遷移：最容易被低估的一段
內容遷移常被當成「複製貼上」，實際上它包含四件事：
- 搬移：把保留的內容移到新結構，並確認格式、圖片、附件都正常。
- 改寫：趁改版把過時、重複、語氣不一致的內容整理掉。
- 重新對應：舊網址與新網址的對照關係要逐筆建立。
- 檢查連結：站內互相引用的連結、外部合作夥伴連過來的連結，都要確認不會斷掉。
第三與第四項直接關係到改版後的搜尋表現。這部分的細節不在本篇重複——網址對照表怎麼做、轉址怎麼設定、上線後要監測什麼，完整清單請看網站改版 SEO 檢查清單。至於新站在開發階段就該做對的技術基礎，則整理在技術 SEO 檢查清單。
遷移的排程建議：先搬結構與重要頁面，再搬長尾內容。如果內容量大，讓內容遷移與開發平行進行，而不是等網站做完才開始搬。
上線切換與回退計畫
切換那一刻，是整個專案風險最集中的地方。可以照這個順序準備：
切換前
- 舊站完整備份（程式、資料庫、上傳檔案），並確認備份真的可以還原
- 記錄網域與主機設定的原始值，包含郵件相關設定
- 新站在正式環境做最後檢查，並確認測試環境不會被搜尋引擎收錄
- 選在流量低的時段，避開檔期與活動
切換當下
- 逐項確認：首頁、主要服務頁、表單送出、後台登入、金流（若有）、分析工具是否回報資料
切換後
- 頭幾天每天檢查錯誤紀錄與表單是否正常
- 確認搜尋引擎開始抓取新網址
- 收集內部同仁的實際使用回饋
回退計畫要在切換前就寫好，而不是出事才想。內容包括：由誰決定回退、依據什麼條件、回退的具體步驟、以及回退後已經產生的新資料怎麼處理。上線前的完整逐項檢查，可以搭配網站上線前檢查清單一起使用。
改版最常見的四個錯誤
一、把改版當成純設計案。只找設計，沒人負責內容遷移與系統銜接，結果上線後一堆斷頭。
二、沒有指定決策者。每次審稿都有新意見進來，設計永遠定不下來，時程被一輪輪的修改吃掉。
三、內容拖到最後才準備。開發完成了，卻因為文案與產品照沒到位而無法上線。
四、上線就結案。改版後的頭一段時間是觀察期，需要有人持續看數據、修問題。報價與合約談的時候就該把這段講清楚，相關的成本結構可以參考網站製作費用怎麼算。
改版能不能順利，多半在動工前就決定了：目標寫得夠不夠具體、範圍有沒有界定、盤點做得夠不夠細。這些事做足了，設計與開發反而是相對單純的部分。
如果你手上有一個準備改版的網站，還在判斷該局部優化還是整站重做，與 NETVANA 討論你的改版規劃。我們會先釐清現況與範圍再談作法；軟體服務採詢問報價制，沒有固定套餐，各服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：改版後最怕流量掉光，完整搬遷步驟看網站改版 SEO 檢查清單；需求要自己寫得出來，可以看軟體需求怎麼寫；後台要換哪一種，看CMS 內容管理系統怎麼選；如果改版同時要做英文版，先看多語系網站開發指南；想知道專案為什麼容易拖，可以看軟體專案為什麼總是延誤；改版切換計畫學起來，換系統一樣要這樣排，可以看換系統時的資料轉移。
