GA4 站內搜尋報表怎麼設定？搜尋字詞收集、判讀與修正流程

GA4 站內搜尋報表是什麼？和 Google 自然搜尋查詢差在哪？

GA4 站內搜尋報表（Site Search Report）指的是紀錄使用者在你的網站搜尋框輸入什麼字詞、看到什麼結果、之後做了什麼動作的資料。這些資料能直接告訴你：訪客在找什麼但站內找不到什麼，內容或商品缺口在哪裡，下一步該優化哪些頁面或分類。

多數網站經營者誤以為 GA4 會自動繼承 UA 的站內搜尋報表，但其實 GA4 需要另外設定才能收集站內搜尋事件。另一個常見混淆是把「站內搜尋字詞」和「Google 自然搜尋查詢」搞混，這兩種資料來源完全不同，回答的業務問題也不一樣。

站內搜尋字詞是使用者在你的網站搜尋框輸入的字

當使用者在你的網站輸入「防水背包」或「運費查詢」，GA4 會在搜尋結果頁網址中抓取查詢參數（如 ?q=防水背包），並以 view_search_results 事件和 search_term 參數紀錄。這筆資料代表使用者在你的網站內尚未找到目標內容，需要透過站內搜尋幫助導航。高頻搜尋字詞通常代表內容架構或導覽設計還有優化空間。

GSC 查詢是使用者在 Google 搜尋結果頁輸入的字

Google Search Console（GSC）顯示的是使用者在 Google 搜尋引擎輸入查詢後，看到你的網站出現在搜尋結果並點擊進來的資料。GSC 告訴你的是「使用者在 Google 找什麼，多少人看到你的網頁並點擊進來」，屬於外部流量分析的範疇，和站內使用者在你的網站搜尋框輸入什麼完全無關。

什麼情境該看站內搜尋，什麼情境該看 GSC

當你需要回答「站內哪些分類或商品被使用者主動搜尋但目前找不到合適結果」這類問題，應該看站內搜尋報表。當你需要回答「哪些 Google 關鍵字能帶來自然搜尋流量、哪些網頁排名可以再提升」，應該看 GSC 查詢報表。兩種資料回答不同問題，各自獨立存在，不應混用。

設定前先確認站內搜尋網址參數

在 GA4 後台啟用站內搜尋功能之前，必須先確認你的網站搜尋結果頁網址是否有攜帶查詢參數，以及參數名稱是否落在 GA4 預設支援的範圍內。沒有查詢參數或參數名稱不符，GA4 的加強型評估（Enhanced Measurement）無法自動辨識搜尋事件，報表只會是一片空白。

打開搜尋結果頁，看網址是否出現搜尋字詞

操作方式很簡單：在你的網站搜尋框任意輸入一個測試字詞（如「測試」），按下搜尋後觀察網址列。如果網址出現類似 https://yoursite.com/search?q=測試、/products?search=測試 或 /search?s=測試 這類格式，代表搜尋結果頁網址有攜帶查詢參數，GA4 有機會自動抓取。如果網址變成 https://yoursite.com/search 然後內容動態改變但網址沒變，那就是不換頁搜尋（又稱 SPA），GA4 自動收集會失效，必須透過 Google Tag Manager（GTM）手動送出事件。

確認參數名稱是否符合 GA4 預設值

GA4 加強型評估預設會辨識五個站內搜尋參數名稱：q、s、search、query、keyword。如果你的網站用的是 ?q=字詞 或 ?search=字詞，GA4 幾乎會自動偵測，不需要另外設定。如果你的網站自訂了其他參數名稱（如 ?find= 或 ?kw=），就必須在 GA4 後台手動新增這些參數名稱。

如果不換頁搜尋或 SPA，可能需要 GTM 自訂事件

單頁應用（Single Page Application，SPA）或AJAX 動態載入的搜尋系統，網址通常不會改變，GA4 加強型評估無法偵測到頁面變化。此時需要透過 GTM 自訂事件觸發條件，在搜尋行為發生時主動送出 view_search_results 事件和 search_term 參數。實作方式是在 GTM 中設定「自訂事件」觸發類型，並以 JavaScript 監聽搜尋框的送出行為，取出輸入值後送入 data layer。

