多數人以為，判斷一個網站該修還是該重做，看的是它幾歲、長得順不順眼、手機打開卡不卡。真正決定這條分界線的，是使用者完全看不到的另一層，也就是這個網站的地基撐不撐得住。
地基是指資料結構怎麼存資料、寫這個網站的程式語言與框架還在不在官方的支援期內、原始碼與主機的完整控制權在不在自己手上。這幾樣讀者從畫面上一件都看不到，卻決定了接下來每一次修改要花多少力氣、冒多大風險。外觀看起來舊，不代表地基有問題；反過來，一個介面做得漂漂亮亮的網站，地基照樣可能已經撐不住下一次的資安更新或流量成長。
地基撐不撐得住，要靠三個自己就能動手檢查的地方見真章：程式語言與框架還在不在支援期內、原始碼與主機的控制權在誰手上、還有這次的需求會不會動到資料結構本身。
症狀清單測不出網站該修還是該重做
網路上流通最多的判斷法，是一張症狀清單：介面設計看起來過時、手機版排版跑掉、載入速度慢、轉換率一路下滑，數到第三項、第四項，就有人建議該改版或乾脆重做。這種清單最大的問題不是列錯項目，而是每一項症狀本身都可以被局部修補暫時壓下去，換一套版面樣板、把圖片壓縮到位、把按鈕挪到使用者比較容易點到的地方，症狀分數立刻就會降下來。
問題是，症狀會消，病灶不一定跟著消。壓縮圖片能讓載入速度變快，但如果拖慢速度的真正原因是資料庫查詢邏輯設計得不好，每次讀取都要跑好幾層迴圈，壓縮圖片只是把體感速度撐過這一次，下次流量一多，一樣的問題還是會冒出來。症狀清單量到的是使用者現在有沒有感覺到不舒服，量不到這個不舒服究竟出在哪一層。
真正該問的問題，從來不是這個網站符合幾項該改版的訊號，而是這個問題出在使用者看得到的表面，還是藏在看不到的地基。同一個症狀，例如轉換率下滑，背後可能是版面配置沒抓住重點，這是表面問題，修版面就能改善；也可能是網站當機的次數變多，資料庫回應時間拖到讓使用者等到不耐煩才放棄，這是地基問題，換版面完全救不了。分界線要往下再挖一層才看得到。
分界線在地基撐不撐得住，不在網站的年紀或外觀
判斷一個網站該修補還是該重做，關鍵不是它幾歲、好不好看，而是地基撐不撐得住。地基包含三件事，資料怎麼存、寫這個網站的程式語言與框架是不是還在官方支援期內、原始碼與主機的完整控制權在不在自己手上。地基之上才是使用者實際會摸到的那一層，視覺呈現、文案內容、版面配置、局部的功能操作。
地基撐得住，就算外觀看起來已經是十年前的樣子，修補永遠是划算的選擇，換版面、改文案、調整功能都可以疊加在原本的地基上，一次一小步，不用整套推翻重來。地基撐不住，情況就反過來，就算外觀還過得去，看起來沒有明顯的問題，修補也只是把面對地基問題的時間往後延，而不是真的解決了什麼。
看起來舊跟地基有問題，是兩件可以完全脫鉤的事。一個網站可以用著十年前的版型、配色偏過時，但只要背後的程式語言持續更新，資料結構設計得夠彈性，這個網站照樣能穩穩撐住流量與功能擴充。反過來，一個介面設計得很新、動畫效果做得很漂亮的網站，如果底層用的框架版本已經停止更新，資料庫設計從一開始就沒有考慮到未來要擴充，這個地基一樣是撐不住的地基，只是暫時被漂亮的外觀蓋住而已。而且地基一旦撐不住，修補的效益會隨時間遞減，同一個地基問題會不斷從不同的地方冒出來，每修一次都只是把症狀壓下去，下一次同樣的問題還是會用不同的樣貌再出現一次，投入的修補成本卻沒有減少。
程式語言和框架有沒有跟上官方支援期
第一個可以自己動手檢查的地基測試，是網站使用的程式語言與框架版本，還在不在官方公告的支援期內。以最多網站在用的 PHP 為例，官方把整個版本的生命週期切成三個階段：主動支援期（Active Support），這個階段除了修 bug，還會持續加入新功能；接著是安全支援期（Security Support），只修復被判定為重大的安全性問題，不再加新功能；最後是生命週期終止（End of Life），完全停止維護，不管之後被發現多嚴重的漏洞，官方都不會再釋出任何修補。
以查證當下的狀態來看，PHP 8.2 已經走到安全支援階段，將在 2026 年 12 月 31 日進入生命週期終止；8.3、8.4、8.5 都還在主動或安全支援期內；8.1 以前的版本，包括 8.0、7.4，已經全數停止支援，不會再收到任何安全性更新。這代表一件很具體的事，如果一個網站現在還跑在 8.1 以前的版本上，往後任何新出現的資安漏洞都不會有官方修補，這不是找人修一個洞就能解決的單點問題，而是整個地基層持續暴露在外的結構性風險。
這種依版本切分支援期的制度不是 PHP 獨有，多數主流程式語言與 CMS 系統都有類似的生命週期規劃。查自己網站實際用的是哪一種語言、哪一個版本，對照官方公告的支援期表，是最直接、也最不需要專業背景就能自己完成的地基健檢，不需要懂程式，只要查得到版本號、看得懂官方公告上支援到哪一天，就能判斷這一層地基還撐不撐得住。
原始碼、主機控制權決定修補選項存不存在
第二個地基測試，問的是另一個問題，手上有沒有這個網站的原始碼，有沒有主機與後台的完整控制權。這不是修補起來麻不麻煩的程度問題，而是修補這個選項存不存在的門檻問題。
如果網站的原始碼被鎖在原本開發的那一方手裡，連自己的主機都沒有完整的存取權限，連請人來評估這次該修哪裡都無從評估起。不是修補的成本比較高，是連評估的入口都沒有。這種情況下，就算地基其實只有一小處出問題，實際能選的路只剩下重做這一條，因為修補的選項在起點就已經被排除了。
反過來，原始碼與主機都完整掌握在自己手上，才有本錢在修補與重做之間做真正的比較，可以請不同的人來看、可以拆解哪一部分真的要動、哪一部分還能沿用，而不是被單一供應商牽著走，只能接受對方報出來的那一個方案。掌握原始碼與主機控制權，本身就是讓地基測試其他兩項有意義的前提，沒有這個前提，前面查到支援期已經過了，也只能被動等對方處理，沒有自己安排修補時程的餘地。
資料結構動不動得了，是改版與局部重做的分水嶺
第三個地基測試，也是最常被忽略的一個，問的是這次要解決的問題，能不能在完全不改動底層資料結構的前提下做到。如果只是換版面、改文案、調色系、把圖片壓縮到位，資料結構完全不需要動，這是純粹的表面修補，怎麼改都不會牽動地基。
但如果需求變成原本只有靜態的形象展示頁、現在要加會員系統，原本只做單一語言、現在要做多語系，原本沒有訂單流程、現在要串金流，這幾類需求都必然要求重新設計資料結構。會員需要儲存帳號、密碼、權限層級；多語系需要每一筆內容都對應多份翻譯版本；金流需要記錄訂單狀態、付款紀錄、退款流程。這時候即使掛著改版的名字，實際在做的事已經是局部重做，如果還是用修補的預算和心態去面對，注定做不完整。
分辨的方法不難，先問這次的需求是同一批資料換個樣子呈現，還是要儲存以前沒有存過的一種新資料。前者是表面工程，後者是地基工程。用一個去識別化的通則情境來看，一個原本只有形象展示頁的中小企業，如果決定要新增會員系統，這已經不是順便改一下版面的範圍，而是要從頭設計會員資料表、權限邏輯、跟原有內容的關聯，這件事本身就是局部重做，只是很多人會用改版這個比較輕鬆的說法去稱呼它，低估了實際要投入的工作量。
維護頻率與成本的曲線，是地基還撐不撐得住的體溫計
前面三個地基測試都是單次檢查，查一次版本、查一次控制權、查一次資料結構就有答案。但地基撐不撐得住，其實更適合用趨勢去觀察，而不是只看一次的結果。如果過去一年，修補這個網站的頻率跟每次的成本是一路墊高的，這次修完，半年後又冒出下一個問題，而且修得比上次更麻煩、花的時間更久，這代表地基層的技術債正在持續計息，繼續修補只是延後付款的時間點，不是真的省下了什麼。
技術債不處理不會自己消失，只會隨著時間持續累積，越晚處理，修復的成本越高。CISQ（Consortium for IT Software Quality，國際軟體品質研究機構）在《The Cost of Poor Software Quality in the US： A 2022 Report》裡估計，美國 2022 年因軟體品質不良付出的總成本達到 2.41 兆美元，其中累積的技術債，也就是修復次優程式碼所需要的重工成本，就占了約 1.52 兆美元。報告指出，技術債持續增長，已經成為修改既有程式碼庫時最大的阻礙，正好呼應維護頻率墊高是地基撐不住的具體訊號這個判斷。
這種隱形的維護成本，不只是修補當下花的錢，還有背後吃掉的時間。Stripe 在 2018 年做的一份跨國調查《The Developer Coefficient》，訪問了超過 1,000 名工程師與超過 1,000 名 C 級主管、橫跨五個國家，發現受訪工程師平均每週有 17.3 小時，占 41.1 小時工作週的 42%，花在維護與修補既有程式碼上，而不是開發新功能，其中約 13.5 小時直接用於清償技術債，等於占掉將近三分之一的工作時間。同一份調查裡，78% 的受訪工程師表示，清償技術債正在影響團隊的生產力。維護老舊地基的隱形時間成本，遠比想像中吃掉更多資源，而這份調查已經是 2018 年的數字，不代表當下最新狀況，但方向上的警訊仍然成立。
更關鍵的是，地基層停止收到安全更新，不是理論上的風險，而是攻擊者正在積極鎖定的方向。根據 Verizon 最新一份《資料外洩調查報告》，漏洞利用取代帳密遭竊，首次成為這份報告 19 年歷史以來最常見的初始入侵手法，過去一年的資料外洩事件中，近三分之一（31%）始於漏洞利用，帳密濫用的占比則降到 13%。報告同時指出，造成這個轉變的主因不是攻擊者變得更厲害，而是企業修補已知漏洞的速度跟不上，受調查的組織裡，只有 26% 已經完整修復美國網路安全暨基礎設施安全局列出的已知漏洞，前一年這個數字還有 38%。維護頻率墊高、修補速度跟不上漏洞出現的速度，兩者疊在一起，就是地基層真正在計息的利息。
SEO 資產是重做的風險管理項目，不是決定要不要重做的理由
地基層的風險持續在計息，但很多人還是按兵不動，理由通常是怕動了 SEO 資產。許多判斷法把 SEO 資產、既有的排名要不要保留，直接當成決定該修補還是該重做的判準之一，邏輯是怕影響 SEO，所以能不動就不動。但 SEO 資產從來不該是要不要處理地基問題的理由，而是處理地基問題時，要不要做好風險管理的執行課題。
地基真的撐不住，該重做就重做，SEO 資產可以透過正確的遷移方式安全帶過去；反過來，用怕掉排名當藉口拖著地基問題不處理，只是把前面提到的技術債利息越滾越高，修補頻率會繼續墊高，資安風險會繼續累積，排名遲早也會因為網站本身撐不住而受影響，載入變慢、頻繁當機、內容更新不了都會反過來拖累排名。SEO 資產遷移是重做決定之後的執行課題，不是決定重做與不做的前提；處理方式決定風險大小，不是動不動決定風險大小。
一次只換一件事，才看得出 SEO 波動的真正原因
風險管理實際上怎麼做，關鍵在拆解變因。如果重做的時候同時換掉網域、換掉 CMS 系統、換掉整個版面配置，又順便把內容全部重寫一遍，一旦排名下滑，會完全無法判斷是哪個環節造成的，原本可以拆解、可以回溯的問題，變成一團完全黑箱的問題。
Google 官方文件《Site moves with URL changes》就明確建議，網站搬遷或改版時要一次只改一件事，不要同時更換網域、CMS 與版面配置，因為一旦排名出現異常，同時改動太多變因會無法定位問題出在哪個環節。正確的做法是分階段推進，即使重做的範圍很大，也可以拆成先換後端系統、保留原本的網址與版面配置，等排名確認穩定之後，再處理視覺與版面這一層，每一個階段只改一件事，出問題的時候才有辦法回頭定位是哪一步造成的。
留住網址結構比留住視覺更重要
很多人以為改版最怕的是內容看起來不一樣，但真正決定 SEO 資產保不保得住的，是網址結構有沒有守住，以及原本已經有排名的內容頁面，有沒有被整批砍掉重寫。視覺可以大幅翻新、版面可以整個重新編排，只要網址與已經帶有排名的內容頁面妥善處理，SEO 資產就能安全帶到新的網站上；反過來，就算視覺完全沒動，網址結構亂改、內容頁面整批消失，排名照樣會受傷。
Google 這份官方文件也指出，永久性的伺服器端轉址不會導致 PageRank 流失，但轉址鏈不宜過長，建議不要超過 3 個、最多不要超過 5 個；搬遷期間，Google 需要重新爬取與重新索引，中大型網站可能要花上數週到數個月，新網址的排名才會完全反映出來，因此建議轉址至少保留 1 年，讓 Google 有足夠的時間把訊號與連結權重完整轉移過去。把這兩點落到實際操作，結論很清楚，保留網址結構與內容頁面，優先順序排在保留視覺之前。
地基撐不住不代表整個網站都得打掉重練
決定重做之後，下一個常見的誤解，是把重做直接等同於把整個網站砍掉、從零開始。地基撐不住指的是某一層出問題，不代表視覺、內容、既有功能全部都要重來，常見而且務實的做法，是局部重建：只換掉已經過了支援期的程式語言或框架，資料庫裡原本的內容和資料照樣保留、照樣搬過去；或者只重新設計資料結構，好讓新功能有地方可以掛，視覺與版面沿用原本還堪用的那個部分。
判斷完地基之後，下一步該做的是盤點哪一層真的撐不住，只重做那一層，而不是把整套預算全部投進去，做一個從零開始的新網站。這個原則也呼應前面表面問題永遠修補划算的立場，即使決定動地基，表面層，視覺、文案，能沿用的就沿用，不必因為反正都要動了而順便把整個網站翻新一遍。反正都要動了、乾脆全部重來，聽起來很合理，實際上是預算浪費最常見的一種陷阱，花錢重做一個地基層根本沒問題的視覺，等於把本來可以留著、還能繼續用的資產丟掉重買。
Google 旗下的 web.dev 有一份案例研究可以具體示範這件事。Rakuten 24 針對既有頁面做了為期一個月的 A/B 測試，只優化網頁核心體驗指標（Core Web Vitals），包括讓版面跳動幅度改善 92.72%、首次輸入延遲改善 7.95%、首次內容繪製改善 8.45%、首位元組時間改善 18.03%，並沒有更動整體的資料結構，也沒有重建全站。結果是每位訪客的營收提升 53.37%，轉換率提升 33.13%，平均訂單金額提升 15.20%。這個案例具體示範了一件事，表面層、體驗層的問題，靠局部優化就能帶來很明顯的商業成果，不需要因為想改善某一點，就把整個地基一起打掉重練。
回到最開始的問題，判斷一個網站該修還是該重做，不是數症狀清單上打勾幾項，而是往下查地基撐不撐得住，程式語言與框架還在不在支援期內，原始碼與主機的控制權在不在自己手上，這次要解決的問題會不會動到資料結構，還有維護的頻率與成本是不是一路墊高。地基撐得住，外觀舊一點都無妨，修補永遠划算；地基撐不住，就算現在看起來還過得去，也只是把要面對的事情往後延。
至於排名、SEO 資產這些牽動生意的顧慮，不必也不應該變成決定要不要處理地基問題的理由，它是重做之後要謹慎執行的風險管理課題，一次只改一個變因、守住網址結構與內容頁面，資產就能安全帶過去。而且重做從來不等於打掉重練，先盤點清楚哪一層真的撐不住，只換掉那一層，留下的部分繼續留著用，才是真正划算的做法。