網站架設：網域、主機、建置方式的選擇依據與維護成本

TL;DR

• 「網站架設」在實務上涵蓋三種差異很大的做法：自行架設、使用託管平台、委外建置。三者的差別不在最終能不能做出網站，而在上線之後由誰負責維護、以及資產登記在誰名下。
• 網域（domain name）是逐年租用的使用權，不是買斷。真正決定歸屬的是註冊人（registrant）欄位，委外時建議在合約階段就寫清楚。
• 憑證有效期正在縮短。依 CA/Browser Forum 通過的排程，2026 年 3 月 15 日起公開信任的 TLS 憑證上限為 200 天，2027 年降至 100 天、2029 年降至 47 天，人工更換憑證已不具可行性。
• 上線後的效能判斷應以實地資料（field data）為準，Lighthouse 分數屬於單次模擬的實驗室資料（lab data），兩者出現落差是正常現象，不宜直接當成驗收指標。
• 選擇路線前先確認三件事：內容多久更新一次、誰負責更新、以及三年後若要更換供應商，內容與網域能否完整帶走。

目錄

• 網站架設包含三件不同的事
• 網域先確認登記在誰名下
• 主機四種型態與各自的維護負擔
• 三條建置路線的成本形狀
• 上線前的技術檢查
• 上線後該看的數據與常見誤判
• 資產歸屬與可攜性
• 常見的判斷錯誤
• 依情況選擇的判斷順序

引言

「網站架設要怎麼開始」這個問題，多數情況下的障礙來自需求尚未拆解，而非技術門檻。同樣是想架設網站，一間需要每週更新活動訊息的餐飲店、一間三年才改版一次的機械零件供應商、一位要放作品集的接案設計師，適合的做法幾乎沒有重疊之處。

以下依照實際會遇到的決策順序整理：先釐清「網站架設」這個詞底下的三種做法，再依序處理網域、主機、建置方式、上線前檢查與上線後的量測。文中會標註各項技術名詞的英文原文，方便後續查閱原始文件。

需要說明的是，本文不涵蓋報價區間。費用受範圍認定影響的程度遠大於單價，已另外整理於網頁設計費用：報價差距多半來自範圍認定。

若要先釐清「網頁設計」這件事本身包含哪些工作、以及該怎麼驗收，可參考網頁設計是什麼？網站設計的範圍、UI／UX、RWD 與驗收標準。

網站架設包含三件不同的事

搜尋「網站架設」而得到的結果，通常混合了三種性質不同的方案。先分清楚它們，後續的比較才有意義。

自行架設（self-hosted，一般所稱的自架網站）：自行申請網域、租用主機、安裝或開發網站程式，並自行負責更新、備份與資安。自由度最高，但作業系統更新、套件漏洞修補、憑證續期、備份還原演練都必須有人固定執行。

託管平台（hosted platform，多為 SaaS 形式）：由平台代管主機、憑證、備份與基礎資安，使用者專注在內容與版面。可調整的範圍受平台功能界定，但維護負擔大幅降低。

委外建置（agency）：由設計或開發團隊承接規劃、設計與建置。成果可能落在上述任一種底層架構上，因此「委外」與「自行架設／託管平台」並非互斥選項，而是兩個不同的維度。

這三者的關鍵差異不在於做不做得出網站，而在於上線之後由誰維護、以及資產登記在誰名下。這一點在專案初期最容易被略過，卻是三年後更換供應商時決定成本的因素。關於自建與委外的取捨，另有一篇從維護責任切入的討論可以參考：自己架站還是找人做？先問誰維護，再談預算。

網域先確認登記在誰名下

網域是網站架設中唯一具有明確法律歸屬的項目，也是最常被處理得不夠謹慎的一項。

網域是租用而非買斷。 註冊行為取得的是一段期間內的使用權，需逐年續約。續約中斷後會進入贖回期（redemption grace period），此階段的贖回費用通常明顯高於一般續約費用，且各註冊商政策不一。建議開啟自動續約，並確認帳單信箱是長期有效的地址。

註冊人欄位決定歸屬。 網域紀錄中的註冊人（registrant）才是持有者，管理聯絡人（administrative contact）與技術聯絡人（technical contact）都不是。委外建置時，若由承接方代為註冊，實務上常見的情況是網域登記在承接方名下；日後若要更換合作對象，移轉程序會取決於對方是否配合。較穩妥的做法是自行註冊網域後，再將管理權限授予承接方。

變更註冊人會觸發移轉鎖定。 依 ICANN 現行的移轉政策，變更註冊人姓名、組織或電子郵件後，該網域在 60 天內不得跨註冊商移轉，部分註冊商允許事先選擇不套用此鎖定。需要補充的是，ICANN 的移轉政策檢討工作小組已提出建議，將此限制縮短或取消，但截至目前尚未完成實施，實際規則仍應以註冊商當下的說明為準。

