Google Search Console 教學：看懂報表找問題出在哪

Google Search Console 是 Google 官方提供的搜尋能見度與網站診斷工具。它能告訴你網站在 Google 搜尋中的曝光、點擊、查詢、頁面、索引狀態、Sitemap 讀取與部分體驗問題，但它不是 GA4，也不是排名追蹤器。真正會用 GSC 的人，不是每天看數字，而是知道每個報表在回答哪一種 SEO 問題。

如果你只把 GSC 當成「提交索引」或「看關鍵字排名」的工具，會很快誤判。GSC 的價值在於把 Google 看到的搜尋端訊號攤開，讓你判斷下一步要查 sitemap、索引、速度、內容、內鏈，還是 GA4 的站內行為資料。

Google Search Console 是什麼？先搞懂它能看什麼

GSC 是搜尋端資料，用來看網站在 Google 搜尋中的能見度與技術狀態。Google 官方的 Search Console 入門說明 把它定位為協助網站擁有者了解搜尋成效、監控問題並改善搜尋呈現的工具。它記錄的是 Google 爬蟲與索引系統對你網站的實際觀察結果，不是網站內部流量或使用者行為的統計。 延伸閱讀：網站改版 SEO 風險控制。

GSC 最常回答四種問題：Google 有沒有看到我的頁面、使用者用什麼查詢看到我、哪些頁面有曝光和點擊、Google 在索引或體驗上發現什麼問題。這些問題都發生在「Google 搜尋結果」這一側，所以它不會完整回答使用者進站後做了什麼。當你打開 GSC 卻不知道下一步該修什麼，通常是因為把「搜尋端訊號」和「站內行為訊號」混在一起看，導致判斷失準。

GSC 的資料範圍與報表對應

GSC 的每一張報表都對應一個具體的搜尋環節。成效報表回答「曝光與點擊從哪裡來」，網頁索引與網址檢查回答「Google 有沒有收錄我的頁面」，Sitemaps 報表回答「Google 有沒有照我給的路徑去爬」，Links 報表回答「外部連結如何指向我」，體驗相關檢查目前主要包括 Core Web Vitals 與 HTTPS；行動裝置可用性報表已退役，介面項目也會依網站資料與 Google 更新而不同。把問題對應到報表，才能知道該去哪個頁籤找答案。

這四類問題的答案彼此獨立，但決策時需要交叉比對。例如成效報表顯示某頁曝光高但點擊率低，你可能會先懷疑標題與描述不夠吸引人，若同時看到 Core Web Vitals 問題，應把它列為另一條使用者體驗診斷線；GSC 不能證明它造成搜尋結果頁上的低 CTR，也不能據此排除標題、摘要、版位或查詢意圖等因素。這種交叉判斷是 GSC 報表使用的核心方法。

下表整理常見問題與 GSC 報表的對應關係，幫助你快速定位該看哪個頁籤。表格只列出 GSC 能直接回答的部分，若問題超出搜尋端範圍，會標註應轉往其他工具。

你想知道的問題	GSC 能不能回答	主要報表
哪些查詢帶來曝光和點擊	可以	成效報表
頁面是否被 Google 編入索引	可以	網頁索引、網址檢查
Sitemap 是否被讀取	可以	Sitemaps 報表
使用者進站後有沒有轉換	不完整	應看 GA4 或 CRM

從報表到行動：先確認問題歸屬

當你看到一項數據異常，第一步不是急著修改頁面，而是確認這個訊號屬於「收錄問題」「曝光問題」還是「點擊問題」。收錄問題會出現在網頁索引與網址檢查，曝光問題會出現在成效報表的曝光量與查詢維度，點擊問題則反映在點擊率與平均排名。三種問題的修復手段完全不同，混在一起處理只會讓修改失去方向。

舉例來說，若成效報表顯示某頁面曝光量極低，但網址檢查顯示該頁已收錄且狀態正常，問題可能出在頁面主題與搜尋意圖不符，或內部連結權重不足。此時應檢查該頁的內容與其他頁面的關聯性，而不是急著改標題。反之，若曝光量正常但點擊率遠低於同查詢的其他頁面，才需要著手調整標題與 meta description。

GSC 的價值在於它提供 Google 搜尋與索引系統的官方資料，但成效表格會省略匿名查詢、只保留重要資料列，部分報表也只列代表性 URL，並不是完整逐筆原始資料。每次決策前，先確認你看到的數據來自哪一張報表，再判斷該數據對應的是哪一個搜尋環節，最後才動手修改。這個順序能避免把時間花在錯誤的修正上。

GSC 怎麼設定：網域資源、網址前置字元與驗證方式

設定 Google Search Console 的第一步，是先決定要用哪一種資源類型，再完成網站擁有權驗證。網域資源適合想完整監控整個 domain 的網站，網址前置字元適合只管理特定協定或子目錄的情境。Google 的網站擁有權驗證說明列出 DNS、HTML 檔案、HTML 標記、Google Analytics 與 Google Tag Manager 等方式，每一種的適用條件與權限要求不同，選錯會直接影響後續報表的資料範圍。

實務上，能改 DNS 就優先選網域資源，因為它會涵蓋 http、https、www、非 www 和子網域，等於把整個 domain 底下所有版本的網址一次收齊。若你只拿得到某個網站後台，或只想驗證單一版本，網址前置字元比較快，但後續報表可能只看到那個前綴的資料，例如只看到 https://www.example.com，而漏掉 http 或子網域的流量。這個差異在合併報表時會造成困擾，所以設定前先確認自己手上握有哪些權限。

網域資源與網址前置字元的取捨

網域資源的驗證方式以 DNS TXT 記錄為主，通常需要登入網域註冊商或 DNS 代管平台。只要你能新增一筆 TXT 記錄，Google 就能確認你對整個 domain 的控制權，之後所有子網域、所有協定版本的資料都會自動彙整到同一份報表。對於品牌官網、企業站或有多個子網域的網站來說，這是資料最完整的選擇，不需要逐一為每個子網域建立資源。

