網站部署是把開發完成的程式、版型與設定搬到正式主機，讓網域指向它並開始對外服務的過程，包括上傳檔案、設定執行環境與資料庫、切換 DNS、啟用 SSL 憑證，以及出問題時退回前一版的準備。常見的部署方式有四種：用主機控制台上傳、用 SFTP 傳檔、從 Git 版本庫部署，以及把建置好的靜態檔案放到靜態託管服務。選哪一種，取決於網站有沒有後端程式、團隊是否使用版本控制，以及出錯時需要多快退回。上線當天除了程式本身，也要留意環境設定、DNS 與憑證的切換順序。
網站部署包含哪些工作
只把檔案上傳到主機，不等於完成部署。一次完整的部署通常涵蓋：
- 程式與檔案：網頁、樣式、腳本、圖片，以及後端程式與它依賴的套件。
- 環境設定：資料庫連線、金流與寄信服務的金鑰、網站網址等，正式站與測試站要分開。
- 資料庫：建立或更新資料表結構，必要時匯入初始資料。
- 網域與憑證：設定 DNS 紀錄指向新主機，啟用 HTTPS。
- 上線後的設定：排程工作、快取、錯誤紀錄與監控。
只有 HTML、CSS 與圖片的網頁部署，重點在檔案放對位置與快取更新；有會員、表單、後台的系統，程式部署還要處理執行環境、套件與資料庫，步驟多出不少。網站是靜態還是動態，可以先看靜態網頁和動態網站的差別。
四種常見的部署方式比較
| 方式 | 做法 | 適合 | 要注意 |
|---|---|---|---|
| 主機控制台上傳 | 在主機管理面板的檔案管理員上傳壓縮檔再解壓 | 小型網站、偶爾更新 | 沒有版本紀錄，覆蓋前要自己留一份舊版 |
| SFTP 傳檔 | 用檔案傳輸軟體把本機檔案同步到主機 | 形象網站、傳統虛擬主機 | 確認主機提供 SFTP，漏傳或多傳檔案不易察覺 |
| Git 部署 | 把版本庫的指定版本拉到主機，或由自動化流程建置後部署 | 多人開發、經常更新的系統 | 版本庫不放密碼與金鑰，公開目錄不含版本控制資料 |
| 靜態託管 | 把建置好的靜態檔案上傳到託管服務 | 形象官網、活動頁、文件站 | 沒有後端程式，表單要另外串接服務 |
想找免費部署網站的方式時，要知道部分靜態託管與雲端服務有免費額度，以 GitHub Pages 為例，官方說明它不是用來經營線上商業或電子商務網站的免費主機，可能套用頻率限制，也有使用配額，超過配額時可能無法提供服務。適合放作品集或專案文件，正式的企業官網仍要評估穩定性與支援。
程式部署要一起處理的設定與資料
後端程式的部署，比靜態檔案多出幾件事，順序錯了就可能讓網站上線即出錯：
- 先備份：部署前備份正式站的檔案與資料庫，WordPress 官方也建議升級前一定要先備份。
- 準備環境設定：OWASP 的機密管理指引提醒密碼、金鑰這類機密不要寫死在原始碼，並建議集中管理、以細部權限控制存取。
- 安裝相依套件：依鎖定的版本安裝，避免正式站裝到和測試站不同的版本。
- 更新資料庫結構：用事先在測試站演練過的步驟執行，確認舊資料能被新程式正確讀取。
- 清除快取並檢查排程：更新後清除程式與頁面快取，確認排程工作、寄信與金流通知仍正常。
這些步驟建議先在和正式站條件相近的環境跑過一次，測試站的建立與同步方式可參考網站測試環境的上線流程。
正式上線的步驟：DNS 與 SSL 切換
- 調低 TTL：解析程式會在 TTL 期間快取舊的答案。切換前先調低要修改紀錄的 TTL，並等原本的 TTL 到期；AWS 的 DNS 遷移文件也以調低 NS 紀錄 TTL 的方式，縮短出問題時無法連線的時間。
- 部署並測試新主機：在新主機完成部署，用暫時網址檢查頁面、表單與後台。
- 準備憑證：Let’s Encrypt 的 HTTP-01 驗證是由用戶端在網站伺服器放置驗證檔，網域還指向舊主機時，新主機用這種方式可能無法通過；需要事先取得憑證時，可以改用在 DNS 建立 TXT 紀錄的 DNS-01 驗證，官方也說明它適用於網站伺服器未對外公開的情況。
- 切換 DNS：修改 A 紀錄或 CNAME 指向新主機，各類紀錄的用途可參考DNS 紀錄的類型說明。
- 確認 HTTPS：檢查憑證、HTTP 轉 HTTPS 的轉址，以及頁面是否還有載入 HTTP 資源的混合內容。
- 檢查搜尋引擎設定：確認沒有把測試站的 noindex 或封鎖檢索的 robots.txt 帶到正式站，再提交 Sitemap。
舊主機不要在切換當天就停用，至少等 DNS 生效、確認新站穩定後再關閉，必要時才能把紀錄指回去。
依部署方式準備退回前一版
退回前一版的做法，要在部署之前就依方式準備好：
- Git 部署：每次上線替版本加上標籤，出問題時部署前一個標籤的版本。
- 控制台或 SFTP：上傳前保留完整的舊版檔案，退回時整包換回，而不是逐一挑檔案。
- 靜態託管：保留前一次的建置結果，重新部署即可。
- 雲端平台的預備位置：以 Azure App Service 為例，可以先部署到預備位置，確認後與正式位置交換，出問題時再交換回來。
- DNS 切換：舊主機保持運作，必要時把 DNS 紀錄改回原本的位址。
資料庫是退回時要小心的部分：新版程式已寫入的訂單、會員資料，不能直接用舊備份覆蓋，要先匯出再處理。回滾條件、權責與期間資料的補回，可搭配測試環境一文的回滾計畫一起規劃。
維護時段與暫停服務的處理
部署需要暫停服務時，選在訪客少的時段，並讓維護頁回應 503 狀態碼。依 MDN 的說明，503 表示伺服器尚未準備好處理請求，常見原因是維護或過載，可能的話用 Retry-After 標頭告知預估恢復時間。Google 搜尋中心也說明，用 503 暫停網站是極端手段，只應用在很短的時間，不宜超過幾天。
Google 也提醒，回傳 503 期間系統無法更新標題與說明；不要讓 robots.txt 回應 503，否則會阻擋所有檢索；也不要用 403、404 或 410 擋住網站，網址會從 Google 搜尋中移除。MDN 另提醒 503 回應通常不應被快取，以免修復後訪客仍看到錯誤頁。維護前先公告時段，結束後立刻檢查主要頁面與表單。
網站部署常見的錯誤
- 測試站的設定帶到正式站：資料庫連線、金流測試金鑰、noindex 沒有改回。
- 用測試站的資料庫覆蓋正式站，部署期間的新訂單與會員資料消失。
- 把版本控制資料夾、環境設定檔或備份檔放在公開目錄。
- DNS 切換後才發現憑證沒準備好，訪客看到憑證錯誤。
- 更新後沒有清除快取，訪客與檢索器仍看到舊版。
- 只測首頁，沒有測表單送出、會員登入與付款流程。
- 部署當天沒有人能操作退回，問題拖到隔天處理。
常見問題
網頁部署和程式部署差在哪？
網頁部署通常指 HTML、樣式與圖片這類靜態檔案的上線；程式部署還包括後端程式、相依套件、環境設定與資料庫更新，步驟較多，也更需要事先演練與退回準備。
FTP 和 SFTP 可以混用嗎？
建議只用 SFTP。MDN 提醒要確認主機提供 SFTP 連線，並說明 FTP 本質上不安全、不應使用；主機若仍開著 FTP，可以請主機商或管理者關閉。
DNS 切換後多久會生效？
取決於原本紀錄的 TTL 與各地 DNS 伺服器的快取，沒有固定時間。事先調低 TTL 能縮短等待，切換期間新舊主機都要保持運作。
部署一定要用 Git 嗎？
不一定。小型網站用主機控制台或 SFTP 也能部署，但要自己保留舊版檔案。多人開發或經常更新的系統，用 Git 管理版本較容易追查變更與退回。
部署完成後要檢查哪些項目？
檢查主要頁面、表單送出、會員登入與付款流程，確認 HTTPS 與轉址正常、沒有測試站的 noindex，並在 Search Console 用網址檢查確認 Google 能取得頁面。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
準備上線前，先確認網站採用哪種部署方式、DNS 與憑證由誰管理，以及出問題時怎麼退回。京采的網頁設計服務可以協助規劃部署流程與測試環境，安排 DNS 與 SSL 的切換順序，上線前逐項驗收表單、會員與金流，並在改版時備妥退回前一版的方式。想討論網站的上線計畫，歡迎與我們聯繫。
