第一次做網站？網頁設計的流程、費用、時程與驗收重點

第一次要做網站，真正讓人猶豫的往往不是要不要做，而是緊接著冒出來的一連串問題：要用哪種方式架設網站、預算大概要抓多少、從動工到上線要花多久、製作流程會經過哪幾關，做完之後又該怎麼驗收。這幾題幾乎每個第一次接觸網頁設計的人都會問上一輪，其中任何一題沒想清楚，後面往往就得回頭重做。

做網站的方式這幾年也在變。AI 已經能依一句話的描述生成整個網站雛形；Google 搜尋結果裡，也有愈來愈多問題直接由 AI 摘要整理成答案，點進網站的機會跟著變少。這些變化多數教學都會提到，比較少被談到的，是幾個容易被忽略、卻可能讓人事後吃虧的環節：網站做完之後，網域、主機、原始檔這些資產登記在誰名下；舊網站改版或換平台時，會不會把累積多年的排名一併弄丟；日後若有機會承接公部門或教育機構的案子，無障礙網頁規範會不會變成一道過不了的門檻。第一次做網站的人很少事先想到這幾件事，它們卻常是後來最花時間補救的部分。

網頁設計涵蓋哪些概念、技術怎麼分工，架站方式、預算與時程怎麼抓，製作流程與上線前的驗收怎麼進行，再加上 AI 建站、資產歸屬、改版遷移、無障礙規範與 GEO（生成式引擎優化），這些環節在動手前先弄懂，做網站時才不會漏想，做完之後也才能長期經營下去。

網頁設計是什麼？

網頁設計是把視覺、內容與技術整合在一起，讓使用者打開網站時看得懂、讀得下去、用起來也順手的過程。它不只是把畫面弄漂亮，還牽涉版面配置、操作流程、資訊層級與程式技術，目標是同時做到好看、好讀、好用這三件事。

對任何品牌或個人來說，網站都是線上最重要的門面。訪客往往在幾秒內就要判斷這個網站可不可信、找不找得到自己要的資訊。好看的外觀只是第一步，接著還要讓訪客順利完成填表、瀏覽服務、下單或發出詢問這些動作，其中任何一步走不下去，前面在視覺上的投入就白費了。

「網頁設計」聽起來範圍很明確，但實務上它常跟「網站設計」「網頁製作」「網站架設」這幾個詞混著用，各自所指的範圍其實不完全一樣，值得先分清楚。

網頁設計、網站設計與網站架設，各自涵蓋的範圍

很多人把「網頁設計」和「網站設計」當成同一件事的兩種說法，交替著用，不特別區分。這種混用不算講錯，只是不夠精確。英文的 web design 本身就同時涵蓋單頁視覺與整體架構兩層意思，翻成中文之後也沒有嚴格切分，久而久之，兩個詞就被當成同義詞使用。市面上還有幾個常被交替使用的相近說法，一併弄清楚，之後討論需求時比較不會出現認知落差。

網頁設計偏重單頁呈現，網站設計涵蓋整體架構

把兩者拆開來看，範圍其實不一樣。網頁設計偏向單一頁面的視覺與版面呈現，關心的是這一頁好不好看、排版順不順，屬於介面層（UI）的工作。網站設計則涵蓋整個網站的架構規劃，包含資訊層級怎麼區分、有哪些頁面要串接、後端功能怎麼安排，是網頁設計的上位概念，一個網站設計專案裡，通常會包含好幾次網頁設計的工作。所以找人「設計一個頁面」跟「做一個網站」，牽涉的規劃範圍差距不小，前者可能只需要處理一頁的視覺呈現，後者要連同架構規劃與多頁串接一起考慮。

網頁設計與網頁程式設計分屬不同的專業角色

另一組容易混淆的說法，是網頁設計跟網頁程式設計（開發）。設計負責看得到、摸得到的介面與體驗，包括版面配置、色彩字體、按鈕位置與操作動線；程式設計負責讓這個介面真正動起來，把設計稿轉換成瀏覽器能執行的程式碼，處理表單送出、資料讀寫、會員登入這類實際的功能邏輯。換個直白的說法，設計決定畫面長什麼樣子、用起來順不順手，開發決定畫面背後的功能能不能真正運作。

實務上這兩個角色常是同一個團隊裡的分工，一人畫視覺稿，另一人接手切版與寫程式；規模較小的團隊，也可能由同一人身兼兩種角色。市面上不少人習慣用「網頁設計」統稱從畫面到功能的整個製作過程，也有人把設計跟開發嚴格分成兩個階段，各自報價。所以開始討論案子前，先確認這次講的「設計」是只到視覺稿為止，還是連同開發一起算，就能提前避開報價範圍認知不一致的狀況。

網頁製作、網站建置與網站架設的語感差異

除了上面兩組，「網頁製作」「網站建置」「網站架設」也是市面上常被交替使用的詞。網頁製作通常指從設計到完成網頁的整個實作過程，強調的是把網頁真正做出來這個動作；網站建置的語感偏向整體，從規劃、設計、開發到上線通常都算在內，比較常出現在企業或機構型的專案描述裡；網站架設口語上常簡稱架站，範圍也最鬆散，用免費平台幾分鐘拉出一個網站雛形，跟自己架設一套完整的內容管理系統，都可能被稱作架站。這幾個詞彼此沒有嚴格的界線，與其糾結名詞該怎麼定義，不如直接問清楚這次包含哪些工作項目，例如含不含後續維護、有沒有包含程式開發。

分清楚這些說法不是為了爭學術定義，而是接下來做網站、跟人溝通時都會直接用到。用詞對齊、範圍談清楚了，各家的網頁設計費用報價才會落在同一個基準上，比較起來也才有意義。

網站由五個核心元素共同組成

一個網站不是只靠畫面撐起來，而是由好幾個環節共同組成，少一塊都會露出破綻。視覺設計與使用者體驗、內容規劃、前後端技術分工、響應式設計，加上載入速度與效能表現，是構成一個網站的五個基本元素。SEO 與 GEO 同樣重要，只是牽涉的技術細節與判斷邏輯較多，適合當成獨立的主題來看。

視覺設計負責好看，使用者體驗負責好用

視覺設計（UI, User Interface）決定網站的第一印象，包括排版、配色、字體、圖示與整體風格，是使用者一進站最先感受到的部分。良好的視覺設計能提升品牌形象，也讓使用者更輕鬆地吸收資訊。

但畫面好看只是一半，另一半要靠使用者體驗（UX, User Experience）撐起來。UX 關心的是導覽設計、資訊層級、按鈕位置與操作流程順不順，讓使用者不迷路、不困惑，能順利完成填表、瀏覽或找到需要的內容。UI 與 UX 是分工關係，一個讓網站好看，一個讓網站好用，只做好其中一邊，網站往往留不住人。畫面漂亮卻找不到聯絡按鈕，或動線清楚卻顯得粗糙沒質感，結果都一樣，訪客會提早離開。

內容規劃是網站真正留住訪客的關鍵

網站真正留住人的，往往不是版面，而是內容本身。內容要清楚、有層次、容易閱讀，還要能回答訪客真正關心的問題，而不是自顧自地講。文案撰寫、圖片搭配、服務介紹與常見問題整理，都屬於內容規劃的範圍，這也是整個網站裡最容易被低估、卻最花時間準備的一塊。

