網站上線檢查怎麼做？正式上線前功能、索引、安全與金流驗收清單

網站上線檢查要先判斷什麼？

網站上線檢查第一步不是看清單有沒有填完，而是判斷現在能不能正式上線。表單、金流、SEO 索引、安全憑證、DNS 或正式環境只要有紅燈問題，就應延後上線。

我會建議把網站驗收分成紅燈、黃燈、綠燈三種狀態。紅燈代表會直接造成商機流失、付款失敗、個資風險或搜尋引擎誤判；黃燈代表不影響核心交易，但要留下補修紀錄；綠燈才是可以簽核的狀態。

紅燈必須延後上線

紅燈項目不能靠「上線後再修」處理，因為它們通常會直接傷到營收、信任或搜尋能見度。

檢查項目	紅燈狀況	判斷
表單	詢價表單送不出去，或公司沒有收到通知信	延後上線
金流	信用卡付款、ATM、超商代碼或發票流程未完成正式測試	延後上線
SEO 索引	正式站仍保留 noindex，或 robots.txt 阻擋重要頁面	延後上線
HTTPS	SSL 憑證錯誤，或 HTTP 無法正確導到 HTTPS	延後上線
正式環境	金流、物流、CRM、Email 仍使用測試金鑰或測試收件人	延後上線

表單失效

企業網站最常見的上線事故不是畫面壞掉，而是客戶填了表單，公司卻沒有收到。每一種表單都要用真實收件流程測一次，包括詢價、預約、訂閱、會員註冊、客服聯絡。

金流測試

電商、課程、會員制網站不能只看購物車能不能按。付款成功、付款失敗、取消交易、訂單成立、發票或通知信，都要在正式環境確認。

robots noindex

改版站很常在測試期間加上 noindex，避免測試頁被搜尋引擎收錄。正式上線前若忘記移除，Google 可能看得到網站，但不把重要頁面放進索引。

SSL 錯誤

SSL 不是網址列有鎖頭就結束，還要檢查憑證是否有效、網域是否涵蓋 www 與非 www、HTTP 是否全部導向 HTTPS，以及頁面內是否有混合內容。

DNS 未確認

DNS 切換前要確認 A record、CNAME、MX、CDN 設定與 TTL。若 DNS 指到錯誤主機，使用者看到的可能是舊站、錯誤頁，甚至完全無法連線。

黃燈可記錄後補

黃燈項目可以上線，但要有明確補修期限與負責人，例如部分圖片 alt 尚未補完、少數次要頁面文案待潤稿、非核心瀏覽器有小版面問題。

綠燈可簽核

綠燈代表核心功能、正式環境、SEO 索引、安全、備份與監控都已通過基本驗收。我的標準是：只要今天開始投廣告、發新聞稿或通知客戶，都不會因網站本身中斷主要業務。

功能與轉換流程要檢查哪些？

功能驗收要從使用者真正會走的路徑檢查：進站、看內容、點選單、填表單、登入會員、送出詢價或完成購物。只測首頁是否正常，無法代表網站可以正式上線。

全站導覽與連結

選單、頁尾、內部連結與外部連結都要逐項檢查。特別是改版網站，舊頁面連到新頁面時，常會出現按鈕仍指向測試網址、錨點失效、頁尾政策頁漏連的情況。

區域	要檢查的內容	通過標準
主選單	產品、服務、案例、關於我們、聯絡頁	每個連結可正常開啟，且不連到測試站
頁尾	隱私權政策、服務條款、公司資訊、社群連結	資訊正確，連結無 404
按鈕	立即詢價、加入購物車、預約諮詢、下載檔案	點擊後進入正確流程
站內搜尋	商品、文章、常見問題、服務頁	搜尋結果合理，沒有測試資料

表單與通知

每一張表單都要測送出成功、必填欄位、錯誤提示、通知信、後台紀錄與 CRM 串接。只看到「送出成功」提示不夠，後端真的收到才算通過。

• 用不同 Email 測試送出。
• 確認公司收件人收到通知。
• 確認客戶收到自動回覆信。
• 確認表單資料進入後台、CRM 或試算表。
• 確認垃圾訊息防護，例如 reCAPTCHA 或 honeypot。

會員登入

有會員功能的網站，要測註冊、登入、忘記密碼、修改資料、登出與權限頁面。上線前最容易漏掉的是忘記密碼信沒有寄出，或一般會員看得到管理者內容。

購物／詢價流程

購物網站要測商品加入購物車、優惠碼、運費、付款、訂單通知與庫存扣除。B2B 詢價網站則要測服務頁、案例頁、表單頁之間的轉換路徑是否順暢。