網址前置字元則允許你用 HTML 檔案、HTML 標記、GA4 或 GTM 等方式驗證，門檻較低，適合只有單一網站後台權限、無法碰 DNS 的人。但要注意，這種資源只涵蓋你輸入的那個完整前綴，例如 https://www.example.com 與 https://example.com 會被視為兩個不同資源，http 與 https 也是分開的。若要跨多個 URL-prefix 資源彙整資料，可透過匯出、Search Console API 或報表工具整合；「變更地址」工具是網站搬遷到新網域時使用，不是合併資源報表的功能。

四種驗證方式的實際適用情境

DNS 驗證通常不受網站模板改版影響，適合長期經營；但驗證記錄仍必須保留，DNS 記錄被移除或權限與網域狀態改變時，所有權可能需要重新確認。HTML 檔案驗證需要你把一個指定檔案上傳到網站根目錄，適合有 FTP 或檔案管理權限的人；HTML 標記則是在首頁的 head 區塊插入一段 meta 標籤，適合使用 CMS 且能編輯主題原始碼的人。這兩種方式都依賴網站本身，若日後移除檔案或標記，驗證就會失效。

Google Analytics 與 Google Tag Manager 的標記驗證只適用 URL-prefix 資源，必須使用符合官方要求的同一 Google 帳號權限，且驗證標記需位於 Google 能讀取的位置；實際權限名稱應以目前驗證畫面為準。但這種方式依賴追蹤碼持續存在，且帳號權限必須一致，若 GA4 或 GTM 的權限被調整，GSC 的驗證狀態也可能受影響。選擇驗證方式時，先問自己哪一項權限最穩定、最不會被異動，再決定用哪一種。

選項	適合誰	優點	注意事項
網域資源	品牌官網、企業站、多子網域網站	資料範圍最完整	通常需要 DNS 權限
網址前置字元	只管理某一版網址的人	驗證方式較多	http、https、www 可能要分開
HTML 檔案或標記	有網站檔案或後台權限的人	工程或 CMS 可快速處理	驗證檔或標記不能移除
GA4 或 GTM	已經有追蹤碼管理的人	不用碰 DNS	帳號權限要一致

設定完成後，GSC 會開始收集資料，但新資源不會立刻有完整報表，通常需要幾天到一週的累積時間。這段期間可以先確認驗證狀態是否顯示為「已驗證」，並提交 Sitemap 協助 Google 發現網站的重要 URL；提交成功不保證抓取、索引或速度提升。若驗證失敗，檢查 DNS 記錄是否生效、HTML 檔案是否放在正確目錄，或追蹤碼是否正常載入，這些是設定階段最常見的問題來源。

GSC、GA4、排名工具差在哪裡

GSC 的資料來自 Google 搜尋結果的曝光與點擊，回答的是「Google 搜尋端怎麼看待你的網站」；GA4 的資料來自網站或 App 內埋設的事件追蹤，回答的是「使用者進站之後做了什麼」；排名工具則從指定地區、裝置與查詢去抓取 SERP，回答的是「特定關鍵字在搜尋結果中的位置」。三者資料來源不同，不能互相替代，把 GSC 點擊當成 GA4 session，或把 GSC 平均排名當成每日精準排名，都是常見誤判。

先確認你要回答的問題，再選工具

如果你要分析使用者進站後有沒有完成轉換、停留多久、從哪個頁面離開，應該看 GA4 事件與轉換報表設定，因為 GSC 只記錄搜尋結果層級的曝光與點擊，無法告訴你點擊之後的行為路徑。反過來說，如果你想知道某個查詢在 Google 搜尋結果中總共曝光多少次、獲得多少點擊，GA4 完全無法提供這類資料，因為它看不到搜尋結果頁。

如果你要追蹤一組關鍵字每天在特定地區與裝置上的排名位置變化，應該搭配 Google 排名追蹤的實作方法，因為 GSC 的平均排名是各次曝光中網站最上方結果位置的平均值，會受到查詢、地區、裝置與搜尋外觀等條件影響，不能當成單一關鍵字在特定時間點的固定名次。排名工具抓取 SERP 的頻率與條件，則能提供更接近真實搜尋情境的位置數據。

實務上，這三類工具各自回答不同層次的問題：GSC 告訴你 Google 有沒有收錄、哪些查詢帶來曝光、點擊率是否異常；GA4 告訴你進站後的使用者行為與轉換；排名工具告訴你競爭對手與特定關鍵字的相對位置。先確認你當下要診斷的問題屬於哪一層，再決定打開哪個報表，而不是三個工具同時開著卻不知道從哪裡開始。

資料邊界與常見誤用情境

GSC 的資料來自 Google 搜尋端，涵蓋搜尋曝光、點擊、查詢字串與索引狀態，但它不包含站內搜尋、直接流量或外部連結點擊。GA4 的資料來自網站或 App 的事件追蹤，能記錄頁面瀏覽、按鈕點擊、表單提交等行為，但它無法得知 Google 搜尋結果中的曝光次數。排名工具則透過模擬或抓取 SERP 取得位置數據，但這類資料並非 Google 官方數據，且不同工具因抓取頻率與地區設定不同，結果可能有所差異。

常見的誤用情境包括：把 GSC 的點擊數直接當成 GA4 的工作階段數，忽略使用者可能多次點擊同一結果或透過其他管道進站；把 GSC 的平均排名當成精準排名，忽略平均排名是加權計算後的結果；或把排名工具的位置數據當成 Google 官方索引診斷依據，忽略排名工具無法反映索引狀態與收錄問題。理解這些邊界，才能避免在錯誤的資料基礎上做出決策。

工具	資料來源	最適合回答	不適合回答
GSC	Google 搜尋端資料	曝光、點擊、查詢、索引問題	站內轉換漏斗
GA4	網站或 App 事件資料	使用者行為、事件、轉換	完整搜尋曝光
排名工具	模擬或抓取 SERP	指定關鍵字位置追蹤	Google 官方索引診斷

