robots.txt 怎麼檢測？網站抓取規則與 SEO 配置檢查方法

網站頁面明明可以正常開啟，也沒有明顯的程式錯誤，但 Google Search Console 裡卻一直顯示抓取異常，甚至直接提示「被 robots.txt 封鎖」。這種問題在網站改版、CMS 更換、測試環境上線之後並不少見。

robots.txt 看起來只是一份很簡單的文字檔，真正出問題時影響卻不小。一條範圍寫得過大的 Disallow，可能把整個產品目錄、部落格文章甚至全站都擋在搜尋引擎之外；反過來，有些站長明明寫了禁止規則，卻發現 Google 還是看得到 URL，又會誤以為 robots.txt 沒有生效。

所以，檢查 robots.txt 不能只開啟檔案看一眼。更重要的是確認：規則有沒有寫錯、目標頁面到底能不能被 Googlebot 抓取，以及頁面不收录究竟是不是 robots.txt 導致的。下面就從實際檢測開始，把 robots.txt 的檢查方法、常見配置問題和 SEO 排查思路講清楚。

一、robots.txt 是什麼？主要控制什麼？

robots.txt 是放在網站主機根目錄下的一份爬蟲存取規則檔案，常見位址是：

https://example.com/robots.txt

搜尋引擎爬蟲存取網站時，可以讀取這份檔案，了解哪些路徑允許抓取，哪些路徑不希望被抓取。

一份簡單的 robots.txt 可能是這樣：

User-agent: *
Disallow: /admin/
Allow: /public/
Sitemap: https://example.com/sitemap.xml

其中幾個常見欄位分別表示：

例如：

User-agent: *
Disallow: /admin/

表示這組規則面向所有遵守 robots.txt 的爬蟲，並告訴它們不要抓取 /admin/ 目錄。

這裡有一個很容易混淆的概念：

robots.txt 控制的是「抓取」，不是「存取權限」。

即使你在 robots.txt 中寫了：

Disallow: /admin/

使用者依然可以直接在瀏覽器裡存取這個位址，只要伺服器本身沒有設定登入驗證或其他權限限制。

所以後台管理、會員資料、訂單資訊等真正敏感的內容，不能依靠 robots.txt 保護。

二、robots.txt 配置錯誤為什麼會影響 SEO？

robots.txt 本身不會決定一個頁面排名高低，但如果搜尋引擎連頁面內容都無法正常抓取，後面的渲染、內容理解和索引自然會受到影響。

實際網站中最常見的幾個問題主要集中在以下幾種情況。

1. 不小心把整個網站禁止抓取

最典型的配置就是：

User-agent: *
Disallow: /

這裡的 / 代表整個網站路徑。

測試環境為了防止搜尋引擎提前抓取，經常會臨時使用這種配置。問題在於，網站正式上線後如果忘了刪除，就可能導致 Googlebot 無法正常抓取全站。

這種情況尤其容易發生在：

• 測試站遷移到正式網域；

• WordPress 改版；

• 更換 CMS；

• 網站整站複製；

• 開發環境配置直接帶到生產環境。

所以網站上線後，robots.txt 最好列入固定檢查項。

2. 誤封產品頁或文章目錄

例如：

User-agent: *
Disallow: /blog/

如果 /blog/ 正好是網站主要的 SEO 內容目錄，那麼所有文章頁面都有可能受到抓取限制。

電商網站也經常出現類似問題：

Disallow: /product/

原本可能只是想封鎖某些動態參數頁面，最後卻把整個產品目錄一起擋住。

3. CSS、JavaScript 等重要資源被誤封

早年間有些站長習慣性地把靜態目錄封掉：

User-agent: *
Disallow: /assets/
Disallow: /static/

現在的 Googlebot 可不是只讀純文字的年代了，它是帶著渲染引擎來抓網頁的。如果這些目錄裡放著頁面排版必需的 CSS 和控制互動的 JS 檔案，爬蟲就拿不到完整的渲染效果。在它眼裡你的頁面可能就是一片亂碼或錯版，直接影響頁面體驗評分和收錄。

4. Sitemap 位址配置錯誤

直接在檔案末尾宣告 Sitemap 確實是個好習慣：

Sitemap: https://example.com/sitemap.xml

