網站該動？該靜？先看它要完成什麼，再決定怎麼建置

同樣被稱為「企業網站」，實際工作可能完全不同。

有些網站主要讓人認識品牌和服務；有些需要持續發布文章與案例；有些讓訪客預約、報名或下載文件；也有些需要登入後管理訂單、課程、案件或內部資料。

這些差異會影響內容、頁面、後台、資料、權限和維護方式。只用首頁風格或頁面數量分類，無法說明網站真正需要處理的事情。

較實際的做法，是先列出網站最重要的三到五項任務，再判斷它主要屬於哪一類，還需要搭配哪些其他能力。

一個網站可以同時屬於多種類型。分類的目的不是替網站貼標籤，而是避免漏掉真正需要被設計和維護的工作。

網站用途回答的是「它要做什麼」，技術架構回答的是「它怎麼完成」。

品牌服務站、內容網站、電商、會員平台與 Web App，屬於用途和營運模式；靜態頁面、伺服器動態生成、CMS、API、資料庫、headless、PWA，則屬於建置與傳遞方式。

例如，內容網站可以使用傳統 CMS 即時產生頁面，也可以由 CMS 管理內容後，預先生成較快的靜態頁面。購物網站可以建立在託管平台上，也可以使用客製前端連接商品、庫存和付款系統。

把兩個維度分開，團隊就不必在「靜態網站」和「購物網站」之間做錯誤選擇，也比較能理解同一項業務需求為什麼可能有不同技術方案。

品牌或服務型網站的主要任務，是建立清楚認識與信任。

常見內容包括品牌介紹、服務項目、合作流程、案例、常見問題、文章與聯絡方式。頁面數量不一定多，但內容層級、品牌語氣和下一步必須清楚。

這類網站可以使用較簡單的技術，也可以搭配 CMS 讓團隊持續更新案例和文章。若服務複雜、受眾不同，還需要建立分類、比較和內部連結，而不只是把所有資訊放在首頁。

適合的判斷不是網站看起來是否華麗，而是第一次進站的人能否理解服務是否適合自己，也能找到足夠證據做出下一步。

活動頁、產品上市頁、廣告落地頁與募資頁，通常圍繞一個明確主題和主要行動。

它們適合使用連續敘事，依序說明問題、價值、內容、條件、證據與報名或購買入口。因為使用期間和流量來源明確，視覺與互動也可以較集中。

但單頁不代表工作一定簡單。活動可能需要場次、名額、付款、通知與後台名單；廣告落地頁還要處理追蹤、版本測試和過期後的重新導向。

如果活動會反覆舉辦，較好的方式不是每次複製一套新網站，而是建立可重複使用的活動內容類型和版型，讓短期頁面仍能被長期管理。

部落格、知識庫、媒體、研究資料庫與教學網站，主要價值來自持續累積的內容。

除了文章編輯器，還需要考慮分類、標籤、作者、日期、搜尋、推薦、版本、引用和內容複查。資料量增加後，資訊架構和內容治理會比單一頁面設計更重要。

如果每篇文章都自由排版，短期有彈性，長期卻可能難以搜尋、重複使用和改版。先定義內容類型和必要欄位，才能讓同一份資料出現在列表、搜尋、相關文章和其他渠道。

近期 CMS 也開始把 AI 摘要、圖片、分類和工作流程放進平台能力。工具可以加快內容製作，但發布權限、來源確認和內容生命週期仍要由團隊管理。

電商網站會展示商品，也要處理價格、庫存、購物車、付款、訂單、配送、退換貨、通知和客服。

商品頁只是交易流程的一部分。真正的複雜度通常來自促銷規則、不同付款狀態、庫存同步、發票、物流和例外處理。

若商品數量少、流程接近標準，成熟的託管電商平台通常能降低建置和維護成本；若有特殊訂價、企業採購、跨系統庫存或複雜會員權益，才需要評估更深入的客製或整合。

選擇電商做法時，要把後台人員每天如何接單、出貨、取消與對帳一起納入，而不是只比較前台版型。