當你發現 GSC 曝光正常但點擊率偏低，問題可能出在標題與描述吸引力不足，此時應回到 GSC 的成效報表檢視查詢與頁面層級的 CTR，而不是急著打開排名工具。當你發現 GA4 的工作階段數與 GSC 點擊數差距過大，應先檢查 GA4 的追蹤程式碼是否正確安裝、是否有重複觸發事件，而不是直接認定資料異常。當你需要向主管或客戶報告某個關鍵字的每日排名變化，才需要搭配排名工具，因為 GSC 無法提供單一關鍵字的即時位置。

成效報表怎麼看：查詢、頁面、CTR、平均排名

成效報表是 GSC 最常用的 SEO 報表，核心指標是點擊、曝光、CTR 和平均排名。Google 的 成效報表指標說明 定義了這些數字的計算方式，但 SEO 判斷不能只看單一指標。單看曝光會誤以為內容有效，單看點擊會忽略曝光不足的潛在需求，單看平均排名則容易把平均值當成固定名次。正確的讀法是把四個指標放在同一組查詢或頁面資料中互相對照，才能判斷問題出在「沒被看到」還是「看到了不想點」。

交叉看「查詢」和「頁面」是成效報表的基本功。查詢告訴你使用者用什麼字看到你，頁面告訴你哪個 URL 承接那些需求。高曝光低 CTR 可能是標題或意圖不匹配；點擊下滑但曝光沒掉，可能是 SERP 版位或標題吸引力問題；平均排名小幅波動，通常不值得立刻大改內容。真正值得動手的是「曝光穩定、點擊持續下滑」或「曝光高、CTR 遠低於同頁面其他查詢」這兩種組合，前者指向標題與摘要的吸引力衰退，後者指向搜尋意圖與頁面內容的落差。

查詢報表：先分品牌詞與非品牌詞，再看意圖

查詢報表列出部分觸發網站曝光的搜尋字詞；為保護隱私會省略匿名查詢，表格也會截斷資料列，因此不能把它當成完整查詢清單。品牌詞的 CTR 通常遠高於非品牌詞，因為使用者已經知道你的存在，點擊行為反映的是信任而非搜尋結果的吸引力。若把品牌詞與非品牌詞混在一起看平均 CTR，會高估頁面在陌生使用者面前的表現，也會讓真正的問題被稀釋。

處理方式是在查詢報表中先篩掉包含品牌名稱的查詢，剩下的非品牌詞才值得逐筆檢視。對每一筆非品牌查詢，判斷它的搜尋意圖是資訊型、導覽型還是交易型，再對照頁面內容是否直接回應那個意圖。例如一個「如何設定」的查詢點進產品頁，曝光再高也很難轉成點擊，因為使用者要的是步驟說明而非產品介紹。這種情況下，調整標題與 meta description 只能治標，真正該做的是在頁面中補上符合該意圖的內容區塊，或另建一篇對應的指南文章。

頁面報表：找出「有曝光沒點擊」的 URL，而不是排名最低的 URL

頁面報表以 URL 為單位彙整成效，適合用來找出「被 Google 收錄且獲得曝光，但點擊率異常低」的頁面。排名最低的 URL 不一定最需要處理，因為低排名可能來自競爭強度或頁面主題太窄；較值得優先檢查的是已有穩定曝光、且在控制查詢、裝置、國家與搜尋外觀後 CTR 明顯偏離自身基準的頁面。排名 5 到 10 或低於全站平均不能單獨證明標題有問題；可用過去區間作基準，但 90 天不是官方固定門檻。

頁面報表也適合用來檢查「多個查詢共用同一個 URL」的情況。當一個頁面同時承接數十筆查詢，代表它是一個主題樞紐，這時要確認每一筆主要查詢的意圖是否都被頁面內容覆蓋。若發現某幾筆查詢的曝光高但點擊極低，且這些查詢的意圖與頁面主軸明顯不同，就應該考慮把那些查詢導向更合適的頁面，或在原頁面中新增一個獨立章節來承接。頁面報表不該只看總點擊數，而是要拆到查詢層級，才能看出單一 URL 內部的成效分布。

CTR 與平均排名：用相對變化判斷，不用絕對數字判斷

CTR 的絕對值受產業、查詢類型與品牌知名度影響極大，沒有通用的「好 CTR」標準。比較合理的做法是看同一查詢或同一頁面在不同時間區間的 CTR 變化，並搭配平均排名的變動一起解讀。若 CTR 下降但平均排名大致持平，只能先判定點擊表現改變；仍要檢查查詢組成、搜尋外觀、SERP 功能、品牌與季節性，不能直接歸因於競爭者標題。若平均排名也下滑，內容相關性與頁面品質只是待驗假說之一。

平均排名是多次曝光位置的平均值，不是單一關鍵字的固定名次。同一個查詢在不同裝置、不同地區、不同個人化設定下，排名本來就會浮動，平均值只能反映大致位置。要判斷排名趨勢，應在成效報表中加上國家與裝置篩選，分開看行動版與桌機版的表現，並拉長到 28 天或 90 天的區間來觀察趨勢。單日或單週波動可能來自樣本量、查詢組成、需求、SERP 版位或網站變更；先確認資料量與變更記錄，再決定是否修改內容。

四個指標的交叉判斷可以濃縮成一個流程：先從頁面報表找出曝光量大的 URL，再切到查詢報表看該 URL 承接哪些字詞，接著篩掉品牌詞，最後對每一筆非品牌詞比較 CTR 與平均排名的相對變化。若曝光高、排名穩定、CTR 低，優先改標題與 meta description；若曝光與 CTR 同時下滑，優先檢查內容是否過時或競爭者是否新增了更完整的資源；若曝光低但點擊率高，代表頁面符合少數人的需求，下一步是擴大主題覆蓋範圍，讓它承接更多相關查詢。

索引與網址檢查：什麼時候該用 URL Inspection

當你只想知道「這一個網址」在 Google 眼中的狀態時，就用 URL Inspection。它回答的是單一問題：這個 URL 有沒有被索引？Google 抓到的是哪個版本？有沒有被 canonical 指向別處？與其只看 Page indexing 報表的群組資料，可輸入網址查看 Google 最近一次索引版本的判定；這不是即時狀態，需另按「測試實際網址」檢查目前可存取性。Google 的網址檢查工具說明清楚列出，這項工具能確認索引狀態、canonical 選擇、抓取紀錄，並提供即時測試功能，讓你在修正後立刻驗證。

