訪客數沒事，不代表沒事
我們配合的一間行銷公司最近來求助。他們手上服務著一個客戶的品牌官網，客戶那邊回報「流量好像怪怪的」，行銷公司打開 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]，我們看過再回。
哇...又乾貨滿滿
log這個字我第一次聽到，完全不知道自己的網站有沒有這個東西qq，平常都是外包的工程師在弄網站，這種事是不是要主動問他『我們的log有沒有記user-agent』，還是問出去人家會覺得我在亂？我們診所網站流量本來就沒多少，是不是根本輪不到我擔心這個?
這篇最後那句『多數行銷公司的報表停在有異常就結案』我要截圖存起來，講的就是我輔導客戶時最常看到的斷點。不是工具不夠好，是沒有人被賦予『看到異常要往下問一層』這個職責，報表做得再漂亮，沒人負責解讀，異常就只是異常，永遠不會變成行動。這種複核角色如果不是外包出去，內部通常也要有一個人專職盯著，不然報表系統再貴都一樣。
這個訊號設計得很好，單看『不重複訪客』很容易被唬，因為真人跟bot對這個指標的貢獻差太多。我自己後台習慣多拉一條請求數跟不重複訪客的比值一起看，自動化流量掉的時候通常這個比值也會跟著崩，兩條線一起比對比只看單一指標準。可惜多數cms內建的分析後台不會主動幫你把這兩條放在一起，要自己手動拉出來比。
這種事最怕的是客戶自己發現數字掉、但我們講不出所以然，信任感一次扣光。我們現在都學乖了，月報先自己做這種請求數跟不重複訪客的比對，免得被客戶問倒才臨時抱佛腳查log。只是要一路查到log格式本身有沒有記ua這麼細，老實講我們業務端根本不會想到，以前都以為流量掉不掉就是it那邊的事，跟我沒關係。
補充一個文章沒提的角度：國外bad bot report這幾年一直在講automated traffic佔比越拉越高，有些報告甚至講到快一半流量是bot，這篇講的請求腰斬情境完全對得上那個趨勢，不是個案。比較想問的是，這種log盤點要不要排進固定的quarterly review，還是真的出事才會有人想到查？我們公司目前完全沒有這條sop
以行銷角度講，這篇戳到最容易犯的盲點
客戶自己看cf後台，看到不重複訪客沒掉就鬆一口氣，我們也跟著鬆一口氣，沒人往下問少掉的到底是什麼。接手過的舊站十間有八間log格式從建站那天就沒人動過，common擺到現在，不是資料弄丟，是打從一開始就沒在記ua。這種事真的要有人主動查才會發現，客戶自己不會想到這
技術補充一個本文沒細講的：
apache預設用的log模組，logformat裡有沒有%{user-agent}i完全看vhost當初怎麼設，只有combined才有這欄。順帶一提nginx預設的log_format其實內建就有ua了，反而是apache這個歷史包袱比較常見。改完customlog那行也要記得reload或restart，不然設定不會生效，常常有人改完設定檔就以為結束了，隔天查還是common。
另外版主颱風天要注意安全，新竹風好大~
補一個更常見的狀況：
很多站根本沒手動設過logformat，是廠商當初裝apache用套件預設值，直接連到common格式，沒人特地選過，就是沒人動過而已。這篇想講的重點也不是叫大家都去手動修log（那當然要修，但那是it那邊的事），是想指出多數行銷團隊連『我可以查log』這個選項都沒想到，異常發生時第一反應永遠是重灌分析工具或換個儀表板，而不是回頭看伺服器自己留了什麼。
感謝關心，颱風天還是乖乖在家研究gpt5.6各版本xd各位注意安全!
感謝分享! 看完立馬想到要問我們負責網站的工程師『我們的access log有沒有記user-agent』，但轉念一想我連自己網站是apache還是什麼都不知道，是不是打電話問代管商就可以了，還是一定要工程師才回答得出來？先tag同事叫他去問，順便問一下我們家的格式是不是也還停在最陽春那種。