訪客數沒事，不代表沒事

我們配合的一間行銷公司最近來求助。他們手上服務著一個客戶的品牌官網，客戶那邊回報「流量好像怪怪的」，行銷公司打開 Cloudflare 後台一看：每日請求數從三萬多筆腰斬再腰斬，掉到五千到七千，而且回不去。

同一段時間，「不重複訪客」這個數字幾乎沒有變化，甚至還小幅上升。行銷公司一開始鬆了一口氣——訪客沒少，應該沒事——但這個組合其實藏著另一個問題：如果真人流量沒變，消失的那兩萬多筆請求，原本就不是真人在按。

這是自動化流量的典型訊號：一支程式一天能發出幾萬次請求，但流量統計裡不管按了幾千次，通常只會被算成極少數「訪客」。請求數暴跌、訪客數不動——這種組合，十之八九是某個原本天天來、突然不來了的自動化東西停手了。多數團隊看到訪客數沒事，就把這個異常結案了，沒人往下多問一句：消失的到底是什麼。這次行銷公司多問了這一句，才找上我們。

多問一步：查伺服器自己留的原始 log

這正是我們接手後多做的一步：不只看 Cloudflare 的免費概觀面板，還回頭比對客戶伺服器自己留的原始 log——理論上這裡是真相的最後一道防線，每一筆進來的請求，伺服器都會記錄。

多數狀況下，這一步會直接撞牆：很多網站的 log 格式是 Apache 預設的 common，只留來源 IP、時間、請求了哪個網址、回應狀態碼，沒有 User-Agent 這一欄。不管來的是 Googlebot、某個 AI 助理，還是一支寫壞的爬蟲程式，這份 log 從第一天開始就沒有記錄「這是誰」——不是資料被清掉或忘了存，是這個欄位打從建站設定的那天起就不存在。common 是 Apache 最陽春的內建格式，不少中大型企業的官網後台也停在這裡：建站時廠商用預設值裝一裝，之後沒人回頭檢查過。

要記到 User-Agent，得手動把格式換成 combined，而且只對換格式之後發生的請求有效——這代表就算現在馬上修，這次消失的兩萬多筆請求身分，也永遠查不回來了。

這一步，多數行銷公司走不到

能查到「請求腰斬但訪客沒少」這個組合，已經超過多數行銷團隊平常會做的事——多數人根本不會回頭比對 Cloudflare 面板裡「請求數」跟「不重複訪客」這兩條線是不是同步變動。就算比對出異常，下一步「查伺服器原始 log 找是誰」還會撞上同一道牆：log 格式有沒有留識別資訊，是客戶網站建站當下的技術決定，不是事後想查就查得到。

免費儀表板告訴你「量」變了，但「誰」變了，得靠額外的設定跟持續盯著才看得出來。這正是多數行銷公司的報表停在「有異常」就結案、卻說不出「異常是什麼」的原因——不是不夠認真，是這件事本來就要跨兩層技術（流量統計＋伺服器 log 設定）才看得出全貌，而多數行銷團隊的工具箱只到第一層。

兩件事現在就能做

第一件事很具體：檢查客戶網站的 log 格式是不是還停在 common。如果是 Apache，vhost 設定裡把 CustomLog 那行從 common 換成 combined，以後至少留得住 User-Agent，下次異常發生時才有東西可查。不是自己管主機的話，問代管商或工程師一句話就夠：「我們的 access log 有沒有記 User-Agent？」

第二件事比較難：留得住資料不代表會有人去看。能不能發現「請求腰斬但訪客沒少」，取決於有沒有人固定把這兩條線放在一起比對——多數時候沒人這麼做，異常就這樣悄悄過去，連查都沒查過。這正是行銷公司找上我們要處理的那一步：不是取代他們第一線的流量報表，是在客戶的儀表板說「有異常」之後，由我們多做那一步「異常是什麼、值不值得處理」的複核。想先看看自己網站現況，跑一次免費分析；手上客戶的站卡在「有異常但說不出原因」，寫信到 [email protected]，我們看過再回。