GA4 站內搜尋設定步驟：加強型評估與查詢參數

GA4 收集站內搜尋資料的核心機制是「加強型評估」中的站內搜尋事件。這個功能會在偵測到搜尋結果頁時自動送出 view_search_results 事件，並從網址參數取出搜尋字詞存入 search_term 維度。以下七個步驟幫助你完成基本設定，設定完成後建議立刻用 DebugView 或即時報表驗證事件是否有被正確送出。

到管理後台確認資料串流

進入 GA4 管理後台，點選左側「資料串流」項目，選擇你正在使用的資料串流。確認「資料串流類型」為「網站」且網址正確。這裡是所有加強型評估事件收集的起點，如果資料串流綁定的網域和實際網站不符，站內搜尋事件可能會完全收不到。

開啟加強型評估中的站內搜尋

在資料串流頁面中，點選「加強型評估」區塊，找到「站內搜尋」選項並將它開啟。GA4 會提示你確認「是否在網站上收集站內搜尋資料」，點選確認即可。開啟後 GA4 會開始嘗試自動偵測含有查詢參數的搜尋結果頁，但前提是網址格式必須符合預設或你自訂的參數名稱。

新增或修正查詢參數

如果你的網站搜尋結果頁使用的參數名稱不在 GA4 預設的五個選項內，需要手動新增。進入加強型評估設定頁，找到「站內搜尋設定」區塊，在「查詢參數」欄位中新增你的自訂參數名稱。例如若你的網站用 ?find= 作為搜尋參數，就新增「find」。GA4 支援多個參數名稱同時設定，以分號分隔。

設定後先用 DebugView 或即時資料做初步確認

加強型評估設定完成後，GA4 需要數小時到 48 小時處理資料才能在標準報表中呈現。在這段等待期內，可以先使用 DebugView 功能即時監控事件發送狀況。開啟 GA4 左側「偵錯」選單，選擇 DebugView，確保「偵錯模式」狀態為開啟，然後在自己的網站上執行一次搜尋操作，觀察 DebugView 是否出現 view_search_results 事件，以及事件參數中是否正確出現 search_term 並含有你輸入的測試字詞。

GA4 站內搜尋報表模板：探索報表欄位怎麼放

GA4 沒有內建像 UA 那樣的「站內搜尋報表」固定入口，你需要在「探索」（Explorations）功能中自行建立報表的資料結構。以下提供可直接複製使用的探索報表配置，幫助你在五分鐘內建立第一份站內搜尋字詞報表。這個模板同時適用於行銷執行者快速建立報表，以及內容營運者用來觀察搜尋行為。

列：搜尋字詞；值：事件計數、總使用者、工作階段、關鍵事件、收益

在探索報表的列（Rows）維度選擇「搜尋字詞」（Session Search Term）。這個維度會以去重後的搜尋字詞作為資料分組依據。在值（Values）區塊依序加入「事件計數」（Event count）、「總使用者」（Total users）、「工作階段」（Sessions）、「關鍵事件」（Key events）、「收益」（Revenue）。事件計數看的是搜尋行為發生次數，總使用者看的是獨立人數，工作階段能計算每次造訪的搜尋頻率，關鍵事件和收益則用來評估該搜尋字詞的商業轉換價值。

篩選器：事件名稱等於 view_search_results

為避免報表中摻入其他事件造成數值失真，需要新增一個篩選器條件：事件名稱（Event name）等於（equals）view_search_results。這個篩選器確保資料只來自站內搜尋事件，不會因為使用者在網站其他動作而稀釋搜尋字詞的統計數字。如果你的網站同時有自然搜尋進站的頁面也包含相同參數，需要更精確地排除非搜尋結果頁面的誤觸。

排序：先用事件計數找需求量，再用關鍵事件或收益找商業價值

報表建立完成後，預設排序通常以搜尋字詞的字母順序排列，這對分析沒有幫助。將排序改為「事件計數」遞減排列，第一眼就能看到哪些搜尋字詞被輸入最多，代表使用者最頻繁尋找的內容或商品。再切換到「關鍵事件」或「收益」排序，能看到哪些高搜尋量字詞同時帶來轉換，代表具體商業價值。這兩種排序視角可以分別回答「使用者需要什麼」和「這些需求能帶來什麼營收」兩個核心問題。

