電商網站架設上線前驗收清單｜六類需求一次確認

一款同款五色、又分成現貨與預購的 T 恤，在後台可能就是 10 個 SKU，再加尺寸會更多；這種商品在上線第一天就容易出狀況。電商網站架設上線前該確認的需求有六類：金流物流與發票、商品庫存與訂單、SEO 與追蹤碼、響應式與效能、會員與通知、營運數據看板。每一類都有可以逐項判斷的通過條件，只要有一類還沒跑通，上線日就該往後挪一步，而不是邊賣邊補。

這六類的順序有原因。金流與物流決定顧客付不付得出錢，商品與庫存決定下單後有沒有東西可以出，訂單與通知決定顧客與客服看不看得到進度，SEO 與追蹤碼決定流量與數據進不進來，響應式與效能決定手機客人會不會在結帳頁離開，數據看板則決定您隔天用什麼判斷要不要調整。

上線前需求確認：六類面向與驗收起點

驗收的起點是「寫得出結果」。金流欄位不寫「已開通」，寫「刷一筆會產生訂單並寄出通知」；SEO 不寫「已填 META」，寫「頁面原始碼看得到設定的標題與描述」。同樣一個動作，後面這種寫法才能在出問題時判斷到底過了沒。

金流、物流與發票要在上線前跑通，範圍包含信用卡刷卡、超商代碼繳費、超商取貨、宅配，以及電子發票載具。這份清單會依平台提供的金物流選項與目標市場而變動，賣到海外的店家與只做台灣本島的店家，題目不一樣；不變的是，上線當天顧客要能自己完成付款與收貨，不必打電話問怎麼辦。

平台提供哪些金流與物流，會改變驗收題目

有些方案把金流與物流綁成一組，有些要各自到服務商後台開通再回填金鑰。開通方式不同，驗收順序就不同：先確認後台欄位填得進去，再確認結帳頁選得到，最後才是用真實卡片跑完一筆訂單。

通路的選擇也要在這時候定下來。商品同時在官網、實體門市或其它通路流通時，庫存地點與銷售通路的對應關係先寫清楚，後面庫存同步的測試才有依據。

每一類都要有看得見的通過條件

六類面向不必擠在同一天驗完，但每一類都要留下看得見的結果：一筆成立的訂單、一封寄出的通知信、一張跑出來的發票、一次手機結帳的完成畫面。這些結果在上線後被質疑時，都可以回頭核對。

金流、物流與發票：跑通三種情境才算驗收通過

至少跑通三組：信用卡刷卡、超商代碼繳費加超商取貨、宅配。結帳頁的發票欄位要選得到會員載具、手機條碼載具與捐贈，三種各開一張測試發票，確認發票有開出、載具或捐贈資訊正確。哪一組跑不通，上線後就是客訴，而且客服沒有辦法在電話裡替客人完成結帳。

情境	驗收動作	通過條件	平台限制
信用卡刷卡	用真實卡片完成一筆小額訂單	訂單成立、狀態更新、通知信寄出	金流服務商需另外開通
超商代碼繳費	下單後產生代碼並完成繳費	代碼產得出來、繳費後狀態回寫訂單	付款與取貨是兩段流程
超商取貨	選門市、完成到店取貨	門市選單載得出來、取貨狀態跟著更新	取貨通知要另外確認
宅配	填收件地址、選宅配方式	出貨單可產生、地址與電話帶入正確	可選的宅配業者依平台串接而異
電子發票與載具	會員載具、手機載具、捐贈各開一次	三種選項都選得到、發票開得出來	需串接發票服務商

超商那一段看起來是一件事，其實是兩件事：一個是客人在機台繳錢，一個是客人到門市取貨。付款成功不代表取貨流程通了，取貨通知沒發出，客人到了門市也領不到。

發票的問題要走到結帳最後一步才看得出來。載具欄位少一個，或者捐贈選項沒開，客人走到最後一步才發現選不到，前面選的商品與運費都要重來。上線前把會員載具、手機載具與捐贈各開一張，比上線後接第一通客服電話省事得多。

