如何檢查網頁能否被 Google 抓取？網站可抓取性檢測與排查方法

網頁新頁面發布了好幾天，瀏覽器打開完全正常，但 Google 就是一直不收录。遇到這種情況，很多人第一反應是重新提交 Sitemap，或者用 site: 搜尋域名看看有沒有結果。但這些方法根本無法幫你確認：Googlebot 到底能不能正常存取並讀取這個網頁？

一個頁面想出現在 Google 搜尋結果中，必須先被搜尋引擎發現和存取，隨後才會進入內容解析、規範化與索引環節。如果伺服器傳回異常、robots.txt 存在攔截，或者頁面誤加了 noindex、錯誤 Canonical，即使網頁在瀏覽器裡看起來一切正常，Google 也無法順利完成抓取和索引。排查網頁可抓取性不能只盯著某一個設定檔，而要順著整個 HTTP 存取和爬蟲解析鏈路一步步往下梳。

一、能抓取、能索引和已經收錄不是一回事

排查之前，最好先釐清這三個經常被混淆的概念：

• 可抓取（Crawlable）： 指 Googlebot 能夠成功發起 HTTP 請求，並完整下載網頁的原始碼或資源。

• 可索引（Indexable）： 指頁面沒有設定任何阻止索引的指令（如 noindex），並且具備進入 Google 索引庫的基礎技術條件。

• 已經收錄（Indexed）： 指 Google 已經完成了內容解析與評估，最終選擇將這個 URL 寫入搜尋資料庫。

三者是層層遞進的邏輯鏈條，不能劃等號。

一個網頁：

• HTTP 回應狀態：200 OK

• robots.txt 狀態：Allowed

這只能說明伺服器沒有拒絕 Googlebot，且爬蟲被允許下載頁面。如果此時頁面 HTML 頭裡寫著 <meta name="robots" content="noindex">，Google 雖然成功抓取了頁面，但會尊重你的指令，絕不會把它放入一般索引庫。

反過來，robots.txt 阻止抓取，並不等於這個 URL 絕對不會出現在 Google 搜尋結果中。如果 Google 透過站外連結發現了這個 URL，即使因為 robots.txt 的攔截無法讀取頁面具體內容，它依然可能將這個網址展示在搜尋結果裡（通常摘要部分會提示由於 robots.txt 限制無法顯示描述）。

所以，當頁面遲遲不被收錄時，第一步是確定問題究竟出在「發現」、「抓取」還是「索引」階段。

二、網頁可抓取性標準排查鏈路

遇到抓取異常時，建議嚴格按照下面這條遞進鏈路逐項排查：

目標網頁 URL
   ↓
HTTP 狀態碼回應是否正常 (排除 403/5xx/異常重新導向)
   ↓
robots.txt 是否允許 Googlebot 存取 (確認未被目錄規則誤殺)
   ↓
頁面 Meta/Header 是否誤加了 noindex (檢查 HTML 與 Response Header)
   ↓
Canonical 標籤指向是否一致 (確認規範網址未錯配)
   ↓
源站與網路層是否存在存取限制 (排查 WAF/CDN/地區封鎖/登入攔截)
   ↓
JavaScript 動態渲染是否有效 (確認 Google 拿到了完整 DOM 結構)
   ↓
Sitemap 與站內連結入口是否正常 (解決抓取入口與發現問題)
   ↓
Google Search Console 即時測試 (取得 Googlebot 視角下的最終診斷結果)

這套流程的優勢在於先排查基礎網路與協定問題，再排查頁面級設定，最後看引擎回饋。如果伺服器本身直接傳回 500 錯誤或被 WAF 攔截，再去研究 Canonical 或 Sitemap 沒有任何意義。

三、第一步：確認 HTTP 狀態碼與回應標頭

Googlebot 存取網頁本質上就是發起標準的 HTTP/HTTPS 請求。排查的第一步，是看伺服器到底給爬蟲傳回了什麼回應代碼。