判斷時不要只站在內部人員角度。真正重要的是第一次來訪的客戶能不能在沒有說明的情況下完成動作。

內容、品牌與法規資訊要檢查哪些？

內容驗收要確認公司資訊、頁面文字、圖片、電話、地址、營業時間、社群預覽、隱私權政策與 Cookie 提示都正確，並清除所有測試資料與假內容。

公司資訊

公司名稱、品牌名稱、電話、Email、地址、營業時間、統一編號與社群連結要逐項核對。這些資訊看似基本，卻會直接影響客戶信任與在地搜尋的一致性。

• 頁首與頁尾的電話是否一致。
• Google 商家檔案、社群平台與網站地址是否一致。
• 聯絡信箱是否為正式信箱，不是測試 Gmail。
• 營業時間是否符合實際服務時間。

頁面文字

所有正式頁面都要檢查錯字、缺字、語氣、價格、服務範圍與案例描述。尤其是首頁、服務頁、方案頁、常見問題與聯絡頁，這些頁面會直接影響詢問率。

我不建議上線前才大改所有文案，但明顯錯誤、過期方案、錯誤價格與不再提供的服務，一定要先修掉。

測試資料清除

正式上線前要把測試商品、假訂單、範例文章、測試會員、預設留言、示範圖片與 lorem ipsum 文字清掉。測試資料一旦被客戶看到，信任感會掉得很快。

測試商品

商品名稱、價格、庫存、分類與圖片都要確認不是測試內容。若商品尚未開賣，應用草稿或隱藏狀態處理，不要讓測試商品出現在正式站。

假訂單

後台訂單、交易紀錄與報表要區分測試與正式資料。若測試訂單留在正式報表，會影響營收判讀、庫存與客服處理。

範例文章

WordPress、CMS 或網站模板常會留下範例文章與預設分類。這些內容若被索引，會讓搜尋引擎與使用者看到低品質頁面。

測試會員

測試帳號、弱密碼帳號與臨時管理者帳號要刪除或降權。保留測試帳號是常見的安全破口，也會讓權限管理變混亂。

隱私權與 Cookie

有收集表單、會員資料、訂單資料或追蹤工具的網站，要檢查隱私權政策、個資告知、Cookie 提示與同意欄位。這不是法律保證，而是上線前基本信任檢查。

手機、瀏覽器與可存取性要怎麼驗收？

手機、瀏覽器與可存取性驗收要確認主要頁面在手機、平板、桌機與常見瀏覽器都能閱讀、點擊、填寫表單，並具備基本對比、label 與鍵盤操作支援。

手機畫面

手機驗收不能只看首頁截圖，要實際操作選單、表單、購物車、付款頁與聯絡按鈕。台灣使用者大量從手機進站，手機流程壞掉通常比桌機小跑版更嚴重。

裝置	檢查頁面	通過標準
手機	首頁、服務頁、商品頁、表單頁	文字可讀，按鈕可點，表單不被鍵盤遮住
平板	選單、圖片區塊、表格、頁尾	排版不重疊，不出現橫向捲動
桌機	主要轉換頁、文章頁、會員頁	版面穩定，重要 CTA 清楚可見

跨瀏覽器

至少要檢查 Chrome、Safari、Edge 與 Firefox 的主要流程。不是每個細節都要完全一致，但選單、表單、影片、付款頁與彈出視窗不能在某個瀏覽器失效。

基礎可存取性

基礎可存取性檢查的目的，是讓更多使用者能順利操作網站。要確認表單欄位有 label、文字與背景有足夠對比、按鈕不是只靠顏色辨識，鍵盤也能移動到主要互動元素。

可存取性不是大型企業才需要。小型企業至少要避免使用者看不清、點不到、填不了表單。

SEO、索引與網址遷移要檢查什麼？

SEO 上線檢查要確認 Title、Meta Description、H 標題、alt、canonical、robots.txt、XML sitemap、Google Search Console、301 轉址與 404 狀態都正確。

頁面 SEO

每個重要頁面都要有獨立 Title、Meta Description 與清楚的 H1。圖片 alt 要描述圖片內容，內部連結要能把使用者帶到相關服務、文章或轉換頁。

• 首頁 Title 是否包含品牌與主要服務。
• 服務頁是否有清楚 H1，而不是只放品牌口號。
• Meta Description 是否能說明頁面價值。
• 重要圖片是否有合理 alt。
• canonical 是否指向正式網址。

索引設定