前端負責畫面，後端負責看不到的運作邏輯

前端負責使用者看得到、摸得到的部分，包括排版、圖片、顏色、互動效果，以及在不同裝置上的版面調整，讓網站不只好看，也能實際操作。後端則負責使用者看不到的運作邏輯，像是表單資料處理、使用者登入驗證、內容管理與資料讀寫，讓網站的功能真正運作起來。兩者缺一不可，而網站愈複雜，就愈依賴後端撐住穩定度。

響應式設計（RWD）要以手機版為主要版本

使用者會透過手機、平板、桌機等各種裝置瀏覽網站，響應式網頁設計（RWD, Responsive Web Design）讓網站能依裝置尺寸自動調整版面，確保內容不變形、不擁擠，在哪種螢幕上都維持一定的閱讀品質。

這件事對台灣使用者格外重要。財團法人台灣網路資訊中心（TWNIC）委託國立陽明交通大學執行的《2025 台灣網路報告》顯示，台灣的行動上網率已經達到 87.12%。換句話說，多數訪客第一眼看到的很可能就是手機版。手機版要是排版跑掉、字太小或按鈕點不到，等於直接把大半潛在訪客擋在門外。所以手機版不是可有可無的選配，做 RWD 網頁設計時，反而該先把它當成主要版本來規劃。

版面要在哪個寬度切換，也有判斷依據。斷點（breakpoint）比較好的抓法是跟著內容走，設在版面開始擠壓的地方，例如導覽列開始換行、卡片變得太窄、表單欄位變得難填的那個寬度，不必死守幾款熱門裝置的尺寸，因為裝置規格每年都在變。

載入速度與 Core Web Vitals 三項指標

網站速度會直接影響使用者願不願意留下來。圖片壓縮、程式優化、主機品質與 CDN 使用，都會左右頁面讀取的快慢，速度也是搜尋引擎評估網站體驗的重要依據。

Google 目前用三項名為 Core Web Vitals（核心網頁指標）的數據評估真實使用者的體驗。LCP（Largest Contentful Paint，最大內容繪製）衡量主要內容多快出現在畫面上，及格門檻是 2.5 秒以內；INP（Interaction to Next Paint，互動到下一次繪製）衡量使用者點擊或輸入後畫面多快有反應，門檻是 200 毫秒以內；CLS（Cumulative Layout Shift，累計版面配置轉移）衡量畫面會不會在載入過程中突然跳動，門檻是 0.1 以下。

新手不需要自己抓數字，用 Google 提供的 PageSpeed Insights 工具檢測，或到 Search Console 查看網站速度報告就好，兩者都會標出哪些頁面沒過門檻、問題出在哪一項指標。

網頁設計常見的三種基礎版型與挑選依據

視覺設計落到實際畫面上，接著要面對的就是版面怎麼擺，這也是新手最常拿不定主意的視覺決策之一。版面配置決定資訊怎麼呈現，也直接影響使用者的閱讀體驗。最常見的版型結構有單欄式、雙欄式與三欄式，多數網站都是從這三種架構延伸出來的。行動裝置普及之下，單欄式（尤其是手機版）已經是多數網站的預設起點，雙欄與三欄則多半是桌機版才會用到的加值，不是每個網站都需要。

看範例網站挑版型時，可以留意三件事：主要內容區塊占的比例夠不夠大、側邊欄放的是真正對訪客有用的輔助資訊還是塞滿了行銷版位，以及版型收到手機版時會不會整個打散變形。

至於自己適合哪一種版型，可以從內容類型判斷。以敘事為主、希望訪客專心閱讀的服務型網站，通常單欄式就夠用；需要同時呈現分類、搜尋與大量文章的知識庫或部落格，雙欄式的側邊導覽會更好用。

單欄式版型讓視線集中在主內容

單欄式（Single Column）排版以直向瀏覽為主，沒有左右欄位分散注意力，讓使用者能專注在主內容上。常見於部落格文章內容頁、Landing Page 與銷售頁、產品或服務的單頁介紹、公司網站的敘事式內容區段、聯絡表單與登入註冊等單功能頁，以及手機版網頁（RWD 的主流架構）。

雙欄式版型以主內容搭配側邊欄

雙欄式（Two Column）排版通常是主內容搭配側邊欄，讓資訊層次更清楚。部落格文章列表頁、企業網站的側邊導覽架構、電商商品分類頁（左側篩選、右側商品）、教學站或知識庫，以及需要顯示分類、搜尋、推薦文章或 CTA 的頁面，都經常採用這種版型。

三欄式版型適合資訊密集的大型網站

三欄式（Three Column）多用在大型資訊型網站，中央呈現主內容，左右兩側顯示輔助資訊。典型的例子有新聞網站的內容與推薦並列頁、大型內容平台、後台管理介面、論壇與教育平台等內容密集網站，以及儀表板（Dashboard）類型的頁面。

網頁設計仰賴的技術與工具

前面談的組成元素與版面安排，最終都要靠實際的技術與工具做出來，大致可以分成前端、後端、資料庫與設計開發工具四大類。

HTML、CSS 與 JavaScript 撐起前端畫面

使用者在螢幕上直接看到的畫面與互動，都靠前端技術呈現。目前所有網站都少不了三項核心技術：HTML 負責建立頁面的基本結構，CSS 負責控制樣式與版面呈現，JavaScript 負責提供互動效果與前端邏輯。無論是企業網站、電商還是平台型網站，都以這三項技術為主體。

後端語言與資料庫，讓功能和資料真正運作

前面提到的表單處理、登入驗證、內容管理這些後端邏輯，要靠後端語言寫出來，常見的有 PHP、Node.js（JavaScript）、Python（Flask、Django）與 C#（ASP.NET）。不同語言適用的系統架構不同，但目的都是支撐功能與資料處理。目前一般網站最常見的仍是 PHP，Node.js 與 Python 在 API 與後台系統中成長快速，C#（ASP.NET）則常見於政府與大型企業內部系統。

網站的文章、產品資訊、設定與會員資料，都需要儲存在資料庫裡才能持續讀取與更新。常見的資料庫有 MySQL、MariaDB、PostgreSQL 與 MongoDB，其中 MySQL 與 MariaDB 仍是一般網站最常使用的資料庫。

靜態網頁與動態網頁的內容產生方式

網站的頁面有兩種產生方式。靜態網頁是事先做好的 HTML 檔案，訪客要看時，伺服器直接把檔案送出去，每個人拿到的內容都一樣。它不需要資料庫與後台，伺服器負擔低、速度快，需要防守的環節也比較少，但改內容得直接修改檔案，頁面一多就很難管理。

動態網頁則是在訪客提出請求時，由伺服器端的程式從資料庫取出資料，套進 HTML 範本，現場組出頁面。內容存在資料庫裡，後台改完文字或商品，前台就跟著更新，會員登入、購物車、依使用者顯示不同內容這類功能，也都靠這種方式運作。WordPress 這類 CMS 以 PHP 搭配 MySQL 或 MariaDB 資料庫運作，電商與會員系統多半也是動態網站。代價是每次請求都要運算與查詢，主機資源與維護的負擔比靜態網站重。