判斷的關鍵在於問題的規模。如果你發現單篇重要頁面沒有收錄，例如一篇主打關鍵字的新文章或產品頁，先用 URL Inspection 確認它是否被 Google 看過、抓取時是否遇到阻擋、最後被索引的版本是哪一個。但如果你在 Page indexing 報表裡看到數百個頁面同時出現「已檢索但尚未編入索引」或「替代網頁含有適當 canonical 標記」，這就不是單一網址的問題，而是網站結構或內容品質的系統性狀況，應該轉往爬取與索引診斷指南，從範例 URL 與類型分布找出共同原因。前者是單頁檢查，後者是批次問題排查，兩者使用的時機與後續動作完全不同。

從報表情境判斷該開哪個工具

實務上，你通常不是先決定工具，而是先看到一個現象，再判斷該用哪個功能。以下四種最常見的情境，可以幫助你建立判斷基準。新文章發布後，可用 URL Inspection 查看最近索引狀態並執行即時測試；即時測試只檢查 Google-InspectionTool 當下能否存取頁面，不等於觸發一般 Googlebot 抓取，也不會驗證 canonical 選擇或所有索引條件。

當 Page indexing 報表顯示大量頁面未編入索引，你要做的不是逐筆輸入網址，而是先看報表分類的類型與數量，再點開幾個範例 URL 確認共同特徵。若 Google 選了不同的 canonical，例如你宣告 A 版本但 Google 選擇 B 版本，URL Inspection 會同時顯示「使用者宣告的 canonical」與「Google 選定的 canonical」，讓你看見兩者差異並決定是否調整內部連結或 rel=canonical 設定。最後，驗證修正是否生效時，判斷依據是問題本質：批次問題回到 Page indexing 看數量是否下降，單頁問題可先用即時測試確認修正後的可存取性；是否已重新抓取、採用 canonical 或編入索引，仍要等待索引版本更新後再確認。

情境	先看哪裡	判斷方式
新文章想確認 Google 是否看過	URL Inspection	查單一網址的索引與抓取狀態
大量頁面未編入索引	Page indexing	看類型、數量、範例 URL
Google 選了不同 canonical	URL Inspection	比較使用者宣告與 Google 選定版本
要驗證修正是否生效	Page indexing 或 URL Inspection	依問題是批次或單頁決定

URL Inspection 的檢查順序與判讀重點

打開 URL Inspection 後，畫面會先顯示「網址已收錄」或「網址未收錄」的結論，但真正的判斷要往下看。若顯示未收錄，先確認原因：是 Google 尚未發現這個網址，還是發現了但抓取時被 robots.txt 阻擋，或是抓取成功但內容被判定為重複或品質不足。每一種原因對應的修正方式不同，例如 robots.txt 阻擋要改伺服器設定，內容判定問題則要調整頁面本身。

若顯示已收錄，接著檢查「使用者宣告的 canonical」與「Google 選定的 canonical」是否一致。兩者不同不代表錯誤，Google 有權自行決定 canonical，但若你發現 Google 反覆選擇了非預期版本，通常代表內部連結或 sitemap 傳遞的訊號不夠明確。最後使用「測試實際網址」功能，這會觸發新的抓取與渲染，適合在修正 meta robots、結構化資料或內容後立即驗證。記得，測試結果是當下狀態，與 Page indexing 報表的歷史資料不同，兩者搭配才能看出趨勢與單點變化。

Sitemap、Links、Experience 報表各自代表什麼

GSC 的其他報表是輔助診斷入口，各自回答不同層次的問題，不能混為一談。Sitemaps 報表只負責呈現 Google 能否成功讀取你提交的 sitemap 檔案，以及其中收錄了多少條 URL；Links 報表則呈現 Google 在爬梳過程中偵測到的內部連結與外部連結樣貌；Search Console 目前保留 Core Web Vitals 與 HTTPS 等個別報表；舊 Page Experience 報表已轉為連結一般指引與個別報表的彙整入口，行動裝置可用性報表也已退役。這三張報表都不是排名分數，也不是品質總評，而是讓你先定位「哪一個環節亮燈」，再決定下一步要往哪個技術流程走。

當 Sitemaps 報表出現讀取錯誤、格式不符或 URL 數量異常時，問題通常出在 sitemap 的生成方式或 robots.txt 的阻擋設定，此時應接著閱讀 Sitemap 網站地圖提交教學，按照其中的格式規範與提交流程逐一排除。當 Core Web Vitals 報表顯示大量 URL 群組未通過時，代表有足夠 CrUX 實際使用資料的群組在 LCP、INP 或 CLS 至少一項未達良好門檻；沒有資料的 URL 不能據此判定好壞，這時應轉往 PageSpeed Insights 指標診斷，從 LCP、INP、CLS 等具體指標找出效能瓶頸。GSC 的角色是告訴你哪裡亮燈，深層修復則要回到對應的技術文件與測試工具，兩者分工明確。

Sitemaps 報表：確認提交狀態，而非索引保證

Sitemaps 報表的核心價值在於「提交狀態的可見性」。它會列出你透過 Search Console 提交的 sitemap 檔案，並顯示 Google 最後一次成功讀取的時間、發現的 URL 數量，以及讀取時是否發生錯誤。這個報表能幫助你確認 sitemap 檔案是否放在正確的路徑、格式是否合乎 XML 規範，以及檔案是否因為過大或逾時而無法完整解析。

但必須強調，sitemap 被成功讀取，不代表其中所有 URL 都會被索引。Google 會根據頁面品質、內容獨特性、網站整體權重等因素決定是否收錄。因此，當 Sitemaps 報表顯示「成功」時，你只獲得了「提交管線暢通」的資訊；若顯示錯誤，則應優先檢查檔案本身與伺服器回應。若想進一步確認個別頁面的索引狀態，應搭配 URL Inspection 工具，而非單看 sitemap 的讀取結果。

Links 報表：觀察連結樣貌，而非完整資料庫

