網站每天被搜尋幾次、被點擊幾次、Google 收錄了哪幾頁，這些資料其實有一本現成的帳本，名字叫 Google Search Console，而且免費。只是多數人建好網站後沒去領這本帳本，等到想看數據才發現，這本帳只從領取的那一天開始記，之前的部分怎麼找都補不回來。
這本帳本簡稱 GSC，也常被直接叫做 Search Console。它是 Google 提供給網站擁有者的工具，讓你看到網站在 Google 搜尋裡的曝光與點擊，也看到 Google 怎麼找到、收錄並顯示這些網頁。設定本身不需要寫程式，多數人真正猶豫的地方，是不清楚該選哪一種資源，也不清楚該用哪一種方式向 Google 證明網站是自己的。
這兩個選擇一旦一開始就選錯，後面拿到的往往是不完整的資料，所以動手之前，先弄清楚它記錄的是哪一端的事，會比直接點進設定畫面省事得多。
Google Search Console 是什麼？
Google 的說明文件把它定位成網站擁有者用來瞭解網站在 Google 搜尋中的成效，以及 Google 如何檢索網站、建立索引並呈現網站的工具。簡單來說，它給的是 Google 那一端的視角：搜尋結果裡出現了你的網站幾次、有多少人點進來、哪些網頁被收錄、哪些網頁遇到問題。
使用門檻比多數人想的低。唯一必要的條件是一個 Google 帳戶，沒有就先建立一個；不需要懂 HTML 或程式碼，也不必付費。它同樣不要求每天登入，Google 偵測到網站出現新問題時，會主動寄電子郵件通知；Google 的建議是大約每個月看一次，或是修改網站內容之後看一次，確認數據穩定。
資料怎麼累積，則值得提早在意。只要有人新增了資源，不論是否已通過驗證，系統就會立即開始收集資料，只是通常要過幾天才會出現在報表裡。收集既然從新增那一刻才起算，越晚新增，能回頭看的日子就越短，即使網站才剛上線、還沒有什麼流量，也建議現在就建好。
GSC 看的是搜尋端，也就是訪客進站之前發生的事。訪客進站之後看了哪些頁面、有沒有完成購買，是 Google Analytics（GA）負責記錄的部分。另外，它呈現的是搜尋表現的現況，並不能保證排名。這兩套工具怎麼分工，站內另有專文說明。
網域資源與網址前置字元的涵蓋範圍差異
新增資源是整個設定的第一個決定，後面能用哪幾種驗證方式、報表能看到多大範圍，都由它決定。入口是 Search Console 每個頁面都有的資源選取器，在裡面選「新增資源」即可；帳戶若已開放平台資源，系統會先問要新增網站資源還是平台資源。平台資源用來追蹤 Instagram、YouTube 等創作者帳號，目前仍在逐步開放，以下只談網站資源。
接著選擇資源類型，再選驗證方式。驗證可以當場完成，也可以先按「稍候再驗證」把資源存起來，之後從資源選取器選回這個尚未驗證的資源，再按「驗證」。資源類型只有兩種，涵蓋範圍卻落差很大，選錯的代價是報表只看得到網站的一部分。
網域資源會合併 http、https、www 與子網域
建立網域資源時，只需要輸入根網域，不含 http:// 或 https://，也不含任何路徑。連 www 都不必寫，輸入 www.example.com 會被建成 example.com，同時涵蓋 www 與非 www 兩種版本。
它的涵蓋範圍是整個網域底下的一切，所有子網域、通訊協定（http、https、ftp）與子路徑的資料都會匯總在一起。以 Google 說明頁的範例來看：
| 資源定義 | 涵蓋 | 不涵蓋 |
|---|---|---|
example.com | http://example.com、https://example.com、http://m.example.com、https://m.example.com/any/path/here | example.org（網域字尾不同，就是不同的資源） |
fish.example.com | fish.example.com 及其下的子網域 | example.com（子網域的資源不含上層網域的資料） |
網域資源的代價是驗證只能走 DNS 記錄，只有 Blogger 或 Google 協作平台上的網站例外。Google 在 2019 年推出網域資源時說明，以往的建議是把網站的每個版本（http、https、www、非 www）分別驗證，網域資源則把這些版本的資料合併在一起，因此建議日後盡可能改用網域資源。
網址前置字元的範圍取決於輸入的那串開頭
前置字元資源的邏輯是輸入什麼就涵蓋什麼。網址要寫完整，包含開頭的 https:// 或 http://，結尾加斜線，例如 https://example.com/pets/。這個資源涵蓋 https://example.com/pets/puppies，也涵蓋帶參數的 https://example.com/pets/cats?a=siamese&b=in-stock，但不涵蓋 http://example.com/pets/（通訊協定不同）與 https://m.example.com/pets/（子網域不同）。
https 與 http、www 與非 www、不同子網域，全都算各自獨立的資源，所以新手最常見的失誤是版本打錯，也就是網站明明跑在 https，資源卻建成 http 開頭。這種情況驗證可以通過，報表卻一直沒有數據。驗證完數天仍是空白時，排除網站還沒在 Google 搜尋出現過的可能之後，第一個要檢查的就是網址版本。
這種只認開頭的特性，也是它的優點。想單獨追蹤某個子路徑，例如 /blog/，替它建一個前置字元資源就行。網站同時支援多種通訊協定或多個子網域時，則要分別新增資源；想分開追蹤網站的不同部分，可以替各網域或各子路徑各建一個，再另外建一個涵蓋全部的上層資源。
握有 DNS 權限就選網域資源，否則走網址前置字元
選擇的原則可以直接看手上的權限。能登入網域註冊商、主機商或 CDN 的 DNS 管理頁，或者能請管理者替你加一筆 TXT 記錄，就選網域資源；只能改網站後台、上傳檔案，或在網頁的 head 區段貼程式碼，就走網址前置字元。
兩個細節常被漏掉。第一，兩種資源可以並存，網域資源底下的特定區段可以另建一個前置字元資源，而且父項資源驗證過後，新增的子項資源會自動沿用同一種驗證方法。第二，用 DNS 驗證前置字元資源時，網域資源也會一併通過驗證，所以握有 DNS 權限的人，不必在兩者之間硬選其一。
DNS 簡單說，就是把網域名稱對應到伺服器位置的系統，TXT 記錄則是它可以存放的一種文字註記，後面的驗證就是靠這一筆註記完成。DNS 的運作方式，站內有專文介紹。
驗證擁有權有五種方法，各自的前提不同
驗證的目的，是向 Google 證明這個網站由你管理。新手最容易在這一步遇到困難，原因是這些方法沒有進階與入門之分，該選哪一種，取決於手上握有什麼權限。五種方法的差異如下：
| 方法 | 適用資源 | 需要的條件 |
|---|---|---|
| 上傳 HTML 檔案 | 網址前置字元 | 能把檔案上傳並發布到網站根目錄，相對簡單 |
| HTML 標記 | 網址前置字元 | 能編輯首頁的 HTML |
| Google Analytics 追蹤程式碼 | 網址前置字元 | 首頁已有該帳戶的 GA 代碼，且在該 GA 資源有編輯權限 |
| Google 代碼管理工具 | 網址前置字元 | 首頁已有該帳戶的 GTM 片段，且有容器的發布或管理員權限 |
| 網域名稱供應商 | 網域資源（前置字元資源也可用） | 能管理 DNS 記錄，較複雜，但是驗證網域資源的唯一方法 |
驗證檔與驗證碼都和建立它的 Google 帳戶綁定，不能拿別人的檔案或標記來用；同一個資源也可以保留多種驗證方法，當作彼此的備援。使用 Wix、Shopify 這類網站代管平台時，上面幾種方法未必都能用，平台也可能有自己的驗證設定或外掛。這時優先照平台的做法走，不確定時，搜尋「平台名稱加 Search Console 驗證」通常就能找到對應的說明。Google 協作平台與 Blogger 帳戶，則直接採用各平台建議的方法。
網域資源只能走 DNS，在供應商新增 TXT 記錄
建立網域資源時，系統會自動選用網域名稱供應商這個方法。如果 Search Console 列出了你的供應商，選取後按「開始驗證」，登入該供應商，驗證就會立即完成。清單裡沒有你的供應商時，改選「任何 DNS 供應商」，走手動流程。
手動流程分三步：
- 取得 Search Console 提供的 TXT 值，它是一串以
google-site-verification=開頭的文字。 - 到 DNS 管理頁新增一筆 TXT 記錄，主機（名稱）欄留空或填 @，值欄貼上整串內容。
- 回到 Search Console 按「驗證」。
類型：TXT
主機／名稱：留空或填 @
值：google-site-verification=（貼上 Search Console 提供的整串內容）Code language: plaintext (plaintext)DNS 在誰那裡管，就到誰的後台加，可能是網域註冊商、主機商或 CDN，視網域的名稱伺服器指向哪裡而定。至於什麼時候要改用 CNAME，Google 建議先用 Google Admin Toolbox 的 CNAME 分頁查詢網域。最常見的結果是查無 CNAME 記錄，這時用 TXT 就對了；只有網域本來就有 CNAME 記錄、且指向上層網域時，才會用到 CNAME。
這個方法最常被問到的是為什麼一直驗證失敗。手動新增的記錄，供應商可能要兩到三天才會開始提供，所以失敗時先隔一兩天再試，也可以用同一個工具選 TXT 查看目前實際生效的記錄。常見的兩個錯誤訊息，意思不同：「找不到驗證用 DNS TXT 記錄」可能只是還沒傳開，幾分鐘到幾天都有可能；「驗證記錄不符」則要確認貼的是驗證頁提供的值，而且名稱欄位留空。
另外，驗證根網域會連帶驗證它所有的子網域，反過來卻不成立，驗證 m.example.com 並不等於驗證 example.com。
上傳 HTML 檔案到網站根目錄
只能管網站檔案、沒有 DNS 權限的人，適合走這條路。做法是下載 Search Console 提供的驗證檔，原封不動上傳到網站根目錄，檔名與內容一個字都不能改，改了就會驗證失敗。上傳之後，要在瀏覽器裡直接開啟這個檔案的網址確認打得開，建議用無痕視窗測試，因為檔案所在的目錄不能要求登入。
這個方法有兩個性質要知道。驗證檔一旦移除，驗證就會失效，所以檔案要一直留著；它也只適用網址前置字元資源，不能驗證網域資源。
導向的規則則容易出錯。同一個網域內的導向，例如 http 導向 https、非 www 導向 www，Search Console 都會跟著去找檔案；example.com 導向 foo.com 這種跨網域的導向，它就不會跟過去。整站流量都導向別的網域時，改用 HTML 標記比較穩。
驗證失敗時，系統會回報幾種訊息：找不到驗證檔、驗證檔內容錯誤、檔案被導向到不允許的位置，以及驗證檔疑遭駭客，後者代表網站可能已被入侵，要優先處理。
HTML 標記要放進首頁的 head 區段
HTML 標記同樣只適用網址前置字元資源。Search Console 會提供一行 meta 標記，要貼進首頁 HTML 的 <head> 區段內，而且標記必須出現在檔案前 2MB 以內：
<meta name="google-site-verification" content="驗證碼" />Code language: HTML, XML (xml)要注意 Search Console 檢查的是哪一頁。它檢查的是未登入的訪客輸入資源網址後，最後落到的那一頁，所以首頁不能要求登入。例如資源網址導向 /home，檢查的就是 /home 這一頁，標記放在被導向之前的頁面就沒有用。貼好之後，用瀏覽器的「檢視原始碼」搜尋 google-site-verification，確認線上版的頁面真的有這行，而不是只改到自己電腦上的副本。
驗證通過後，這行標記不要移除，Search Console 會定期檢查它還在不在。標記不在首頁、不在 <head> 內、內容與 Search Console 給的不同，或格式有誤，都是驗證失敗的常見原因，整段複製貼上能避開大部分的問題。
用 WordPress 的話，可以透過主題或外掛提供的 head 插入功能貼入標記。Google 的說明頁也提到，WordPress 專用的 Site Kit 可以代為處理驗證，並提供簡化的 Search Console 資料檢視，同時提醒安裝任何外掛前仍要先做功課。Site Kit 的安裝與用法，站內有專文介紹。
已裝 GA 或 GTM 的網站，可直接借用代碼驗證
網站已經裝了 Google Analytics 或 Google 代碼管理工具（GTM）時，可以直接借用既有的代碼來驗證，這是最省事的一條路。
GA 方法有幾個前提。登入 Search Console 與 GA 要用同一個 Google 帳戶，且在該 GA 資源有編輯權限；首頁的 <head> 內要有 gtag.js 或 analytics.js 片段，而且不能被修改；GA4 的驗證對應的是資料串流。舊版片段，也就是含 _gat、_getTracker 或 urchin.js 的程式碼，則不被支援。
GTM 方法則需要容器的「發布」或「管理員」權限，同樣要用同一個帳戶。它對程式碼的位置也有要求，<noscript> 區塊必須緊接在 <body> 開頭標籤之後，中間不能插入 data layer。這兩種方法都只適用網址前置字元資源。
這條路最脆弱的地方，是驗證依附在另一套工具的代碼上。Google 的說明頁就舉過例子：GA 追蹤碼驗證通過後，有人改了網站範本，代碼跟著消失，驗證就失效了。換主題、改範本的時候，代碼很容易被一起拿掉，所以建議再加上一種驗證方法當備援。GA4 在 WordPress 的安裝方式，站內有專文介紹。
驗證失敗，以及日後失效的原因
按下驗證卻失敗，和驗證成功很久之後突然失效，是兩件不同的事。前者可以逐項排查，常見原因有這些：
- 標記或檔案不在 Search Console 要檢查的那一頁。
- 檔案或標記的內容被改動，與 Search Console 提供的不一致。
- 頁面或檔案所在目錄需要登入才看得到。
- 伺服器逾時、無法連線，或網域名稱查詢發生錯誤。
- 重新導向的次數過多。
- DNS 的 TXT 記錄還沒生效。
後者則是維護的問題。Search Console 會定期檢查驗證權杖，只要權杖還在且有效，驗證就會持續有效；一旦確認不到，會先通知你，超過寬限期仍未修正，權限才會失效。權杖消失的原因，通常是檔案被刪、標記被移除、DNS 記錄被清掉，或 GA／GTM 代碼在改版時被拿掉。
比較麻煩的是唯一的已驗證擁有者離開。若所有已驗證的擁有者都失去權限，資源上所有的使用者都會失去存取權，所以建議在「擁有權驗證」設定頁多加幾種驗證方法當備援。多人驗證同一個資源時，如果用的是同一種方法，要留意別覆寫掉別人的權杖。接手別人的網站時，自己驗證通過之後，也可以把前任擁有者的權杖移除。
提交 Sitemap 只是提示，但能看到 Google 的處理狀態
Sitemap 是一份列出網站網址的檔案，向 Search Console 提交它，只是給 Google 一個提示，無法保證 Google 一定會下載，也不保證會用它去檢索網址。它也不是必要步驟，沒有提交，Google 一樣找得到網頁，只是提交後可能加快 Google 發現網站內容的速度。
小型網站其實可以略過。Google 的說明提到，網頁約 500 個以內、且從首頁循著連結就能走到每一頁的網站，可能不需要 Sitemap，直接請求為首頁建立索引即可；Wix、Squarespace 這類代管服務通常自動管理 Sitemap，WordPress 等 CMS 多半也已自動產生。
即使如此，多數網站還是值得送一次，因為提交之後，Sitemap 報表會告訴你 Google 何時讀取、讀到幾個網址、有沒有錯誤，這是不提交就看不到的處理狀態。
送出前先確認 Sitemap 網址能直接打開
送出前最常見的失誤，是送了一個打不開、或根本不是現行那一份的網址。先用瀏覽器直接開啟 Sitemap 的網址，看得到 XML 內容才算過第一關。檔案裡列的網址要使用含完整網域的絕對網址，檔案採 UTF-8 編碼，也不能被登入或 robots.txt 擋住。Google 建議把它放在網站根目錄，這樣才能涵蓋全站的網址。
接著用網址檢查工具，對這個 Sitemap 網址執行「測試線上網址」，確認「網頁擷取」顯示「成功」，代表 Googlebot 抓得到。另外，Sitemap 裡的 <priority> 與 <changefreq> 會被 Google 忽略，<lastmod> 則是在內容準確且可驗證時才會被採用。
用 WordPress 的話，要多留意一件事。WordPress 核心從 5.5 版起，就在 /wp-sitemap.xml 提供 Sitemap 索引，預設涵蓋公開的文章類型與分類法、作者彙整頁與首頁。裝了 SEO 外掛之後，這份 Sitemap 常改由外掛接管，網址變成 /sitemap_index.xml 這類格式。兩份擇一送，別送錯，也別讓兩份並存。Sitemap 本身怎麼製作、WordPress 怎麼設定，站內另有專文說明。
在 Sitemap 報表貼上網址並送出
操作本身很簡單，兩個步驟就能完成：
- 打開 Sitemap 報表，在「新增 Sitemap」欄位貼上剛測過的網址。
- 按下提交。
送出後 Google 會立即嘗試擷取，成功後再按自己的步調回訪，通常不需要重複送；擷取失敗的話，會再試幾天後才放棄。
有三個限制容易被忽略。第一，只有擁有者能用報表提交 Sitemap，沒有擁有者權限時，可以改在 robots.txt 加一行 Sitemap 指令，多份 Sitemap 就多寫幾行：
Sitemap: https://example.com/my_sitemap.xmlCode language: plaintext (plaintext)第二，報表只列出透過報表或 API 送出的 Sitemap，從 robots.txt 或其他方式被發現的不會出現在清單裡，最多顯示 1,000 筆提交。第三，Sitemap 只會出現在送出的那個資源裡，http 與 https、www 與非 www 是不同的資源，在報表裡看不到剛送的 Sitemap 時，先確認自己開的是不是同一個資源版本。
Sitemap 報表的三種狀態與常見錯誤原因
報表上的狀態有三種，各自的意思不同：
- 成功：Sitemap 已載入並處理，沒有錯誤，所有網址都排入檢索佇列。
- 發生錯誤：Sitemap 擷取得到但有錯誤，能解析的網址仍會排入佇列，點進去可以看錯誤清單。
- 無法擷取：系統無法擷取這份 Sitemap。
狀態顯示成功，不等於網頁已經收錄。報表上的「系統探索到的網頁」，是從 Sitemap 剖析出來的網址數，重複的網址只算一次，Google 並不保證這些網頁都已檢索或編入索引。想知道這份 Sitemap 的網址實際收錄了多少，可以點「查看索引涵蓋範圍」，用 Sitemap 篩選網頁索引報表。
看到錯誤時，常見原因有這幾種：Sitemap 被 robots.txt 擋住；網站有尚未解決的人工判決處罰時，Sitemap 不會被讀取；提供的網址有誤，回傳 HTTP 404；Sitemap 內的網址與 Sitemap 所在位置的網域或層級不符，例如 Sitemap 放在 http://www.example.com/sitemap.xml，裡面的網址卻是 http://example.com/ 或 https://www.example.com/，www 與協定只要有一項對不上就不合法。
單一 Sitemap 的上限是 50,000 個網址或 50 MB（未壓縮），超過就要拆成多份，再用 Sitemap 索引檔彙整。暫時性的錯誤通常不必重送，數小時後仍然存在，才需要再送一次。已經提交、狀態也是成功，網頁卻仍沒被收錄的情況，站內另有專文說明深入的排查方式。
確認 Google 已找到並收錄重要網頁
設定完最自然的下一個問題是，Google 有沒有收下自己的網頁。整站層級看網頁索引報表，單頁層級用網址檢查。報表看得到全貌，卻不能查單一網址；網址檢查則一次只查一個網址。
打開報表之前，有個更快的初判方式。網頁少於 500 個的網站，可能根本用不到這份報表，直接在 Google 搜尋使用 site: 語法就能確認：
site:example.com：看 Google 知道這個網站的樣本網頁。site:example.com/petstore：看某個子路徑下的網頁。site:example.com 某個詞：用網站內容裡的詞搜尋。site:後面接完整網址：確認單一網頁有沒有被收錄。
只有這些搜尋查不到、又願意花時間理解報表時，才需要用報表找原因。新網站可能要一週左右才會開始被檢索與收錄，找不到頁面時，最好的第一步是對首頁要求建立索引，讓 Google 從首頁開始檢索。
網頁索引報表中，未建立索引不一定是問題
網頁索引報表把網址分成「已建立索引」與「未建立索引」兩組，下方的「網頁未編入索引的原因」表會列出各個原因。讀這份報表的目標，是讓每個重要網頁的標準版本都被收錄，並不是讓所有的網址都被收錄。
灰色的未建立索引，多數有正當理由。重複的網址不該被收錄，只有標準版本才算數；被 robots.txt 擋住、帶有 noindex 標記，或是刪除後回傳 404 的網頁，同樣是合理的未收錄。需要留意的反而是重要網頁變成灰色。報表裡的「來源」欄，則標示問題出在 Google 還是網站，網站經營者一般只能處理「網站」那一側的問題。
報表也有幾個限制。網址總數與自己估算的頁數不會完全一致；範例網址清單最多 1,000 筆，也不保證列出該狀態的全部網址；已建立索引不保證每次搜尋都會出現。報表不能搜尋單一網址，要查單頁得用網址檢查。總網址數遠少於實際的頁數，通常代表 Google 還沒找到這些網頁。新網站可以先等一週左右，同時確認網頁有內部連結可以走到、也列在 Sitemap 裡。報表上方還能用 Sitemap 篩選：所有已知網頁、所有已提交的網頁、僅限未提交的網頁，或特定的某一份 Sitemap。
網址檢查回報的探索、檢索與索引狀態
網址檢查的入口有兩個，一個是在任何頁面頂端的檢查列輸入完整網址，這個網址必須屬於目前開啟的資源，另一個是在報表裡的網址旁點「檢查」。
第一次打開結果卡片時要記住，預設顯示的是最近一次索引的版本，不是即時狀態，網頁之後可能已經變更。頂端的判定分兩種：「網址在 Google 服務中」表示可以出現在搜尋結果，但不保證一定會出現；「網址不在 Google 服務中」則表示無法出現。想最確定網頁有沒有出現，還是直接在 Google 搜尋該網址。
展開「網頁索引」後，有三個區塊：
- 探索：Google 怎麼找到這個網址，是透過 Sitemap 還是參照網頁；顯示「Google 無法辨識的網址」就代表 Google 先前從未找到它。
- 檢索：上次檢索的時間、檢索代理程式（電腦或行動）、「是否允許檢索？」（看 robots.txt）、「網頁擷取」成功與否，以及「是否允許編入索引？」（看有沒有 noindex）。
- 索引：使用者宣告的標準網址，與 Google 所選的標準網址是否一致。
要注意，「Google 所選的標準網址」只出現在索引版本的結果裡。每個資源每天可以檢查的次數有上限。
線上測試反映現況，但不保證收錄
按下「測試線上網址」，Search Console 會即時抓取目前的版本，適合在修好問題之後確認結果。成功的線上測試還能看到螢幕截圖，這是索引版本沒有的功能。每個資源每天的線上檢查也有次數上限。
不過線上測試顯示有效，不代表網頁一定會被收錄。它不檢查網頁品質與安全性準則、人工判決處罰或安全性問題、依法或其他原因的內容移除、網址是否被暫時封鎖，也不判斷是不是重複的網頁。「可編入索引」只代表 Google 抓得到、沒有偵測到阻擋，網頁還要滿足沒有人工判決處罰、不是另一個已索引網頁的重複，品質也夠高，才有機會被收錄。
要求建立索引的使用時機與每日配額
在網址檢查的結果頁按「要求建立索引」，系統會先做快速檢查，通過才排入佇列，線上測試判定不可編入索引的網址，是送不出去的。Google 的說明是通常需要一天左右，也可能長達一兩週，而且不保證一定收錄。這個要求有每日配額，用在刀口上比較實際。
適合按的時機有限：新網站先對首頁按一次，或是網頁有重要變更、一週以上都沒被 Google 注意到時。其他情況不必按，因為 Google 會依網頁的變更頻率自動重新檢索。一次有很多新頁面時，改提交 Sitemap 並標示 <lastmod> 更有效率。至於「已發現」與「已檢索」卻仍未建立索引這兩種狀態的成因與處理方式，站內另有專文說明。
成效報表先認識四個指標與六個分組
資源驗證完、幾天後有資料時，成效報表是最先打開的報表。預設檢視會顯示過去 3 個月的點擊次數與曝光次數。這份報表由四個指標組成：
| 指標 | 意思 |
|---|---|
| 點擊次數 | 使用者從搜尋結果點進你網站的次數 |
| 曝光次數 | 你的網站連結出現在搜尋結果的次數 |
| 點閱率 | 點擊次數除以曝光次數 |
| 平均排序 | 網站「最高」排序結果的平均排序 |
報表分成上方的圖表和下方的表格兩部分，表格可以切換六個分組分頁：查詢、網頁、國家／地區、裝置、搜尋外觀、日期。查詢看的是使用者搜了什麼字，網頁看的是哪些網址被看到，其餘幾個分頁則依序拆出國家、裝置、搜尋外觀與日期的差異。平均排序在圖表上，是整個網站最高結果的平均；在表格裡，則是該列網址或分組的平均。
這幾個數字各有一套固定的計算規則，不先弄懂，很容易誤讀。
點擊、曝光與平均排序，各有一套計算規則
曝光的條件比想像中寬鬆，連結只要出現在使用者目前看到的那一頁搜尋結果，就算一次，不論有沒有捲動到畫面內。有些項目例外，需要點「顯示更多」，或在獨立捲動的輪播與展開區塊裡，要捲入畫面或展開才算。捲動離開再捲回、翻頁離開再回來，不會重複計算。
點擊則必須前往 Google 以外的網頁才算。使用者點了某個連結、返回後再點同一個，只算一次；點不同的連結，各算一次。「查詢優化」連結會在 Google 內產生新的搜尋，它的點擊與曝光都不計入。在 AI 摘要或 AI 模式中，點擊外部連結算一次點擊，AI 摘要整塊只佔一個位置，裡面所有連結共用同一個位置。
平均排序的算法最特別，每次曝光取網站「最高」的那個位置，再對所有查詢平均。依 Google 說明頁的範例，查詢 1 的結果出現在第 2、4、6 位，記為 2；查詢 2 的結果出現在第 3、5、9 位，記為 3；平均排序是 （2+3）÷2＝2.5。一個搜尋結果元素只佔一個位置，廣告不佔位置，沒被使用者看見的位置，例如結果排在第三頁、使用者卻只看了第一頁，就不會記錄，顯示為「-」。
所以報表說名次是 5，自己搜尋卻看到 8，是正常的。報表的數字是所有搜尋的平均，而自己看到的結果還會受搜尋記錄、地點等因素個人化。另外，重複網址的資料會歸到 Google 所選的標準網址。
預設 3 個月，資料最多保留 16 個月
預設的日期範圍是過去 3 個月，可以切換日期範圍與搜尋類型：網頁、圖片、影片、新聞，各類型的資料分開計算，不會合併。時間精細度有每小時、每日、每週、每月四種，每小時只在 24 小時檢視可用，週與月的檢視能抹平週末與假日的波動，適合看長期趨勢。
時區要特別留意。報表的日期以太平洋時間（PT）為準，只有 24 小時檢視才改用瀏覽器所在的時區，所以和台灣的日期會有時差。最新幾天的資料也可能是初步資料，圖表上以虛線標示，幾小時內可能再變動。Google 在 2018 年推出新版 Search Console 時就說明，成效報表提供 16 個月的資料，可以拿來做跨年度的比較。
剛驗證完的新資源，資料要等幾天才會累積起來，打開是空白很正常。數天後仍是空白，可能是網站尚未在 Google 搜尋出現過，也可能是前面提到的前置字元版本打錯。
圖表總數與表格總數對不上的原因
最容易讓人懷疑報表壞掉的場景，是把表格的列加起來，結果和圖表的總數對不上。原因出在彙整方式：圖表一律依資源彙整，表格則依所選的分組而不同。依查詢、國家／地區、裝置、日期分組時，表格依資源彙整；依網頁或搜尋外觀分組時，則是依網頁彙整。
舉例來說，同一個查詢、同一個網站出現了兩個結果，圖表只算一次曝光，依網頁分組時兩個網頁各算一次曝光，總數自然不同。
另一個原因是匿名查詢。為了保護隱私而省略的匿名查詢，會計入圖表的總數，卻不會出現在表格裡；套用查詢篩選器時，圖表也不含這部分。再加上 Search Console 只儲存並顯示最重要的資料列，表格的列表可能不完整，需要完整資料時得用資料大量匯出。對比兩組資料時，若某個值在其中一組極少出現，該組會顯示「~」（無法提供）；匯出之後，「~」與「-」這類值都會變成 0。
第一次打開成效報表時的閱讀順序
第一次看報表，可以從大到小這樣讀。先看圖表的趨勢，把精細度調成每週或每月，抹平週末波動，看整體是上升、持平還是下滑。再切到「查詢」分頁，看帶來曝光的搜尋字詞是否符合網站定位，有沒有意料之外的詞；曝光高但點閱率低的查詢，往往是改善標題與說明的機會。
接著切到「網頁」分頁，找出撐起搜尋流量的那幾個頁面。網頁是依最終網址分組的，重複網址的資料會歸入標準網址。有需要時再看「國家／地區」與「裝置」，了解搜尋發生在哪些國家，以及電腦、平板與手機各佔多少。
平時不必天天看，每月快速看一次，留意點擊或曝光有沒有突然增減就行。Search Console 的總覽頁會一併顯示人工判決處罰與安全性問題，定期查看時先確認這兩項沒有警示，沒有就不必特別進去看。
想進一步篩選，例如平均排序大於 10 的查詢、規則運算式篩選或品牌詞，或是想看 AI 帶來的曝光，站內各有專文可以接著讀。
協作者以使用者身分加入，擁有權留給可交接的帳號
設定的最後一塊，是誰能看、誰能改。小公司常見的情境是行銷同事、外包工程師或代理商要看數據，要給的是使用者身分，擁有權則不要綁在會離職的人身上。每個資源至少要有一位已驗證的擁有者，否則所有使用者都會失去存取權。
新增使用者的入口在「使用者和權限」頁面，這個頁面只有擁有者看得到。新增時填對方的 Google 帳戶電子郵件，一定要是有效的 Google 帳戶，不能新增電子郵件群組，再選擇權限。非擁有者的上限是 100 位。
擁有者、完整權限使用者與權限受限使用者的分工
Google 的權限分成幾個層級：
- 擁有者：擁有完整控制權，可以新增或移除使用者、變更設定、檢視全部資料並使用全部工具。擁有者又分兩種。已驗證擁有者靠權杖證明身分，要新增或移除，得在網站上增減權杖；委派擁有者則由已驗證擁有者授予，不需要權杖，新增或移除只要在使用者管理畫面操作。
- 擁有完整權限的使用者：可以檢視所有資料，並執行部分動作。
- 權限受限的使用者：只能檢視多數的資料。
- 相關聯使用者：代表網站執行特定動作或存取特定資料的帳戶，但不能直接開啟資源。
前面的 Sitemap 一節提過，用報表提交 Sitemap 需要擁有者權限，這是擁有者與兩種使用者之間最明顯的差別之一。實務上，給協作者「擁有完整權限的使用者」通常就夠用，擁有權則留給公司可以交接的 Google 帳號，不要綁在個人信箱上，否則人員異動時，整個資源的存取都可能出問題。
移除人員時，連驗證權杖一起收回
很多人只在使用者清單按下「移除存取權」，就以為結束了。但如果對方是已驗證擁有者，他的權杖還留在網站上，仍能重新取得存取權。遇到這種情況，系統會跳出警告，提醒這位使用者可能重新取得存取權，必須把通知中列出的權杖一併移除，才算真正收回。
各驗證方法的收回方式不同：
- HTML 檔案：刪除網站根目錄中，該使用者專屬、內含 google-site-verification 字串的檔案，只刪屬於他的那一份。
- HTML 標記：從首頁原始碼移除該使用者專屬的 meta 標記。
- 網域名稱供應商：刪除對應的 DNS 記錄。
- Google Analytics：換用另一個 GA 帳戶，或撤銷對方的編輯權限。
- Google 代碼管理工具：換用另一個帳戶，或撤銷對方的發布或管理員權限。
找不到遺留的權杖時，可以在「使用者和權限」頁面點「未使用的擁有權權杖」查看。若發現不認得的擁有者，網站可能已經被入侵，駭客也可能在你移除之後再把權杖加回來，建議自行加固網站，或請資安專業人員協助。網域、主機、後台與 DNS 帳號由誰保管、離職時怎麼交接，站內另有專文說明，網站被入侵後的處理方向也有專文可看。
Google Search Console 的設定只需要做一次，之後留下來的是一個很輕的習慣。驗證做完、Sitemap 送出之後，每個月花幾分鐘看一次成效報表，留意點擊或曝光有沒有突然增減，修改網站內容後再回來看一次收錄狀態，這樣就夠了。
資料是從新增資源那一刻才開始收集的，所以最適合動手的時機，就是現在。