robots.txt 是什麼？設定、指令與安全邊界完整說明
robots.txt 不只是讓爬蟲知道哪些頁面不要抓，它的核心在於區分「節省爬取預算」與「從索引移除」兩種需求。這篇從檔案位置、指令全解析、常見範本到安全邊界，帶你一步步正確設定。
robots.txt 是什麼：定義、位置與檔案特性
robots.txt 是一份放在網站根目錄的純文字檔，用來告訴搜尋引擎爬蟲哪些路徑可以檢索、哪些應該跳過。它遵循 Robots Exclusion Protocol，所有的規則都只是建議：合作的爬蟲會遵守，不合作的爬蟲可以直接無視。整份檔案必須是 UTF-8 編碼的純文字檔，檔名嚴格區分大小寫，寫成 robots.txt 才算有效，大小寫錯誤、加上副檔名或放在子目錄都會讓爬蟲完全找不到這份檔案。
檔案的位置是最常被忽略的細節。爬蟲在進入網站時，只會向根目錄請求 /robots.txt，因此放在 /wp-admin/robots.txt 或 /blog/ 底下都不會被讀取。同樣的原理也適用在檔名：Robots.txt、ROBOTS.TXT 甚至是 robot.txt 都會讓規則失效，因為大多數的伺服器對靜態檔案的路徑比對是區分大小寫的。編碼則是另一個容易被誤傳的細節。Google 的規格要求 robots.txt 必須是 UTF-8 編碼的純文字檔，並且明確說明它會忽略檔案開頭的 Unicode BOM，不會因為一個 BOM 就整份跳過。真正的風險在於存檔時用了非 UTF-8 的編碼：Google 會直接略過無法解析的無效行、只採用剩下讀得懂的部分，於是你以為已經生效的那幾行 Disallow，其實從頭到尾沒有生效過。
在繼續往下之前，有一個概念必須先建立：robots.txt 只是「偏好清單」，不是防火牆。即使你把後台路徑寫進 Disallow，任何不遵守協議的機器人仍然可以照爬不誤。這個特性同時也是 robots.txt 最大的優點跟最大的限制：它讓搜尋引擎能在不浪費頻寬的前提下快速認識網站結構，卻無法當成安全控制使用（我們會在後面的安全邊界段落詳細討論）。理解這層合作本質，對於後續的指令設計與除錯會很有幫助。
robots.txt 與 meta robots 的差異：節省爬取預算 vs 從索引排除
robots.txt 和 meta robots 處理的是兩個完全不同的目標：robots.txt 控制爬蟲「要不要來訪」以及「來訪時可以看哪些路徑」，目的是節省爬取預算；meta robots 則是在爬蟲已經來訪、讀取頁面之後，才告訴它「這一頁要不要放進索引」。如果你把兩者混用，最常見的後果就是：明明想讓某個頁面從搜尋結果消失，卻只在 robots.txt 裡把它 Disallow，結果 Google 沒有讀到頁面上的 noindex 標籤，導致那個頁面以「沒有描述的裸網址」形式繼續留在索引裡。
這個分工的關鍵在於「爬蟲能不能看到頁面內容」。一旦 Disallow 生效，爬蟲會直接跳過該頁，完全不會解析 HTML，自然也就不會發現 <meta name="robots" content="noindex">。因此，meta robots noindex 只對「robots.txt 允許造訪」的頁面有效。想真正從搜尋結果移除某個網址，必須讓爬蟲能成功抓取，再透過 noindex 指令處理。反之，如果你只是不希望爬蟲花費資源在某些低價值頁面（例如內部搜尋結果、階段性活動頁）上，同時頁面本身就沒打算出現在搜尋結果，那一行 Disallow 就足夠了，不需要額外的 noindex。
| 目的 | 作用層級 | 是否可被爬蟲讀取後套用 noindex | 典型適用情境 |
|---|---|---|---|
| 節省爬取預算 | 路徑／目錄 | 否（爬蟲被擋即略過） | 大量重複頁面、內部搜尋結果、階段性活動 |
| 從索引排除 | 單一頁面 | 是（需允許爬蟲讀取該頁） | 特定需要隱藏的頁面（如會員專屬、感謝頁） |
| 同時節省預算並排除索引 | 先允許後 noindex | 可（先 Allow 該路徑，再於頁面放 noindex） | 需要完全移除且避免浪費預算的頁面 |
表格整理出三種決策情境：第一列是單純的預算管理，第二列是單純的索引控制，第三列則是需要兩者兼顧的進階做法。實務上最常踩到的地雷，就是誤用第一列的做法去解決第二列的問題，也就是只 Disallow，卻期待頁面從 SERP 消失。成功機率極低，因為 Google 還是可以透過外部連結或 sitemap 建立該網址的索引條目。
節省爬取預算的場景：低品質目錄、重複內容、測試站
當網站規模大到爬蟲無法在單次造訪中處理所有頁面時，每一分預算就變得珍貴。這時用 robots.txt 一次 Disallow 整個目錄（例如 /staging/、/archive/2024/、/filter/）可以讓爬蟲跳過數千個不需要入庫的頁面，把資源集中在真正重要的分類頁、產品頁和作者頁上。但要注意，Disallow 目錄時必須確認該目錄底下沒有放著被其他頁面依賴的 CSS 或 JavaScript 檔案，否則可能間接破壞重要頁面的 rendering 品質。
從索引排除的場景：要到搜尋結果隱藏的特定頁面
如果目標是讓某個特定的網址從搜尋結果消失（例如用戶個人資料頁、結帳完成後的感謝頁），就必須讓爬蟲讀得到該頁的 HTML，再從 HTML 裡下 noindex。實作上可以在 robots.txt 裡保持 Allow 該路徑，然後在 <head> 加入 <meta name="robots" content="noindex">。這麼做的好處是爬蟲仍然不會把爬取預算浪費在該頁（因為它只來一次讀取 noindex 就離開了），又能在下一次更新索引時順利將該頁清除。如果你需要進一步理解 noindex 的運作，可以參考我們對爬蟲與索引整體機制的說明。
robots.txt 指令全解析：User-agent、Disallow、Allow、Sitemap、Crawl-delay
robots.txt 真正的控制力來自五個核心指令，每一個都解決不同層級的問題。User-agent 指定這串規則要對哪一個爬蟲生效；Disallow 告訴爬蟲不要抓取哪些路徑；Allow 則反過來，在一個大範圍 Disallow 的區塊裡開一道例外門；Sitemap 是友善地提供網站地圖的完整網址；Crawl-delay 則設定連續請求之間至少間隔幾秒。五個指令組合起來，可以讓爬蟲同時完成多種任務，但組合時有兩個優先序規則一定要遵守：最特定的 User-agent 群組會優先被採用，以及在同一個群組內，路徑長度越長的規則越優先。
核心指令：User-agent、Disallow、Allow
User-agent 開頭的那一行，重要性不亞於 Disallow 本身。用 User-agent: * 代表規則對所有爬蟲生效，但如果你需要對 Googlebot 和 Bingbot 分別設定不同規則，就必須為每一個爬蟲建立獨立區塊。當同一個路徑在不同區塊被反覆定義時，爬蟲只會取用自己對應的那個區塊；如果找不到專屬區塊，才會回頭套用星號區塊。Disallow 的路徑必須以 / 開頭、相對於網站根目錄來寫，例如 Disallow: /admin/ 會擋掉 /admin/ 這個目錄底下的所有網址；寫成 Disallow: https://example.com/admin/ 這種絕對網址則不符合規格。至於少了結尾斜線的 Disallow: /admin，它不是失效，而是範圍變大：Google 採前綴比對，這一行會連 /admin-tools、/administrator 一起擋掉，問題是擋過頭而不是沒擋到。Allow 則是在 Disallow 範圍內切出例外，例如你 Disallow 了整個 /products/ 目錄，但希望 Google 還是可以抓取 /products/bestsellers/，就可以補上一行 Allow: /products/bestsellers/，因為路徑長度較長，Allow 的優先序會高過 Disallow。
理解這個規則最直接的用途，就是處理大型網站裡的「隱藏重要資源」問題。有些團隊為了省事，會直接 Disallow 一整個子網域或目錄，卻沒注意到底下藏了被其他頁面引用的圖檔或腳本。一旦 Google 無法抓取這些資源，就可能影響 rendering 品質，進而讓內文內容無法完整入庫。要留意的是，順序本身並不影響判定。Google 是依路徑長度決定優先序，不是依行的先後，長度相同時才採較寬鬆的那一條。把大範圍的 Disallow 寫在前、小範圍的 Allow 緊接在後，純粹是為了可讀性，也讓日後改動時比較不會漏掉例外。
延伸指令：Sitemap 與 Crawl-delay
Sitemap 指令的用法非常單純：一行一個完整的 sitemap.xml 網址，放在哪個 User-agent 區塊都可以，甚至可以直接放在檔案最尾端，與任何區塊平行。Google 會讀取這些連結並將其納入已知的 sitemap 清單，但前提是你沒有不小心把同一個 URL 寫進 Disallow 裡，那會讓爬蟲無法讀取 sitemap 本身。Crawl-delay 則是針對非 Googlebot 的爬蟲（如 Bingbot、Yandex）提供一種節流機制，值代表兩次請求之間的秒數間隔。請注意 Googlebot 不支援 Crawl-delay，Google 的規格文件直接把它列在不支援的欄位裡。而 Search Console 過去那個「檢索頻率限制」工具，也已經在 2024 年 1 月 8 日移除，現在沒有任何介面可以手動調降 Googlebot 的速度。如果真的需要在短時間內緊急降速，Google 給的做法是對檢索要求回傳 500、503 或 429 狀態碼；若是長期的爬取量過大，該處理的是哪一種網站結構（例如分面導覽）在量產無意義網址。關於支援與不支援的欄位清單，Google 的 robots.txt 規格文件寫得很完整。
| 指令 | 語法 | 作用 | 優先序規則 | 備註 |
|---|---|---|---|---|
| User-agent | User-agent: Googlebot | 指定此區塊適用的爬蟲 | 最特定匹配優先 | 可用 * 代表全部 |
| Disallow | Disallow: /private/ | 禁止抓取指定路徑 | 與 Allow 衝突時，路徑長度優先 | 須使用相對路徑 |
| Allow | Allow: /private/public/ | 在 Disallow 範圍內例外開放 | 路徑長度越長越優先；長度相同時採較寬鬆者 | 與 Disallow 的先後順序不影響判定 |
| Sitemap | Sitemap: https://example.com/sitemap.xml | 提供 Sitemap 完整網址 | 無優先序問題 | 一行一個完整網址 |
| Crawl-delay | Crawl-delay: 10 | 設定連續請求的最少間隔秒數 | 僅對宣告之 User-agent 生效 | Googlebot 不支援 |
常見 robots.txt 場景範本：全站開放、屏蔽目錄、屏蔽搜尋結果、多爬蟲分流
大多數的 robots.txt 需求都落在以下四種場景裡，你可以根據自己的網站規模直接調整參數。全站開放的寫法最簡單，只需要兩行 User-agent: * 和 Disallow:（空白），表示所有爬蟲都可以自由抓取。第二種場景是屏蔽特定後台目錄，例如 Disallow: /wp-admin/ 和 Disallow: /administrator/，目的是避免在日誌中出現大量無意義的後台請求，並節省爬取預算。第三種是屏蔽內部搜尋結果頁，通常用 Disallow: /search 或搭配查詢參數的 Disallow: /?s=，但必須一併檢查網站的分頁與排序參數，否則容易只擋到一半。第四種是多爬蟲分流，為 Googlebot、Bingbot 等不同爬蟲開獨立區塊，各自指向不同的 Allow/Disallow 規則。
使用範本時最容易忽略的失敗模式，就是只 Disallow 了主目錄，卻忘記排除該目錄底下額外的動態路徑。舉例來說，Disallow: /wp-admin/ 後台目錄雖然擋掉了，但 /wp-admin/admin-ajax.php 這類 WordPress 需要的 AJAX 端點，若剛好被其他前端頁面引用，就可能造成功能異常。另一個常見狀況是屏蔽搜尋結果頁時，只處理了乾淨的 /search，卻漏掉 /search?q=keyword&page=2 這類帶參數的版本，爬蟲仍然可以從外部連結或 sitemap 發現並浪費預算。因此每個範本都應該在套用後，立刻用 Search Console 的網址檢查工具挑幾個關鍵網址逐一驗證，確認沒有擋到不該擋的資源。
| 場景 | Disallow 範例 | 目的 | 常見失敗模式 |
|---|---|---|---|
| 全站開放 | Disallow: | 允許所有爬蟲自由抓取 | 忘記寫 Disallow: 空白行，導致語法錯誤 |
| 屏蔽後台 | Disallow: /wp-admin/；Disallow: /administrator/ | 節省預算、避免後台請求 | 未排除 AJAX 端點導致前端功能異常 |
| 屏蔽內部搜尋結果 | Disallow: /search；Disallow: /*?s= | 防止搜尋結果頁浪費預算 | 漏掉帶參數版本或分頁連結 |
| 多爬蟲分流 | Googlebot 區塊: Disallow: /beta/；Bingbot 區塊: Allow: / | 針對不同搜尋引擎分配資源 | 未宣告特定 User-agent 導致規則混用 |
robots.txt 設定錯誤的後果與常見地雷
robots.txt 一旦寫錯，最輕的後果是浪費爬取預算，最重的後果是整站從搜尋結果消失。這些錯誤通常都發生在上線前沒有經過雙重驗證，或是團隊在修改規則時漏掉了對應的 Allow 例外。以下從兩個最常見的結果來整理地雷清單：一個是導致整站不被收錄的致命寫法，另一個是明明設了規則，頁面卻還是在搜尋結果裡出現的誤用。
導致整站不被收錄的寫法
最典型的錯誤，就是把 Disallow: / 當成「禁止根目錄」來寫，結果變成禁止所有路徑。只要一行 Disallow: /，Googlebot 就會完全跳過你的網站，連首頁都不會進來。另一個常見失誤是沒有在 Disallow 路徑結尾加上斜線：Disallow: /blog 不但會擋掉 /blog，也會擋掉 /blog-post、/blogging 等所有以 /blog 開頭的網址。在測試階段，開發團隊有時會用 Disallow: / 來防止預發環境的網站被索引，但正式上線時忘了移除，就會變成重大 SEO 災難。修正這類錯誤後，可以到 Search Console 的 robots.txt 報告確認 Google 實際抓到的是哪一份檔案，再從該檔案的選單送出重新檢索要求。
導致頁面仍出現在搜尋結果的誤用
第二種典型錯誤是用 robots.txt 取代 meta robots noindex，結果就是如前所述，頁面繼續以裸網址形式留在索引裡。還有一種狀況是 Disallow 寫法不完整：例如同時有 www 和非 www 版本，但你只在其中一個子網域放了 robots.txt，另一個完全沒有，導致爬蟲從另一個入口進入後仍然正常索引。解決方法不是把同樣的 robots.txt 複製到所有子網域，而是統一透過 301 重導向收斂網站版本，並在 GSC 中設定主要版本。更完整的修正流程，可以搭配我們在技術 SEO 健檢方法中提到的多版本檢查步驟。
robots.txt 的安全邊界：對善意爬蟲有效，無法防禦惡意機器人
robots.txt 對合群的爬蟲是一種合作訊號，對不合作的爬蟲則完全沒有任何阻擋能力。任何你寫進 Disallow 的敏感路徑（例如內部測試環境、開發中的 API、尚未公開的產品頁面），只有像 Googlebot、Bingbot 這類會主動宣告身份且遵循規範的爬蟲才會遵守；惡意機器人、競爭對手的爬取程式、或是 GPTBot 這類 AI 訓練爬蟲，除非它們自己選擇遵守，否則 robots.txt 對它們來說只是一份可以被忽略的檔案。
合作性搜尋引擎爬蟲之所以願意遵守 robots.txt，主要是出於規模經濟與信譽考量。Google 官方說明給這份檔案的定位很清楚：robots.txt 主要用來避免網站因要求過多而超載，而不是用來讓特定網頁不出現在搜尋結果。換句話說，它處理的是伺服器負載，不是能見度。如果爬蟲大量違反這個協議，網站管理者可以透過防火牆直接封鎖該爬蟲的 IP 範圍，因此對主流搜尋引擎來說，維持協議是雙贏。但這層合作關係只存在於「有身份、有信譽、有公開文件」的爬蟲身上，你不能預設所有進入你伺服器的請求都會這麼友善。
善意爬蟲會遵循的條件
善意爬蟲遵循 robots.txt 的必要條件包含三項：爬蟲具有公開可查的 User-agent 字串、該爬蟲的營運主體有正式的文件說明其遵循 Robots Exclusion Protocol、以及該爬蟲會定期讀取並快取你的 robots.txt。如果一個爬蟲沒有公開的身份（例如偽裝成一般瀏覽器的 UA）、不提供任何官方文件、或從不更新自己快取的 robots.txt，那就不能被歸類為善意爬蟲。實務上，你可以透過伺服器日誌交叉比對，檢查特定 User-agent 是否確實在 Disallow 生效後停止存取該路徑，這個行為本身就是最直接的遵循證明。
針對 GPTBot、CCBot 等 AI 訓練爬蟲，雖然它們通常會提供自己的 User-agent 並宣稱遵循 robots.txt，但這仍不足以構成安全保證。如果網站希望這類爬蟲完全不碰特定內容，除了在 robots.txt 中加入對應的 Disallow 規則，更根本的做法是從伺服器端設定 IP 過濾，或是在應用層加入 token 驗證。關於非合作性爬蟲，真正有效的控制點在伺服器層，不在 robots.txt。
| 條件 | robots.txt 適用 | robots.txt 不適用 |
|---|---|---|
| 爬蟲有公開 User-agent 並遵循協議 | ✅ 可透過 Disallow 管理 | |
| 爬蟲隱藏身份或偽裝瀏覽器 | ❌ 需依靠 WAF／IP 黑名單 | |
| 想隱藏未公開網址不被任何外部訪客發現 | ❌ 必須使用密碼保護或存取代碼 | |
| 想節省大型網站的爬取預算 | ✅ 直接 Disallow 低價值目錄 |
如何測試、上線與監控 robots.txt
一套完整的 robots.txt 流程必須包含測試、上線與持續監控三個階段，少了任何一個環節，都可能讓規則寫對卻沒生效、或是生效後擋到關鍵資源卻沒人發現。這裡要先更正一個已經過時的習慣：Search Console 舊版的 robots.txt Tester 已在 2023 年 11 月被 robots.txt 報告取代，原本的測試工具網址現在直接回 404，網路上大量教學仍在引用它。目前正確的分工是兩件工具各管一半：robots.txt 報告（位於 Search Console 的「設定」內）會列出 Google 為你網站前 20 個主機抓到的 robots.txt、最後一次檢索的時間，以及解析時遇到的警告與錯誤；至於某一個特定網址到底有沒有被擋住，要用網址檢查工具，看它的「是否允許檢索」欄位。最後，定期比對伺服器日誌和爬取統計，能讓你掌握搜尋引擎實際抓取的頁面範圍，以及爬取頻率是否如你所預期。
實務上，很多團隊會在上線前只做一次語法檢查，卻忽略了生效時間差。Google 的爬蟲會快取 robots.txt 的內容，一般最多 24 小時，在無法重新抓取的情況下還可能快取更久，所以新規則不會即時全面生效。因此在部署變更後，應該先到 robots.txt 報告送出重新檢索要求，並在隔天確認 Google 抓到的版本已經換成新的那一份。如果你是大型網站的管理者，建議將 robots.txt 的變更納入部署檢查清單，並在每次變更後至少持續監控一週，確保沒有出現搜尋流量突然大幅波動的情形。
robots.txt 與爬取預算管理
robots.txt 是爬取預算管理的第一道防線，但它不是唯一的工具。大型網站的爬取預算有限，Google 會根據網站的規模、更新頻率和頁面品質來動態分配；如果你把預算花在大量低品質或重複的頁面上，重要的產品頁或最新文章就可能延遲被發現。robots.txt 可以在爬蟲進入網站的第一步，就把這些不必要的路徑先過濾掉，讓爬蟲不必浪費時間在那些你根本不希望被搜尋的頁面上。
但是，只靠 robots.txt 過濾還不夠。某些歷史累積的重複內容，可能已經有外部連結指向它們，爬蟲還是會從那些入口點嘗試存取。這時就需要搭配 noindex 標籤來進行索引層面的清理，以及 canonical 標籤把連結訊號集中到主要頁面。robots.txt、noindex 和 canonical 三者各有分工：robots.txt 決定要不要抓、noindex 決定要不要收進索引、canonical 決定多個相似頁面當中哪一個才是主要版本。這三者的分工，正好就是爬取與索引兩個階段的分界線。
| 管理手段 | 作用階段 | 適用情境 | 限制 |
|---|---|---|---|
| robots.txt | 爬取前過濾 | 大量低價值目錄、內部搜尋結果、階段性活動頁 | 無法阻止外部連結引導的索引建立 |
| meta robots noindex | 爬取後索引階段 | 單一需要從搜尋結果隱藏的頁面 | 需先讓爬蟲能夠讀取該頁 |
| canonical | 索引過程訊號合併 | 重複或相似內容的頁面群 | 屬於提示訊號，非強制指令 |
在分配爬取預算時，一個好習慣是定期檢查 GSC 的「爬取統計資料」報表，觀察 Googlebot 每日的下載量與平均回應時間。如果某個目錄的每日下載量特別高，但那些頁面幾乎沒有流量或轉換，就可以考慮用 robots.txt 先將該目錄 Disallow，然後觀察一到兩週的流量變化，確認沒有誤擋到重要的網址後再正式納入長期規則。
FAQ: robots.txt 常見問題
robots.txt 放錯位置會發生什麼事？
爬蟲只會到網站的根目錄讀取 /robots.txt，放在任何子目錄底下都會被完全無視。如果你的網站是多子網域架構，每個子網域也需要自己的根目錄放置一份 robots.txt。
robots.txt 可以用來讓 Google 不要索引某個頁面嗎？
不行。Disallow 只是不讓爬蟲讀取內容，但 Google 仍可能透過外部連結或 Sitemap 知道這個網址，並將它收進索引。要從索引移除，必須使用 meta robots noindex，並確保 robots.txt 沒有擋到該頁。詳細機制可以回看本文「與 meta robots 的差異」段落。
robots.txt 與 meta robots 的差別是什麼？
robots.txt 控制爬蟲「要不要來」以及「能看哪些路徑」，主要用來管理爬取預算；meta robots 控制爬蟲讀取頁面後「要不要放進索引」。兩者互補但不能互相取代。必要的話，可以先用 robots.txt 允許抓取，再於頁面加上 meta robots noindex。
如何驗證我的 robots.txt 寫得對？
舊版的 robots.txt Tester 已經下線，不要再找它。現在用 Search Console「設定」裡的 robots.txt 報告確認 Google 抓到哪一份檔案、有沒有解析錯誤，再用網址檢查工具逐一驗證關鍵網址的「是否允許檢索」結果。
robots.txt 可以阻擋 AI 訓練爬蟲嗎？
可以對遵守協議的 AI 爬蟲（例如 GPTBot）發出 Disallow 要求，但無法強制執行。不合作的爬蟲可能會無視，因此敏感內容還是需要透過 IP 過濾或密碼保護來避免被存取。本文的安全邊界段落有進一步討論。
多久需要更新一次 robots.txt？
沒有固定的更新頻率，但每當你新增需要排除的目錄（例如新活動網站、新內部搜尋參數），或是發現爬取預算浪費在無意義的頁面上，就應該立刻更新。大型網站建議每季至少檢查一次，與其他技術 SEO 項目同步。
想先自己檢查：相關免費工具
先用這幾個工具把文章提到的項目對照一次，再回到你的網站情境閱讀結果。