正式上線前要確認 robots.txt 沒有阻擋重要頁面，頁面沒有保留 noindex，XML sitemap 已更新，並在 Google Search Console 檢查主要網址狀態。

GSC 的網址檢查工具可以看 Google 是否能擷取頁面、是否允許索引、canonical 判斷是否合理。提交 sitemap 不代表一定立即收錄，但能幫助 Google 發現正式頁面。

改版遷移檢查

改版網站最怕舊網址流量直接掉進 404。上線前要整理舊 URL 與新 URL 對應，重要流量頁、外部連結頁與高轉換頁都要優先保護。

舊 URL 對應 301

舊頁面永久搬到新頁面時，應使用 301 轉址。若只是導到首頁，使用者找不到原本內容，搜尋引擎也難以理解頁面對應關係。

sitemap 差異

新 sitemap 應只包含正式、可索引、狀態碼正常的頁面。測試頁、草稿頁、重複頁與 404 頁不應出現在 sitemap。

重要流量頁保護

若舊站已有自然搜尋流量，應先用 GA4、GSC 或既有報表找出重要頁面，再確認轉址、內容對應與內部連結。這一步省掉，改版後常會看到流量斷層。

速度、伺服器與流量承載要確認什麼？

速度與伺服器驗收要確認 PageSpeed Insights、Core Web Vitals、圖片壓縮、CDN、快取、Gzip 或 Brotli、伺服器資源與流量尖峰情境能支撐正式上線。

頁面速度

速度檢查要看首頁、服務頁、商品頁、文章頁與表單頁，不要只測首頁。若首頁很快但商品頁圖片過大，使用者真正購買時仍會卡住。

項目	建議工具	通過標準
頁面載入體感	實機手機測試	主要內容能快速出現，互動不明顯卡頓
Core Web Vitals	PageSpeed Insights	重點頁面沒有嚴重紅色警示
圖片	瀏覽器開發者工具或 CMS 後台	圖片已壓縮，優先使用 WebP 等現代格式
追蹤碼	Tag Assistant 或瀏覽器檢查	沒有重複安裝造成載入負擔

快取與壓縮

快取、CDN、Gzip 或 Brotli 可以降低伺服器壓力，也能改善使用者等待時間。上線前要確認快取不會讓使用者看到舊價格、舊庫存或舊活動頁。

伺服器資源與壓力測試

若上線當天會發 EDM、投廣告、辦活動或公布新品，就要先確認主機 CPU、記憶體、磁碟與資料庫是否能承受流量。壓力測試不一定要做得很複雜，但至少要知道尖峰來時誰負責處理。

流量承載的判斷不能只問「主機規格夠不夠」。更務實的問題是：如果同時湧入一批訪客，網站會慢、會錯，還是會直接掛掉？

HTTPS、安全與資安掃描要檢查什麼？

安全驗收要確認 SSL、HTTPS 轉址、HSTS、後台密碼、CMS 更新、外掛漏洞、檔案權限、reCAPTCHA 與基礎弱點掃描，避免正式上線後暴露風險。

SSL 與 HTTPS

SSL 憑證要有效，所有 HTTP 頁面要導向 HTTPS，並避免混合內容。可用 SSL Labs 檢查憑證與協定狀態，但重點是確認客戶能安全送出資料與付款。

HSTS 可以降低使用者被導到非 HTTPS 的風險，但設定前要確認全站 HTTPS 已穩定，否則錯誤設定會讓修復變麻煩。

後台與外掛

CMS、WordPress、佈景主題與外掛要更新到安全版本。管理員帳號不要使用 admin 這類容易猜的名稱，密碼要有足夠強度，離職人員或測試帳號要移除。

• 確認管理者權限只給必要人員。
• 移除未使用外掛與測試外掛。
• 確認檔案權限沒有過度開放。
• 後台登入頁有基本防護，例如限制嘗試次數或 reCAPTCHA。

進階資安檢查

OWASP ZAP、Sucuri 或主機商掃描可以用來做基礎檢查，但不用把上線前驗收變成完整滲透測試。企業主需要知道的是：是否有明顯漏洞、弱密碼、過期元件與不該公開的檔案。

正式環境切換前要檢查哪些第三方服務？

正式環境切換前要確認 API Key、金流、物流、CRM、地圖、聊天工具、SMTP、Webhook、Email 通知與社群分享都已從測試環境切到 production。

測試環境切正式環境

第三方服務最常見的上線事故，是網站看起來正常，實際卻還連到 sandbox。這會造成付款失敗、物流單建立失敗、CRM 沒有客戶資料，或通知信寄到測試信箱。