現在主流的做法是動態系統加上快取與 CDN。快取把組好的頁面暫存起來，下一位訪客來時直接送出現成的頁面，不必每次重新查資料庫；CDN 則把內容的副本放在世界各地的伺服器，由離訪客最近的一台回應，高流量時也比較不受影響。這樣一來，後台維護起來像動態網站一樣方便，訪客看到的速度又接近靜態網頁，兩邊的優點都拿得到。

從 Figma 介面稿到 VS Code 的設計開發工具

視覺與介面規劃通常靠 Figma 完成，它目前是 UI/UX 領域最普及的工具；Photoshop 與 Illustrator 則用來處理圖片與視覺素材。開發階段最普遍使用的程式編輯器是 Visual Studio Code（VS Code），因為彈性高、擴充性強；其他常見的專業工具還有 WebStorm（前端與 JavaScript 常用）、PhpStorm（適合 PHP 開發）與 Visual Studio（用於 C#、.NET 系統）。

AI 開始滲入網頁設計的每個環節

這幾年 AI 的進展比多數人想像的快，影響最明顯的是設計開發與建站這兩端。

在設計與開發端，程式編輯器內建的 AI 功能已經不只是自動補全。除了依描述產生程式片段，現在還多了「代理模式」（agent mode），AI 能自己讀懂整個專案的程式碼架構，一次改動多個檔案，甚至自主執行測試指令、依結果反覆修正。工程師的角色也從逐行寫程式，轉為審核與調整 AI 產出的結果。

在建站端，不少無程式碼平台已經把「用一句話描述需求，AI 直接生成整個網站雛形」做成內建功能，而且愈做愈完整，不只產出單一頁面的模板，還能一次生成包含多個頁面、版面、配色與初步文案的網站草稿，新手連挑模板的步驟都能省略。

不過 AI 做出來的網站，通常還需要人工把關三件事。第一是品牌一致性，AI 生成的版型與文案多半還帶著範本感，需要重新調整用色、字體與文案語氣，才貼近自己的品牌調性；第二是 SEO 與內容深度，AI 生成的文字容易流於空泛，缺乏真正的產業知識與細節；第三是資安與資料掌控權，使用免費或 AI 平台時，網站的資料仍然掌握在平台手上，不是完全屬於自己。AI 能幫新手快速跨出第一步，但生成出來的版本比較接近初稿，還不是可以直接上線的成品。

架設網站的三種常見方式

了解技術與工具之後，接下來要決定網站由誰來做、用什麼方式做。第一次架設網站，多半會在三種主要方式之間選擇：免費／無程式碼架站平台、自行架設內容管理系統（CMS），以及委託專業網頁設計公司或自由設計師。三種方式在成本、彈性與技術門檻上都不一樣，適合的族群也各有差異。

免費與無程式碼架站平台，可搭配 AI 生成網站草稿

免費架站平台以預設模板搭配拖曳式介面操作，不需要程式背景，常見的有 Wix、Google Sites 這類服務，想先用免費方案架設網站的新手，多半從這類平台最容易上手。想開網路商店的人常用的 Shopify 也屬於這一類，它是月租制的代管平台，主機已經包含在訂閱方案裡，不需要自己買主機或架設。

優點：

• 操作簡單，不需要技術背景即可製作頁面
• 建置速度快，幾小時內就能完成網站雛形
• 主機、備份與 SSL 由平台管理，不需要自己設定
• 初期成本低，多數平台提供免費方案或月租制

缺點：

• 客製化有限，版型與功能受平台規範影響
• 功能擴充通常需要額外付費
• SEO、速度與效能多半不如自行架設的系統
• 資料移轉不容易，未來換平台成本較高
• 模板使用者多，網站風格容易重複

前面提到的 AI 生成網站功能，在這類平台上最常用到，輸入一段需求描述，幾分鐘內就能拿到一份含多個頁面的網站草稿。門檻雖然比過去更低，文案與品牌細節還是要自己再調整一輪，不要照單全收。

這類平台比較適合個人作品集、小型活動網站，或是想先把內容展示出來、預算有限、沒有技術背景又希望快速上線的人。

自行架設 CMS，網站與資料握在自己手上

自行架設 CMS 是很常見的做法，其中又以 WordPress 架站最普遍，其他還有 Joomla、Drupal、Ghost。自己架設網站的好處是彈性高，網站架構與資料都能完整掌握在自己手上。

優點：

• 版面與功能自由度高，可依需求調整
• 能透過模組擴充電商、預約、會員、多語系等功能
• 主機與資料自主管理，不受平台綁定
• 對 SEO 友善，能建立完整的內容架構
• 成本彈性也高，使用免費資源並自行維護時，主機加網域一年大約 5,000 元到 6,000 元就能運作

缺點：

• 需要具備主機管理、備份與安全性的基本技術
• 外掛與版型更新可能出現相容性問題
• 流量增加時需要做效能最佳化，例如快取與 CDN
• 程式、安全與維護事項都要自己負責

自行架設 CMS 比較適合想長期經營品牌或內容的人、中小企業網站、對 SEO 或功能擴充有需求，以及不想被平台綁定的使用者。

委託專業網頁設計公司或自由設計師

交給專業設計團隊打造網站，能走完從規劃到上線的完整流程。

優點：

• 提供從架構、視覺、前端、後端到 SEO 基礎設定的完整規劃
• 視覺風格可依品牌量身打造，整體品質一致
• 能開發客製功能，例如 API 串接、預約系統、會員中心
• 遇到問題有專業團隊協助排查
• 在效能、安全性與 RWD 方面通常也更完整

缺點：

• 網頁設計費用較高，通常落在 30,000 元到 200,000 元以上
• 製作需要經過規劃、設計、討論與測試，時間較長
• 需要提供品牌素材、文案與圖片才能推進製作

委託製作比較適合中小企業與品牌形象官網、需要呈現品牌形象或有明確視覺風格需求的個人與企業、需要客製功能、系統整合或完整規劃的案子，以及希望省時省力、不想自己維護網站的人。

三種架站方式的優缺點對照表

架站方式	優點	缺點	適合對象
免費/無程式碼平台	快速、簡單、初期成本低	客製化有限、功能受限、SEO 較弱	個人、學生、小型展示網站
自行架設 CMS	高彈性、可擴充、完整掌握資料、SEO 友善	需要自行處理主機、更新、安全等技術門檻	個人品牌、中小企業、長期經營者
專業設計公司/自由設計師	品質穩定、可客製化、品牌一致性高	費用較高、製作週期較長	中小企業、品牌官網、高階需求

網站架設費用的五個組成項目

決定好架站方式之後，接下來最實際的問題就是要花多少錢。網站的費用通常由五個項目組成：網頁設計及功能擴充、主機費用、網域費用、SSL，以及維護費用。架站方式不同，加上網站內容多寡與功能複雜度，都會讓費用出現落差。網域和主機常有首年優惠，估算架設網站的長期費用時，這兩項要看續約價，不要只看第一年的價格。

使用免費架站平台的第一年與次年費用

就算是主打免費網站架設的平台，第一年費用也大約落在 500 元到 18,000 元之間：網頁設計及功能擴充 0 到 5,000 元，主機費用通常已包含在平台方案中（每月 0 到 1,000 元，一年大約 0 到 12,000 元），網域費用 500 到 1,200 元，SSL 多半免費，維護費用則是 0 元。