Links 報表分為「外部連結」與「內部連結」兩個區塊。外部連結區塊會列出 Google 偵測到、指向你網站的最常用錨點文字與來源網域；內部連結區塊則呈現你網站內各頁面之間的連結分佈。這個報表的主要用途是觀察連結的「樣貌」，例如哪些錨點文字被大量使用、哪些頁面獲得較多內部連結權重，以及外部連結是否集中在少數幾個網域。

需要留意的是，GSC 的 Links 報表並非完整的反向連結資料庫。它只顯示 Google 在爬梳過程中「選擇性」記錄的樣本，與第三方工具（如 Ahrefs、Moz）的資料庫規模與更新頻率不同。因此，這個報表適合用來做趨勢觀察與異常偵測，例如某個頁面突然獲得大量外部連結，或內部連結結構出現斷裂。若要進行完整的連結分析或競爭者比較，仍需搭配專業工具，GSC 的定位是提供第一手偵測結果，而非全量統計。

Experience 報表：頁面體驗訊號的彙整入口

舊 Page Experience 報表已轉為一般指引與 Core Web Vitals、HTTPS 個別報表的入口，不再把行動裝置可用性、侵入性插頁等項目合成單一整體評分。Core Web Vitals 會依 CrUX 實際使用資料，把有足夠資料的 URL 群組標成「良好」「需要改善」或「不佳」；這不是全站所有 URL 的完整清單。

Core Web Vitals 報表適合按指標與 URL 群組分流，PageSpeed Insights 則可同時查看可用的欄位資料與單次實驗室診斷。行動裝置可用性報表已於 2023 年 12 月退役，行動體驗需改用 Lighthouse、Chrome DevTools 與實機測試；HTTPS 問題則回到 HTTPS 報表、憑證與混合內容檢查。

報表	回答的問題	不代表什麼
Sitemaps	Google 是否讀到 sitemap 與 URL 數	不保證頁面會被索引
Links	Google 偵測到的連結樣貌	不是完整 backlink database
Experience	Core Web Vitals、HTTPS 與頁面體驗指引	不是完整速度優化報告
Manual actions	是否有人工判決處罰	沒有顯示不等於整站品質完美

AK GSC Diagnostic Router：把報表變成下一步

AK GSC Diagnostic Router 是一套把 GSC 報表轉成下一步行動的判斷流程。作法是先判斷你看到的訊號屬於設定問題、搜尋成效問題、索引問題、探索問題、體驗問題，還是政策與安全問題，再接到對應的修正流程。這個路由器的價值在於降低誤判：很多網站看到 GSC 警告就急著改內容，或看到平均排名下降就急著買工具，但問題可能只是 sitemap 讀取錯誤、canonical 不一致、查詢意圖變了，或 GA4 轉換設定根本沒接好。先確認訊號屬於哪一類，才不會把資源投錯地方。

路由器的核心是「訊號 → 判斷 → 下一步」的對應關係。以下表格列出五種最常見的 GSC 訊號、應該先確認的面向，以及對應的處理動作。這張表不是要取代後續各節的細部判斷，而是讓你在打開報表時，先有一個快速分流的地圖。

GSC 看到的訊號	先判斷	下一步
property 沒資料	設定或驗證範圍	檢查 property 類型與驗證權限
曝光下降	查詢、頁面、國家、裝置	比較成效報表區間
重要網址未索引	單頁或批次問題	開 URL Inspection 或 Page indexing
Sitemap 無法讀取	檔案可讀性與網址清單	回到 sitemap QA
Core Web Vitals 不佳	範本、裝置、網址分組	用 PSI 做深層診斷

路由器底下有三個最常被誤判的判斷點：0 點擊的網址該不該動、舊文該重寫還是開新頁、同一個查詢該由哪個網址接住。這三個判斷點各自需要不同的 GSC 資料欄位與觀察區間，以下分別說明。完整的刪除、更新、合併、轉址決策帳本在 SEO 審計方法與決策帳本，這裡只講 GSC 資料怎麼讀、怎麼分流到那套決策帳本。

零點擊分流：0 點擊的網址不是看到就砍

零點擊分流（0-click triage）的判斷原則是：0 點擊不是刪除的理由，只是要往下追問曝光、內鏈、頁齡與負責頁歸屬的起點。多數人的直覺是點擊等於零就等於沒用，但同一批 0 點擊網址裡，有的是根本沒曝光的孤兒頁，有的是曝光很高卻沒人點的頁面，兩種情況的下一步完全不同。前者要查索引與內鏈，後者要查標題與內容是否符合搜尋意圖。

實際輸入資料是 GSC 成效報表拉 90 天區間，把點擊數為 0 的網址篩出來，再依曝光數排序逐頁看。AK 對這個步驟的描述很直接：「我處理的方式很簡單：先到 GSC 把 90 天 0 點擊的頁面拉出來，按點擊數排序，一頁一頁看。」這是 AK 在 2026 年 6 月 29 日的一手方法陳述，屬於待驗證的判斷假說，排序動作本身只是篩選候選名單的操作步驟，不是排名會提升的證明。

零點擊分流的決策步驟依序如下：

1. 先看曝光數：曝光也是 0，可能是尚未索引、沒有符合查詢的曝光、資料量太低或報表限制；先用網址檢查確認索引狀態，再查查詢需求與內鏈，不要只憑 0 曝光下結論。
2. 曝光不是 0 但點擊是 0：看查詢是什麼、標題與內容是否對得上使用者意圖，這通常是內容或標題問題，不是頁面該不該存在的問題。
3. 查這個網址有沒有內部連結指向它：完全孤兒的頁面可能較難被使用者與爬蟲發現，也缺少站內脈絡；若它應被保留，先補具語意的內鏈，再按網站資料量設定觀察窗口。
4. 查頁齡：新頁需要與已累積資料的舊頁分開看；30 天可作為 AK 的初始分流窗口，但不是 Google 保證或普遍門檻，仍要依抓取、索引與查詢量調整。
5. 查這個網址是不是某個查詢的負責頁：如果它其實該負責某個查詢卻排名落後另一個網址，問題可能出在查詢負責頁分流，見下方說明。