但麻煩的是，後面網站換了網域、強制啟用了 HTTPS，或者 Sitemap 檔案名稱改成了 sitemap_index.xml，這裡卻沒有跟著改。搜尋引擎沿著無效位址走過去只拿到 404，不僅浪費抓取資源，也失去了一次讓爬蟲高效發現新頁面的機會。既然要寫，就得確保它是能正常回傳 200 狀態碼的絕對路徑。

三、robots.txt 怎麼檢測？

想靠肉眼去逐行看 robots.txt，如果只有三五行還好說，一旦規則堆到幾十行，帶各種萬用字元和複雜的 Allow/Disallow 交錯，光盯著檔案看很容易漏掉細節。特別是要確認某一條具體產品頁或者文章頁到底能不能被爬，人工比對非常費眼。

最省事也最準確的辦法，就是用 Chahu 的robots.txt 檢測工具進行檢測，就能直接幫你模擬爬蟲的比對過程：

1. 填入主站網域

直接輸入網域（比如 https://example.com）即可。工具會自動去請求根目錄下的 robots.txt，不用自己再去手動拼接 URL 位址。

2. 傳入具體的排查路徑

這是最關鍵的一步。假設你發現某款商品 https://example.com/products/item-a 在 Search Console 裡一直報錯，或者某篇新發的部落格 /blog/seo-guide 遲遲不抓取，就把斜線後面的具體路徑貼上來進行測試。

做這一步的價值在於，我們排查問題時，核心目的是弄明白「這個特定頁面到底能不能被搜尋引擎讀取」，而不是機械地去背規則檔案裡寫了什麼。

3. 對照輸出結果定位問題

送出後直接看測試結論，重點關注三個指標：

• 檔案連通性： robots.txt 本身能不能正常載入回傳 200，還是回應逾時了；

• 規則解析明細： 工具辨識出的 Allow、Disallow 以及 Sitemap 宣告是否齊全；

• 路徑比對結論： 針對 Googlebot 這類主流爬蟲，你剛剛輸入的路徑最終判定是允許（Allowed）還是禁止（Blocked）。

一旦檢測出核心業務頁面被標記為禁止存取，直接拿著工具測出的那條衝突規則，去伺服器根目錄的檔案裡針對性修改就可以了。

四、robots.txt 檢測結果應該怎麼看？

跑完檢測拿到結果後，很多人容易把不同回傳狀態的邏輯搞混。把工具吐出來的檢測報告看懂，關鍵是要分清下面這 5 種常見情況：

1. 順利讀取並正常解析

看到狀態正常別急著慶祝，這只能說明 robots.txt 這個檔案確實掛在根目錄下，而且語法沒有大面積崩潰。 檔案能開啟只是第一步，緊接著要逐項排查細節：

• 是不是失手寫了 Disallow: / 把全站給封了；

• 核心的業務目錄（比如商品頁、部落格欄目）有沒有被帶進去；

• Sitemap 宣告的連結位址能不能通；

• 抓取重點頁面時到底給沒給通行權限。

2. 直接報 404（找不到檔案）

很多新手看到 robots.txt 回傳 404 就大驚失色，其實完全沒必要。robots.txt 並不是網站的剛需配置。如果你對網站抓取沒有任何限制需求，就算不放這個檔案，搜尋引擎也會預設全站都可以自由抓取。 要記住：robots.txt 報 404 和你網站網頁報錯 404 是兩碼事，只要伺服器回應正常，它本身並不會導致站點降權。

3. 請求逾時或彈 5xx 伺服器錯誤

如果在檢測時發現一直載入逾時，或者抓出來的是 500、502、503 這種錯誤碼，問題一般不在規則檔案本身，而是伺服器或 CDN 節點出狀況了。 這種情況其實挺危險的，因為 Googlebot 遇到 robots.txt 回傳 5xx 時，出於保護源站的目的，通常會選擇暫時停止對你全站的抓取。看到這種報錯，第一反應應該是去查源站服務和 CDN 配置，確保請求能正常回應。

4. 結果顯示「允許抓取（Allowed）」

比如測試 /blog/seo-guide，工具回饋 Googlebot 可以正常存取，這只能說明你的 robots.txt 這一關過去了。 但這絕對不等於這個頁面就一定能被 Google 收錄。「能抓取」和「給索引」是兩碼事。如果頁面依然不進索引，就得繼續沿著鏈條往後查：程式碼裡刷沒刷 noindex？canonical 標籤指沒指錯？頁面是不是回傳了 301/404？或者是內容品質太差被過濾了？