餐廳訂位、課程報名、顧問預約、場地租借與維修申請，都屬於服務流程型網站。

前台需要讓使用者選擇日期、項目或條件，後台則要處理名額、確認、取消、提醒、付款和人員安排。

一張表單可以收集資料，卻不一定能完成整段服務。如果團隊仍要手動重新輸入、逐一確認，網站只是把紙本換成線上入口。

規劃時應先畫出目前流程，確認哪些步驟適合自動化、哪些需要人工判斷，以及例外狀況如何處理。這類網站的價值，來自前台操作和內部工作都變得更清楚。

會員中心、學習平台、客戶專區、員工入口和合作夥伴網站，會依登入身分提供不同資料和功能。

除了註冊與登入，還需要處理邀請、審核、忘記密碼、停權、角色、資料下載和操作紀錄。不同使用者能看見、修改和匯出什麼，也需要明確規則。

入口網站常會整合多套服務，提供單一導覽和身分入口。但畫面集中，不代表資料自然整合，背後仍要確認每個系統的權限、同步與責任。

只要涉及會員和私人資料，安全、隱私、備份和離職停權就不是上線後才補做的項目，而是網站類型本身的一部分。

報價試算器、排程工具、儀表板、線上編輯器、專案管理和資料分析系統，通常更接近 Web App。

它們不以閱讀內容為主要目的，而是接收輸入、執行邏輯、保存狀態，再提供結果。畫面可能不多，功能和資料關係卻很複雜。

近期網站工具已能用 AI 依提示產生可操作的 Web App，連接 CMS 資料、設計系統和雲端部署。這可以加快原型和部分製作，但需求、資料模型、權限、安全、測試與長期維護仍需要另外規劃。

是否需要 Web App，不應只看想不想加入互動，而要確認這項工具是否真的能縮短工作、降低錯誤或提供一般內容頁無法完成的服務。

論壇、社群、媒合、市集和投稿平台，不只服務網站經營者與訪客，也要處理會員彼此之間的內容、交易或互動。

這類網站需要帳號、內容審核、檢舉、通知、搜尋、聲譽、交易或爭議處理。平台規則和管理機制，往往比首頁視覺更影響能否長期營運。

平台初期最大的風險，通常不是功能不夠，而是沒有足夠內容、供給或參與者形成價值。第一版應先驗證最核心的媒合或互動，再逐步增加社群與自動化功能。

網站技術可以建立入口，真正的平台仍需要持續的營運、管理和信任機制。

傳統上，靜態網站指伺服器直接提供已準備好的頁面；動態網站則會依資料庫、使用者或當下條件產生內容。

現在兩者之間已有許多混合方式。網站可以預先生成大部分內容，在有更新時重新發布；也可以先快速顯示靜態頁面，再於特定區塊載入即時資料。

互動網站描述的則是使用者參與程度，例如表單、篩選、計算、投票、遊戲或個人化。它可以建立在靜態或動態架構上。

因此，靜態、動態和互動比較適合用來理解技術和行為特性，而不是作為企業只能選一項的網站分類。

動態網站的「動態」，通常是指內容會依資料、條件或使用者狀態改變。網站動態效果則是淡入、轉場、視差、捲動動畫和影片背景等視覺表現。

一個沒有資料庫的品牌頁，也可以使用大量動畫；一個處理庫存、會員和訂單的動態網站，畫面則可能非常安靜。

兩者的成本與風險不同。資料動態需要後端、資料庫、權限和維護；視覺動態則要考慮效能、手機、減少動態偏好和內容可讀性。

先分清楚需求屬於資料、流程還是視覺，可以避免只想增加畫面效果，卻誤以為需要建立複雜系統，也能避免真正的資料功能被當成簡單動畫估算。

傳統 CMS 通常同時管理內容與前台頁面。Headless CMS 則把內容透過 API 提供給網站、App、數位看板或其他介面使用。