很多網站的「內容負債」就是這樣慢慢長出來的：弱頁越生越多，能真正帶客戶進來的頁面卻沒變強，Googlebot 還得在裡面繞來繞去，白白浪費力氣。這是 AK 在 2026 年 6 月 29 日提出的判斷方向，屬於待驗證的假說，不是已證明的機制，需要抓取記錄與對照組才能確認 Googlebot 的力氣真的被稀釋，而不是被其他因素影響。

零點擊分流的邊界很清楚：0 點擊只是分流用的第一個訊號，不是刪除收據。完整的刪除、更新、合併、轉址判斷還要接曝光、內鏈、轉換、頁齡與負責頁歸屬一起看，這套完整決策帳本在上方連結的 SEO 審計方法頁，這裡只負責把 GSC 資料整理成可以往下追問的候選名單。

更新 vs 新開頁判斷：舊文重寫還是開新頁

更新 vs 新開頁判斷（refresh-vs-new）的判斷原則是：如果查詢已經有網址拿到部分排名和曝光，優先評估更新這個網址，不是急著另開新頁；如果新主題和舊網址的語意距離太遠，才該開新頁。常見的錯誤直覺有兩種，一種是迷信新網址永遠比舊網址乾淨、排名比較容易起來，另一種是不管內容差多遠都硬要更新舊文，捨不得放棄舊網址的既有排名。

實際輸入資料是這個查詢目前的排名與曝光落在哪個網址、舊網址和新主題的語意距離、舊網址既有的內鏈與網址年齡。決策步驟如下：

1. 先查這個查詢有沒有既有網址已經拿到部分曝光：有，先評估舊網址能不能承接新主題，不要另開一頁製造內部競爭。
2. 查舊網址的核心主題和新主題差多遠：差距大到會稀釋原本的主語，就該開新頁，硬改反而讓兩個查詢意圖互相打架。
3. 查舊網址的內鏈與年齡：舊網址若已有相關曝光、外部或內部連結與清楚的頁面任務，更新可能比新開頁少一部分重建成本；URL 年齡本身不是保證。
4. 更新後排入固定週期回頭看成效報表，不是改完就結案。

AK 在 2026 年 5 月中下旬對自有站台做過一次舊文更新實驗，以下是這項觀察的完整記錄。這份記錄不是通則證明，而是單一案例的證據狀態，需要更多對照組才能確認更新舊文的效益是否普遍成立。

AK 一手觀察欄位	內容
證據狀態	Review，需 AK 進一步確認
站點／來源類型	AK 自有站，純 AI 寫作站台
觀察窗口	約半個月，2026 年 5 月中下旬
樣本／分母	40 至 50 篇舊文，未提供完整網址清單
變更槓桿	用新流程重新優化這批舊文，流程細節未公開
觀察結果	關鍵字數量沒有明顯成長，排名一個月內從約 1000 成長到接近 8000，原話未定義這個數字對應排名、流量還是曝光
AK 判讀	同一批網址已有排名基礎時，更新舊文的邊際效益可能高於開新頁
替代解釋	同期演算法更新、季節性、SERP 版位變動、未記錄的其他站內改動
什麼情況會推翻此推論	若同期其他改動可解釋同等幅度成長，或未更新的對照網址出現相同成長
來源／出處	Threads @darkseoking，貼文 DYy_DlLk_5B，2026-05-26
最後查核日	2026-07-21

更新 vs 新開頁判斷的邊界是，這個案例還沒有完整的網址清單與同期改動記錄，不能直接當成「更新舊文永遠優於開新頁」的通則。它能支持的最小結論是，同一批網址已有排名基礎時，更新舊文是值得先評估的選項，不是唯一答案。

查詢負責頁分流：同一個查詢該由哪個網址接

查詢負責頁分流（query-owner branch）的判斷原則是：曝光最高的網址不一定是負責頁，要用頁面任務和內容範圍決定哪個網址該接住這個查詢。常見的錯誤直覺是看曝光最高的網址就直接當作負責頁，但曝光最高的網址也可能只是內容剛好匹配到查詢字詞，實際任務並不對。例如一個「SEO 工具」查詢，曝光最高的可能是某篇工具列表文，但真正該負責這個查詢的可能是產品頁或教學頁，取決於頁面任務設定。

AK 進行這類盤點時，會把 sitemap、逐頁內容與 GSC 查詢資料接在一起，讓每個網址同時具有頁面內容、曝光、點擊與排名脈絡，這是診斷流程，不把單一指標當成刪改依據。實際操作上，AK 的做法是把 Codex 或 Claude Code 指向網站，一個下午就能分好群、抓出孤兒頁與互搶頁，連轉址設定跟內鏈修改都整理出來，但最後決定要不要動的仍然是人；這是方法立場，不是已證明的排名因果。

查詢負責頁分流的決策步驟如下：

1. 在成效報表用該查詢篩選，看有幾個網址同時拿到曝光。
2. 對照每個網址的內容範圍和頁面任務，判斷哪一個網址在語意上真正該負責這個查詢。
3. 如果目前排名領先的網址其實任務不對，把內容、標題與內鏈錨文字逐步收斂到該負責頁。
4. 非負責頁如果還有獨立價值，調整成支援頁並內鏈回負責頁，而不是直接刪除。

查詢負責頁分流的邊界是，負責頁判斷需要對照頁面任務和內容範圍，不能只看曝光數字自動決定；曝光只是分流的起點，不是結論。同一個查詢可能同時有多個網址拿到曝光，但只有一個應該被當成主要承接頁，其餘網址要嘛轉為支援角色，要嘛逐步收斂內容避免內部競爭。

每週 GSC SEO 檢查清單

AK 將每週一次設為多數穩定網站的初始監控節奏，除非網站正在改版、遭遇大幅下滑或剛修復技術問題。固定節奏比每天刷新報表更有效，因為 GSC 資料有延遲，過度反應會製造更多錯誤決策。把檢查固定在每週同一天，例如週一上午，能讓你在不被打斷的時間內完整看完報表，並在週間執行必要的修正。