建議日期範圍用最近 28 天與前期比較，避免單日誤判

站內搜尋資料容易受到促銷活動、廣告導流或季節性事件影響，單日資料往往失真。建議設定「最近 28 天」與「前期 28 天」做對比，例如和前一週或前一月比較。這種做法能過濾短期波動，看出搜尋行為的穩定趨勢。如果你的網站有週期性的內容更新或行銷活動，也可以對齊這些事件時間點做交叉觀察。

GA4 站內搜尋報表該看哪些指標

把探索報表拉出來只是第一步，真正的價值在於看懂每個指標代表的業務意涵。站內搜尋報表的指標不應該單獨解讀，而要交叉比較才能產生可行動的洞察。以下矩陣將每個指標對應到具體的判斷情境和建議動作。

高搜尋量代表真實需求，不一定代表搜尋結果好

事件計數高的搜尋字詞代表大量使用者在你的網站上主動輸入這個詞找內容或商品，這表示該需求是真實且有強度的。但搜尋量高並不等於你提供的搜尋結果品質好、高搜尋量也可能同時伴隨高跳出率或低轉換，代表使用者頻繁搜尋但仍然找不到想要的東西，只是他們選擇放棄而非修正搜尋。

高搜尋量低轉換代表內容、商品或搜尋結果不匹配

當一個搜尋字詞的事件計數排名很高，但關鍵事件次數極少甚至收益是零，通常代表三種可能性之一：你的網站根本沒有這個品項或內容；現有的商品命名或文章標題和使用者搜尋用的詞不一致，導致搜尋演算法無法正確匹配；搜尋結果頁的排序或呈現方式讓使用者點擊後發現不符合預期而快速離開。遇到這種情況不應該先怪搜尋引擎，而是回頭檢查商品命名、分類標籤和落地頁內容。

搜尋後離開可視為找不到答案的警訊

GA4 可以透過事件序列（Event sequence）觀察使用者在搜尋後的行為。如果搜尋事件發生後的使用者後續動作是「離開」（exit）或「離站」（bounce），而不是繼續瀏覽其他頁面，代表使用者認為搜尋結果無效。這種訊號在 UA 舊版報表稱為「搜尋離開」（Search Exit），在 GA4 中需要透過「路徑探索」（Path Exploration）或自訂漏斗來近似觀察。雖然 GA4 沒有內建「搜尋後離開率」這個單一指標，但這個行為模式仍然值得追蹤。

搜尋修正代表命名、分類或搜尋結果排序可能不直覺

如果同一個使用者在短時間內連續輸入多個相似的搜尋字詞，例如先搜「運動鞋」再搜「跑步鞋」再搜「男跑步鞋」，代表你的分類命名或搜尋結果排序不夠直覺，迫使使用者必須層層縮小範圍。多數電子商務網站的使用者不會只有一次搜尋行為，這類搜尋修正序列透露的是網站資訊架構和搜尋演算法的改善空間。可以透過「區段」功能建立「有連續搜尋事件的工作階段」區段，觀察這批使用者的整體轉換率是否低於平均。

站內搜尋字詞怎麼轉成 SEO、商品與 UX 優化

站內搜尋資料的最終目的不是放在報表裡觀賞，而是要轉化成具體的優化行動。不同類型的搜尋缺口需要不同的處理方式，以下矩陣以情境分類說明每種缺口應該怎麼回應，而非只停留在概念說明。

高搜尋量但無內容：新增文章、FAQ 或分類入口

當一個搜尋字詞的事件計數很高，但你的網站根本沒有對應的內容或商品，卻沒有任何「無結果頁」（No Results Page）的流量，這個落差說明使用者可能搜尋後沒有得到任何指引就離開了。解決方案是在無結果頁或相關類別頁面新增「您可能想找」的推薦內容，建立對應的文章或 FAQ 解答常見問題，並在站內搜尋結果頁提供相關分類入口而非空白結果。

高搜尋量但無商品：檢查選品、商品命名或搜尋同義詞