次年（後續每年）不再有網頁設計的開辦支出，主要剩下平台方案與網域的年費，大約落在 500 元到 13,000 元之間；之後若要加購功能或版型，再依需求另計。像 Shopify 這類月租制平台，月費依訂閱方案而定，實際金額要以平台公布的方案為準，可能高於這個區間。

自行架設 CMS 的第一年與次年費用

第一年費用大約落在 5,000 元到 30,000 元以上：網頁設計及功能擴充 0 到 10,000 元，主機費用 4,500 到 12,000 元，網域費用 500 到 1,200 元，SSL 可用 Let’s Encrypt 或 Cloudflare 等方式免費取得，維護費用則落在 0 到 10,000 元。若使用免費資源並自行維護，第一年費用可壓在 5,000 元到 6,000 元左右。

次年（後續每年）費用大約落在 5,000 元到 22,000 元以上，各項目區間與第一年相近；若全部使用免費資源自行維護，每年約 5,000 元到 6,000 元就能維持運作。

委託專業設計公司製作的第一年與次年費用

第一年費用大約落在 35,000 元到 230,000 元以上：網頁設計及功能擴充 30,000 元到 200,000 元以上，主機費用 4,500 到 12,000 元，網域費用 500 到 1,200 元，SSL 通常免費或由設計公司提供，維護費用則依需求議定，落在 0 到 20,000 元。

次年（後續每年）費用，主機、網域與 SSL 的區間與第一年相近，網頁設計及功能擴充則依實際需求另計，維護費用同樣依需求議定。

同樣是網頁設計費用，各家報價之間的落差，多半來自包含的範圍不同。資訊架構與流程規劃、系統整合、效能與 SEO 基本設定，以及上線後的保固與維護有沒有算在內，都會讓報價拉開不小的距離。所以比報價時要看的是包含哪些項目、交付到什麼程度、哪些另計，而不是只比總價。

三種架站方式的費用對照表

費用項目	免費架站平台	自行架設 CMS	專業網頁設計
第一年網頁設計及功能擴充	0～5,000 元	0～10,000 元	30,000～200,000+ 元
主機費用（年）	0～12,000 元（含在平台方案）	4,500～12,000 元	4,500～12,000 元
網域費用（年）	500～1,200 元	500～1,200 元	500～1,200 元
SSL	免費	免費（Let’s Encrypt/Cloudflare）	免費或由設計公司提供
維護費用（年）	0 元	0～10,000 元	0～20,000 元（依需求議定）
第一年總費用	約 500～18,000 元	5,000～30,000+ 元	35,000～230,000+ 元
次年（後續每年）總費用	約 500～13,000 元	5,000～22,000+ 元	5,000 元以上（依需求另計）

網站製作時程依架站方式而不同

預算有了譜，新手接下來最常問的，就是網站製作要花多久才能上線。時間長短會受架站方式、內容準備度、功能複雜度與操作熟悉度影響，沒有單一答案，但每種架站方式都有大致的區間可以參考。

從數小時到數個月的製作時間區間

架站方式	製作時間	主要原因
免費/無程式碼平台	數小時至數天	模板與拖曳式介面為主，流程最精簡，素材齊全甚至一天內可完成
自行架設 CMS	1～6 週	套版主題約 1～2 週，需要調整佈景主題、外掛設定或客製功能則可能拉長到 4～6 週以上
專業設計公司/自由設計師	1～3 個月	完整流程含企劃、視覺設計、前端切版、後端開發與測試，複雜或多語系網站可能超過 3 個月

拉長或縮短製作時間的關鍵因素

製作時間長短，主要取決於幾個變數：

• 內容確認與回覆速度
• 文案、圖片等素材是否準備齊全
• 視覺設計或版面調整的複雜度
• 是否需要客製化功能或 API 串接
• 頁面數量多寡
• 是否需要 RWD 客製調整
• 是否包含電商、會員系統、多語系等進階功能

素材準備得愈完整、回覆確認得愈快，整體製作時間通常就愈短。

動工前要準備好的核心素材

決定好架站方式、抓好預算與時間之後，真正動工前要先把核心素材備齊。素材到位，製作才推得快，反覆修改的次數也會少很多。

從品牌識別到網站架構的七類必備素材

開始製作前，建議先準備好以下七類素材：

• 品牌識別素材：Logo（準備標準版，以及適用淺色、深色背景的變體）、明確的主色與輔助色系，以及指定的內文與標題字型
• 公司或個人介紹：品牌故事與核心理念，能強化訪客信任感，也有助於後續的內容佈局
• 服務或產品說明：清楚描述流程、特色與優勢，幫助訪客理解並提升轉換意願
• 高品質視覺素材：產品照片、作品集、團隊或環境照，建議統一風格與畫質以維持一致性
• 案例或作品集：服務型網站建議準備一到兩個代表性案例，說明需求、執行過程與成果
• 行動引導（CTA）設定：明確規劃希望訪客採取的動作，例如聯絡預約、加入社群、訂閱或購買
• 網站架構（Sitemap）草案：列出所需頁面，例如首頁、關於、服務、案例、部落格與聯絡等

讓準備工作更有效率的實務建議

• 內容完整性是關鍵：內容準備不足是專案延遲最常見的原因，建議及早開始彙整與撰寫
• 重視素材質感：高品質圖片與清晰文案，通常比複雜動畫更能塑造專業印象
• 明確設定行動目標：提前決定主要的轉換動線，能避免後期反覆調整結構
• 建立有序的檔案夾：依品牌識別、圖片、文案、案例等分類整理素材，提升交付與溝通效率
• 提供參考網站範例：提供二到三個風格或功能參考的網站，有助於快速對齊設計期望
• 兼顧 SEO 與擴充性：初步規劃內容分類與標題結構，方便後續的內容擴充與搜尋引擎優化

網站從概念到上線的製作流程

素材備齊之後，就進入實際製作。不管選的是哪一種架站方式，網站從概念變成能上線運作的成品，大致都會經過幾個階段；自行架設或委託設計公司時流程最完整，選擇免費平台則會省略其中幾個步驟。

規劃與資訊整理，先確定網站目的與內容架構

開始製作之前，要先確認網站的目的、目標族群、核心內容與預計呈現的功能，同時整理網站架構（Sitemap）、重要頁面列表與風格方向。這一步規劃得愈清楚，後續流程愈不容易走回頭路。

導覽列與頁面的排列，照訪客找答案的先後順序來安排會比較順暢：先讓人知道你是誰，再說明能做什麼、做過什麼、怎麼合作，最後才是怎麼聯絡。頁面內部也是同樣的邏輯，先回答訪客的疑慮，再給證據，最後才放行動按鈕。

視覺設計，決定網站的第一印象

這個階段依據前一步的規劃完成整體視覺設計，包括色彩設定、字體選擇、排版方式與圖片風格。視覺設計決定訪客對網站的第一印象，也是品牌呈現的重要環節。

前端製作，把設計稿變成能瀏覽的網頁

前端製作用 HTML、CSS 與 JavaScript，把視覺設計稿實作成真正能瀏覽的網頁，包含版面、互動效果與 RWD 跨裝置布局，確保網站在不同裝置上都維持良好體驗。

後端開發，讓網站的功能真正運作