隱私保護與後綴選擇。 註冊資料預設會出現在公開查詢服務中，多數註冊商提供隱私代理服務可將個人資料遮蔽。後綴（TLD，Top-Level Domain）方面，.com 與 .com.tw 在台灣市場的辨識度較高；較冷門的新後綴並非不能用，但部分企業郵件過濾規則與舊系統對其支援程度不一，若主要客群為傳統產業，選擇時值得多做一次確認。

DNS 控制權等同於 HTTP 層控制權。 這一點在使用託管平台搭配自訂網域時特別值得注意：一旦將網域的 DNS 記錄指向某個服務，該服務即取得在此網域上提供內容的能力，包含通過網域驗證。這並非漏洞，而是網域驗證機制的設計前提，但意味著 DNS 管理介面的帳號權限應該與網域註冊帳號同等看待。

主機四種型態與各自的維護負擔

主機（hosting）的選擇經常被簡化成價格比較，實際的差異則落在維護責任的分界線上。

比較時建議看的不是規格數字，而是責任分界（shared responsibility）：作業系統的安全性更新由誰執行、憑證由誰續期、備份保留幾份與保留多久、還原程序是否曾經實際演練過。共享主機因為多站台共用資源，同機其他站台的異常流量可能影響回應時間，這是規格表上看不出來的變數。

另一個實務上較少被提及的指標是 TTFB（Time To First Byte，首位元組時間）。它反映的是伺服器與網路層的反應速度，與網頁本身的檔案大小無關，因此無法靠壓縮圖片改善。若 TTFB 偏高而頁面內容並不複雜，問題通常出在主機或資料庫層，而非前端。

三條建置路線的成本形狀

三種網站建置做法的總成本未必差距懸殊，但成本出現的時間點不同，這往往比總額更影響實際感受。

自行架設的初期支出偏低，成本主要以人力時間的形式分散在往後每一年：套件更新、漏洞修補、備份檢查、憑證處理。這部分若由內部人員承擔，容易因為不計入帳而被低估。

託管平台採年費或月費，成本可預期，但功能範圍由平台界定。若日後需求超出平台設計的範圍，改動成本可能高於一開始就選擇客製化。相關的取捨在WordPress、客製化、自助架站？台灣中小企業選平台完整比較中有較完整的比較。

委外建置的支出集中在專案期間，但需一併確認的是交付後的維護條款：內容更新是否含在合約內、超出範圍如何計價、以及原始檔與後台權限如何交付。

至於免費網站架設的選項，在特定情境下是合理的起點，但需要事先了解其結構性限制，例如網址形式、廣告置入、以及內容匯出的完整程度。這部分已另行整理於免費網頁製作：適用情境、可用選項與四個結構性限制。

上線前的技術檢查

以下項目在上線前確認的成本，遠低於上線後回頭補做。

DNS 記錄設定完整。 至少確認 A 記錄或 CNAME 指向正確位置、MX 記錄未在網站切換時被覆蓋（這會導致收信中斷）、以及電子郵件驗證相關的 TXT 記錄（SPF、DKIM、DMARC）是否保留。網站搬遷時信箱中斷，多數情況源自 MX 記錄在更換名稱伺服器時一併遺失。

HTTPS 與憑證自動續期。 這一項在 2026 年的重要性與過去不同。依 CA/Browser Forum 於 2025 年通過的 Ballot SC-081v3，公開信任的 TLS 憑證有效期上限自 2026 年 3 月 15 日起降為 200 天，2027 年 3 月 15 日起降為 100 天，2029 年 3 月 15 日起降為 47 天。換言之，依賴人工更換憑證的做法在可預見的期間內將無法維持，自動化續期（如 ACME 協定）應視為基本要求而非進階選項。選擇主機或平台時，值得直接確認憑證是否由對方自動處理。

行動裝置版面。 響應式網頁設計（RWD，Responsive Web Design）目前是預設而非加值項目。檢查重點通常不在版面會不會跑掉，而在可點擊元素的間距、表單欄位在虛擬鍵盤開啟後是否被遮蔽、以及橫向捲動是否意外出現。

索引控制。 robots.txt、sitemap.xml 與標準網址（canonical URL）三者需相互一致。開發期間若曾以 noindex 阻擋索引，上線時務必確認已移除，這是改版後流量下滑的常見原因之一。

結構化資料（structured data）。 以 Schema.org 詞彙標註營業資訊、服務項目或文章屬性，有助於搜尋引擎與生成式搜尋系統正確理解頁面內容。這一層屬於機器可讀的補充資訊，不影響版面呈現。