電商網站常見的問題是某些字詞被搜尋很多次，但站內根本沒有這個商品。這可能代表你的商品線確實缺少這個品項，值得評估是否新增採購；也可能是商品名稱和規格表達和消費者認知不一致，例如你賣的產品型號是「XYZ-100」，但多數消費者搜尋的是「XYZ100」或「XYZ100 規格」。另一種可能是消費者用行業術語搜尋，但你的商品標題用的是技術代號。檢查商品命名與描述中的關鍵字覆蓋，並建立搜尋同義詞資料庫讓搜尋演算法能正確匹配。

高搜尋量但低參與：改善搜尋結果排序、篩選器與落地頁文案

搜尋量高代表需求存在，但如果搜尋後的平均工作階段長度（Average session duration）異常短、跳出率異常高，代表使用者點進去的頁面或商品不符合預期。首先檢查搜尋結果頁的排序邏輯是否將暢銷品或高相關商品排在前面；其次檢查篩選器是否能快速幫使用者縮小範圍；最後檢查落地頁的標題、圖片和摘要是否和搜尋字詞的預期一致。如果文案和實際內容有落差，會造成高點擊但低停留的反常現象。

自然搜尋進站後又站內搜尋，通常代表原落地頁沒有滿足下一步需求

透過「流量來源」維度過濾「自然搜尋」（Organic Search）進站的訪客，觀察這批人進入你的網站後又進行了哪些站內搜尋。如果有大量自然搜尋流量進站後隨即使用站內搜尋，代表你為這些關鍵字順位優化的落地頁內容深度不足，沒有辦法在單一頁面內解答使用者的完整需求。這種情境適合用於 SEO 內容策略規劃、把站內搜尋字詞當成「內容群缺口」的地圖，優先在自然搜尋流量集中的類別下新增更多深度內容或系列文章。

進階站內搜尋分析：依來源、到達頁、裝置與國家切分

基本的站內搜尋字詞報表只能告訴你「使用者搜尋了什麼」，但無法回答「誰在搜尋」、「從哪裡來的」、「在哪個頁面卡住」、「用什麼裝置找不到」。進階切分維度能讓你看到不同族群、不同流量來源、不同頁面之間的搜尋行為差異，這些差異往往藏著最具體的改善方向，而這些方向是主競品文章很少深入探討的。

依來源切分：不同流量帶來的站內需求是否不同

透過「工作階段來源與媒介」（Session source/medium）維度過濾不同流量來源的站內搜尋行為。直接流量（Direct）進站的訪客通常已經對你的品牌有認知，他們的搜尋行為代表對網站內容深度的需求；付費流量（Paid）進站的使用者可能是被廣告素材吸引，進站後的搜尋行為透露的是商品或分類命名與廣告文案的一致性；自然搜尋流量（Organic）進站後的搜尋代表該頁面內容未能在第一時間滿足使用者需求，是 SEO 內容策略的重要參考依據。

依到達頁切分：哪些頁面讓使用者必須再搜尋

到達頁（Landing Page）是訪客進站後第一個看到的頁面。如果某個頁面的跳出率異常高且隨即觸發站內搜尋，代表這個頁面的內容或引導設計無法幫使用者找到下一步資訊。將「到達頁」維度加入探索報表的次要維度或建立自訂區段，觀察哪些頁面的「跳出後站內搜尋率」最高。這些頁面優先需要優化：可能是內部連結不夠明顯、分類導覽不易理解、或是頁面本身的資訊密度不足以回答使用者當下的問題。

依裝置類別切分：手機搜尋多可能代表導覽或分類不夠清楚

行動裝置（Mobile）使用者在網站上的瀏覽與搜尋行為模式通常與桌面裝置不同。如果行動裝置的站內搜尋事件計數佔比異常高，可能代表手機版的導覽選單設計不易理解，或是分類層級在行動介面上不夠直覺，迫使手機使用者傾向用搜尋框而非點擊導覽來找內容。這類洞察適合用來推動網站 UX 改善提案，特別是針對行動版網站的資訊架構重整。

SEO 流量進站後搜尋了什麼，可回推內容群缺口