這份清單的目標不是看完所有報表，而是找出「這週最該修的一件事」。多數時候，問題會集中在成效下滑、索引異常或體驗指標惡化三類之中；先處理會直接影響流量的項目，再處理技術債，才能讓每週投入的時間產生實際回報。

先看總覽與安全性，再深入成效報表

打開 GSC 首頁時，先確認總覽區有沒有安全性問題、人工判決處罰或重大索引警告。這些訊息通常會以橫幅或圖示呈現，若出現紅色警示，應優先處理，因為它們可能導致頁面被移除或排名大幅下降，遠比一般成效波動更緊急。

接著進入成效報表，將日期範圍設為最近 28 天，並與前一個 28 天期間比較。比較時務必將品牌詞與非品牌詞分開觀察，品牌詞與非品牌詞的基準不同；品牌詞下滑可能來自需求、SERP、品牌事件、追蹤或網站問題，非品牌詞也受需求與版位變化影響。分開觀察是為了縮小假說，不是直接指定根因。

在成效報表中，特別注意高曝光但低點擊率（CTR）的查詢。這類查詢代表你的頁面有機會出現在搜尋結果中，但標題或內容描述未能吸引使用者點擊。針對這些查詢，檢查頁面的 title 與 meta description 是否準確傳達內容價值，並只在內容確實支持時調整標題與摘要；數字、年份或行動語句不是通用解法，也不應製造過期或過度承諾。

檢查重要頁面與索引狀態，確認技術健康

逐一檢查網站中流量占比最高的 10 至 20 個頁面，觀察它們的點擊與曝光是否異常下降。若某個重要頁面的曝光突然減少，可能原因包括競爭對手內容超越、頁面被重新索引後排名波動，或是內部連結結構變動；此時可用網址檢查工具確認頁面是否正常收錄，並查看是否有新的結構化資料錯誤。

接著前往「網頁索引」報表，查看 Page indexing 是否新增大量相同類型的排除原因。常見的排除原因包括「已發現但尚未編入索引」「已編入索引但出現重複內容」或「遭到 noindex 標記」；若同一類型問題突然增加，通常代表某次改版或設定變更影響了整批頁面，需要回溯最近的變更記錄來定位根源。

確認 Sitemaps 報表中的最近讀取狀態是否正常。GSC 會顯示 sitemap 最後一次成功讀取的時間，以及處理的網址數量；若讀取失敗或網址數明顯減少，可能是 sitemap 格式錯誤、伺服器回應異常或 robots.txt 阻擋了爬蟲。修復 Sitemap 的抓取或解析問題能恢復一條 URL 發現管道，但不能保證新頁面被快速發現或避免索引延遲。

檢視體驗指標與結構化資料，延伸至完整診斷

最後檢查 Experience 報表中的 Core Web Vitals 是否出現新的 URL group 問題。若發現新的效能問題，先確認是特定頁面模板造成，還是全站性的資源載入問題；例如圖片未壓縮、第三方腳本阻塞渲染或伺服器回應時間變長，都可能導致 LCP 或 INP 惡化；Core Web Vitals 是整體頁面體驗的一部分，但報表狀態不能單獨證明排名變化。

如果 GSC 的 Enhancements 或 Rich results 相關報表出現結構化資料問題，下一步要確認 schema 是否和頁面正文一致。可延伸閱讀 Schema 結構化資料教學，把 Article、FAQ、HowTo、Breadcrumb、JSON-LD 與驗證工具放進同一套檢查流程，確保標記內容與頁面可見內容一致，並只使用 Google 現行支援的 rich result 類型；HowTo 搜尋外觀已退役，FAQ 搜尋外觀也已停止顯示，結構化資料不會取得精選摘要資格。

如果 GSC 報表已經看出問題，但還不知道先修哪一塊，可以延伸閱讀 SEO 健檢檢查清單，把索引、內容、技術、內鏈、成效與商業優先級放進同一套 audit 流程。這份清單能幫助你將 GSC 觀察到的現象，對應到具體的修正動作，並依照影響範圍與修復成本排出先後順序，讓每週的檢查不只是記錄數據，而是真正推動網站進步。

GSC 資料的延遲、批次更新與決策節奏

Google Search Console 的資料並非即時串流，而是以批次方式更新，這直接決定了你應該用什麼節奏來解讀報表、下判斷、排工作。理解這套延遲機制，你才不會被單日數字牽著走，也才知道哪些波動值得追、哪些只是系統尚未收斂的雜訊。

GSC 的資料延遲從哪裡來

GSC 的報表資料來自 Google 對搜尋索引與點擊行為的取樣與彙整，這個過程不是即時發生的。一般來說，成效報表中的查詢、頁面、曝光與點擊數據，會有約兩到三天的延遲；索引狀態與網址檢查的結果則可能更慢，尤其是新頁面或大幅修改過的頁面，Google 需要重新爬取與處理，這段時間可能從數小時到數週不等。

這意味著你昨天在網站上做的修改，不會立刻反映在今天的 GSC 數字裡。如果你把「昨天改了標題、今天 CTR 沒變」當成失敗，其實是誤讀了資料的時間軸。正確的作法是先確認資料的截止日期，再對照你實際的變動時間點，應先看報表顯示的資料截止時間；三到五天只能作為 AK 的初始緩衝，不代表頁面修改已被重新抓取，也不是 Google 的固定驗證門檻。

批次更新還有一個特性：GSC 會不定期修正歷史數據。例如某一天 Google 調整了演算法或重新處理了索引，過去幾週的曝光與點擊數字可能被回填修正。歷史數字可能因資料處理、註記事件或方法更新而變動，但不能一律歸因於演算法或索引重新處理。看到差異時先查 Search Console 的資料異常註記、時區、篩選條件與報表限制。

單日波動為什麼不能直接驅動決策

單日數據的樣本量通常不足以區分「真實變化」與「隨機波動」。以一個每天只有數十次點擊的頁面來說，某天多五次點擊、少三次點擊，在百分比上看起來很劇烈，但實際上可能只是使用者行為的自然起伏。若你根據這種單日波動就急著改標題、刪內容或調整內部連結，反而會打斷原本穩定的測試條件，讓你無法判斷到底是哪個變因造成了後續的變化。

