WordPress 提交 Google Search Console 完整攻略

快速總覽：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 三個地基打穩

開始驗證前，先確認正式網址與公開頁面狀態。以下三項有助於網站管理與索引排查，但驗證能否通過仍取決於所選方法的權限、驗證資訊與存取條件。

第一，網站要走 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 介紹。

確認正式網址、永久連結與索引設定後，再依持有的 DNS 或網站管理權限選擇驗證方法。HTTPS 與網址結構本身不會代替擁有權驗證。

新增資源：網域資源 vs 網址前置字串，怎麼選

進到 GSC 後台，第一個動作是「新增資源」。你會看到兩個主要選項，我先把差異整理出來。

只要擁有 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 容器驗證，條件是登入 GSC 的同一 Google 帳號對 GTM 容器具備「發布」權限，且容器片段已正確安裝。適合已經用 GTM 統一管理所有追蹤碼的較大型站。沒用過 GTM 的人不用為了這個特別去裝，GTM 設定教學 是另一條獨立主線，不建議為了驗證勉強學。

大多數自架 WordPress 站長會落在「DNS TXT」或「HTML 標記」這兩個選項。其他三種則看你的工具鏈是否剛好有重疊。

用 WordPress 外掛加入驗證碼的通用路徑

如果你選的是 HTML 標記驗證，先在既有 SEO 外掛的設定中找「網站管理員工具」「網站驗證」或類似欄位，把 Google 提供的 content 值貼入並儲存。不要為了驗證同時安裝多個 SEO 外掛，以免重複輸出標記或產生設定衝突。

Site Kit by Google： 這個最特別。Site Kit 是 Google 官方出的 WordPress 外掛，初始設定會連結既有 Search Console 資源或建立資源，並提供選擇性連結 Analytics；AdSense 等其他服務需依需要另行設定。在 Site Kit 裡連結 GSC 的過程，本身就把驗證順便做完了，你幾乎不需要手動碰驗證碼。如果你是那種「想用 Google 全家桶但又不想管太多設定細節」的站長，Site Kit 是最省事的選擇，完整流程可以參考 Site Kit by Google 教學。

這些方式的本質動作相近：把 Google 提供的驗證資訊加入網站，差別在介面與自動化程度。沿用網站既有且持續維護的工具即可，不要只為驗證更換外掛；能正確輸出驗證碼與 sitemap 才是重點。

儲存 HTML 驗證標記後，先確認公開首頁的原始碼能看到正確的 google-site-verification。若仍是舊內容，可清除網站與 CDN 快取後再試；若已正確輸出但驗證失敗，還要核對資源前綴、標記位置及 Google 是否能存取頁面。

Sitemap 從產生到提交：一個完整的閉環

驗證通過之後，下一步是提交 Sitemap。對 WordPress 站長來說，這個動作可以拆成四步，每一個環節都要走完才算數。

第一步，確認 XML sitemap 已開啟。 WordPress 核心可產生 wp-sitemap.xml，許多 SEO 外掛則提供 sitemap 索引與納入內容類型等設定。先確認網站目前由哪個機制輸出，避免設定互相衝突。Google 支援提交多份 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 提交。開啟「Sitemaps」，輸入網站實際產生的 Sitemap 網址，例如 https://example.com/wp-sitemap.xml 或 https://example.com/sitemap_index.xml。網域資源需提供完整網址；若網址前置字元資源已顯示固定前綴，依介面補入其餘路徑。提交後查看讀取狀態。

第四步，看狀態、排查問題。 提交後等待 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 另一個經常派上用場的功能，是排查單頁問題。如果某篇文章流量突然掉了，把網址貼進去，查看「網頁索引」資訊、上次檢索與 Google 選取的標準網址，再判斷是否需要修正；未索引狀態不一定是錯誤，這部分跟 Google 網頁收錄查詢 那篇可以一起看，觀念會串起來。

這裡要特別提醒一個新手常搞混的點：URL Inspection 顯示的「Google 索引」狀態，跟它旁邊那個「測試線上網址」（Live Test）是兩件事。「Google 索引」反映的是 Google 上次實際檢索並建立索引時看到的版本，可能是一兩週前的舊狀態；「測試線上網址」則是 Google 當場重新抓一次你現在這一頁的即時結果。所以當你剛改完一頁的內容或修好一個錯誤，URL Inspection 上層還顯示舊狀態時，不用慌，按一下「測試線上網址」確認現在的版本是好的，再要求建立索引讓 Google 重新評估。把這兩個狀態分清楚，能省下非常多「明明改好了為什麼 GSC 還顯示錯誤」的誤判。