後端開發要實作網站需要的動態功能，例如資料處理、後台管理、使用者登入、預約系統、表單驗證與金流串接。這是讓網站真正能處理資料、執行功能的關鍵一步。

上線，正式啟用主機、網域與 SSL

完成製作與測試後，最後一步是設定主機、綁定網域並啟用 SSL，讓網站正式對外公開。主機要先設定好正式環境，網域的 DNS 記錄要指向正確的主機位置，SSL 憑證安裝完成後，網址才能用 https 開頭安全連線。這幾件事都到位，正式環境放的也是製作完成的最終版本、不是測試用的暫存內容，網站才算正式上線。這些設定完成之後，先用正式網址把整個網站逐項驗收一遍，確認沒問題再正式公開。

上線前要自己逐項確認的驗收項目

網站做完，正式上線前還有一關不能省，就是自己逐項確認過一次，而不是聽到一句「我們測過了」就簽收。用不同裝置實際打開來看、檢查正式網址的 HTTPS 與測試殘留、拿數據複驗速度、把關鍵功能操作過一輪、確認基本 SEO 設定到位，最後再確認後台帳號與其他網站資產的歸屬，這幾件事做完，才算真正驗收。

跨裝置實際開啟畫面，不只是看設計稿

正式簽收前，找一支手機、一台平板，加上桌機瀏覽器，把網站從頭到尾實際打開來看一次，不要只看設計稿，也不要只聽對方說「這個有做 RWD」。重點檢查排版有沒有跑掉、字會不會小到看不清楚、按鈕在手機上點不點得到、表單欄位好不好填、圖片會不會被裁到看不出重點。

多測幾種瀏覽器與作業系統的組合也有幫助，因為 Safari 跟 Chrome 對某些 CSS 屬性的支援程度不完全一樣，在其中一個瀏覽器看起來正常，換到另一個未必如此。自己手邊的裝置有限時，找家人或同事的手機借測幾分鐘，也比完全沒測過好。

用無痕視窗檢查正式網址的 HTTPS 與測試殘留

製作階段多半是用內部測試網址檢查，正式網址上的小細節很容易漏看，等到真正上線後才被訪客發現。所以切到正式網址之後，要再從外部訪客的視角檢查一次。

先確認全站都強制使用 HTTPS，訪客輸入 http 開頭的網址時，會自動轉址到 https 版本。接著檢查混合內容（mixed content），也就是頁面本身是 https，裡面的圖片、字型或外部腳本卻還用 http 載入。這種情況下，瀏覽器可能把那些資源擋掉，造成缺圖或功能失效，網址列也可能顯示頁面不安全的提示。

再用瀏覽器的無痕視窗開啟正式網址，確認沒有殘留測試用的浮水印、佔位圖片或「建置中」提示。也建議搜尋一下網站名稱，看看主機商或架站平台預設的歡迎頁面，是不是還留在某個網址底下沒清掉。

用 PageSpeed Insights 複驗核心網頁指標

把正式網址貼進 PageSpeed Insights，先看實驗室數據裡的 LCP 與 CLS 有沒有過門檻，而不是憑感覺認定「網站看起來速度還可以」。工具會直接標出問題出在哪一項指標，比自己用眼睛猜準確得多。

不過，這些門檻是理想狀態。圖片多、動態效果豐富，或是功能需要載入較多程式的網站，受限於內容本身，不一定每一項都能達標。Google 把 LCP 介於 2.5 秒到 4 秒的頁面歸為「需要改善」，還不算「不佳」，所以實務上至少要守住一條底線：首屏，也就是打開網頁不用往下捲就看到的第一個畫面，要在 3 秒內出現，免得訪客還沒看到內容就先離開。

INP 的情況不一樣，它要靠真實訪客實際點擊、輸入的紀錄才量得到，新網站上線前還沒有這些資料，所以上線前改看 Total Blocking Time（TBT，總阻塞時間）這項實驗室指標當參考。TBT 能反映頁面被程式佔用、沒辦法回應操作的時間，是 INP 在實驗室裡的替代指標，但不能完全取代 INP。真正的 INP 與真實使用者的體驗，要等上線後累積足夠的使用者資料，再回到 PageSpeed Insights 的真實使用者資料區，或 Search Console 的核心網頁指標報表查看。

問題在上線前找出來，趁大量訪客還沒看到時處理掉，成本最低。實驗室數據盡量過關，至少確認首屏能在 3 秒內出現，再讓網站正式公開；三項指標的長期追蹤，則留到上線後持續進行。

表單、金流與會員登入的功能測試

網站上有表單、金流或會員系統，上線前都要真的操作過一輪，而不是只看畫面有沒有跑版。填一次聯絡表單，確認後台或信箱真的收到通知信；金流串接要完成一筆真實的小額付款測試，確認金額對得上、付款成功後訂單狀態也正確更新；會員系統要實際註冊一組帳號、登入登出，確認驗證信與忘記密碼流程都能用。

表單的通知信要用 Gmail、Outlook、公司信箱等不同的信箱各測一次，也要看垃圾信匣，因為同一封信在不同信箱的收件結果可能不一樣。另外要確認送出的內容在後台也留有一份，寄信失敗時，才找得回訪客留下的資料。

順手把網站上所有的按鈕與連結都點過一輪，特別是頁尾、選單裡平常不太會去點的連結，確認導向的都是對的頁面，沒有連到還在製作中的暫存網址，或是連結整個是空的。手機上的電話與 LINE 等聯絡按鈕也要實際點過：電話連結在行動裝置上會直接撥號，要確認撥出去的是正確的號碼；LINE 按鈕則要確認會開啟對應的帳號。網址打錯或頁面被移除時，訪客會看到 404 頁，這一頁也要有回首頁或主要入口的連結，讓訪客不至於停在死路。

基本 SEO 設定與內容校對

上線前也該把基本 SEO 設定檢查一遍：每個頁面的 Title 與 Meta Description 有沒有分別設好、標題階層（H1、H2）用得對不對、Sitemap 有沒有提交到 Search Console 讓搜尋引擎知道網站有哪些頁面。這幾件事上線後才補做也可以，但愈早設好，搜尋引擎開始收錄的時間點就愈早。

新站上線時還有兩個容易忘記的設定，一是 robots.txt 有沒有擋住全站，二是製作階段為了避免測試內容被收錄而加上的 noindex（不索引）設定有沒有拿掉。noindex 沒拿掉，頁面會被搜尋結果排除；robots.txt 若擋住爬蟲，搜尋引擎也看不到頁面內容。

同時也該把內容再校對一次，包括圖片有沒有加上替代文字（alt）、文案有沒有錯字或格式跑掉，以及隱私權政策這類法規要求的頁面是不是已經真的上線，而不是還停在草稿階段。這幾項看起來瑣碎，但都是訪客與搜尋引擎第一次接觸網站時就會碰到的東西。

網站的五項資產，先確認各自的歸屬

網站上線了，不代表每一樣東西都已經在自己手上。網域註冊人是誰、主機控制台誰能登入、當初的設計稿與程式源碼有沒有拿到、CMS 後台開到哪一個權限等級、SSL 憑證掛在誰的帳號底下，這五件事決定了網站能不能真正由自己作主，最好在動工前問清楚、驗收時再確認一次。