商品、庫存與訂單流程：上線前的同步測試

商品批次匯入之後，要逐項對照規格、價格與圖片；同款不同色的變體各自對到正確的網址；組合商品扣減庫存要連動；訂單從成立到出貨的通知，以及會員中心裡的狀態查詢，要完整跑過一次。這四件事分屬商品、庫存與訂單三個環節，缺一項就會在上線後變成退款或重寄。

批次匯入後要對的三件事

批次匯入用平台指定的檔案格式：Shopify、WooCommerce 官方匯入都用 CSV，也有系統走 xlsx。先匯出要修改的商品、改完再匯入，比一筆一筆開快得多，品項上百或有多個庫存地點時，差距更明顯。匯完之後要對的是規格、價格與圖片，尤其是變體商品，顏色與尺寸的對應錯了，客人收到的就不是他選的那一件。

同款不同色的變體，網址要能各自指向自己。Google 的商品變體結構化資料文件寫明，網站要能用各自的網址（例如帶參數的網址）直接預選每一個變體，並顯示該變體正確的圖片、價格與庫存，Google 才能檢索並辨認每一個變體。驗收時把每個顏色的網址複製到無痕視窗直接打開，確認預選的顏色、價格與庫存都對。

組合商品是超賣的破口。A、B、C 三個單品組成另一項促銷商品 D，只要其中一個單品庫存為零，D 的庫存就要同步歸零。這個連動沒接上，後台看起來還有貨，訂單照收，出貨時才發現湊不齊。

訂單通知與會員狀態要跑完一輪

第一次結帳可能同時觸發兩件事：註冊會員與寄出訂單通知。這一串要一次跑完，包含註冊信、訂單成立、付款成功、出貨通知；顧客在會員中心看得到訂單狀態，客服才不用逐筆回覆進度。優惠券也要在這一輪一起測，折扣碼套用後金額有沒有正確反映，跟通知信一樣都是客人回頭檢視的環節。

會員登入可以用 Email，也可以開放社群帳號。同一組信箱用不同方式登入時，系統要當成同一個會員，否則同一個客人會拿到兩份訂單紀錄，回購的判斷也會跟著失準。

SEO 基礎與追蹤碼：上線前設好就不用重來

META 標題與描述、自訂友善網址、Sitemap、robots.txt、圖片 alt、結構化資料，這些欄位在上線前寫好。它們在後台按下去就存好了，但要等搜尋引擎重新抓取才會反映在搜尋結果上，所以上線後才補，等於把收錄時間往後推。

上線前該寫好的欄位

META 標題與描述是 Google 產生搜尋結果標題與摘要的主要依據之一，但 Google 也可能改用頁面上的其他文字；自訂友善網址決定分類頁與商品頁的網址長相，Sitemap 讓搜尋引擎一次拿到網站地圖。圖片 alt 是搜尋引擎理解商品圖的重要線索，也幫助使用螢幕閱讀器的顧客；結構化資料讓商品頁有機會在搜尋結果顯示價格、庫存與評價。

robots.txt 告訴爬蟲哪些網址先不要檢索，它本身不是讓頁面不進搜尋結果的機制。架站期間的測試頁或會員頁不想被搜尋到，用的是 noindex 或密碼保護；正式上線前要把 noindex 或密碼拿掉，否則正式站也會被擋在搜尋結果外。

結構化資料在不同平台的處理方式不同。有些平台內建基本的 SEO 架構，使用者只要填欄位；有些平台要在後台自行加入程式碼，甚至無法編輯單一頁面的 HTML。這一項在選平台時就要問清楚，因為它決定上線前由誰來寫、寫不寫得完。

追蹤碼與事件

GA4 的加入購物車、開始結帳、完成購買這幾個事件，要跟 Facebook 像素與轉換 API 一起在上線前確認觸發。完成購買事件要帶 transaction_id，GA4 用它避免同一筆訂單被重複計算，例如顧客重新整理感謝頁；有送金額 value 就一定要帶幣別 currency，營收才算得準。上線後才補，中間那段加購與結帳的數據不會留下來，廣告歸因會斷在補設的那一天。