服務	要檢查的設定	常見錯誤
金流	正式商店代號、正式 API Key、付款通知網址	仍使用 sandbox 金鑰
物流	正式物流帳號、門市選擇、託運單建立	測試訂單無法出貨
CRM	正式管線、欄位對應、名單來源	客戶資料進錯名單
Email	SMTP、寄件網域、通知收件人	通知仍寄給工程師或測試信箱
Webhook	正式 endpoint、簽章驗證、錯誤重試	事件送到測試網址

不要留下 sandbox

金流、物流、CRM 與 API 串接都要確認環境名稱、金鑰、callback URL 與後台模式。只看前台按鈕能不能點，不足以證明正式交易會成功。

測試收件人

通知信、訂單信、表單信與系統警報要寄到正式負責人。若仍寄到工程師個人信箱，業務和客服可能完全不知道有新詢問。

測試金鑰

API Key、Webhook secret、OAuth client、地圖 API 與聊天工具都要切成正式設定。測試金鑰有時會有額度、網域或功能限制，上線後才發現會很難補救。

金流物流驗收

金流要測成功、失敗、取消與通知回傳；物流要測運費、超商門市、宅配選項與訂單狀態。若有電子發票，也要確認正式開立流程與買受人資訊。

Email 與通知

Email 通知要測寄件人名稱、寄件網域、SPF、DKIM、退信、垃圾信匣與內部收件人。表單成功但通知信進垃圾信匣，對業務來說仍等於漏單。

備份、還原與回滾計畫怎麼驗證？

備份驗收不能只確認「有設定備份」，還要實際測還原、確認備份範圍、回滾窗口、負責人與 RTO，才能知道網站出包時是否救得回來。

備份不是有設定就好

備份要包含檔案、資料庫、媒體、設定檔與必要的第三方設定紀錄。很多網站以為有主機備份就安全，等到要還原才發現只備到檔案，沒有資料庫。

實際還原測試

至少要在測試環境做一次還原，確認網站能開、資料能讀、表單能送、會員能登入。沒有還原測試的備份，只能算是一份尚未驗證的希望。

回滾決策與執行人

正式上線前要先定義什麼狀況需要回滾、誰有權決定、誰負責執行、多久內要完成。出事當下才討論，通常會拖過最適合回滾的時間。

項目	驗收內容	負責人
備份範圍	檔案、資料庫、媒體、設定檔、外掛版本	工程或主機管理者
還原測試	在測試環境還原並確認主要功能	工程
回滾條件	付款失敗、網站無法連線、重大 SEO 阻擋、資料錯誤	PM 與主管
RTO	可接受的恢復時間目標	主管與工程
溝通窗口	異常通知、決策回報、客戶或內部公告	PM

上線後 48 小時要監控什麼？

網站上線後 48 小時要監控 uptime、錯誤日誌、API、表單、付款失敗、GA4、GSC、伺服器 CPU、記憶體、磁碟與警報，不能上線後就放著不管。

即時監控

上線當天要有人看網站是否能連線、是否出現 500 錯誤、DNS 是否穩定、SSL 是否正常。若有主機監控或 uptime 工具，要確認警報會通知到負責人。

轉換監控

表單送出、電話點擊、加入購物車、付款成功、付款失敗、會員註冊都要觀察。流量正常但表單數歸零，通常不是市場突然沒興趣，而是轉換流程可能壞了。

SEO 監控

GA4 可觀察流量與事件，GSC 可觀察索引、提交 sitemap、網址檢查與搜尋曝光變化。上線後短時間內不必期待排名立刻穩定，但重大阻擋與大量 404 要立刻處理。

異常回報節奏

上線後 48 小時內應設定固定回報節奏，例如上線後 1 小時、半天、第一天結束、第二天結束各回報一次。回報內容要包含問題、影響範圍、處理狀態與下一步。

監控項目	要看什麼	異常處理
uptime	網站是否能正常連線	通知工程與主機商
錯誤日誌	500、PHP 錯誤、API timeout	判斷是否修補或回滾
表單	送出量、通知信、後台紀錄	立即重測表單與收件設定
付款	成功率、失敗訊息、金流回傳	聯絡金流商並檢查正式設定
伺服器	CPU、記憶體、磁碟、資料庫負載	擴充資源或調整快取

誰負責簽核網站上線？

網站上線簽核應由 PM 統整，工程、設計、行銷、主管與廠商分別對自己的檢查項目負責，並留下驗收紀錄、證據與最後 Go / No-Go 判斷。