當自然搜尋流量進站後又執行站內搜尋，代表該訪客從 Google 進入一個未被滿足需求的頁面，必須依賴站內搜尋嘗試自行找到解答。這個行為序列是 SEO 內容策略的珍貴資料：哪些類別頁面讓自然流量進站後仍然需要再搜尋，代表該類別需要補充更完整的內容或系列文章；哪些搜尋字詞在自然流量區段中排名特別高，代表使用者對這個主題有高度興趣但現有內容深度不足，可以作為下一波內容建設的首要候選。

GA4 找不到站內搜尋資料怎麼辦

報表空白是最常見的站內搜尋設定問題。空白可能來自三個方向：事件根本沒有被送出、事件有送出但參數沒被正確擷取、資料還在處理中尚未出現在報表中。面對空白報表不需要急著懷疑 GA4 故障，用以下決策樹逐步排除，通常都能找到原因並修復。

事件沒出現：先看網址參數與加強型評估

開啟 GA4 即時報表（Realtime）觀察當下是否有任何 view_search_results 事件。如果即時報表中完全看不到這個事件，第一步檢查你剛才測試的搜尋結果頁網址是否真的帶有查詢參數，GA4 加強型評估需要網址包含參數才能觸發事件；第二步確認加強型評估的站內搜尋功能已經開啟；第三步確認參數名稱是否已在自訂參數清單中新增。如果網址根本沒有參數，就必須走 GTM 自訂事件的路線，不能依賴加強型評估的自動偵測。

有事件但搜尋字詞空白：檢查參數名稱是否被 GA4 收到

如果在 DebugView 或即時報表中看到 view_search_results 事件確實存在，但「搜尋字詞」維度卻是空白，通常是參數名稱沒有被 GA4 正確對應。這種情況有兩種可能：一是參數名稱不在預設五個也不在你的自訂清單中，二是參數值在網址中被 URL 編碼後導致無法正確讀取。解決方式是在 GA4 DebugView 的事件詳情中展開「事件參數」列表，確認 search_term 參數是否真的收到值，如果完全沒有這個參數就回頭檢查自訂參數設定。

SPA 或不換頁搜尋：用 GTM 送 view_search_results 與 search_term

如果你的網站搜尋框送出後網址不變，GA4 的加強型評估無法自動偵測頁面變化。此時需要透過 GTM 手動部署：建立一個「元素可見度」或「自訂事件」觸發條件監聽搜尋框的 submit 事件，擷取 input 值後用 gtag 指令送出 view_search_results 事件，並將搜尋字詞作為 search_term 參數傳入。GTM 的設定雖然比開啟加強型評估多一個步驟，但可以完整控制事件的觸發時機與資料內容，是 SPA 網站的必要解法。

剛設定完成先等資料處理，不要用當天資料下結論

GA4 的資料處理延遲（Data processing latency）通常需要 24 到 48 小時，特別是加強型評估事件可能在設定變更後需要更長時間才會完整寫入。在設定完成後的 24 小時內，如果即時報表能看到事件但標準報表仍無資料，這是正常現象，不需要急著調整設定。建議在設定完成 48 小時後再檢視標準報表的完整資料，如果超過 72 小時仍無資料才啟動故障排除流程。

為什麼 GA4 找不到 UA 舊版站內搜尋報表

從 Universal Analytics 遷移到 GA4 的使用者，常常直覺地以為「站內搜尋報表會自動存在」，但事實上 GA4 的資料模型和 UA 完全不同。UA 的站內搜尋報表是預先建立好的固定報表，只要開啟就能看到；而 GA4 沒有這樣的固定入口，需要你自己建立探索報表、確保事件正確發送，並理解新的資料查詢邏輯。這個差異不是 GA4 的功能缺失，而是產品架構的改變，需要用新的方式重建這項分析能力。

UA 的站內搜尋報表不是 GA4 的固定入口

在 UA 中，站內搜尋報表是「行為」報表下的內建報告，只要在管理後台啟用「站內搜尋網址參數」設定，報表就會自動生成。GA4 完全移除了這個預設報表介面，改為以事件導向（Event-based）的資料模型收集所有資料。要在 GA4 中看到站內搜尋資料，你需要建立探索報表（Explorations）並設定對應的維度與篩選器。這個改變意味著：不是「GA4 沒有站內搜尋功能」，而是「GA4 要求你用不同方式重建這個功能」。