很多新手喜歡直接看瀏覽器上的頁面，但瀏覽器能開啟不代表爬蟲也能開啟。最簡單準確的方法是用 Chahu 的 HTTP 狀態檢測工具，輸入網址就能直觀看到伺服器給不同請求傳回的實際 Response Header 和重新導向路徑。

常見回應狀態及排查方向：

但是瀏覽器打得開，不代表 Googlebot 就能打得開。很多網站部署了 CDN、高防 IP 或 WAF，防火牆規則如果設定不當，會把正常的自動化請求直接識別為惡意 Bot 並拋出 403 回應。一般訪客用瀏覽器存取拿到的是 200 OK，而爬蟲存取拿到的卻是 403，這種情況下搜尋引擎根本抓不到任何內容。

四、第二步：檢查 robots.txt 抓取規則

HTTP 狀態確認無誤後，接著查看根目錄下的 robots.txt 檔案（例如 https://example.com/robots.txt）。

robots.txt 的作用是告知搜尋引擎哪些路徑可以抓取，哪些路徑禁止抓取。

HTTP

User-agent: *
Disallow: /blog/

如果你的目標頁面正好位於 /blog/my-post/ 下，那麼這條指令就會直接禁止爬蟲進入該目錄。

手寫或人工核對複雜的 robots.txt 規則很容易漏掉萬用字元邏輯，建議用 robots.txt 檢測工具 跑一下測試。直接輸入具體頁面 URL，工具會自動模擬 Googlebot 匹配規則，快速判斷目前路徑是 Allowed 還是 Blocked。

在排查 robots.txt 時，特別需要關注規則涵蓋範圍與 noindex 的衝突問題：

如果一個頁面同時設定了 robots.txt Disallow 和 <meta name="robots" content="noindex">，Googlebot 是讀不到頁面裡的 noindex 的！因為 robots.txt 已經阻止了爬蟲下載這個 HTML 檔案。如果該頁面在站外有外鏈，Google 依然可能把這個網址建立索引並展示在搜尋結果中。想要徹底移除頁面，正確的做法是允許抓取，並在頁面中保留 noindex。

五、第三步：排查頁面級 noindex 指令

當 robots.txt 顯示允許抓取（Allowed），但頁面依然不被收錄，就需要檢查頁面原始碼中是否存在阻止索引的標籤。

排查重點包括兩個位置：

1. HTML 原始碼裡的 Meta 標籤：

   HTML

   <meta name="robots" content="noindex, follow"> 

2. HTTP 回應標頭裡的 X-Robots-Tag：

   HTTP

   HTTP/1.1 200 OK X-Robots-Tag: noindex

此類問題極其常見於網站改版或測試上線階段。開發人員在 staging 環境中統一設定了 noindex 避免測試頁面被收錄，切到正式環境後忘記清理該標籤。

結果就會導致：頁面存取正常、HTTP 200、robots.txt 允許，但 Google 就是堅決不收錄。你可以直接透過 Chahu 的 Meta 標籤檢測工具 批次掃描目標頁面，它會自動拎出隱藏在 HTML 或 Header 裡的 robots、noindex 等索引限制指令，比在瀏覽器控制台翻程式碼高效得多。

六、第四步：檢查 Canonical 規範網址設定

當頁面可存取、未攔截且沒有 noindex 時，如果 Google 依然不收錄，有可能是 Canonical 標籤把權重轉移到了其他頁面。

例如目前存取的頁面是：

https://example.com/product?color=red

但頁面 HTML 中設定了：

HTML

<link rel="canonical" href="https://example.com/product" /> 

這並不是抓取失敗，而是你主動告訴 Google：「目前頁面只是一個帶參數的變體，請把 https://example.com/product 作為唯一規範版本進行索引。」

可以藉助 Canonical 與 hreflang 檢測工具 一鍵提取目前 URL 宣告的規範位址。排查時重點確認以下幾點：

• Canonical 連結是否指向了錯誤的 URL 或不帶斜線的舊版本；

• 是否存在 HTTP 與 HTTPS 混用導致的規範化衝突；

• 頁面是否存在互相指向的邏輯死循環（例如 A 頁面 Canonical 指向 B，B 又指向 A）。