RACI 分工

RACI 可以把責任講清楚：誰負責執行、誰最終負責、誰要被諮詢、誰需要被通知。沒有分工的驗收清單，最後很容易變成每個人都以為別人檢查過。

檢查項目	執行負責	最終簽核	需被通知
功能與表單	PM、工程	PM	業務、客服
內容與品牌資訊	行銷、設計	行銷主管	主管、廠商
SEO 與轉址	SEO 或網站管理者	PM	主管、內容團隊
正式環境與資安	工程、主機管理者	技術負責人	PM、主管
Go / No-Go 決策	PM 彙整	主管或業主	全專案成員

驗收紀錄

每個檢查項目都要留下證據，例如截圖、測試訂單編號、表單送出紀錄、GSC 檢查結果、PageSpeed 測試連結、備份還原紀錄。口頭說「測過了」不適合用在正式上線。

知識交接

網站正式上線後，內部至少要知道後台怎麼登入、誰能改內容、誰負責收表單、誰看 GA4 與 GSC、誰處理主機與金流問題。交接不完整，網站會在第一個小問題出現時卡住。

網站上線前一定要檢查哪些項目？

一定要檢查功能、表單、內容、手機版、SEO 索引、速度、HTTPS、資安、正式環境、備份回滾與上線後監控。若網站有金流、物流、會員或 CRM，這些第三方服務也要做正式環境測試。

哪些問題發生時應該延後網站上線？

表單無法送出、金流未通過正式測試、robots.txt 或 noindex 阻擋重要頁面、SSL 錯誤、DNS 未確認、正式環境仍使用測試金鑰、沒有可還原備份，這些都應延後上線。

如何驗證網站安全？

可先檢查 SSL 憑證、HTTPS 轉址、後台密碼、CMS 與外掛版本、檔案權限、reCAPTCHA 與管理者帳號。若需要更進一步，可用 SSL Labs、Sucuri 或 OWASP ZAP 做基礎掃描。

如何測試網站速度？

可用 PageSpeed Insights 檢查 Core Web Vitals，也要用真實手機開啟首頁、服務頁、商品頁與表單頁。上線前應確認圖片已壓縮、快取啟用、CDN 正常，且沒有過多重複追蹤碼拖慢頁面。

Google Search Console 的網址檢查工具要怎麼用在上線前驗收？

可用網址檢查工具測試重要頁面是否能被 Google 擷取、是否允許索引、canonical 是否合理。它能幫助發現 noindex、robots 阻擋或擷取錯誤，但不代表提交後一定會立即收錄。

網站表單要怎麼確認真的有送出成功？

要用真實資料送出一次，確認前台成功訊息、公司通知信、客戶自動回覆信、後台紀錄、CRM 或試算表同步都正常。只看到前台顯示成功，不能代表公司真的收到詢問。

網站改版上線時，舊網址一定要做 301 轉址嗎？

如果舊網址已有搜尋流量、外部連結、社群分享或使用者收藏，就應對應到最相關的新網址並設定 301 轉址。不要把所有舊網址都導到首頁，這會降低使用者體驗，也不利於搜尋引擎理解頁面關係。

金流、物流、CRM 這類第三方服務要怎麼確認不是測試環境？

要檢查後台環境模式、正式 API Key、callback URL、Webhook endpoint、通知收件人與正式帳號。最可靠的方式是跑一次正式流程，例如建立正式測試訂單、確認付款通知與 CRM 名單進入正確管線。

備份有設定就代表可以上線嗎？

不代表。備份要確認範圍包含檔案、資料庫、媒體與設定，也要實際做還原測試。沒有測過還原的備份，無法證明網站出問題時真的救得回來。

網站上線後 48 小時要看哪些數據？

要看 uptime、錯誤日誌、表單送出、付款成功與失敗、API 回應、GA4 事件、GSC 索引狀態、404、伺服器 CPU、記憶體與磁碟。若有異常，要記錄影響範圍、處理人與下一步。

網站上線檢查應該由誰負責？

通常由網站專案 PM 統整，工程負責技術與正式環境，行銷負責內容與追蹤，設計負責版面與品牌，主管或業主負責最後 Go / No-Go 簽核。每個檢查點都應有負責人與驗收證據。

小型企業網站需要做可存取性檢查嗎？

需要做基本檢查。至少要確認文字對比足夠、按鈕容易點、表單欄位有 label、鍵盤能操作主要功能。這些項目不只服務特定族群，也能降低一般使用者在手機上操作失敗的機率。