對任何經營 WordPress 網站的企業而言，Google Search Console（GSC）出現收錄警訊是一件必須嚴肅對待的事。一般的搜尋排除（例如 `noindex` 標籤）通常很容易在網頁原始碼中被抓出來，但如果警告是顯示：在「X-Robots-Tag」HTTP 標頭中偵測到「noindex」，這代表錯誤被隱藏在一般網頁檢視原始碼中完全看不見的地方！

本期案例是一家經營線上教育培訓的 WordPress 網站，他們在一次主機搬遷後，遇到了全站搜尋收錄量與曝光量異常下降的情況。以下是 WebCare 運維團隊協助其診斷、排查與修復的技術實錄。

一、遭遇痛點：網站搜尋收錄量大幅下降

該線上教育平台平時主要依賴搜尋引擎帶來的自然流量。然而在主機遷移完成後，行銷人員發現使用 Google 搜尋自家品牌與課程關鍵字時，網站多個主要頁面並未出現在搜尋結果中。

行銷人員登入 GSC 查看「網頁編入索引」報告，發現大量頁面被標示為「未編入索引」，其排除原因皆為：

  • 警示訊息： Google 標示大量頁面「未編入索引」，原因全部指向「X-Robots-Tag HTTP 標頭中偵測到 noindex」。
  • 搜尋曝光表現： 從下方的 Google Search Console 數據走勢圖可以清楚看到，搜尋曝光與點擊數在移轉主機後迅速下降。
Google Search Console 曝光異常與回升趨勢圖
圖：GSC 顯示搜尋曝光量在修復前出現明顯下滑，經檢修後已逐步恢復

二、什麼是「X-Robots-Tag」？為何此項錯誤不易在前端被察覺？

一般人所熟知的 noindex，是寫在網頁 HTML <head> 區塊內部的 Meta 標記：<meta name="robots" content="noindex">。這種標記只要滑鼠右鍵點擊「檢視網頁原始碼」就能輕易查出。

然而，**X-Robots-Tag** 則是透過伺服器端（如 Apache 或 Nginx）在傳送網頁時，夾帶在 HTTP 響應標頭（HTTP Response Header）中的指令。

它的優點是可以用來指示搜尋引擎如何處理非 HTML 檔案（如 PDF 檔或圖片），但缺點是一旦設定錯誤，一般的 HTML 原始碼中完全找不到任何痕跡，必須透過專業的伺服器 HTTP Header 檢測工具（如 `curl` 指令或開發者工具的 Network 欄位）才能查出。

三、WebCare 技術排查：錯誤到底出在哪裡？

WebCare 團隊在接手檢修後，立即進行了以下步驟：

1. 排除 WordPress 後台與外掛設定

我們首先確認了 WordPress 後台的「設定 > 閱讀」中，「阻擋搜尋引擎索引這個網站」 並沒有被勾選。同時也檢查了客戶使用的 RankMath SEO 外掛，其全站與單頁 robots 設定皆為 `index`。這證實了錯誤並非來自 WordPress 本身，而是更底層的伺服器配置。

2. 檢測 HTTP Response Headers

我們在終端機使用 curl 指令讀取網站標頭：
curl -I https://www.client-domain.com

回傳結果中，清楚顯示了這一行：
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive

這導致搜尋引擎爬蟲無法正常讀取網頁，網頁隨之被排除在收錄名單之外。

3. 揪出 Nginx 伺服器設定中的 staging 殘留規則

由於客戶使用的是 Nginx 伺服器，我們進入伺服器後台檢查 Nginx 設定檔（通常位於 `/etc/nginx/sites-available/`）。

經過逐行排查，我們在該網站的 `server {}` 設定區塊中，抓到了這一行代碼：
add_header X-Robots-Tag "noindex, nofollow";

原來，該網站在主機搬遷前，曾架設在暫存的測試站（Staging Site）供內部驗收，當時的工程師為了防止未完工的測試站被 Google 收錄，在伺服器端加上了這行規則。但在正式上線搬遷到正式伺服器時，工程師**直接複製了測試站的 Nginx 設定檔，卻忘記將此行指令移除**。

四、解決方案與修復成效

查明原因後，WebCare 團隊迅速實施了以下改善措施：

  1. 移除伺服器錯誤指令： 將 Nginx 設定檔中的 `add_header X-Robots-Tag "noindex, nofollow";` 規則刪除。
  2. 重新載入伺服器： 執行 `sudo nginx -t` 檢查語法無誤後，使用 `sudo systemctl reload nginx` 重新載入設定，使變更立即生效。
  3. 清理多重快取： 清除 WordPress 快取外掛（WP Super Cache）以及 Cloudflare CDN 快取，確保 Google 爬蟲再次造訪時收到最新乾淨的 HTTP 標頭。
  4. 手動申請 Google 重新抓取： 登入 Google Search Console，使用網址檢查工具（URL Inspection）對首頁與多個核心產品頁面點擊「要求編入索引」，主動通知 Google 爬蟲網站已恢復正常。

五、最終成效：搜尋曝光逐步回升並恢復正常收錄

在修復後的第 3 天起，Google 搜尋引擎再度開始抓取並重新收錄該網站的頁面。在修復後的第 10 天，GSC 後台的「X-Robots-Tag noindex」警告已全數清除。

正如上方趨勢圖所示，**搜尋曝光數在錯誤排除後，呈現顯著的回升趨勢**，點擊量也逐步回歸正常，使該平台重新恢復了正常的諮詢與收單管道。

這個案例說明了網站上線或主機搬遷時，除了確認前端網頁顯示正常外，伺服器端的技術細節同樣會直接影響 SEO 收錄。如果您在維護過程中遇到類似的搜尋異常問題，歡迎與 WebCare 團隊聯繫，我們將協助您排查並維持網站的穩定運作。