修改 canonical 或 noindex 後，可先檢查公開頁面的 HTML 與 HTTP 回應標頭，再執行 URL Inspection 的「測試線上網址」查看目前抓取結果。一般索引檢查呈現的是 Google 已保存的版本，未必反映剛完成的修改；X-Robots-Tag 形式的 noindex 也不會出現在 HTML 中。即時測試可協助檢查存取與輸出，但不保證索引，也不能預告 Google 最終選取的 canonical。

WordPress 站長最常踩的五個提交地雷

整理反覆出現的 WordPress 提交卡關場景，可歸納成底下五個，每個都附排查方向。碰到問題時不要急著重提交，先回頭對照這張表找根因。

地雷一：sitemap 狀態一直顯示「無法讀取」。 最常見的原因是外掛其實沒產 sitemap，或網址打錯。先在瀏覽器直接打開 你的網域/sitemap_index.xml，看得到 XML 內容才代表有產。看得到但 GSC 還是讀不到，下一步檢查 robots.txt 有沒有 Disallow: /sitemap 之類的封鎖規則。

地雷二：www 跟非 www 搞混。 你在 GSC 開的是 https://example.com，但 WordPress 實際輸出的是 https://www.example.com（或反過來），應先確認正式網址、轉址與資源範圍。新增對應正式版本的網址前置字元資源，或使用 DNS 驗證的網域資源涵蓋各變體；不必只為驗證而更動正式網站網址。網址不一致也會牽動 canonical，這部分可以對照 Canonical URL 指南。

地雷三：HTTPS 跟 HTTP 混用。 你的資源是 https:// 開頭，但 WordPress 還有部分頁面輸出 http://，可能造成安全警告、重複版本或資料分散；HTTP 本身並不表示 Google 無法檢索。若正式版本是 HTTPS，應裝好有效憑證，將 HTTP 網址逐一轉向對應的 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）架構。同一根網域下的子站可由網域資源涵蓋，也可依管理權限另建網址前置字元資源。不同網域應確認相應擁有權。Google 支援在已驗證網站間跨站提交 Sitemap，因此不必假設跨網域網址都會被忽略；若採集中管理，須遵循官方跨站提交條件並保持每個網址與網站歸屬清楚。

這三種架構的共同重點是：sitemap 不是「把所有網址倒進去就好」，它是一個要根據網站結構主動設計、主動修剪的工具。網站愈複雜，sitemap 的策略性愈高，也愈值得你花時間把低價值頁剔除。

搬家或換網域之後，GSC 要做的三件事

換網域、HTTP 與 HTTPS 切換，或 www 與非 www 版本變更時，需要同步檢查轉址、canonical、Sitemap 與 Search Console 資源；單純更換主機但網址不變，通常不需建立新的 GSC 資源，但仍要監測抓取與索引。若更換整個網域，可依WordPress 網域遷移教學完成 301 與網址變更設定。

第一，為舊網址準備一對一的永久轉址。搬遷啟用時，讓舊網址回應 301 或 308 並指向對應的新網址，避免全部轉到首頁。轉址需由能回應舊網址的伺服器或服務提供；Google 建議通常至少保留一年，對仍使用舊連結的讀者則可保留更久。同時更新內部連結、canonical 與 Sitemap，並監測新舊網址的抓取及索引。

第二，在新網域開一個新的 GSC 資源並完成驗證。 不要用舊資源硬撐，因為舊資源綁的是舊網域，新網域的驗證狀態、提交記錄、報表都得在新資源重新累積。新資源驗證好之後，立刻提交新網域的 sitemap，讓 Google 盡快開始認識新家。

第三，確認是否適用 GSC 的「網址變更」工具。搬到另一個網域或子網域時，依工具的資格與檢查結果，從舊資源提出變更，且需擁有新舊資源的權限。先完成逐頁轉址與新站驗證；單純 HTTP 改 HTTPS、同網域內的路徑變更或只換主機，不使用這個工具。