5. 結果顯示「禁止抓取（Blocked）」

如果檢測直接彈了 Blocked，通常意味著你輸入的路徑正好踩中了某條 Disallow 規則。 比如檔案裡寫著 Disallow: /blog/，那 /blog/seo-guide 必然被拒之門外。如果這個目錄剛好是你用來做 SEO 拿流量的核心板塊，那沒啥好說的，趕緊把這條規則從檔案裡刪掉或重新限定作用域。

五、Allow 和 Disallow 同時存在時怎麼看？

robots.txt 稍微複雜一點之後，經常會同時出現 Allow 和 Disallow。

例如：

User-agent: Googlebot
Disallow: /products/
Allow: /products/public/

第一眼看過去，整個 /products/ 都被禁止了，但下面又單獨放行了：

/products/public/

因此：

/products/public/item-a

可能仍然能夠被 Googlebot 抓取。

實際判斷規則時，不能簡單認為「只要出現 Disallow 就一定禁止」，還需要看哪個規則與目標路徑比對得更加具體。

比如：

Disallow: /products/
Allow: /products/public/

對於：

/products/public/a.html

/products/public/ 顯然比 /products/ 比對得更具體，因此 Allow 規則會發揮作用。

這也是為什麼檢查 robots.txt 時，測試真實 URL 往往比單純肉眼閱讀規則更可靠。

網站規則一旦有幾十條，靠人工逐條比對很容易看漏。

六、robots.txt 最常見的 SEO 配置錯誤

1. 測試環境規則沒有刪除

還是這條：

User-agent: *
Disallow: /

它可能是最簡單，同時也是影響範圍最大的錯誤。

網站正式上線或者遷移網域後，第一時間檢查 robots.txt 很有必要。

2. 誤封 SEO 核心目錄

例如：

Disallow: /blog/
Disallow: /products/
Disallow: /category/

這些目錄如果本來就承載大量搜尋流量，貿然禁止抓取顯然不合適。

真正需要封鎖的通常是後台、搜尋結果頁、某些參數組合或者沒有搜尋價值的重複頁面，而不是看到目錄多就全部禁止。

3. 把 robots.txt 當成 noindex 使用

這是做 SEO 時非常常見的誤區。

例如不想讓某個頁面出現在 Google：

Disallow: /private-page/

不少人會認為這樣就能徹底阻止頁面被收錄。

實際上 robots.txt 的核心作用是阻止抓取，而不是專門控制索引。

如果 Google 透過外部連結或者其他頁面知道這個 URL，即使無法抓取內容，URL 仍有可能出現在搜尋結果中。

如果真正的目的就是「不希望頁面進入索引」，一般應該考慮頁面級 noindex：

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

而且要注意，如果 robots.txt 同時把頁面完全禁止抓取，Googlebot 反而可能讀不到頁面裡的 noindex 指令。

所以：

Disallow 和 noindex 解決的是兩個不同的問題。

4. Sitemap 只寫相對路徑

例如：

Sitemap: /sitemap.xml

更推薦寫成完整位址：

Sitemap: https://example.com/sitemap.xml

同時檢查 Sitemap 本身是不是回傳 200，裡面的 URL 是否仍然有效。

5. 用 robots.txt 保護敏感後台

例如：

Disallow: /admin/
Disallow: /customer-data/

這只能告訴守規則的搜尋引擎「不要抓」。

它無法真正阻止別人存取。

而且 robots.txt 是公開檔案，反而會讓別人知道網站存在這些路徑。

真正涉及敏感資料的頁面，應該依靠登入認證、權限管理、IP 限制等方式保護。

七、robots.txt 正常，為什麼 Google 還是不抓取？

這個問題實際比 robots.txt 寫錯更常見。

如果檢測結果已經確認目標頁面允許 Googlebot 抓取，但 Search Console 裡仍然沒有正常索引，就應該把排查範圍往其他方向擴展。

檢查 HTTP 狀態碼

頁面首先應該能夠正常回傳：

200

如果回傳的是：

301
302
404
500

就需要分別檢查重新導向、頁面不存在或者伺服器錯誤。

檢查 Meta Robots

