網站應該局部修復，還是重新製作？

用可觀察的行為定義成功

把「做得現代一點」改成訪客能完成的任務。例如：訪客找到適合的服務、理解包含的範圍，再提交一份會送達正確收件箱的查詢。提交後的處理也要一起定義。畫面顯示「提交成功」，並不能證明公司已收到訊息。

• 寫下目標客戶及他最需要解答的問題。
• 確定這個頁面要讓訪客完成甚麼行動。
• 定義如何從開始到結果驗證整個行動。

分清頁面問題與平台限制

用手機和電腦各走一次重要流程，記錄出問題的頁面、具體情況，以及能否重現。也要查看團隊在頁面背後的工作；網站外觀可以沒有明顯問題，但日常更新仍然很困難。

• 訪客能否自行理解服務，而不用等你解釋？
• 導覽、表單及確認訊息是否正常？
• 團隊能否可靠地更新重要內容？
• 現有平台能否支援實際需要的語言及系統連接？

以範圍明確的修復驗證判斷

假設例子，並非客戶項目：一家公司收到的查詢很含糊，因為服務頁沒有說明範圍，表單亦只詢問姓名。可以先改寫該頁並加入一個相關問題，再決定是否需要新平台。測試訊息是否送達，再檢視查詢是否包含回覆所需的資料。預先訂好檢討日期；流量少時，可能仍未有足夠依據作結論。

證明根本限制後，再考慮重做

如果所需改動依賴已失去支援的軟件、容易失效的補救方法，或現有架構無法容納已確認的使用流程，重做會更合理。要求提案比較修復與重做的範圍，包括內容搬遷、系統連接、日後編輯及維護。換一個新設計，並不能自行解決服務定位不清楚或查詢沒有人回覆的問題。

把現有網址納入項目範圍

若網址會改變，應建立舊頁面與相關新頁面的對應清單，並測試重新導向。Google 的網站遷移指南建議盡可能使用伺服器端永久重新導向，並在遷移後持續監察。遷移期間，搜尋曝光可能波動。沒有業務理由時保留可用的網址，亦應準備上線出問題時的復原方案。

先整理需求，再索取報價

準備現有網址、優先流程、觀察到的錯誤、內容負責人及需要連接的系統。要求提案列出明確的驗收方法，並獨立說明持續費用。Chronicle 在確認範圍後以美元（USD）報價。如果更新內容或修復表單已足夠，可以保留現有網站，待檢討結果後再決定是否重做。