更務實的作法是設定一個觀察窗口。以週為單位累積數據，可先用兩到三週作為 AK 的觀察起點，但是否足夠仍取決於曝光量、季節性、改動幅度與對照條件。例如，某個查詢的曝光連續三週下滑，且點擊率也同步走低，這才值得你動手檢查頁面內容與競爭對手；如果只是某一天掉下來，隔天又回升，那多半只是雜訊，不需要採取任何行動。

決策節奏因此應該跟著批次更新的頻率走，而不是跟著日曆上的每一天走。每週固定一個時間點檢視 GSC 數據，比每天打開報表焦慮來得有效。你可以在每週檢視時，把過去四週的數據拉出來對比，找出持續上升或持續下降的項目，再決定下一個要修的東西。這樣一來，你的行動依據是趨勢，而不是單點，判斷的穩定度會高很多。

批次更新對工作排程的實際影響

既然 GSC 資料有延遲，你的 SEO 工作排程就必須把這個時間差算進去。假設你本週三修改了某個重要頁面的標題與 meta description，合理的作法是記錄下修改日期，然後等到下週二或週三再去看成效數據，因為那時的資料才會包含你修改後的完整一週表現。若你每天都去刷新報表，看到的只是修改前的舊資料，除了增加焦慮，沒有任何決策價值。

同樣的道理也適用在索引狀態的追蹤上。當你提交了新的 sitemap 或要求重新索引某個頁面，GSC 的「網址檢查」工具會顯示目前的索引狀態，但這個狀態是 Google 處理當下的快照，不是即時回報。如果你發現狀態顯示「已發現，尚未編入索引」，不要急著重複提交，重複提交不保證加速處理，而且有提交配額；Google 沒有說會因「催促」而懲罰性延後。應依頁面重要性與抓取紀錄安排複查，沒有固定一週門檻。

把批次更新的特性納入你的每週檢查流程，能讓你的工作節奏更貼近 Google 的實際運作方式。你不需要每天盯著 GSC 看，而是每週固定時間做一次完整的數據回顧，並把「資料截止日」與「你的行動日」之間的落差視為正常現象。這樣一來，你判斷「下一個該修的東西」時，依據的是已經收斂的數據，而不是還在變動中的半成品。

當你已經從 GSC 的延遲與批次更新中，建立起以週為單位的決策節奏，下一步就是把這個節奏落實成具體的執行計畫。你需要有人協助你定期檢視數據、判斷趨勢、排定修改優先序，並在每次改動後追蹤成效。若要評估外部 SEO 協助，可先核對 AK SEO Labs 公開列出的服務範圍與適用情境：SEO 策略藍圖為 15 萬起的一次性方案，交付網站現況診斷、內容架構建議與執行優先順序；SEO 成長顧問為 10 萬起／月，以內容架構、搜尋意圖、數據回饋與月度策略調整為範圍；規模化 SEO 系統為 15 萬起／月，只有網站具產品、地區、分類、資料庫或比較條件等可規模化資料時，才評估規模化建頁、資料結構與模板設計、內部連結與索引策略。

FAQ

Google Search Console 是免費的嗎？

是。GSC 是 Google 官方免費工具，只要你能驗證網站擁有權，就可以查看該 property 的搜尋成效、索引與部分技術狀態。

GSC 和 Google Analytics 有什麼不同？

GSC 看 Google 搜尋結果中的曝光、點擊、查詢和索引狀態；GA4 看使用者進站後的事件、頁面、來源和轉換。兩者應互補，不應互相替代。

沒有工程師可以設定 GSC 嗎？

可以，但取決於你有哪些權限。若能改 DNS 最穩；若只能進網站後台，可能用 HTML 標記、GA4 或 GTM 驗證。沒有任何網站權限就無法完成擁有權驗證。

GSC 的平均排名可以當真正排名嗎？

不能完全當成固定排名。平均排名會受查詢、地區、裝置、個人化和不同曝光位置影響，適合看趨勢與分群，不適合當單一精準名次。

GSC 顯示未編入索引一定是錯誤嗎？

不一定。有些頁面本來就不該索引，例如重複頁、noindex 頁、redirect 或低價值頁。先確認該 URL 是否真的重要，再判斷是不是需要修復。

URL Inspection 要不要每天送出索引要求？

不建議。URL Inspection 適合重要頁面修正後測試與提交，不適合當每天大量送出的工具。大量頁面應先處理 sitemap、內鏈與索引資格。

Sitemap 成功提交後為什麼頁面還沒收錄？

Sitemap 成功只代表 Google 能讀到清單，不代表每個 URL 都會被索引。頁面仍要通過可爬取、可索引、canonical、內容品質與重複性等判斷。

GSC 資料會延遲多久？

GSC 資料通常不是即時資料，不同報表更新節奏也不同。做 SEO 判斷時應看數天到數週趨勢，不要用單日波動做重大決策。

GSC 要看哪些報表就夠了？

多數網站先看總覽、成效、網頁索引、網址檢查、Sitemaps、Core Web Vitals、人工判決處罰即可。等基本判斷穩定後，再看 Links、Enhancements 與其他細項。

多個人可以一起管理同一個 GSC property 嗎？

可以。GSC 可以新增使用者並設定權限。企業網站建議用公司可控帳號作為 owner，再授權給 SEO、工程與行銷成員，避免離職或帳號遺失造成權限問題。

GSC 顯示某個網址 0 點擊，代表這頁該刪除嗎？

不代表。0 點擊只是零點擊分流的起點，還要看曝光、內鏈、頁齡，以及這個網址是不是某個查詢的負責頁。曝光與點擊都是 0 時，先查索引、查詢需求與報表限制；有曝光但 0 點擊時，再檢查查詢、位置、SERP 外觀、標題與內容意圖。兩種情況都不能只憑單一指標下結論。

同一個查詢，兩個網址都有曝光，要怎麼判斷誰是負責頁？

不要只看曝光最高的網址。查詢負責頁分流要對照每個網址的內容範圍和頁面任務，判斷哪一個網址在語意上真正該負責這個查詢，再把內容、標題和內鏈錨文字逐步收斂過去。