Canonical 屬於規範化建議而非強制命令。Google 會綜合考慮頁面內容重複度、Sitemap 提交路徑、站內跳轉等多重訊號。如果 Google 最終選擇的規範 URL 與你宣告的不一致，可以在 GSC 中檢視系統的具體判定理由。

七、第五步：排查伺服器存取限制與 JS 動態渲染

如果前面所有的設定檔看起來都毫無問題，但頁面依然無法被抓取，問題通常隱藏在伺服器網路層或前端渲染機制中。

1. 防火牆與 WAF 誤封

許多站點使用的 Bot 管理軟體（如 Cloudflare 的 Challenge 模式或高防策略）在過濾惡意流量時，容易將真正的搜尋引擎爬蟲誤判。排查時建議核對 CDN/WAF 攔截日誌，或者透過反向 DNS 查詢（Reverse DNS）確認存取請求是否來自於官方 Googlebot IP 段。

2. 頁面強制登入或地區 IP 封鎖

對部分設定了「登入後可見」或指定國家/地區 IP 才能存取的站點，Googlebot 從美國 IP 存取時可能直接被重新導向到登入頁或傳回 403/404。如果不希望這些頁面放棄公開搜尋引擎流量，必須調整針對爬蟲的鑑權策略。

3. JavaScript 用戶端渲染（CSR）問題

現代前端框架（React、Vue、Angular）廣泛採用用戶端渲染。Google 雖具備解析 JavaScript 的能力，但這屬於二次渲染（Rendering）過程，極其消耗資源。

如果 API 回應較慢、關鍵 API 被 robots.txt 攔截，或者前端程式碼報錯，Google 抓到的初始 HTML 可能只是一個 <div id="app"></div> 空殼，導致頁面被判定為無有效內容的空白頁。

排查建議： 使用 GSC 的「測試實際網址」功能，重點查看 Rendered HTML（渲染後的 DOM 結構） 與 截圖，確認爬蟲是否能夠順暢取得並渲染出頁面主體正文。對於強依賴 JS 的網站，優先推薦採用伺服器端渲染（SSR）或預渲染方案。

八、第六步：檢查 Sitemap 與站內連結入口

Sitemap 和站內內鏈解決的是搜尋引擎「發現 URL」的問題。如果一個新頁面剛剛發布，沒有在任何既有頁面中放置 <a href="..."> 入口，Sitemap 裡也沒有包含這個 URL，它就會變成一個孤立頁（Orphan Page）。即便這個頁面本身 100% 可抓取，Google 也可能根本不知道它的存在。

排查時可以使用 Sitemap 檢測工具 驗證地圖檔案的可用性，並確認：

• XML Sitemap 能否被正常下載且語法無誤；

• 新發布的頁面是否已即時更新至 Sitemap 中；

• 首頁、分類頁或相關文章列表中是否存在指向該新頁面的自然 HTML 連結（避免僅使用 JS onClick 跳轉，爬蟲無法追蹤此類路徑）。

同時需要明確一點：放入 Sitemap 不等於一定會被抓取或收錄。Sitemap 只是一個主動通知的索引指南，如果頁面本身存在 403、noindex 或重複內容問題，Sitemap 無法解決這些技術故障。

九、最終確認：使用 Google Search Console (GSC) 進行實測診斷

前面的步驟幫助我們快速排查了網頁公開的技術設定。在確認 HTTP 200、robots.txt Allowed 且無 noindex 後，最後一步就是回到 Google Search Console 中取得 Google 官方的實際診斷結論。

開啟 GSC，在頂部搜尋列輸入目標頁面的完整 URL，使用 「網址檢查（URL Inspection）」 工具。

重點查看以下核心指標：

1. 已發現 - 目前未建立索引： Google 知道了這個 URL，但還沒有排期安排抓取，通常發生在站點抓取預算有限或新站信任度較低時。

2. 已抓取 - 尚未建立索引： Google 已經成功下載並讀取了頁面，但經過品質評估後決定暫時不寫入索引庫（通常與內容品質、重複度或結構有關）。