東西掛在設計公司名下，並不代表哪裡有問題。實務上很多長期配合的案子，網域、主機都是由設計公司集中管理，出狀況時對方能立刻處置，不必等人找帳號密碼，運作起來反而更單純。真正重要的是兩件事，一是知道現在這些東西掛在誰的名下，二是在合作之初就把這些問題問清楚，而不是等到有一天想換人維護，才發現自己什麼都拿不到。

用 WHOIS 查詢網域的註冊人

要查自己的網域目前登記在誰名下，可以用 WHOIS 查詢。搜尋「WHOIS 查詢」就能找到免費的查詢工具，輸入網域名稱後，畫面上「Registrant（註冊人）」欄位寫的就是目前登記的對象。不過依 ICANN 的註冊資料政策，.com 這類網域的註冊人姓名在公開查詢結果裡通常會被遮蔽，顯示成「REDACTED」之類的字樣；查不到時，可以登入網域註冊商的帳號查看，或請代辦的設計公司提供網域的註冊資料畫面確認。

查到的結果通常是兩種情況，而且都合理。登記在自己名下，主導權最清楚，往後不管要換主機、調整 DNS 設定或轉移到別的服務商，都不需要經過誰同意；由設計公司代辦、掛在對方名下，好處是續約、DNS 調整這類事情對方可以直接處理，不必每次來回索取帳號密碼，長期配合下來反而省事。

真正要問清楚的是，之後如果想把註冊人改到自己名下，流程怎麼走、需要多久、要不要另外收費。這個問題在簽約前問一次，比事後才問清楚容易得多。

主機控制台的管理權限與轉移流程

主機或雲端服務的控制台權限也是同樣的道理。委託代管時，帳號握在設計公司或代管服務商手上很常見，也確實比較好維護，主機出狀況需要重開服務、還原備份時，對方能立刻動手處理，不必先等誰授權。

要問清楚的是，真的需要的時候，自己能不能拿到一組具備管理權限的帳號，以及未來如果想把主機轉移到別的服務商，流程怎麼走、費用怎麼計算。這個問題平常很少有人想到，真正想起來的時候，往往已經是緊急狀況，例如原本配合的對象突然聯繫不上，那時才問就太晚了。

原始設計稿與程式源碼，不是每種方案都會交付

有些網頁設計方案本來就不會交付程式源碼。做出來的是一個可以正常使用、也能自己改內容的成品網站，但拿不到最底層的程式碼本身，套用固定版型或訂閱制的服務尤其常見，這是方案本身的設計，不是刻意藏著不給。

視覺設計稿的原始檔也是同一回事，像 Figma、PSD 或 AI 這類原始檔案，有的方案本來就含在報價裡，有的則要另外計費才會交付。

這件事最好在簽約前就問清楚，不要等到專案結束才發現拿不到。可以直接問對方，這個方案含不含程式源碼與設計原始檔，需要的話要不要另外報價。未來如果想換人維護，或是想在既有基礎上做二次開發，這個答案會直接影響能不能順利接手。

CMS 後台帳號的權限等級，決定自己能動的範圍

用 WordPress 這類 CMS 架設網站時，後台帳號的權限等級決定了自己能動的範圍有多大。最高等級（WordPress 稱為 Administrator，管理員）可以安裝外掛、調整系統設定，幾乎所有東西都能動；等級較低的編輯者帳號，通常只能修改文章與頁面內容，碰不到後台的系統設定。

兩種安排各有各的道理。只開放編輯者權限，好處是不會有人誤觸設定選項把網站弄壞，長期配合維護的案子這樣分工其實很常見，也算是一種保護機制。代價是之後想自己調整版面設定或安裝新外掛時會處處受限，每次都得回頭請製作方幫忙。

驗收清單裡常被漏掉的一條，就是後台管理員帳號拿到了沒有、自己拿到的是哪一個等級，以及日後如果需要更高權限，能不能申請調整。

SSL 憑證的歸屬帳號，續約通知才不會漏接

SSL 憑證需要定期續約，多數主機或服務商現在都會自動處理，不太需要自己動手。但憑證終究掛在某一個帳號底下，到期提醒信也只會寄到某一個信箱。如果那個帳號跟自己完全沒有連結，一旦真的漏掉續約，往往要等到瀏覽器跳出「不安全」的警告、訪客都看到了，才知道出事。

要確認的事情很簡單，問一句「SSL 續約是誰負責、會不會自動續」，通常答案就夠清楚了，不需要因為這件事另外準備一整套監控機制。

網站上線後的七項維護工作

上線並不是專案的終點，而是維護階段的起點。驗收是在上線前確認一次，維護則是上線之後要一直做下去的事；有系統地進行，網站才能維持穩定、安全、運作順暢，訪客的使用體驗也才不會走下坡。

維護可以抓一個節奏：每週確認網站運作正常、備份有成功執行；每月做一次更新，順便清掉用不到的外掛、盤點帳號權限；每季回頭檢視網站結構與內容。不過安全性更新不要等到月底，發布後要儘快套用。如果維護委託給設計公司或代管服務，要先確認代管包含哪些項目，以及網站出現異常時，多久內會有人處理。

定期確認主機與網域的合約和續約

主機與網域是網站運作的根基，合約與續約要定期管理（網域通常按年續約，主機則依方案而定），避免因為漏繳費用導致服務中斷，讓訪客連不上網站。

監控網站的可訪問性與回應速度

建立即時監測機制，持續檢查網站的可訪問性、回應速度與穩定狀態。一旦發生異常中斷或效能嚴重延遲，就能第一時間發現、快速排錯，把網站的正常運作時間拉到最高。

程式與安全更新，修補漏洞並強化防護

核心架構、外掛或模組要定期更新到最新穩定版本，主要目的是修補安全漏洞、強化系統防護，同時確保功能相容。更新前務必先完整備份，避免更新後出現相容性問題影響網站運作。

登入入口也要一併保護：管理員帳號不要多人共用，也不要用 admin 這類好猜的名稱，密碼要又長又獨特，並為管理員帳號開啟雙重驗證，再限制登入嘗試的次數，降低被猜出密碼的機會。

定期備份與災難復原，網站安全的最後防線

資料庫、程式碼與媒體檔案都要完整備份，並訂出明確的備份頻率，例如每日或每週一次。遇到人為誤刪、主機故障或資安攻擊時，才能依靠備份快速恢復服務，把損失降到最低。

備份要實際演練還原過才算數，並確認資料庫與檔案都能完整復原。只存了檔案、從沒還原過，出事時才發現救不回來，備份就失去了意義。

表單與金流等關鍵功能的定期複測

表單提交、會員登入、購物車與金流串接等關鍵互動功能，都需要定期做端對端測試。外部服務更新或程式異動都可能讓功能悄悄壞掉，例行測試能確保核心流程一直順暢。

定期更新內容，SEO 設定也跟著調整

定期檢視並更新產品資訊、部落格文章與聯絡資料等內容，維持資訊的正確性與時效性。持續提供有價值的內容，也有助於提升使用者參與度與搜尋引擎的收錄表現。

內容更新時，也該檢視 Title、Meta Description 與標題結構（H1、H2）這些基本 SEO 元素有沒有跟著同步調整，維持網站的能見度與使用者體驗。

效能與 Core Web Vitals，定期用數據複查