當同一份商品、文章或服務資料需要跨多個渠道重複使用，分離內容和介面能提高彈性；前端團隊也能選擇適合的技術。

但這種架構會增加預覽、發布、搜尋、快取、整合和開發維護的工作。若網站只有單一介面、團隊人數少，完整的傳統 CMS 可能更直接。

Headless 不是比一般網站更先進的類型，而是當內容重複使用和開發需求足夠明確時，可以採用的架構選擇。

Progressive Web App 可以讓符合條件的網站被安裝到裝置，並依功能需求提供離線、通知、捷徑或更接近應用程式的使用方式。

它適合需要頻繁回訪、保留工作狀態、接收通知或在不穩定網路中使用的服務，例如課程、現場作業、會員工具與部分企業系統。

近期 Chrome 持續改善 Web App 安裝與作業系統整合，包括新的 HTML 安裝元素，以及 macOS 上更清楚的 PWA 通知權限和來源識別。

但不是每個企業網站都需要安裝。若訪客只偶爾閱讀服務內容，要求安裝反而增加阻力。PWA 應該建立在清楚的回訪價值上，而不是把「像 App」本身當成目標。

「AI 網站」至少可能有兩種意思。

第一種是使用 AI 協助建立網站，包括產生多頁架構、文案、圖片、程式與 Web App。第二種則是網站本身提供 AI 搜尋、推薦、客服、生成或自動化功能。

前者改變的是製作流程，後者改變的是網站服務。兩者都需要人工確認內容、資料、權限、成本和錯誤處理。

主流 CMS 已開始提供統一的 AI 連接與能力介面，網站平台也能以提示產生可連接 CMS 的 Web App。這讓原型與整合更快，但不代表每個網站都需要加入聊天視窗，也不代表生成結果可以未經測試直接發布。

AI 應該對應明確任務，例如協助查找大量資料、整理需求或降低重複工作，而不是只為網站增加一個流行入口。

除了讓人點擊和輸入，網站也開始探索如何讓 AI 代理更可靠地理解並執行任務。

Chrome 在 2026 年推出 WebMCP origin trial，嘗試讓 Web App 以結構化工具方式提供表單和功能，協助瀏覽器代理完成訂位、規劃或其他操作。這仍是提案與測試階段，不應被視為所有網站已經需要採用的標準。

即使不使用新協定，網站仍可先把基本工作做好：使用正確 HTML、清楚的表單標籤、可辨認的按鈕、穩定網址、合理權限和明確狀態。

Agent-ready 的趨勢提醒我們，網站未來的使用者可能同時包含人與受人委託的工具。但代理能力不能跳過同意、安全、確認和人工接手。

功能增加後，網站不只需要更多開發，也會增加內容、資料、權限、客服和維護工作。

品牌網站需要持續確認服務和案例；內容網站要處理分類與過期資訊；電商和平台需要管理交易、會員與爭議；Web App 則要監控資料、錯誤、使用量和版本。

新技術不會自動解決治理問題。AI 產生內容後仍要審閱，PWA 通知需要權限和退訂，平台資料需要備份，網站功能也要定期更新和測試。

選擇類型時，可以同步列出上線後每週、每月和每年需要做的工作。若沒有任何人能承擔，表示目前範圍可能需要縮小，或增加外部維護支援。

開始規劃時，可以先回答六個問題：

主要使用者是誰？他要完成什麼？網站管理哪些內容和資料？是否需要登入、交易或個人化？內容由誰更新？發生錯誤時由誰處理？

接著，再選擇主要網站類型。例如第一版先完成品牌服務、案例和詢問流程；第二階段加入內容發布；確認需求後再增加會員或試算工具。

這種做法不是把網站切成互不相關的專案，而是先建立可以運作和驗證的核心，再逐步增加其他類型的能力。

這是 Amicable 理解網站類型的方式：不從技術名詞、流行功能或版型開始，而是先理解網站要完成的任務，再組合內容、服務、交易、工具與平台能力。網站可以很簡單，也可以持續成長，但每一項複雜度都應有清楚的使用理由。