3. 抓取失敗 / 拒絕存取： 系統會直接給出具體的 HTTP 錯誤碼、robots.txt 攔截規則或 DNS 故障說明。

如果頁面剛剛完成修復，可以直接點擊 「測試實際網址」，即時向源站發起一次測試請求。確認無誤後點擊 「請求建立索引」，將 URL 重新推入抓取佇列。

排查 Google 收錄故障時，最忌諱把「爬蟲進不來」與「進來後不給收錄」混為一談。

實際工作中，建議把兩類工具結合使用：先透過 Chahu 快速做一次公開技術鏈路的診斷與排查，解決掉 HTTP 403、robots 攔截或 noindex 等基礎問題；然後再去 Google Search Console 查看索引回饋。按照這套標準流程逐步推進，絕大多數看起來很棘手的 Google SEO 收錄故障都能迎刃而解。

相關閱讀

1. Google Search Console 顯示「已抓取-尚未建立索引」，頁面內容明明很好，問題出在哪？

這個狀態最容易被誤解。GSC 顯示已抓取，說明 Googlebot 成功下載了頁面的 HTML 程式碼，問題出在後面的評估環節。常見原因有：頁面內容與站內其他頁面高度重複，Google 認為沒有必要重複索引；頁面主體內容太少，比如只有幾百字配一張圖，被判定為「內容稀薄」；或者頁面載入了大量廣告、彈窗，影響了核心內容的提取品質。還有一種情況是網站整體權威性不足，Google 對新站的抓取和索引本身就比較保守。排查時可以先用 site: 限定 URL 看看有沒有被索引，如果確實沒有，重點檢查內容獨特性，適當擴充正文，確保頁面的核心資訊在 HTML 原始碼中直接可見，不要依賴 JS 二次載入。

2. 網站換了伺服器 IP，之後 Google 一直不抓新內容，跟 DNS 解析有關係嗎？

有關係。換 IP 後 DNS 解析需要全球生效，Googlebot 從不同地區的機房發起抓取時，可能有的節點拿到了新 IP，有的還是舊快取。如果舊伺服器已經關停，部分 Googlebot 節點就會拿到連線逾時或拒絕存取的回應，導致抓取失敗率飆升。這種情況會在 GSC 的「抓取統計」裡看到明顯的 5xx 錯誤增多。排查方法是用 dig 或 nslookup 指令從多個位置查詢域名的 A 記錄，確認解析是否已全球同步。如果持續 48 小時仍有異常，適當調低 DNS 的 TTL 值能加速快取重新整理。

3. Hreflang 多語言頁面，Google 抓取時總是抓錯語言版本，問題可能在哪？

hreflang 本身不會影響抓取，但會影響 Google 選擇哪個版本展示給哪個地區的使用者。如果 Google 抓到的頁面總是錯誤的語言版本，問題通常出在內容協商機制上。很多網站根據請求頭的 Accept-Language 做 302 臨時跳轉，但 Googlebot 發起的請求往往不帶語言偏好，直接被丟到了預設語言版本。正確的做法是用 URL 區分不同語言版本（比如 /en/、/zh/ 目錄），而不是依賴請求頭做跳轉，同時配合 hreflang 標註各版本之間的關係。如果必須用同 URL 做內容協商，確保 Googlebot 的 User-Agent 也能拿到正確的語言版本，不要對爬蟲做特殊跳轉邏輯。

4. Google 抓取時頁面的圖片、CSS、JS 檔案傳回 404，會影響頁面索引嗎？

會影響，但影響程度取決於這些資源的重要性。如果 CSS 和 JS 載入失敗，Google 的渲染器無法完整建構頁面佈局和樣式，可能會把頁面判定為排版混亂或功能殘缺。圖片 404 相對輕微一些，但如果頁面核心內容是以圖片形式呈現的（比如文字全部寫在圖片裡），而圖片又打不開，那頁面就會被判定為空內容。建議定期用 GSC 的「核心網路指標」和「網頁測試」工具檢查頁面資源的載入情況，確保所有被 HTML 引用的靜態資源 URL 都是可存取的，且 robots.txt 沒有誤攔截這些資源路徑。