定期用 PageSpeed Insights 或 Search Console 的網站速度報告，複查 LCP、INP、CLS 這三項核心網頁指標，而不是單憑感覺判斷網站好像變慢了。網站的資料量會增長、內容也會持續改動，效能跟著起伏是常態，所以這幾項數據要拉長時間持續追蹤，而不是驗收時過關一次就放著不管。

可以替網站訂一份效能預算，為影響速度的項目設上限，例如圖片總容量、字型數量，以及追蹤碼、聊天工具這類第三方腳本的數量。之後每加一個新功能，都先問值不值得用載入時間去換。分數只是參考，目的是讓訪客用起來順暢，不必為了追高分砍掉必要的功能。

網站變慢時，也可以先做初步判斷。後台操作也一樣緩慢、尖峰時段特別慢，可以先從主機資源夠不夠用查起；只有部分頁面慢，就先查那幾頁的圖片、字型與第三方腳本。

網站改版和搬遷，避免流量與排名一併流失

網站用了幾年之後，常會遇到需要改版、換主機，或整個換一套 CMS 的時候。這件事本身沒有問題，真正容易出錯的是新舊網址的對應。如果沒處理好，原本累積好幾年的搜尋排名，跟其他網站連過來的外部連結權重，可能在改版上線那天就直接歸零重來。

網址結構打掉重練，舊排名與外部連結權重等於歸零

改版最常見的雷，是趁機把網址結構整個重新設計。例如原本的服務頁網址是 /service/logo，改版時為了讓架構更清楚，換成 /products/logo-design。這種調整看起來只是讓網址變漂亮，但如果沒有做好新舊網址的對應，Google 會把新網址當成一個從沒看過的全新頁面。過去這一頁累積的排名，還有其他網站連過來的外部連結權重，都不會自動跟著搬過去，等於歸零重新評估。這件事不是只有整個網站搬家才會遇到，改版時只調整某個分類的網址結構，一樣算在內。

網址結構要不要調整，是設計上的合理考量，不是不能改，只是改的時候要有配套，而不是直接把舊網址關掉、換上新的就結束。

301 永久轉址與新舊網址對應表

配套做法是設定 301（或 308）永久轉址，這是 Google 官方建議的處理方式，而且轉址本身不會造成 PageRank（網頁排名權重）流失，舊網址的權重會透過轉址傳遞到新網址。

重點是要做一份「一對一」的新舊網址對應表，舊的服務頁轉到新的服務頁、舊的文章頁轉到新的文章頁，一筆對一筆。盤點舊網址可以從網站地圖、伺服器紀錄與 Search Console 的外部連結報表下手；頁面少就逐筆核對，頁面多則先照規則批次處理，再抽樣確認轉址內容對不對。

把所有舊網址通通轉到新首頁，是改版時最容易出現的偷懶做法，等於把原本頁面累積的排名與外部連結權重一起丟掉。Google 官方文件明確提到，不建議把大量舊網址轉址到一個不相關的單一目的地，例如首頁，這樣做可能讓使用者感到困惑，也可能被視為軟性 404 處理；唯一合理的情境，是原本分散在好幾個頁面的內容真的合併成一個頁面。

轉址還分永久與暫時兩種。301（或 308）是永久轉址，Google 會把新網址當成正式版本看待，適合固定搬過去、不會再改回來的情況；302（或 307）是暫時轉址，Google 不會把它當成新網址才是正式版本的訊號，原網址可能繼續留在搜尋結果裡，適合暫時性移動、之後還會改回來的情況。網站改版屬於永久性搬遷，原則上都該用 301（或 308），誤用暫時轉址的話，Google 可能一直把舊網址當成正式版本。

Search Console 網站搬遷工具與上線後的觀察期

如果這次改版連網域都換了，可以在 Search Console 用「地址變更工具」通知 Google，加快確認新網址身分的速度。這個工具只適用於換網域或子網域，同網域內調整網址結構並不適用，把轉址設好、送出新版網站地圖就足夠。使用前要先在 Search Console 分別驗證舊、新網站兩個資源，且用同一個 Google 帳號管理。

上線之後也別急著鬆一口氣，建議持續觀察 Search Console 的索引涵蓋範圍與搜尋分析報表，確認新網址正常收錄、排名沒有異常掉幅。用地址變更工具搬遷時，流程會持續運作 180 天，轉址至少要維持這麼長時間；單純調整網址結構、沒用搬遷工具時，Google 官方建議轉址盡量保留久一點，至少一年，確保排名訊號完整傳輸過去。

換平台時，內嵌資源、驗證檔與多語系標記也要一併更新

換一個架站方式，例如從免費架站平台搬到自己架設的 CMS，會斷掉的不只是網頁本身的網址。頁面裡內嵌的圖片、影片、JavaScript 與 CSS 檔案也各自有自己的網址，同樣要列進盤點清單一併設定轉址，不然頁面轉過去了，圖檔或嵌入內容還是會壞掉。網站原本用來驗證身分的檔案跟驗證碼，也要在新平台重新設定一次。原本若有多語系版本，語言對應的標記（hreflang）也要跟著新網址更新，沒同步改的話，搜尋引擎可能會抓到語言版本彼此指錯網址的情況。

網站蒐集個資前，法規要求的告知義務

網站一旦開始蒐集訪客資料，個資與隱私權政策就成了一件容易被忽略、卻可能帶來麻煩的事。只要網站有聯絡表單、會員系統、電子報訂閱，或使用 Google Analytics 這類會蒐集使用者資料的工具，就已經算是在蒐集個人資料，不是只有電商或大公司才需要處理這件事。

個資法規定蒐集資料前要告知的六項事項

依《個人資料保護法》的規定，網站透過聯絡表單、會員註冊或電子報訂閱蒐集姓名、Email、電話等個人資料時，須告知當事人以下事項：蒐集者的名稱、蒐集目的、個人資料的類別、個人資料利用的期間地區對象與方式、當事人可以行使的權利，以及若拒絕提供資料會有什麼影響。

告知的方式也有講究，不能只在網站角落貼一則公告就算了事，而是要讓使用者在提供資料之前，就能明確知道這些內容。

隱私權政策與 Cookie 同意的準備要點

隱私權政策頁面通常要涵蓋幾項基本內容：蒐集哪些資料、用途是什麼、保存期限多久、是否使用 Cookie 或分析工具，以及使用者可以怎麼行使查詢或刪除資料的權利。

有一個實務細節新手很容易漏掉，就是不少廣告功能本身就要求網站有隱私權政策。Google Ads 的目標客戶比對（Customer Match）規定，隱私權政策要揭露會把客戶資料分享給第三方代為處理；Meta 的《商業工具使用條款》也要求，裝了 Meta 像素的網頁要用清楚的告示說明會透過 Cookie 等技術蒐集資料來投放廣告，以及訪客可以怎麼選擇退出。這類要求通常到開始投廣告才會碰到，建議在網站上線清單裡就把隱私權政策排進去，不要等到要下廣告才臨時補做。

台灣無障礙網頁規範，公部門與教育標案的硬門檻

除了個資與隱私權，另一項容易在動工前被忽略的法規門檻，是網站的無障礙規範。台灣自 2017 年 2 月正式實施「網站無障礙規範」，內容參酌 W3C 的 WCAG（網頁內容可及性規範），把網頁分成 A、AA、AAA 三個檢測等級。對一般商業網站來說，做到無障礙是加分項，讓視覺、聽覺或行動能力受限的訪客也能順利使用網站；但對公部門網站、學校、教育機構，或承接政府標案的網站，這通常不是加分，而是規格書上白紙黑字寫著的硬性門檻。