搬家期間最重要的一件事是耐心。Google 把索引從舊網址搬到新網址，通常需要幾週到幾個月，這段時間新舊網址會同時存在於索引裡，是正常現象。只要 301 設好、sitemaps 提交好、網址變更工具通知好，剩下的就是持續在 GSC 監測新網域的索引進度，不要在過渡期反覆改結構、改網址，那只會把 Google 搞混。

站長的 GSC 週報表、月報表與季報表 SOP

驗證、提交都做完之後，GSC 從這一刻起變成你的長期監測儀表板。但報表那麼多，到底該看哪些？我給你一份常用的檢查節奏，分成週、月、季三層。

每週花十分鐘看三件事：

1. 「效能」報表，看點擊數跟曝光數有沒有異常波動。重點不是看絕對數字，而是看突然的掉落或暴衝，那些通常代表 Google 演算法波動、或你自己改了什麼。
2. 「Sitemaps」狀態，確認還是「成功」、已發現的網址數有沒有跟著你新增文章而增加。如果一直停在原數字，可能是新文章沒被加進 sitemap。
3. 「網頁索引」報表的「原因」分頁，看有沒有重要網址出現「已檢索，目前未建立索引」等狀態。這個狀態不能單憑報表確診內容太薄，應再用網址檢查、內容與內部連結交叉確認。

每月做一次深度檢查：

1. 把「效能」報表切到過去 28 天，篩選「點擊數下降」的查詢，找出退步的關鍵字，回去對照是不是某篇文章被改弱了、或被競品超越。如果整體掉了，也要懷疑是不是被演算法更新波及，可以對照 排名下降復原 的排查思路。
2. 看「網頁索引」裡的「排除」分類，定期清理重複內容、被 noindex 的頁面。這牽動到爬取預算，站愈大愈重要，觀念可以對照 爬取預算優化。
3. 跑一次「核心網頁指標」，確認 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 僅支援含 JobPosting 的職缺頁，或在 VideoObject 中嵌入 BroadcastEvent 的直播影片頁。一般文章與商品頁不在支援範圍內，不應把它當成通用索引捷徑；這些頁面仍透過可檢索連結、Sitemap 與適當的網址檢查流程協助 Google 發現。

今天就能開始的行動清單

把整篇文章濃縮成一份你可以現在就照著做的清單。照順序走完，你的 WordPress 站就完成了跟 Google 的第一次正式接觸。

1. 確認三個地基： 網站走 HTTPS、永久連結結構穩定、「設定 → 閱讀」裡的「阻擋搜尋引擎」沒被打勾。
2. 決定資源類型： 有 DNS 控制權就開網域資源、用 DNS TXT 驗證；沒有就開網址前置字串、用 HTML 標記。
3. 加入驗證資訊： 用既有 SEO 外掛貼入 HTML 標記，或依 Site Kit 的連結流程完成驗證。
4. 回 GSC 按驗證： DNS 可能要等記錄傳播；HTML 標記若已出現在公開首頁，通常能較快確認。
5. 找到並提交 sitemap： 瀏覽器先確認網站實際的 Sitemap 網址可正常開啟，再到 GSC 提交。
6. 挑一篇重要文章用 URL Inspection 推： 練一次這個工具，往後你才知道怎麼主動推單頁、怎麼查單頁狀態。
7. 建立週報表節奏： 每週十分鐘看效能、sitemap 狀態、網頁索引原因；每月做一次深度檢查。

WordPress 目前支撐全球超過四成的網站，根據 W3Techs 的長期追蹤統計（2026 年 6 月），它的市佔率長年穩居內容管理系統第一名。這代表你正在用的這套工具鏈，背後有一整個生態在撐，問題通常都能找到對應的文件或處理方式，不用從頭造輪子。

把 GSC 串好、Sitemap 提交、報表看懂，這三件事是WordPress 站長做 SEO的地基工程。地基穩了，後面寫再多內容、做再多優化，才會真的被 Google 看見。現在就挑出你網站的首頁，把這份清單走完第一遍，剩下的只是重複與深化。SEO 從來是長期投資，而這次設定，就是你存進 Google 帳戶裡的第一筆本金。

如果你在驗證或提交過程卡關，回頭把「三個地基」跟「五個地雷」那兩段再看一次，大多數問題的答案都藏在那裡。真的排查不出來，把卡住的那一頁網址丟進 URL Inspection，讓 Google 自己告訴你它看到了什麼，往往比自己猜更快。祝你的 WordPress 站早日出現在搜尋結果第一頁。