靜態網站上線不是把連結丟出去就結束。第一個 HTTPS 公開連結能打開，只代表檔案發佈成功；接下來要確認的是：有沒有人打開、從哪裡來、看了哪些頁面、用什麼裝置，以及網站是否因為圖片或檔案太大而浪費頻寬。
剛上線的網站不一定需要完整的分析套件。你先需要一層夠輕的統計資料，用來判斷連結是否真的被看見，下一輪應該修哪裡。
先決定你要用資料回答什麼
統計資料如果沒有問題意識，很容易變成每天多看一眼的數字。
不同網站要看的重點不同。線上作品集要知道對方是否進到作品頁；登陸頁要看流量來源是否和投放渠道一致；文件站要找出使用者最常進入和卡住的頁面；課堂作業或客戶預覽則更在意對方是否能從手機和常見瀏覽器打開。
| 網站類型 | 上線後更值得看的問題 |
|---|---|
| 線上作品集 | 訪客有沒有打開作品詳情，而不只是首頁？ |
| 線上履歷 | 連結寄出後，是否有人真的打開？ |
| 登陸頁 | 流量來源是否來自預期的廣告、社群或電子郵件？ |
| 文件站 | 哪些頁面是主要進入點？ |
| AI 生成網站 | 修正檔案結構後，訪客是否能抵達正確頁面？ |
| PDF 或活動頁 | QR Code、簡報、社群連結是否帶來流量？ |
先寫下問題，再看數字。這樣才不會把每個上升或下降都解讀過頭。
造訪和訪客不是同一件事
造訪次數代表頁面被打開的次數。訪客數則用來估算有多少不同使用者或工作階段參與，實際定義會依平台而異。
這兩個數字常被混在一起看。
如果造訪很多、訪客很少，可能是你自己一直測試，也可能是同一批人在反覆審閱。訪客增加但造訪深度很低，則可能代表第一頁沒有承接到對方預期，或連結被分享到不精準的地方。
| 看到的現象 | 可能原因 | 可以怎麼做 |
|---|---|---|
| 上線當天造訪突然很高 | 內部測試、自己反覆刷新 | 先排除 QA 期間的雜訊。 |
| 訪客少但來源很清楚 | 只分享到一個渠道 | 等更多渠道分發後再判斷。 |
| 接上自訂網域後流量上升 | 網址更容易信任或分享 | 看熱門頁面是否也跟著改變。 |
| 很多人只看一頁 | 頁面資訊不夠、CTA 不清楚、載入太慢 | 先檢查首屏、行動版和圖片大小。 |
Cloudflare Web Analytics、Plausible 和 Matomo 都會區分頁面瀏覽、訪問、訪客、來源、裝置等資料。名稱不完全相同，但判讀原則一致：不要用單一數字替整個網站下結論。
流量來源能檢查連結有沒有發到正確地方
靜態網站常常是透過很分散的方式被分享：LinkedIn、Instagram、LINE、電子郵件、QR Code、簡報、履歷、提案 PDF 或課堂系統。流量來源可以幫你判斷哪個渠道真的帶來訪客。
要注意的是，有些 App 或瀏覽器不會完整帶出 referrer，所以一部分流量可能會顯示為 direct。這不代表資料沒有用，只是不能把 direct 簡單解讀成「使用者手動輸入網址」。
如果你在做小型活動或招募投遞，建議用 UTM 讓連結更清楚。DeployPages 提供 UTM builder，可以替不同渠道建立可辨識的網址。
| 分享位置 | 可用的命名方式 |
|---|---|
| LinkedIn 貼文 | utm_source=linkedin&utm_medium=social |
| 電子報或通知信 | utm_source=newsletter&utm_medium=email |
| 活動 QR Code | utm_source=event&utm_medium=qr |
| 提案 PDF | utm_source=proposal&utm_medium=pdf |
| 履歷附件 | utm_source=resume&utm_medium=document |
UTM 適合用在外部入口，不適合亂加在站內導覽。站內連結應該保持乾淨，避免把資料弄得更難讀。
裝置和瀏覽器會告訴你下一步要測哪裡
很多靜態網站在開發筆電上看起來正常，真正出問題的是手機。
裝置和瀏覽器資料能幫你安排 QA 順序。如果大多數訪客來自行動裝置，寬表格、過大的 hero 圖、太小的按鈕、不可換行的英文網址，都會比桌面版更嚴重。如果某個瀏覽器比例不低，更新後就應該用那個瀏覽器打開一次。
實務上可以這樣做：
- 用手機打開首頁和熱門頁面。
- 測試選單、按鈕、表單、下載連結和圖片。
- 檢查長文字、程式碼片段和表格是否溢出。
- 優先測熱門頁面，不只測你自己最熟的頁面。
- 每次大更新後，看特定裝置的表現是否突然變差。
統計資料不會取代測試，但能讓測試不再靠猜。
熱門頁面常常推翻原本的假設
團隊很容易高估首頁，低估使用者直接進入內頁的情況。
作品集可能是某個作品頁被轉貼；文件站可能是某篇設定教學被搜尋到；活動頁可能是 QR Code 直接打到報名頁；AI 生成網站可能是某個 path 在 prompt 裡被寫死，結果所有人都從那裡進來。
看熱門頁面時，重點不是只找「最多人看哪一頁」，而是判斷這些頁面是否準備好承接流量：
- 標題和描述是否清楚？
- 行動版是否正常？
- 主要 CTA 是否可見？
- 頁面是否有過期資訊？
- 如果頁面被替換，舊連結是否有合理去處？
如果某個舊頁面還有流量，不要直接刪掉。先建立替代頁，或把內容整理到新 URL。大型更新前，保留 還原到先前版本 的路徑會更安心。
頻寬是成本和體驗的早期警訊
靜態網站不需要每次請求都跑後端，但檔案本身仍然可能很重。
圖片、PDF、影片、字型和 JavaScript bundle 都會消耗頻寬。流量不大時你可能感覺不到；一旦連結被社群轉發，過大的資源會同時影響載入速度和用量。
如果頻寬增加速度明顯高於造訪成長，先查這幾件事：
| 可能原因 | 檢查方式 |
|---|---|
| 圖片太大 | 檢查 build 資料夾和瀏覽器 DevTools 的檔案大小。 |
| PDF 被大量下載 | 看熱門頁面和被請求最多的資源。 |
| 字型載入太多 | 減少 font family、weight 和未使用字型。 |
| JavaScript bundle 過重 | 確認靜態頁沒有帶入不必要的套件。 |
| 外部網站直接引用你的資源 | 檢查來源、國家和異常請求模式。 |
對作品集和登陸頁來說，最常見的修正不是換平台，而是壓縮圖片、移除未使用素材、避免把原始大圖直接丟上線。
什麼時候需要更完整的分析工具？
內建統計資料適合回答上線後的第一層問題：連結是否有人打開、來源大概在哪、熱門頁面是哪些、訪客用什麼裝置、頻寬是否合理。
如果你需要更細的事件追蹤、漏斗、轉換歸因、跨產品報表，或要把資料接到行銷和 CRM 流程，那就該評估 Google Analytics、Plausible、Matomo 或其他專門工具。
比較好的順序是：
- 先發佈網站。
- 用內建統計資料確認基本流量。
- 修正明顯的頁面、裝置和檔案問題。
- 真的需要更細資料時，再加入外部分析工具。
不要為了看起來完整而一開始就塞進很多 script。每個第三方 script 都會影響載入、隱私說明和維護成本。
隱私、Cookie 和第三方 script 要一起考慮
流量統計不是只跟行銷有關，也跟隱私和使用者信任有關。
如果你加入第三方分析 script，應該同步檢查隱私權政策和 Cookie 說明。至少要讓使用者知道網站會收集哪些資料、用途是什麼、是否有第三方服務參與，以及使用者可以如何管理偏好。
小型靜態網站可以先用平台提供的輕量統計資料，等到需要事件追蹤或更細分的報表，再做更完整的資料治理。這不是保證合規，而是比較務實的產品順序。
上線第一週的檢查節奏
第一週不用一直盯著 dashboard，但應該有固定檢查點。
| 時間 | 檢查項目 |
|---|---|
| 發佈當天 | HTTPS、首頁、主要頁面、圖片、CSS、下載連結。 |
| 第一次分享後 | 流量來源是否和分享渠道一致。 |
| 第二天 | 熱門頁面、行動裝置、主要瀏覽器。 |
| 第三到第七天 | 頻寬、舊頁面、異常來源、direct traffic 變化。 |
| 大更新後 | 比對更新前後熱門頁面和裝置資料。 |
這樣做的目的不是追求漂亮圖表，而是把上線後的問題縮小到可處理範圍。
DeployPages 在這個流程裡做什麼
DeployPages 把統計資料放在靜態網站發佈流程裡，而不是要求你先設計一整套分析架構。
典型流程是：
- 上傳資料夾、ZIP、PDF 或框架靜態輸出。
- 取得 HTTPS 公開連結。
- 分享給客戶、同學、團隊或活動渠道。
- 用 統計資料 查看造訪、來源、頁面、國家和地區、裝置、瀏覽器與頻寬。
- 專案值得保留後，接上 自訂網域。
- 更新開始變頻繁時，再加入 CLI 部署、密碼保護或版本還原。
很多靜態網站都適合這個順序：先確認公開連結真的有效，再決定要不要投入更重的工具。