三個優先等級組合出四種無障礙標章

規範把檢測項目分成三個優先等級。第一優先等級是開發網頁必須滿足的最基本要求，共 29 條檢測基準，沒做到，身心障礙使用者可能完全無法取得網站上的部分資訊。第二優先等級是應該要滿足的等級，沒做到雖然不至於完全看不到內容，但會讓部分使用者遇到明顯困難。第三優先等級則是最高規格，多半屬於額外的加分項目，一般網站不強制要求做到。

容易被搞混的是，標章不是三種而是四種，因為它們是這三個優先等級的不同組合。A 標章對應第一優先等級的 29 條；AA 標章（雙 A）須同時符合第一與第二優先等級，共 68 條；AAA 標章（三 A）須符合三個優先等級，合計 90 條。夾在中間的是 A+ 標章，內容是第一優先等級的 29 條，再加上第二優先等級其中 5 條與第三優先等級其中 1 條，總計 35 條。

這個組合方式帶出一個反直覺的結果：通過 AA 不代表就符合 A+。A+ 裡面那 1 條來自第三優先等級的檢測碼，是網頁導盲磚（:::）搭配快速鍵的設計，而 AA 的範圍並不包含它。看標案規格書時要看清楚要求的是哪一種標章，別以為等級數字看起來比較高就一定涵蓋得住。

公部門與教育標案，幾乎把 AA 等級標章當門檻

政府機關網站、學校網站，或是承接政府標案的網站，規格書通常會直接要求取得 AA 等級無障礙網頁標章，並且接受定期與不定期稽核，沒有達標的話標章可能被取消，連帶影響案子能不能結案驗收。

如果知道自己的網站將來有機會承接這類案子，例如學校、公部門或政府補助的專案，這件事最好在網站規劃階段就排進去，而不是等標案來了才臨時補做。事後回頭調整既有的版面結構與程式碼，成本比一開始就規劃進去高出不少。

替代文字與色彩對比是最常被扣分的項目

實際檢測時，最常被扣分的幾個項目其實不難改善。圖片有沒有加上替代文字（alt），讓螢幕報讀軟體能唸出圖片內容；文字與背景的色彩對比夠不夠，太淺的字配上太淺的底色，一般人可能也要瞇眼才看得清楚；整個網站能不能只靠鍵盤完整操作，不依賴滑鼠點擊；表單的每個欄位是否都有對應的標籤（label），而不是只靠一個看起來像提示文字的灰色 placeholder。

這幾項檢查即使不是為了拿標章，套用在一般商業網站上也是好事。色彩對比不夠、表單填寫困難，本來就是會讓訪客提早放棄的常見問題，無障礙檢查等於是拿一套更嚴謹的標準，把這些細節一次抓出來。

AI 搜尋時代，SEO 之外多了 GEO

網站做出來之後，能不能被找到，決定了前面所有投入值不值得。這件事的基礎規則沒有變，但這幾年多了一個新變數，就是愈來愈多搜尋結果會先被 AI 摘要整理過一次，才顯示給使用者看。

SEO 仍是網站被搜尋引擎找到的基礎

SEO（搜尋引擎優化）決定網站能不能被 Google 等搜尋引擎找到，做法包括標題結構、關鍵字佈局、內容品質、Meta 設定與結構化資料規劃，是網站曝光與流量成長的基礎。SEO 沒有因為 AI 搜尋興起而過時，它仍是 GEO（生成式引擎優化）的前提，不是被取代的舊做法。

零點擊搜尋成長，GEO 成為新變數

愈來愈多問題會被 Google 的 AI 摘要功能或 ChatGPT 這類 AI 工具直接整理成答案，使用者不一定要點進網站才能得到解答，這種現象叫做零點擊搜尋（zero-click search）。Pew Research Center 在 2025 年的一項分析發現，搜尋結果出現 AI 摘要時，使用者點進傳統搜尋結果連結的比例只剩 8%，沒有 AI 摘要時則是 15%，幾乎少了一半。Similarweb 的另一份數據也顯示，Google 上新聞相關搜尋的零點擊占比，一年之內從 56% 成長到 69%。

對第一次做網站的人來說，這代表除了傳統 SEO，還要讓內容有機會被 AI 摘要或引用，這方面的優化稱為 GEO（生成式引擎優化，Generative Engine Optimization）。

Google 表示 GEO 沒有專屬的優化秘技

新手不需要為 GEO 另外學一套新技術。Google 官方本身的說明就指出，沒有專屬於 AI 的優化秘技，重點仍然是把內容寫得清楚、結構化、對使用者真正有幫助。Google 也明確說明，AI Overview 與 AI Mode 用的其實是跟一般搜尋一樣的排名系統，而不是另外一套獨立機制，只是多疊了兩層技術。一層是 RAG（檢索增強生成），從既有的搜尋索引裡抓出最新、最相關的網頁內容當依據；另一層是 query fan-out（查詢展開），把使用者原本的一句提問自動拆成好幾個相關的子查詢，各自去搜尋結果裡找答案，最後再整合成一段回應。換句話說，網站在一般搜尋排得上去，才有機會被這套機制抓到、引用進 AI 產生的答案裡。

段落結構清楚，才容易被 AI 摘要引用

同一份指引裡有幾個具體、可以直接照做的建議。內容要先為真人讀者寫，不是為了搜尋引擎湊字數；用清楚的標題階層與段落把內容組織好，讓 H2、H3 各自對應一個明確的子主題，邏輯順暢的內容本身就比較容易被 AI 系統抓到重點。

這份指引也特別提到一個容易被誤解的地方：不需要為了讓 AI 讀懂，刻意把內容拆成一小段一小段的碎片，那種做法反而沒有幫助，正常寫成完整、易讀的段落就好。真正有幫助的是寫出獨到的觀點，而不是重複別人已經講過的內容。AI 系統會同時分析很多頁面，找的是真正提供新資訊或新角度的內容，二手整理的內容很容易被忽略。

最後還有一個前提，是網站本身能不能被正常爬取與索引。內容寫得再好，只要網站的技術設定擋住了搜尋引擎的爬蟲，或是頁面根本沒有被收錄，前面談的這些 GEO 做法就都無從發生，所以 SEO 基礎一定要先做好。

第一次做網站，架站方式、費用與時程可以先照這些區間抓個大概，製作流程也有固定的階段可循，唯獨上線前的驗收一定要自己走過一遍。網頁設計的核心依然是視覺、內容、使用者體驗與技術的整合，只是現在多了幾層過去不太被提起的責任：內容能不能被 AI 讀懂並引用、資產有沒有真的握在自己手上、改版搬遷會不會讓多年累積的排名平白流失，以及上線之後願不願意把維護當成長期要做的事。網站做完之後撐不撐得久，往往就看這幾件事。

網頁設計的技術與工具會一直變，AI 生成網站雛形也只會愈來愈快、愈來愈普及，這件事不必抗拒，也不用神化。真正決定一個網站能走多遠的，終究是清楚的目的、扎實的架構，以及做完之後有沒有把它當成一項資產長期經營下去。