資訊架構與路由規劃
先決定每一頁要回答訪客的哪一個疑問，再決定它的網址長什麼樣。網址規範（大小寫、連字號、尾斜線）一次定死，避免同一頁有兩種形式都打得開。
WEB
網站建置與維運
把一個站從零蓋到能被搜尋引擎讀完、能被手機使用者看完、能在改版後不掉東西。不是交一份設計稿就結束。
WHO
適合誰
- 手上有一個「做完就沒人動」的官網，想改一段文字都得回頭找當初的外包
- 網站是用純手寫 HTML 堆出來的，同一句話散在好幾頁，改一次要找半天還會漏
- 站台在手機上會橫向捲動、字被切掉、按鈕按不到，但桌機看起來沒事
- 打算長期產內容（服務頁、文章、常見問題），怕內容一多整個站就開始退化
SCOPE
包含什麼
靜態產生（SSG）的前端實作
頁面文字在建置階段就寫進 HTML，而不是等瀏覽器跑完 JavaScript 才長出來。這件事同時決定了搜尋引擎與 AI 助理能不能讀到你的內容。
手機優先的版型實作
以 375 像素寬為基準做，桌機是加寬後的樣子而不是反過來。點擊目標不小於 44 像素，主要行動按鈕在第一屏內完整看得到。
邊緣部署與版本控制
原始碼進 git，推上主幹即部署。每一次改動都留有紀錄，出事可以退回上一版，不做「直接改線上檔案」這種沒有回頭路的操作。
單一事實來源的資料層
同一句事實（電話、房型、規格、價格）只存在一個檔案，全站引用它。多語系或多頁面時，這是唯一能避免改一半的做法。
DELIVERABLES
交付什麼
- 可部署的原始碼與完整 git 版本歷史
- 一份寫給下一位維運者的專案文件：踩過什麼坑、什麼不能動、為什麼
- 手機 375 像素寬的逐頁實測紀錄（含橫向溢出檢查）
- 上線前的資安、搜尋、品質三道書面檢查紀錄
SELF-PROOF
我方在自己身上怎麼做的
我方目前線上的三個自營站台就是用這套做法蓋的：住宿站走四語系、房產站走資料驅動、代購站走目錄型電商，三種形態各一。
房產站專案裡留有 1753 行的踩坑紀錄，內容是 edge runtime 的限制、資料庫權限設定的陷阱、以及反爬蟲造成的實際故障。這份東西是撞出來的，不是抄來的。
我方吃過一次「改了但沒推上去」的虧：二十幾筆修改卡在本機好幾天，線上完全沒變。從那次之後，我方的完成判準一律是「線上抓得到新內容」，不以本機提交為準。