WordPress 提交 Google Search Console 完整攻略
WordPress 網站要怎麼提交到 Google Search Console？本篇完整教學涵蓋資源類型選擇、HTML 標記驗證、Sitemap 提交與收錄排查，帶你用 GSC 穩定讀取索引與排名數據。
作者：褚崇名（Sliven）
本頁目錄
- 快速總覽：WordPress 接 GSC 的完整流程
- 常被誤解的一件事：裝了 SEO 外掛，不等於網站被收錄
- 接 GSC 之前，先把 WordPress 三個地基打穩
- 新增資源：網域資源 vs 網址前置字串，怎麼選
- 五種驗證方法逐一拆解，附 WordPress 場景對照
- 用 WordPress 外掛加入驗證碼的通用路徑
- Sitemap 從產生到提交：一個完整的閉環
- Sitemap 不是萬能：它跟 robots.txt、GSC 提交的分工
- 提交完不是結束：用 URL Inspection 主動推單頁
- WordPress 站長最常踩的五個提交地雷
- 多語系、WooCommerce、多站點：WordPress 特殊架構的 GSC 考量
- 搬家或換網域之後，GSC 要做的三件事
- 站長的 GSC 週報表、月報表與季報表 SOP
- 把搜尋引擎的世界看大一圈：GSC 之外的三個延伸
- 今天就能開始的行動清單
快速總覽：WordPress 接 GSC 的完整流程
想像一下：你花了三個月用 WordPress 把網站蓋起來，文章一篇一篇上架，結果在 Google 搜尋寫過的標題，一條都找不到。原因可能是尚未被發現、索引設定、內容品質或查詢競爭，不能只靠是否驗證 GSC 判斷。
把 Google Search Console（以下簡稱 GSC）想成網站在 Google 搜尋端的官方監測工具。沒有驗證 GSC，Google 仍會正常發現、檢索與索引公開網頁；驗證後則能提交 Sitemap、檢查網址與查看搜尋成效，但不會因此取得優先排名或收錄保證。
這篇要解決的，就是 WordPress 站長從零到完整串接 GSC 的每一個環節。流程拆成三塊：
- 驗證身份：讓 Google 確認你是這個網站的擁有者。
- 提交 Sitemap：把整個網站的網址地圖交給 Google。
- 持續監測：用報表確認哪些頁面真的被收錄、哪些卡住了。
對照 WordPress 的特殊之處：你的 sitemap 不用自己手寫 XML，WordPress 核心或 SEO 外掛能協助產生；你的驗證碼也不用碰 FTP，許多 SEO 外掛後台就有欄位可以貼。整篇文章會跟著這條主線走，碰到 WordPress 特有的卡點我會特別標出來。如果你要的是 GSC 報表怎麼看、關鍵字怎麼優化，可以參考另一篇更通用的 Google Search Console 完整教學；這篇只鎖定「WordPress 網站如何正式提交進 GSC」這條主線。
常被誤解的一件事：裝了 SEO 外掛，不等於網站被收錄
很多 WordPress 站長在接觸 GSC 之前，會被問兩個問題。第一個：「你有沒有裝 SEO 外掛？」答案通常是「有」。第二個：「那你有沒有進過 GSC 後台？」答案常常是「沒有，裝了外掛不是就會自動被 Google 收錄嗎？」
這是一個很普遍的誤會，我得把它說清楚。
SEO 外掛在做的事，是協助網站產出或管理 title tag、meta description、canonical、結構化資料與 XML sitemap。它們是「對內」的整理工具，讓你的網站準備好被檢查。
SEO 外掛能產生 sitemap 或加入驗證標記，但不會因為安裝完成就強迫 Google 收錄頁面。網站擁有權仍要透過 DNS、HTML 標記、Google Analytics、Tag Manager 或官方整合流程驗證；各方法都需要具備相應權限。
SEO 外掛、WordPress 核心或其他 Sitemap 工具能輸出技術標記與網址清單，Google 也可能透過內部連結、外部連結與 robots.txt 的 Sitemap 宣告發現網站。GSC 的角色是提供提交與診斷介面，不保證把等待縮短到幾天，也不代表驗證後會排進特殊優先佇列。外掛與 GSC 功能互補，但網站被發現並不以兩者同時存在為前提。
另一個新手迷思是「我在 WordPress 按發佈，就等於上架到 Google」。發佈只是讓網址公開存在；Google 還要先發現、檢索並決定是否索引。內部連結與 Sitemap 都能協助發現，GSC 則讓你檢查結果。
把這件事再拆細一點，你會發現 Google 對一個網址的「認識」其實分成好幾個階段：被發現（discovered）、被檢索（crawled）、被建立索引（indexed）、出現在搜尋結果（served）。發佈文章只完成第零步：網址誕生。後面四步每一步都可能卡住，而你只有在 GSC 裡才看得到每一頁到底卡在哪一階段。沒有 GSC，你等於閉著眼睛開車，以為油門踩了就會到，卻不知道半路有沒有拋錨。正因如此，我把「串 GSC」當成 WordPress 站長做 SEO 的第一個動作，別等到流量出問題才補裝。
接 GSC 之前，先把 WordPress 三個地基打穩
很多人一拿到 GSC 就急著驗證，結果卡在「為什麼驗證一直失敗」或「提交了 sitemap 但狀態一直是失敗」。實務上十次有八次，問題出在 WordPress 本身的地基還沒弄好。我習慣在驗證之前，先確認這三件事。
第一，網站要走 HTTPS。 Google 從 2014 年就把 HTTPS 列為排名訊號之一，現在幾乎所有現代瀏覽器都會把 HTTP 網站標成「不安全」。如果沒裝 SSL 憑證，驗證碼跟 sitemap 都能跑，但後續 SEO 成效會被綁手綁腳。WordPress 主機後台大多有一鍵安裝 Let's Encrypt 的選項，具體操作可以對照 SSL 憑證完整教學。
第二，永久連結結構要穩定。 ?p=123 這種網址不是索引或排名障礙，但描述性網址通常更方便讀者辨認與管理。新站可依內容架構選擇「文章名稱」或自訂結構；既有網站不要只為了改得好看就更換所有網址，若確定要改，必須建立一對一 301 重導向。詳細做法可參考 WordPress 永久連結設定。
第三，確認 noindex 與 robots.txt 符合預期。 WordPress 的「阻擋搜尋引擎索引這個網站」選項會輸出 noindex，若正式站仍勾選，提交 GSC 也不會改變該指示。robots.txt 是合規爬蟲的檢索指示，不是存取控制；若封鎖重要路徑，Google 也可能看不到頁面上的 noindex。這部分可看 noindex 介紹。
把這三個地基打穩，再去 GSC 開資源，會省下後面非常多排查的時間。老實說，只要先把 HTTPS 跟永久連結弄對，後面的 GSC 驗證多半能一次通過，省下反覆排查的折磨。地基這件事，CP 值最高。
新增資源：網域資源 vs 網址前置字串，怎麼選
進到 GSC 後台，第一個動作是「新增資源」。你會看到兩個主要選項，我先把差異整理出來。
| 類型 | 涵蓋範圍 | 驗證方式 | 適合誰 |
|---|---|---|---|
| 網域資源（Domain） | 所有子網域 + http/https + www/非 www 全包 | 只能用 DNS TXT 記錄 | 擁有完整網域控制權、要長期經營的人 |
| 網址前置字串（URL prefix） | 單一協定 + 單一網域前綴（例如只有 https://example.com） | 五種驗證方式任選 | 只想驗證某個子站、或沒有 DNS 權限的人 |
只要擁有 DNS 控制權，網域資源通常最省事，因為能涵蓋 www、非 www、http、https 與子網域。DNS 記錄搬遷時仍可能遺漏；驗證失效主要影響帳戶存取與提交能力，不會讓 Google 停止正常檢索，也不會把既有搜尋資料改成不準。
如果你沒有 DNS 權限，例如網域是公司資產、DNS 是另一個部門管的，那就退一步選網址前置字串，用 HTML 標記或 Google Analytics 驗證。但記得，這種方式只涵蓋你填的那一個網址前綴，之後新增子網域要再開一個資源。
DNS 設定的具體操作，可以對照 DNS 網域指向設定教學，把 Google 給你的 TXT 記錄加到目前實際管理名稱伺服器的 DNS 後台。加完後等記錄傳播，再回 GSC 按「驗證」。
五種驗證方法逐一拆解，附 WordPress 場景對照
GSC 提供五種驗證方法，但對 WordPress 站長來說，真正會用到的只有兩三種。我把五種都列出來，讓你知道為什麼有些方法可以直接略過。
方法一：DNS TXT 記錄。 把一段 Google 給你的文字加到網域的 DNS 設定裡。最穩定、涵蓋最廣，缺點是要進 DNS 管理介面，對新手稍有門檻。適合有網域控制權、想長期經營的站長。
方法二：HTML 標記。 拿一段 <meta name="google-site-verification" content="..." />，加到首頁的 <head> 裡。許多 WordPress SEO 外掛都有專屬欄位可貼這段碼，不用改主題檔案，也不用 FTP。
方法三：HTML 檔案。 下載 Google 產生的 .html 檔，上傳到網站根目錄。對 WordPress 來說需要 FTP 或主機檔案權限，不熟檔案系統的人容易傳錯位置；一般外掛更新不會覆蓋網站根目錄的驗證檔，但搬站時可能遺漏。
方法四：Google Analytics。如果網站已安裝 Google Analytics，可在符合 Google 驗證條件時使用同一帳號完成驗證；帳號須具備相應權限，而且追蹤碼必須以支援的方式出現在頁面中。適合已使用 GA 做資料分析、不想新增驗證檔案的人。
方法五：Google Tag Manager。 透過 GTM 容器驗證，條件是你在 GTM 有容器層級的權限。適合已經用 GTM 統一管理所有追蹤碼的較大型站。沒用過 GTM 的人不用為了這個特別去裝，GTM 設定教學 是另一條獨立主線，不建議為了驗證勉強學。
| 你的 WordPress 情境 | 我推薦的驗證方法 |
|---|---|
| 自架站，網域自己買的 | DNS TXT（一次到位，涵蓋所有變體） |
| 網域是公司的，沒有 DNS 權限 | HTML 標記（透過 SEO 外掛或網站程式碼加入） |
| 已經在跑 GA4，同一個 Google 帳號 | Google Analytics（最快，省一個步驟） |
| 用 Site Kit by Google 串好全家桶 | Site Kit 自動帶你驗證，幾乎零手動 |
大多數自架 WordPress 站長會落在「DNS TXT」或「HTML 標記」這兩個選項。其他三種則看你的工具鏈是否剛好有重疊。
用 WordPress 外掛加入驗證碼的通用路徑
如果你選的是 HTML 標記驗證，先在既有 SEO 外掛的設定中找「網站管理員工具」「網站驗證」或類似欄位，把 Google 提供的 content 值貼入並儲存。不要為了驗證同時安裝多個 SEO 外掛，以免重複輸出標記或產生設定衝突。
Site Kit by Google： 這個最特別。Site Kit 是 Google 官方出的 WordPress 外掛，裝好之後它會直接幫你把 GA4、GSC、AdSense、PageSpeed Insights 全部串起來。在 Site Kit 裡連結 GSC 的過程，本身就把驗證順便做完了，你幾乎不需要手動碰驗證碼。如果你是那種「想用 Google 全家桶但又不想管太多設定細節」的站長，Site Kit 是最省事的選擇，完整流程可以參考 Site Kit by Google 教學。
這些方式的本質動作相近：把 Google 提供的驗證資訊加入網站，差別在介面與自動化程度。沿用網站既有且持續維護的工具即可，不要只為驗證更換外掛；能正確輸出驗證碼與 sitemap 才是重點。
一個小提醒：三個外掛的驗證碼欄位都支援「儲存後即時生效」，但偶爾會遇到快取外掛把舊的 <head> 卡住，導致 GSC 驗證一直失敗。遇到這種情況，先去快取外掛手動清一次快取，再回 GSC 按「驗證」，九成會立刻通過。這條排查路徑幾乎是 WordPress 驗證失敗的第一懷疑對象。
Sitemap 從產生到提交：一個完整的閉環
驗證通過之後，下一步是提交 Sitemap。對 WordPress 站長來說，這個動作可以拆成四步，每一個環節都要走完才算數。
第一步，確認 XML sitemap 已開啟。 WordPress 核心可產生 wp-sitemap.xml，許多 SEO 外掛則提供 sitemap 索引與納入內容類型等設定。先確認網站目前由哪個機制輸出，避免同時啟用多套 sitemap。
第二步，找到你的 sitemap 網址。 WordPress 常見的 sitemap 網址包括：
- WordPress 核心：
你的網域/wp-sitemap.xml - SEO 外掛常見格式：
你的網域/sitemap_index.xml
在瀏覽器打開這個網址，應該會看到一份 XML 格式的索引頁，列出 post-sitemap.xml、page-sitemap.xml、category-sitemap.xml 等子地圖。看到這份索引，代表外掛確實有在產 sitemap。XML Sitemap 的觀念細節可以對照 XML Sitemap 介紹。
第三步，在 GSC 提交。 回到 GSC 後台 → 左側選單「Sitemaps」→ 在欄位輸入 sitemap_index.xml（只需填後面那段，網域部分 GSC 已經知道）→ 按「提交」。狀態欄位會顯示「成功」或「無法讀取」。
第四步，看狀態、排查問題。 提交後等待 GSC 更新讀取狀態，回報時間不固定。如果顯示 0，或持續顯示「無法讀取」，回去檢查 sitemap 網址是否正確、Googlebot 能否存取，以及 sitemap 功能是否真的開啟。完整排查流程可以參考 Sitemap 產生與提交實作教學。
很多人卡在第三步就放著不管，其實第四步才是 sitemap 真正發揮價值的地方。sitemap 不是「提交完就沒事」，它是一個持續告訴 Google「我這個網站長這樣、有這些頁面」的活文件。每當你新增文章、調整分類，外掛會自動更新 sitemap，Google 下次來抓就會看到最新版本。
Sitemap 不是萬能：它跟 robots.txt、GSC 提交的分工
很多人以為「提交了 sitemap，Google 就一定會收錄所有頁面」。這是另一個需要打破的迷思。Sitemap 是「建議」，不是「命令」。Google 自己講得很白：提交 sitemap 等於把地圖遞給 Google，至於要不要真的走進每一個房間、要不要把每一頁收進索引，決定權還是在 Google 手上。
實際運作上，Google 發現你網站頁面有三條路徑可以走：
- 自然漫遊：它順著你網站的內部連結自己爬過去（這是最主要、也最被信賴的路徑）。
- robots.txt 的 Sitemap 宣告：你在 robots.txt 裡寫上 sitemap 網址，等於被動告知所有搜尋引擎。
- GSC 手動提交：你主動把 sitemap 遞進 Google 的官方窗口。
這三條路徑可以並用。內部連結協助爬蟲理解網站結構，robots.txt 的 Sitemap: 宣告可讓支援該指令的搜尋引擎發現地圖，GSC 提交則提供 Google 的讀取狀態回饋。
既然 robots.txt 宣告就能讓 Google 找到 sitemap，為什麼還要在 GSC 提交？因為 GSC 會回報是否成功讀取與發現的網址數，方便排查格式和存取問題；個別網址是否索引仍要看網頁索引報表，而不是期待 Sitemap 報表列出所有排除原因。
有些快取外掛或主機層級快取會暫存 robots.txt。修改後可清除相關快取，再查看 Search Console 的 robots.txt 報表與實際檔案內容；舊版 robots.txt 測試工具已不是現行介面。
提交完不是結束：用 URL Inspection 主動推單頁
Sitemap 提交的是「整個網站的地圖」，但有些頁面你會希望 Google 立刻處理，例如剛發的時效性文章、剛修正過的重大錯誤頁。這時候要用的是 GSC 的 URL Inspection 工具。
操作流程：在 GSC 最上方搜尋欄貼入完整網址，查看目前狀態；若尚未收錄或剛完成重要修正，可執行即時測試後按「要求建立索引」。這只是提出重新檢索要求，不保證收錄、時程或優先順位。
幾個使用限制要先知道。第一，這不是保證收錄按鈕。 重複提交不會讓網址更快，Google 也沒有說過度提交會降低網站優先序。第二，工具有配額。 不要把它當批次提交介面；大量頁面仍靠內部連結與 Sitemap 協助發現。工具細節可對照 URL Inspection 工具介紹。
第三，最適合用在三種情境： 剛發布且具時效性的重要文章、剛修正 noindex 或 canonical 錯誤的頁面、改完內容希望 Google 盡快重新評估的舊文。日常營運抓這三個時機就夠，不用每篇都推。
URL Inspection 另一個經常派上用場的功能，是排查單頁問題。如果某篇文章流量突然掉了，把網址貼進去看「涵蓋範圍」狀態，它會明確告訴你這頁是「已建立索引」、「已建立索引，但未被 Sitemap 提交」、「已檢索，但目前未建立索引」、「重複內容，Google 選了不同的標準網址」等等。每一種狀態背後對應不同的修法，這部分跟 Google 網頁收錄查詢 那篇可以一起看，觀念會串起來。
這裡要特別提醒一個新手常搞混的點：URL Inspection 顯示的「Google 索引」狀態，跟它旁邊那個「測試線上網址」（Live Test）是兩件事。「Google 索引」反映的是 Google 上次實際檢索並建立索引時看到的版本，可能是一兩週前的舊狀態；「測試線上網址」則是 Google 當場重新抓一次你現在這一頁的即時結果。所以當你剛改完一頁的內容或修好一個錯誤，URL Inspection 上層還顯示舊狀態時，不用慌，按一下「測試線上網址」確認現在的版本是好的，再要求建立索引讓 Google 重新評估。把這兩個狀態分清楚，能省下非常多「明明改好了為什麼 GSC 還顯示錯誤」的誤判。
還有一個被低估的用法：拿 URL Inspection 來驗證你的 WordPress 改動有沒有真的生效。例如你剛把某篇舊文的 canonical 從自訂網址改回自我指向，或者剛把某頁的 noindex 拿掉，不確定外掛是不是真的把標記輸出出去了，最快的方法就是把那個網址丟進 URL Inspection 看「網址檢查」回傳的 HTML，確認 rel="canonical" 或 noindex 的值是不是你要的。這比你自己開原始碼找還快，而且看到的是 Google 真正拿到的版本，不是你瀏覽器看到的版本。
WordPress 站長最常踩的五個提交地雷
整理反覆出現的 WordPress 提交卡關場景，可歸納成底下五個，每個都附排查方向。碰到問題時不要急著重提交，先回頭對照這張表找根因。
地雷一：sitemap 狀態一直顯示「無法讀取」。 最常見的原因是外掛其實沒產 sitemap，或網址打錯。先在瀏覽器直接打開 你的網域/sitemap_index.xml，看得到 XML 內容才代表有產。看得到但 GSC 還是讀不到，下一步檢查 robots.txt 有沒有 Disallow: /sitemap 之類的封鎖規則。
地雷二：www 跟非 www 搞混。 你在 GSC 開的是 https://example.com，但 WordPress 實際輸出的是 https://www.example.com（或反過來），驗證碼就會找不到。解法有兩條：要嘛在 WordPress「設定 → 一般」把兩個網址欄位統一，要嘛改用網域資源驗證，一次涵蓋所有變體。網址不一致也會牽動 canonical，這部分可以對照 Canonical URL 指南。
地雷三：HTTPS 跟 HTTP 混用。 你的資源是 https:// 開頭，但 WordPress 還有部分頁面輸出 http://，瀏覽器會跳「不安全」警告，GSC 的檢索也會被打斷。正解是裝好 SSL、強制 HTTPS 重導向，讓全站統一走加密協定，這部分看 HTTP 換 HTTPS 完整攻略。
地雷四：改網址結構之後沒做 301。 你把永久連結從 /%postname%/ 改成 /blog/%postname%/，舊網址全部失效，等於一夜之間把 Google 已經收錄的頁面全刪掉。改結構一定要搭配 301 重導向，觀念可以看 301 與 302 重導向指南，實務上 WordPress 可以用 Redirection 這類外掛處理。
地雷五：裝了快取外掛把驗證碼也快取掉了。 某些激進的快取設定會讓 Google 拿到的首頁 HTML 跟實際不同，驗證碼位置跑掉或被壓縮掉。排查方式是用無痕視窗打開首頁，檢視原始碼，搜尋 google-site-verification 確認 meta 標記還在。如果時有時無，把首頁暫時排除在快取之外，驗證通過之後再恢復。
這五個場景涵蓋不少常見的 GSC 提交問題。把它們記下來，下次卡關時就不用從零開始猜。
多語系、WooCommerce、多站點：WordPress 特殊架構的 GSC 考量
如果你的 WordPress 不是單純的單語系內容站，GSC 的資源規劃要再往前想一步。這幾種架構的提交邏輯都不太一樣。
多語系網站。 多語系站可能使用獨立子網域或子路徑。網域資源可涵蓋所有版本，若團隊需要分語系授權與篩選，也可另建 URL 前綴資源。每個語言版本應輸出正確 hreflang，且互相雙向回指，包含自我參照與有效正規網址。Search Console 舊版「國際指定目標」報表已停止提供，應用爬蟲或原始碼驗證標記。
電商站。 產品、分類、變體與篩選網址可能快速增加。大型或更新頻繁的網站才需要優先處理爬取預算；小型站更常見的是重複網址與索引策略不清。Sitemap 應只列希望索引的正規網址，篩選與變體頁則依是否有獨立使用者價值決定 canonical、noindex 或可索引，不要只因缺貨就一律排除。
多站點（Multisite）架構。 WordPress Multisite 用一個安裝底下列出多個子站，每個子站是獨立網址或子網域。這種架構下，每個子站原則上應該是獨立的 GSC 資源，各自提交各自的 sitemap，不要混在一起。把多個子站的網址塞進同一份 sitemap，Google 會直接忽略不屬於該網域的網址，等於白做工。
這三種架構的共同重點是：sitemap 不是「把所有網址倒進去就好」，它是一個要根據網站結構主動設計、主動修剪的工具。網站愈複雜，sitemap 的策略性愈高，也愈值得你花時間把低價值頁剔除。
搬家或換網域之後，GSC 要做的三件事
換網域、HTTP 與 HTTPS 切換，或 www 與非 www 版本變更時，需要同步檢查轉址、canonical、Sitemap 與 Search Console 資源；單純更換主機但網址不變，通常不需建立新的 GSC 資源，但仍要監測抓取與索引。若更換整個網域，可依WordPress 網域遷移教學完成 301 與網址變更設定。
第一，搬家前先在新站把 301 重導向設好。 舊網址要一對一指向新網址，讓 Google 知道「這頁沒有不見，只是搬家了」。301 是把舊網址的排名權重轉移到新網址的唯一正規管道，沒設好等於把多年累積的 SEO 資產丟進垃圾桶。搬家過渡期，舊站至少要保留 301 半年到一年，讓 Google 有充足時間完成權重轉移，太早把舊站下架是常見的致命錯誤。
第二，在新網域開一個新的 GSC 資源並完成驗證。 不要用舊資源硬撐，因為舊資源綁的是舊網域，新網域的驗證狀態、提交記錄、報表都得在新資源重新累積。新資源驗證好之後，立刻提交新網域的 sitemap，讓 Google 盡快開始認識新家。
第三，用 GSC 的「網址變更」工具（Change of Address）。 這是 GSC 專門給整站搬家用的一個功能，它會明確告訴 Google「整個網站從舊網域搬到新網域了」，加速 Google 把索引從舊網域轉到新網域。這個工具要在舊網域的 GSC 資源裡操作，而且只有網址前置字串資源支援，網域資源不支援，所以搬家時你可能需要臨時開一個網址前置字串資源，純粹為了用這個功能。
搬家期間最重要的一件事是耐心。Google 把索引從舊網址搬到新網址，通常需要幾週到幾個月，這段時間新舊網址會同時存在於索引裡，是正常現象。只要 301 設好、sitemaps 提交好、網址變更工具通知好，剩下的就是持續在 GSC 監測新網域的索引進度，不要在過渡期反覆改結構、改網址，那只會把 Google 搞混。
站長的 GSC 週報表、月報表與季報表 SOP
驗證、提交都做完之後，GSC 從這一刻起變成你的長期監測儀表板。但報表那麼多，到底該看哪些？我給你一份常用的檢查節奏，分成週、月、季三層。
每週花十分鐘看三件事：
- 「效能」報表，看點擊數跟曝光數有沒有異常波動。重點不是看絕對數字，而是看突然的掉落或暴衝，那些通常代表 Google 演算法波動、或你自己改了什麼。
- 「Sitemaps」狀態，確認還是「成功」、已發現的網址數有沒有跟著你新增文章而增加。如果一直停在原數字，可能是新文章沒被加進 sitemap。
- 「網頁索引」報表的「原因」分頁，看有沒有重要網址出現「已檢索，目前未建立索引」等狀態。這個狀態不能單憑報表確診內容太薄，應再用網址檢查、內容與內部連結交叉確認。
每月做一次深度檢查：
- 把「效能」報表切到過去 28 天，篩選「點擊數下降」的查詢，找出退步的關鍵字，回去對照是不是某篇文章被改弱了、或被競品超越。如果整體掉了，也要懷疑是不是被演算法更新波及，可以對照 排名下降復原 的排查思路。
- 看「網頁索引」裡的「排除」分類，定期清理重複內容、被 noindex 的頁面。這牽動到爬取預算，站愈大愈重要，觀念可以對照 爬取預算優化。
- 跑一次「核心網頁指標」，確認 WordPress 沒有因為裝了新外掛而拖慢速度。CWV 是 Google 公開承認的排名訊號之一，外掛裝太多是 WordPress 站長最常見的退化原因。
每季做一次大盤點：
回頭看提交的 sitemap，把已下線網址與不再希望索引的分類移除；檢查安全性問題與人工判決處置；用網址檢查、瀏覽器與實測確認手機版內容完整。Google 已全面採用行動優先索引，意思是主要以手機版內容進行檢索、索引與排名判斷，不是額外的行動版排名加分。Search Console 的行動裝置可用性報表已在 2023 年 12 月停止提供。
報表看久了你會發現一件事：GSC 真正的價值不是「提交」，而是「持續回饋」。你從這個儀表板知道 Google 怎麼看你、哪些頁面卡在哪、哪裡有機會擴張。它是你跟 Google 之間的雙向對話，不只是單向送件。
把搜尋引擎的世界看大一圈：GSC 之外的三個延伸
串好 GSC 之後，有幾個延伸方向值得你接著碰，它們會放大你這次設定的投資報酬率。這些的用意是讓你「知道方向在哪」，不要求一次到位。
第一是串 GA4。 GSC 告訴你「Google 怎麼把你帶進來」，GA4 告訴你「訪客進來之後做了什麼」。兩個數據源疊起來，你才看得到「曝光 → 點擊 → 工作階段 → 轉換」的完整漏斗。WordPress 串 GA4 的做法可以參考 WordPress GTM 加 GA4 串接教學。
第二是理解點擊率為什麼重要。 Backlinko 分析超過 400 萬筆 Google 搜尋結果的研究（2025 年 4 月）發現，排名位置的點擊率分布差距非常大，排名第一的結果拿走的點擊量是排名第十的好幾倍，而 GSC 的效能報表正是你唯一能拿到自己網站真實 CTR 的地方。換句話說，GSC 不只是「確認有沒有被收錄」，它還告訴你「標題跟描述到底吸不吸引人點」。
第三是別只看 Google。 Bing 雖然在台灣市佔低，但有對應的 Bing Webmaster Tools，邏輯跟 GSC 幾乎一樣，提交成本很低，等於用同一套技能多做一個流量來源。先把 GSC 的主線走穩，再回頭挑一個延伸觸角往深處鑽，會比一次想全部學完更扎實。
順帶澄清一個常被拿來問的工具：Google 的 Indexing API。很多人聽到「API 可以直接叫 Google 來索引」，以為這是比 GSC 更快的捷徑。但 Indexing API 目前只正式支援兩種內容類型：JobPosting（職缺）跟 BroadcastEvent（直播事件），一般內容站、部落格、電商產品頁送過去，Google 不保證會處理。對絕大多數 WordPress 站長來說，按部就班走 sitemap 加 GSC 提交這條正規路徑，反而比繞去碰 API 更實際。與其追逐看起來很炫的捷徑，不如把基本動作做扎實。
今天就能開始的行動清單
把整篇文章濃縮成一份你可以現在就照著做的清單。照順序走完，你的 WordPress 站就完成了跟 Google 的第一次正式接觸。
- 確認三個地基： 網站走 HTTPS、永久連結用文章名稱、「設定 → 閱讀」裡的「阻擋搜尋引擎」沒被打勾。
- 決定資源類型： 有 DNS 控制權就開網域資源、用 DNS TXT 驗證；沒有就開網址前置字串、用 HTML 標記。
- 加入驗證資訊： 用既有 SEO 外掛貼入 HTML 標記，或依 Site Kit 的連結流程完成驗證。
- 回 GSC 按驗證： DNS 可能要等記錄傳播；HTML 標記若已出現在公開首頁，通常能較快確認。
- 找到並提交 sitemap： 瀏覽器先確認
你的網域/sitemap_index.xml跑得出來，再到 GSC 提交。 - 挑一篇重要文章用 URL Inspection 推： 練一次這個工具，往後你才知道怎麼主動推單頁、怎麼查單頁狀態。
- 建立週報表節奏： 每週十分鐘看效能、sitemap 狀態、網頁索引原因；每月做一次深度檢查。
WordPress 目前支撐全球超過四成的網站，根據 W3Techs 的長期追蹤統計（2026 年 6 月），它的市佔率長年穩居內容管理系統第一名。這代表你正在用的這套工具鏈，背後有一整個生態在撐，問題通常都能找到對應的文件或處理方式，不用從頭造輪子。
把 GSC 串好、Sitemap 提交、報表看懂，這三件事是WordPress 站長做 SEO的地基工程。地基穩了，後面寫再多內容、做再多優化，才會真的被 Google 看見。現在就挑出你網站的首頁，把這份清單走完第一遍，剩下的只是重複與深化。SEO 從來是長期投資，而這次設定，就是你存進 Google 帳戶裡的第一筆本金。
如果你在驗證或提交過程卡關，回頭把「三個地基」跟「五個地雷」那兩段再看一次，大多數問題的答案都藏在那裡。真的排查不出來，把卡住的那一頁網址丟進 URL Inspection，讓 Google 自己告訴你它看到了什麼，往往比自己猜更快。祝你的 WordPress 站早日出現在搜尋結果第一頁。
常見問題
提交了 Sitemap，等於被收錄嗎？
www 跟非 www、http 跟 https 要分開驗證嗎？
換 WordPress 主題會讓驗證碼失效嗎？
Google Search Console 跟 Google Analytics 差在哪？
操作步驟
- 在 GSC 建立資源並複製 HTML 標記：登入要綁定的 Google 帳號，選「網址前置字串」、輸入網域（確認 www 與 https），展開「其他驗證方法」找到 HTML 標記，複製整段 meta 碼。
- 用 SEO 外掛貼驗證碼：在 Rank Math「General Settings → Webmaster Tools → Google Search Console」或 Yoast「設定 → 網站管理員工具 → Google Search Console」貼入 Google 給的 content 值並儲存；改用 Site Kit 連結 GSC 時也會順便完成驗證。
- 儲存後即時生效並視情況清快取：SEO 外掛會自動把 meta 標記插進全站 head，儲存即生效；若 GSC 驗證失敗，先到快取外掛手動清一次快取再回 GSC 按驗證，九成會立刻通過。
- 回到 GSC 按驗證：按下「驗證」，Google 會爬取網站確認碼存在；順利的話幾秒鐘跳出成功提示，點「前往資源」進入主面板。
- 確認成功後進入主面板：主面板左側選單列出成效、網頁索引、Sitemap、網址審查等功能，驗證即完成。