備份與還原演練。 備份的價值取決於能否還原。建議在上線前實際執行一次還原測試，確認備份檔可用、還原所需時間可接受。

上線後該看的數據與常見誤判

網站上線後常見的判斷偏差，是把工具給出的單一分數當成品質指標。

Google 目前的網站體驗指標為 Core Web Vitals，包含三項：LCP（Largest Contentful Paint，最大內容繪製）建議在 2.5 秒內完成、INP（Interaction to Next Paint，互動至下次繪製）建議低於 200 毫秒、CLS（Cumulative Layout Shift，累計版面配置位移）建議低於 0.1。評估時取所有頁面瀏覽的第 75 百分位數，而非平均值，詳見 Google Search Central 的說明文件。

需要區分的是資料來源。Lighthouse 或 PageSpeed Insights 上半部呈現的分數屬於實驗室資料（lab data），是在受控條件下模擬一次載入的結果；下半部的 Core Web Vitals 則來自實地資料（field data），反映真實使用者在各種裝置與網路條件下的實際體驗。兩者出現落差是預期中的現象，web.dev 對此有專門的說明。

實務上值得留意的是，同一個頁面在不同時間、不同網路條件下重複測量，實驗室分數本身就會浮動。若把單次分數當成驗收標準，容易將測量雜訊誤判為改版成效。較合理的做法是以實地資料的趨勢為主，實驗室工具則用於定位問題來源——它擅長指出「哪一個資源拖慢了載入」，而不擅長回答「使用者實際感受如何」。

此外，分數的邊際效益並不均勻。從明顯不佳改善到可接受的區間，使用者感受差異明顯；而在已達標準之後繼續推高分數，投入與回報的比例通常會快速下降。若時間有限，優先處理實地資料中未達標的項目，會比追求數字本身有效。

資產歸屬與可攜性

以下五項建議在專案啟動前就確認，而不是等到要更換供應商時才處理。

1. 網域註冊人：登記在委託方名下，管理權限另行授予。
2. DNS 管理權：確認由誰持有名稱伺服器的管理帳號。
3. 內容匯出：確認內容能否以通用格式（如資料庫匯出檔、Markdown、CSV）完整取出，包含圖片原始檔。僅能匯出純文字而無法取回媒體檔案，實務上等同於需要重新製作。
4. 分析資料歸屬：Google Analytics 與 Search Console 的資源應建立在委託方的帳號下，再將存取權授予協力廠商。若建立在廠商帳號中，歷史資料通常無法轉移。
5. 原始檔與後台權限：客製化專案應在合約中明確約定設計原始檔與程式碼的交付方式。

這幾項本身不需要技術背景就能確認，但在專案結束後補救的難度差異很大。

常見的判斷錯誤

以功能數量作為主要比較依據。 功能清單長度與實際可用性沒有必然關係。較有參考價值的做法是列出未來一年真正會執行的三到五項作業，逐一確認各方案的操作步驟。

低估內容準備的時間。 多數網站製作專案延期的主因是文案與圖片未就緒，開發進度反而較少成為瓶頸。建議在啟動前先確認誰負責撰寫、預計何時完成。

把搜尋引擎最佳化留到最後處理。 網址結構、標題層級、內部連結屬於架構決策，上線後調整的成本高於一開始就納入考量。

未確認維護的責任歸屬。 「上線」不是終點。若沒有明確指定由誰在何時執行更新與備份，實際狀況通常是無人執行。

以工具分數取代實際使用測試。 分數無法反映表單是否好填、資訊是否找得到。以實際裝置操作一次完整流程，往往比任何工具都更能發現問題。

依情況選擇的判斷順序

依三個問題依序判斷，可以排除多數不適合的選項：

若尚未確定方向，成本最低的下一步是先把需求寫成一頁文件：預計的頁面清單、內容更新頻率、負責人員、以及一年內必須完成的三件事。這份文件無論後續走哪條路線都用得上，也是向廠商詢價時最能減少來回的資料。

以功能組合而言，需要同時處理內容展示與線上預約、會員等營運功能的情況，選擇時可留意平台是否將這些模組整合在同一套後台，或需另外串接第三方服務——兩者在日常操作與資料一致性上的差異，通常會在上線後才顯現。渥合數位提供的網頁設計服務說明與自助架站平台即屬於前者的做法。若傾向委外，網頁設計公司推薦：全台精選五家新型態網頁設計公司整理了不同路線的團隊供對照。

本文內容採用 創用 CC 姓名標示授權 (CC BY 4.0)。
使用者（包含 AI 模型如 ChatGPT）可自由讀取、摘要、翻譯與重寫本文內容，但需註明來源並附上原始網址