驗收方式很直接：開 debug mode 或即時報表，實際走一次加購到完成購買，看到事件一筆一筆進來才算過。新安裝的標籤最多可能要 30 分鐘才開始收資料，裝完馬上看不到，先別急著判定失敗。

三裝置響應式與載入速度：驗收方式

手機、平板與電腦各自打開商品頁、購物車與結帳頁走一遍，這是響應式的基本驗收。RWD 的排版在三種裝置上可能長得不一樣，選單收合方式、按鈕位置、欄位順序都不同，所以三個裝置都要各自走完一次結帳，電腦版沒問題不代表手機也過了。行動裝置的客人結帳不卡住，這一項才算過關。

三個裝置各走一次結帳

走的時候看的是最後一步：手機上按鈕好不好按、欄位會不會被鍵盤蓋住、付款方式選不選得到。商品頁排版漂亮，但結帳頁在手機上要多滑好幾層才找得到付款按鈕，那就是要修的地方。

載入速度看實際環境

圖片上傳前先轉成 Webp，同畫質的檔案比較小，載入時間跟著縮短。PSI 分數會被第三方程式碼拉低，它適合拿來找問題，實驗室環境的量測不一定抓得到真實瓶頸。能不能上線，看 Google 公布的 Core Web Vitals 門檻：LCP 在 2.5 秒內、INP 在 200 毫秒以內、CLS 在 0.1 以內，取真實使用者資料的第 75 百分位，手機與電腦分開看。新站資料還不夠時，就用手機實際走一次結帳，把感受記下來對照。

上線前也可以用後台的預覽功能，先把商品頁與文章看過一次，確認版位與文字都對，再決定何時公開。有些平台還能指定日期與時間自動上架，下班後要換的活動可以先排好。

上線前需求與驗收清單對照表

把六類面向、對應的驗收動作、通過條件與平台限制放在一起，上線前逐格確認。每一格都要有一個看得見的結果，判斷起來才不會各說各話。

面向	驗收動作	通過條件	平台限制
金流、物流與發票	信用卡、超商代碼繳費、超商取貨、宅配各跑一筆	訂單成立、狀態更新、通知信寄出、發票開立	金流與物流選項依方案與市場不同
商品、庫存與訂單	批次匯入後對照規格、價格、圖片，並跑一次訂單流程	變體對應正確、套組與單品庫存連動、不缺貨不超賣	匯入格式依平台而定（CSV 或 xlsx）
會員與通知	首次結帳註冊、登入、套用優惠券、查訂單	註冊信與訂單通知寄出、會員中心看得到狀態	社群登入需同一信箱視為同一帳號
SEO 基礎	填 META、自訂網址、Sitemap、robots.txt、圖片 alt	頁面原始碼看得到設定、Sitemap 提交成功	部分平台無法編輯單頁 HTML
追蹤碼	走一次加購到完成購買	GA4 事件與像素都收到訊號	事件需在上線前觸發
響應式與效能	手機、平板、電腦各走一次結帳	三裝置版面正常、商品頁與結帳頁符合 Core Web Vitals 門檻	各裝置排版可能不同，需分別驗
營運數據看板	打開後台報表與行銷工具串接	訂單、流量與轉換數據看得到	報表範圍依平台與方案不同

營運數據看板如果排到上線後才處理，第一週就少了判斷依據。訂單、流量與轉換數據在後台看得到，上線第一週才有辦法判斷哪一個商品頁要改、哪些關鍵字帶進來的訂單比較多；報表範圍依平台與方案不同，這件事要在簽約前問清楚。

這週能先做的一件事，是把三組金物流情境各跑一筆測試單，從付款到出貨完整走完。做完之後，您在後台會看到三筆狀態各自完整的訂單，接著排上線日就有底了。若要把這份清單排進您們的上線時程，與我們一起確認上線前的驗收順序。