查看頁面 HTML 中有沒有：

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

如果存在 noindex，那麼 robots.txt 即使完全允許抓取，頁面仍然可能不會進入正常索引。

檢查 X-Robots-Tag

有些網站不會在 HTML 裡設定 noindex，而是透過 HTTP Header 回傳：

X-Robots-Tag: noindex

排查時這一項也不能漏掉。

檢查 Canonical

例如目前頁面是：

https://example.com/product-a

但 Canonical 卻指向：

https://example.com/product-b

Google 就可能把另一個 URL 當成規範頁面。

檢查 Sitemap 和站內連結

重要頁面最好能夠出現在 Sitemap 中，並且從網站導覽、分類頁或其他相關內容中獲得正常的內部連結。

如果一個頁面幾乎沒有任何入口，即使 robots.txt 沒有限制，搜尋引擎發現和抓取它的速度也可能比較慢。

所以當頁面不收录時，排查思路應該是：

robots.txt
   ↓
HTTP狀態碼
   ↓
noindex
   ↓
Canonical
   ↓
Sitemap
   ↓
內部連結與頁面品質

而不是看到沒有收錄，就一直修改 robots.txt。

robots.txt 檢查真正需要確認的，並不是網站有沒有這份檔案，而是 搜尋引擎面對某一個具體頁面時，到底會不會被抓取規則擋住。日常排查時，可以先透過 Chahu 的 robots.txt 檢測功能讀取網站目前規則，再輸入產品頁、文章頁或其他重要 URL 的路徑進行測試。

如果發現頁面確實被 Disallow 誤封，就回到 robots.txt 調整規則；如果結果顯示允許抓取，但 Google 仍然沒有正常收錄，就不要繼續反覆修改 robots.txt，而應該檢查 HTTP 狀態碼、noindex、Canonical 和 Sitemap。把「能不能抓取」和「能不能進入索引」分開來看，很多看似複雜的 SEO 抓取問題其實會清楚很多。

常見問題

Q1: 網站改版後頁面打得開，但 Google Search Console 提示「被 robots.txt 封鎖」該怎麼排查？

A: 這種情況絕大多數是因為測試環境的程式碼直接覆蓋到了正式站。你可以先用工具輸入具體的 URL 路徑測試。重點看看是否有 Disallow: / 這種全站封禁指令，或者是否有像 /blog/、/product/ 這樣包含了你核心頁面的目錄規則。如果檢測工具顯示該 URL 確實被擋住了，去根目錄修改 robots.txt 刪掉對應的 Disallow 行即可。

Q2: 網站如果沒有 robots.txt 檔案，會影響 Google 排名嗎？

A: 完全不會。如果你的網站回傳 404（找不到 robots.txt），Google 會預設「該網站沒有任何抓取限制」，然後正常爬取你的全站頁面。只有當你的伺服器配置錯誤導致 robots.txt 回傳 5xx 伺服器報錯時，Googlebot 為了安全起見才會暫停抓取整個網站。

Q3: 哪些檔案或目錄是絕對不能在 robots.txt 裡禁止抓取的？

A: 千萬不要封鎖渲染頁面所必需的 CSS、JavaScript 檔案以及圖片資源目錄（比如 /assets/ 或 /wp-content/）。現代 Google 爬蟲是以「渲染模式」來解析網頁的，如果它拿不到樣式表和腳本，就會把你的頁面辨識為錯版或內容缺失，直接打低行動端體驗分，嚴重影響排名。

Q4: 我可以直接用 robots.txt 來隱藏後台管理位址或敏感資料嗎？

A: 絕對不行！robots.txt 是一個公開檔案，任何人只要在你的網域後面加上 /robots.txt 都能看到裡面的內容。如果你把 /admin_secret_login/ 寫入 Disallow，反而是在給駭客和惡意爬蟲「指路」。真正的敏感目錄和後台，必須透過伺服器帳號密碼鑑權、防火牆或 IP 白名單來保護。

Q5: 每次修改完 robots.txt 之後，Google 需要多久才能更新規則？

A: 通常 Googlebot 在幾小時到幾天內會重新讀取一次網站的 robots.txt。如果你剛修改了規則並急著讓 Google 生效，可以在 Google Search Console 的「抓取工具」或頁面檢查工具裡請求重新抓取，強制更新 Google 快取的規則。