GA4 以事件與參數建立站內搜尋分析

GA4 的所有資料都是以「事件」為單位記錄，站內搜尋只是其中一種事件類型。view_search_results 是用來標記「使用者看到搜尋結果頁」的事件，而搜尋字詞則存在 search_term 這個事件參數中。你可以透過「搜尋字詞」維度查詢所有含 search_term 的事件，並用事件名稱篩選 view_search_results 來確保只分析站內搜尋行為。這種資料模型的優點是彈性更高，可以自由組合維度與指標，但缺點是沒有 UA 那種一鍵開啟的傻瓜式報表。

搜尋離開、搜尋修正可用事件序列與搜尋後行為近似觀察

UA 的站內搜尋報表有一個指標叫「搜尋離開率」（Search Exit Rate），代表使用者在站內搜尋後直接離開的比例；另一個指標「搜尋修訂率」（Search Refinement Rate）代表使用者在短時間內連續修正搜尋字詞的比例。GA4 沒有這兩個預設指標，但你仍然可以透過「路徑探索」（Path Exploration）功能建立近似的觀察方式：將路徑起點設為 view_search_results 事件，觀察搜尋後使用者的下一個動作是離開、點擊特定頁面還是再次搜尋。這種分析方法比 UA 的固定指標更有彈性，只是需要多一步設定。

資料治理：站內搜尋字詞不要收進個資，長期追蹤要注意保留期

站內搜尋字詞看似只是一般內容關鍵字，但實際上使用者在搜尋框輸入的內容可能遠超過你想收集的範圍。有人在找「iPhone 價格」，也有人在找「女朋友電話」或「自己的Email」。如果搜尋框的資料沒有經過處理就直接傳入 GA4，可能會觸發個人資料（Personally Identifiable Information，PII）的合規風險。同時，GA4 的資料保留設定會影響長期趨勢分析的可行性，需要在設定初期一併納入考量。

搜尋框可能被輸入 Email、電話、姓名，要先排除

網站搜尋框的設計通常沒有嚴格的輸入格式限制，使用者可能輸入任何文字，包括 email 位址、電話號碼、真實姓名、身分證字號或其他可用於識別特定個人的資料。當這些資料透過 view_search_results 事件傳入 GA4 並存入 search_term 參數，就會成為資料庫中的潛在 PII。根據 Google 的隱私權政策，GA4 不應收集可用於識別個人身分的資料。處理方式是對搜尋字詞進行資料前處理（Data preprocessing），在事件傳送前過濾掉符合 email 格式、手機號碼格式或特定命名模式的輸入。這個處理可以在 GTM 的自訂 JavaScript 變數中實作，也可以透過 Google Tag Manager Server Side 進行過濾。

探索報表資料有保留期限，長期趨勢要提早規劃

GA4 標準版（Free）的資料保留設定影響兩個維度的資料：事件層級資料（Event-scoped data）預設保留 2 個月；使用者層級資料（User-scoped data）預設保留 14 個月。探索報表預設使用事件層級資料，意味著兩個月前的站內搜尋字詞原始資料會被刪除。這對需要觀察長期趨勢的資料分析需求造成限制，例如要比較去年和今年的同期站內搜尋行為，會發現歷史資料已經不存在。解決方案是在資料刪除前建立自動匯出流程，將原始事件資料定期匯出至 BigQuery 或 Google Sheets 進行長期保存。

需要跨年度追蹤時，評估 BigQuery 或固定匯出流程

如果站內搜尋資料對你的業務具有策略價值，需要做跨年度趨勢分析或年度報告，那麼在 GA4 後台的資料保留設定之外，必須額外規劃資料長期保存機制。GA4 的 BigQuery 串接功能可以將所有原始事件資料即時同步到 BigQuery，不受 GA4 內部保留期限限制；另一個替代方案是使用 Looker Studio 串接 GA4 並設定自動排程匯出到 Google Sheets，雖然匯出頻率和資料量有上限，但對於中小型網站已經足夠。無論選擇哪種方式，強烈建議在年初就建立好匯出流程，而不是等到年底才發現歷史資料已經被刪除。