robots.txt 介紹：是什麼、對 SEO 有何效果
robots.txt 是網站對搜尋引擎爬蟲發布的路權聲明書，只管「能不能被爬」、不管「能不能被索引」。解析檔案位置、指令寫法、避免誤擋重要頁面，以及擋 GPTBot 等 AI 爬蟲的做法。
作者：褚崇名（Sliven）
本頁目錄
- robots.txt 是什麼？一句話講透
- 一個比喻：網站大門口的「管理員佈告欄」
- 這份檔案對 SEO 的影響，比你想像的大
- 「封鎖」不等於「隱形」，這個觀念最常被誤解
- Googlebot 讀到你的 robots.txt 時，實際發生什麼
- HTTP 狀態碼決定一切
- 五個核心指令，看懂就能上手
- 規則衝突時，Google 怎麼決定聽誰的
- 五種網站的 robots.txt 寫法範例
- 範本一：內容部落格（WordPress）
- 範本二：電商網站
- 範本三：開發中或測試環境
- 範本四：放行 Google 但擋特定爬蟲
- 範本五：多語系網站的注意事項
- 最常見的致命錯誤
- 網站搬家與改版時，robots.txt 怎麼處理
- robots.txt 與 noindex 的關鍵差別
- AI 搜尋時代的新抉擇：要不要放行 GPTBot？
- Google-Extended 與 GPTBot 的兩難
- robots.txt 與其他技術 SEO 設定的協同關係
- 三個免費工具幫你驗證 robots.txt
- 驗證時要特別留意的三個陷阱
- 動手前的行動清單
你是否遇過這種狀況：網站改版三個月，重要頁面卻始終不出現在 Google 搜尋結果，但你明明寫了好內容、也提交了 Sitemap。你懷疑主機、懷疑速度、懷疑演算法，卻沒想到元兇可能是一份你從沒開過的文字檔。robots.txt。這個檔案是網站根目錄裡的一個純文字檔，體積通常不到 1 KB，卻能決定 Google 的爬蟲能不能走進你的網站大門。
三分鐘重點：robots.txt 是放在網站根目錄的純文字檔，用來告訴搜尋引擎爬蟲「哪些路徑可以爬、哪些不要爬」。它不是拿來移除已收錄頁面的工具，而是控制「爬蟲的進入權與抓取範圍」。寫對了，能保護爬取預算、加速索引；寫錯了，可能把整個網站封鎖在 Google 之外。在 AI 搜尋時代，它還多了一個新任務：決定 GPTBot、Google-Extended 這類 AI 爬蟲能不能讀取你的內容。
接下來會把 robots.txt 的原理、語法、實戰寫法、常見錯誤，以及 2026 年最熱門的「要不要擋 AI 爬蟲」抉擇一次講清楚。你讀完，應該能自己寫出一份安全又有效率的 robots.txt，不必再把命運交給主機預設值。
robots.txt 是什麼？一句話講透
robots.txt 是一份放在網站根目錄的純文字檔，網址固定是 https://你的網域/robots.txt。它的角色，是網站對外發布的「爬蟲通行規則」。任何守規矩的搜尋引擎爬蟲（Googlebot、Bingbot 都是），在開始抓取你的網站之前，會先來讀這份檔案，看看哪些路徑允許進入、哪些被列為禁止區域（見 Google 搜尋中心的 robots.txt 簡介，2025 年 9 月）。
換句話說，robots.txt 做的事很單純：它是「建議」，不是「圍牆」。Google 在文件裡講得很明白，robots.txt 是一套協定（protocol），Google 會盡力遵守，但惡意爬蟲、不守規矩的程式照樣會無視它。所以如果你用它來擋後台登入頁，那是對君子有效、對小人無效，真正的敏感資料必須靠帳號密碼與伺服器層級的驗證來保護。
一個比喻：網站大門口的「管理員佈告欄」
把你的網站想像成一棟開放大樓，Googlebot 是來拜訪的訪客。robots.txt 就是掛在大門口的佈告欄，上面寫著：「一樓大廳、二樓展間歡迎參觀；三樓倉庫、四樓機房請勿進入。」訪客看到佈告欄，會客氣地照辦。但這只是禮貌性的引導，並沒有實體門鎖。真正能鎖門的，是後端的權限控管。換個角度想，這份檔案也是你跟搜尋引擎之間的一份默契：你負責把規則寫清楚、講明白，對方負責盡量遵守。雙方各司其職，網站的爬取與收錄才能跑得順暢。
這個比喻很關鍵，因為它同時點出 robots.txt 的能力邊界：它能引導爬蟲走對路，但無法強制任何人。一旦你誤以為它是鎖，把「不希望被排名的頁面」全塞進 Disallow，你就踩進了 SEO 最經典的陷阱之一。這部分後面會專門拆開來講。
這份檔案對 SEO 的影響，比你想像的大
很多人以為 robots.txt 只是個「技術設定」，交給工程師處理就好。這個想法很危險。這份檔案直接影響三件事，每一件都跟你的自然流量有關。一個寫錯的規則，可以讓你花三個月經營的內容完全消失在搜尋結果；一個寫對的規則，可以讓你的網站在同等內容下被收錄得更完整、更迅速。它的影響力往往無聲無息，等你察覺時，要嘛流量已經歸零，要嘛對手已經超前。
第一，能不能被爬。如果 robots.txt 把某個路徑封鎖，Googlebot 就不會去抓那個路徑下的頁面。頁面不被爬，就不會被收錄進索引，自然也不會出現在搜尋結果（見 Google 搜尋中心的搜尋運作說明，2025 年 9 月）。你寫得再好的文章，只要被 Disallow 擋住，等於從未存在。
第二，被爬得多有效率。Google 對每個網站都有一個「爬取預算」（crawl budget），也就是它在一定時間內願意花多少資源來抓你的頁面。如果你的網站有大量低價值頁面（篩選參數網址、搜尋結果頁、分頁迴圈），Google 會把寶貴的爬取額度浪費在這些頁面上，反而重要的內容排不到。透過 robots.txt 封鎖這些低價值路徑，能把爬取預算集中到真正該被收錄的頁面。這是大型網站（頁面數破萬的電商、內容站）一定要做的功課，想深入理解可以參考這篇爬取預算優化指南。
第三，被誰爬。2026 年的 robots.txt 不只面對傳統搜尋引擎，還面對一大群 AI 爬蟲：OpenAI 的 GPTBot、Google 的 Google-Extended、各家訓練資料採集器。要不要放行牠們，直接影響你的內容會不會成為 AI 模型的訓練材料，也影響你會不會在 AI 搜尋結果裡被引用。這是一個全新的策略決策，傳統 SEO 教學幾乎沒碰過。
「封鎖」不等於「隱形」，這個觀念最常被誤解
很多站長把 robots.txt 的 Disallow 想成「隱形斗篷」，以為加了封鎖，頁面就會從世界上消失。這個誤解會帶來兩種代價。第一種代價是前面提過的：已經被收錄的頁面不會因為被封鎖就自動移除，反而會以你看不到的方式繼續存在於索引。第二種代價更隱晦：如果你封鎖了一個頁面，卻同時有大量外部網站連向它，Google 可能會根據外部連結的錨點文字，給這個頁面一個「它自己都無法控制」的排名與描述，因為 Google 讀不到頁面內容來校正這個推測。
換句話說，robots.txt 的 Disallow 是「請爬蟲別來看」，不是「讓這個頁面不存在」。真正想讓頁面從索引消失，正確的工具是 noindex；想讓頁面連外部都看不到，正確的工具是刪除頁面加上 410 狀態碼。把這三件事的層次分清楚，你的技術 SEO 才會精準。
這個觀念之所以重要，是因為它牽動你對整份 robots.txt 的設計哲學。一份好的 robots.txt，封鎖的應該是「本來就不該被收錄、且還沒被收錄」的東西（後台、篩選參數、搜尋結果頁），拿來補救「已經被收錄但你不想要」的頁面只會適得其反。前者是預防，後者要用別的工具。
Googlebot 讀到你的 robots.txt 時，實際發生什麼
要真正懂 robots.txt，你必須知道爬蟲讀檔的順序，以及檔案不存在或出錯時會怎麼反應。它直接決定你的網站會不會被意外封鎖，重要性遠超過一般人以為的冷知識。
Googlebot 的標準流程是：拜訪一個網域時，先抓 /robots.txt，再依規則決定接下來能抓哪些網址。它會把抓到的檔案快取一段時間（通常約 24 小時），所以你改了 robots.txt 之後，不會立刻生效，需要等 Google 重新抓取（見 Google 的 robots.txt 建立說明，2025 年 9 月）。
HTTP 狀態碼決定一切
這裡有一個很多人看漏的細節：當 Googlebot 來抓 /robots.txt 時，伺服器回傳的狀態碼，會被 Google 解讀成完全不同的意思。三種情況整理成下表。
| HTTP 狀態碼 | Google 的解讀 | 實際後果 |
|---|---|---|
| 200（成功） | 檔案存在，依照內容規則爬取 | 正常運作，你寫的規則生效 |
| 404（找不到） | 沒有規則＝完全開放 | Google 假設「沒有任何限制」，整站都會被爬 |
| 5xx（伺服器錯誤） | 暫時抓不到，視為「全站暫時封鎖」 | Google 會停止抓取整個網站，直到能正常讀到檔案為止 |
看出問題了嗎？如果你因為改版，把 robots.txt 弄成回傳 500 錯誤，Google 會把整個網站當成「暫時禁止進入」，所有頁面都不會被抓。這比寫錯規則還慘，因為你根本不知道自己被擋了。技術 SEO 健檢的第一步通常是打開瀏覽器手動訪問 https://你的網域/robots.txt，確認它回傳 200、而且內容是預期的。這個動作只要 5 秒，卻能抓出最致命的問題。
五個核心指令，看懂就能上手
robots.txt 的語法其實很簡單，整份檔案由幾組「規則群組」組成，每個群組針對特定的爬蟲（user-agent）設定允許或禁止的路徑。你只需要認識五個關鍵字。
| 指令 | 作用 | 範例 |
|---|---|---|
| User-agent | 指定這組規則要套用給哪個爬蟲；* 代表全部 | User-agent: Googlebot |
| Disallow | 禁止爬蟲抓取指定路徑 | Disallow: /wp-admin/ |
| Allow | 明確允許某個被 Disallow 涵蓋的子路徑 | Allow: /wp-admin/admin-ajax.php |
| Sitemap | 宣告你的 XML Sitemap 網址，方便爬蟲找到 | Sitemap: https://example.com/sitemap.xml |
| Crawl-delay | 要求爬蟲每次抓取間隔幾秒（Google 已不支援） | Crawl-delay: 10 |
這裡有幾個重點要記住。第一，Disallow: 後面留空，代表「允許全部」，等於沒設限；而 Disallow: / 代表「禁止整站」。這兩者差一個斜線，結果天差地遠。第二，Google 支援的路徑比對規則包含 *（任意字串）和 $（行尾結束）兩個萬用字元，讓你能精準地封鎖像是 /*?sort= 這類帶排序參數的網址（見 Google 的 robots.txt 規格，2025 年 9 月）。
第三，Crawl-delay 這個指令雖然寫進檔案不會報錯，但 Google 已經不再理會它，Google 會用自己的演算法決定爬取節奏。所以如果你寫 Crawl-delay: 30 想放慢 Google 來減輕主機負擔，實際上是沒有效果的，別白費力氣。
規則衝突時，Google 怎麼決定聽誰的
當檔案裡同時存在多組規則，Google 的處理邏輯有一套明確的優先順序，不是「從上到下遇到第一條就停」。這套邏輯如果你搞錯，會寫出看似嚴謹、實際上漏洞百出的檔案。
Google 會先選出與爬蟲名稱最具體相符的 user-agent 群組；若有多個同樣具體的群組，會合併其中規則，而 User-agent: * 的通用群組不會與專屬群組合併（依 robots.txt 規格）。接著再比較相符規則的路徑長度，通常由較具體、較長的路徑優先；若 allow 與 disallow 同樣具體，Google 會採用限制較少的規則。
舉個具體例子，假設你的檔案長這樣：
User-agent: *
Disallow: /private/
User-agent: Googlebot
Disallow: /private/
Allow: /private/public-report.pdf
對 Googlebot 來說，* 和 Googlebot 兩組雖然都匹配，但 Google 只套用具體指名 Googlebot 的那一組；在這組裡，/private/public-report.pdf 這條 Allow 規則的路徑長度（26 個字元）比 Disallow: /private/（9 個字元）更長，所以最終 Googlebot 可以抓取這份 PDF。附帶一提，正因為通用群組不會被併入計算，範例裡的 Googlebot 那組才需要重複寫一次 Disallow: /private/；只寫在 * 那組的封鎖，對有專屬群組的爬蟲不生效。這就是 Allow 用來「在禁止區域裡開一個例外通道」的典型手法，也是 WordPress 範本裡為什麼要特意保留 admin-ajax.php 的原因。
這個機制很實用，但也容易讓人掉以輕心，尤其當檔案裡同時存在通用群組與專屬群組時，實際生效的規則可能跟你直覺相反。實務上的習慣是：寫完之後，用網址檢查工具或第三方測試器逐一驗證關鍵網址，不要用肉眼猜。
五種網站的 robots.txt 寫法範例
光講語法太抽象。下面直接整理出五種最常見網站的範本，你可以對照自己的情況調整。每種範本背後都有明確的「為什麼這樣寫」。
範本一：內容部落格（WordPress）
WordPress 是目前全球市佔率最高的內容管理系統，根據 W3Techs 的統計（2026 年 6 月），WordPress 在所有使用已知 CMS 的網站中佔有壓倒性的比重。它的後台目錄不該被索引，但某些 AJAX 處理程式需要被爬到才能正常渲染。
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /*/feed/$
Disallow: /*/feed/rss/$
Disallow: /trackback/
Disallow: /?s=
Disallow: /search/
Sitemap: https://example.com/sitemap_index.xml
這個範本的邏輯是：封鎖後台與登入頁、封鎖 RSS feed 與 trackback（這些會製造大量重複內容）、封鎖站內搜尋結果頁（/?s= 與 /search/，這些頁面對 SEO 沒有價值卻會吃掉爬取預算），同時保留 admin-ajax.php 讓前端功能正常運作。最後一行用 Sitemap 指令主動告知 XML Sitemap 的位置，讓爬蟲不必自己摸索。如果你還不太熟悉 XML Sitemap 的運作，可以參考這篇XML Sitemap 完整介紹。
範本二：電商網站
電商網站是爬取預算最容易出問題的類型，因為它會自動產生大量篩選、排序、分頁網址，動輒把一個 500 頁的商品目錄膨脹成好幾萬個變體網址。你需要封鎖這些變體，把爬蟲精力集中在真正的商品頁。
User-agent: *
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*?page=
Disallow: /cart
Disallow: /checkout
Disallow: /account
Disallow: /search?q=
Sitemap: https://shop.example.com/sitemap.xml
範本三：開發中或測試環境
如果你的網站有測試站（staging），你通常會希望整站不被 Google 收錄，避免測試內容汙染正式站的索引。這時可以用 Disallow: / 封鎖整站。但要特別注意，只有在你確定這個網域不要任何搜尋流量時才能這樣寫，千萬別把這行寫進正式站的 robots.txt。
User-agent: *
Disallow: /
範本四：放行 Google 但擋特定爬蟲
有時你想對大部分爬蟲關門，但對 Google 開放。你可以這樣寫，先放行 Googlebot，再封鎖其他所有爬蟲。Google 會從所有匹配的群組中挑選最具體的那組 user-agent 規則套用，書寫順序不影響結果。
User-agent: Googlebot
Disallow:
User-agent: *
Disallow: /
範本五：多語系網站的注意事項
如果你的網站同時服務台灣、香港、中國等多個市場，透過子目錄（例如 /zh-tw/、/zh-hk/）或子網域分隔語系，robots.txt 的設計要多一層考量。多語系網站通常會搭配 hreflang 標籤，告訴 Google 每個語言版本之間的對應關係。這時你絕對不能封鎖任何一個語言版本的目錄，否則 Google 讀不到 hreflang 訊號，就無法正確地把對的版本送給對的市場使用者。多語系的完整設定觀念，可以參考這篇多語系 SEO 與 hreflang 指南。
實務上，多語系網站的 robots.txt 通常只需要封鎖共通的後台與系統路徑，語系目錄本身保持完全開放。真正該花心力的地方，是確保每個語言版本都能被正常爬取、收錄，並透過 hreflang 正確互相指向。robots.txt 在這裡的角色是「不要妨礙」，把舞臺留給 hreflang 與內容本身。
最常見的致命錯誤
robots.txt 是那種「寫對沒人感謝你、寫錯大家找你算帳」的檔案。實務上最常見的災難有下面幾種，希望你別重蹈覆轍。
第一種，也是最經典的：把 Disallow: / 留在正式站上線後的 robots.txt 裡。這通常發生在開發階段，工程師為了不讓測試站被收錄，寫了 Disallow: /，網站正式上線時忘了拿掉。結果整站被 Google 完全封鎖，搜尋流量歸零。這個錯誤出現的頻率高得嚇人，而且當事人往往要等好幾週才會發現「怎麼都沒流量」。排查的第一步永遠是打開 /robots.txt 看內容。
第二種，用 robots.txt 來移除已經被收錄的頁面。這是觀念上的根本錯誤。假設你有一篇過時的促銷頁面，已經被 Google 收錄了，你想讓它從搜尋結果消失。於是你在 robots.txt 加了 Disallow: /old-promo。結果是：Google 不再爬那個頁面，但它仍然保留在索引裡，因為它從沒收到「請移除」的訊號。更糟的是，因為你禁止爬蟲讀取，Google 看不到頁面內容，反而可能用別人引用你的外部連結文字來推測內容，讓這個過時頁面繼續以錯誤的面貌出現在搜尋結果。正確做法是用 noindex，這部分可以參考這篇robots.txt 與 noindex 為什麼不能同時用，務必看懂。
第三種，封鎖了 CSS 與 JavaScript 檔案。早期有人為了節省爬取資源，把 /wp-includes/ 或 /*.css、/*.js 整個 Disallow。這在現代是自殺行為，因為 Google 採取 mobile-first 索引，它需要渲染頁面才能正確理解內容與體驗，而渲染需要讀取 CSS 與 JS（見 Google 的 Mobile-first 公告，2023 年 10 月）。擋掉這些資源，Google 看到的會是一個殘缺、跑不出來的頁面，等於自己把排名分數往下壓。行動流量已是全球網路流量的主力（Statista 的行動流量統計，2026 年 4 月），行動版本的完整呈現絕對不能被你的 robots.txt 破壞。
第四種，大小寫與斜線搞混。robots.txt 的路徑比對是大小寫敏感的，/WP-Admin/ 和 /wp-admin/ 是兩條不同的路徑。如果你封鎖了 /WP-Admin/，但實際後台路徑是小寫，這條規則等於沒生效。這類低級錯誤在主機搬家或網址重整後特別容易冒出來。
第五種，把 robots.txt 當成內部連結管理的替代品。有人以為封鎖某個頁面，Google 就不會把它的內部連結權重算進去，於是拿它來做精細的連結權重調度。這是誤解。robots.txt 控制的是「要不要爬」，不是「要不要傳遞權重」。真正想管理內部連結的流向，應該從網站架構與內部連結策略下手，門口貼告示牌這件事根本幫不上忙。
網站搬家與改版時，robots.txt 怎麼處理
這是一個實務上極度重要、卻很少有教學認真對待的情境。網站搬家或大改版，是 SEO 流量最容易斷崖式下滑的時刻，而 robots.txt 往往是風暴中心之一。如果你曾經歷過那種改版後流量腰斬的惡夢，就會明白箇中風險；完整的搬家防災觀念，整理在這篇SEO 網站搬家與改版指南，這裡只聚焦 robots.txt 的部分。
搬家分兩種情況，處理方式完全相反。第一種是換主機、換 CMS、但網域不變。這種情況下，robots.txt 應該原封不動從舊站搬到新站，規則、路徑、Sitemap 網址都保持一致。最常見的災難是新站用了 CMS 預設的 robots.txt（很多預設值會封鎖整站或重要目錄），而你沒注意到，導致上線後流量歸零。實務上的鐵律是：新站上線前，逐字比對舊站與新站的 robots.txt，任何差異都要有明確理由。
第二種是換網域，例如從 old.com 搬到 new.com。這時舊網域的 robots.txt 絕對不能封鎖任何東西，因為你需要 Google 持續爬取舊網域，才能正確處理你設定的 301 重導向，把舊網址的權重轉移到新網址。如果在舊網域加了 Disallow: /，Google 看不到 301 的目標，權重轉移就會中斷，等於親手把多年累積的 SEO 資產歸零。這個錯誤看似離譜，卻真實發生過，原因通常是有人急著「把舊站關掉」卻沒想清楚順序。
一個更微妙的點：搬家期間，新舊兩個網域的 robots.txt 會同時存在於 Google 的快取裡。你需要耐心等待重新抓取，並透過 GSC 主動提交新網域的 Sitemap，加速 Google 認識新的結構（見 Google 的 Sitemap 說明，2025 年 9 月）。這段過渡期可能持續數週，期間流量會波動，這是正常的，但前提是你沒有在 robots.txt 上犯下前面說的那些致命錯誤。
robots.txt 與 noindex 的關鍵差別
這個主題值得單獨拉出來講，因為它是 SEO 初學者最容易混淆的觀念，也是最容易造成反效果的誤用。以下用一個對照表把兩者的本質差異講清楚。
| 比較項目 | robots.txt | noindex |
|---|---|---|
| 作用階段 | 爬取階段（爬蟲要不要抓） | 索引階段（抓到了要不要收錄） |
| 典型位置 | 根目錄的純文字檔 | 頁面 HTML 的 meta tag 或 HTTP header |
| 能移除已收錄頁面嗎 | 不能，反而會讓頁面留在索引 | 能，明確告訴 Google 不要收錄 |
| 適合封鎖整個目錄嗎 | 適合（例如後台、搜尋結果頁） | 適合單一頁面或可逐一標記的範圍 |
| 兩者混用的後果 | 如果同時用 robots.txt 封鎖又想靠 noindex 移除，noindex 會失效，因為爬蟲根本進不去讀到 noindex 標籤 | |
這個表格最後一行是最關鍵的：兩者混用會互相打架。你想用 noindex 讓某頁面從索引消失，卻又同時在 robots.txt 封鎖那個頁面，Googlebot 進不去就讀不到 noindex，頁面反而繼續留在索引裡。正確的做法是：要移除已收錄頁面，就移除 robots.txt 的封鎖、改用 noindex；要從一開始就不讓某目錄被爬，就用 robots.txt。想更深入了解 noindex 本身的運作，可以讀這篇noindex 完整介紹。
AI 搜尋時代的新抉擇：要不要放行 GPTBot？
這是 2026 年最值得花腦筋思考的 robots.txt 議題，也是大多數傳統教學完全沒覆蓋的盲區。自從大型語言模型崛起，一群全新的爬蟲出現在網路上，牠們的目的不是建立搜尋索引，而是收集訓練資料與建構即時檢索庫。OpenAI 的 GPTBot 就是其中最具代表性的一個，它會抓取公開網頁用來訓練與改進模型（依 OpenAI 的說明文件，2025 年 9 月）。
這帶來一個兩難：放行，你的內容會被吸收進 AI 模型，但換來的是 AI 搜尋結果裡有機會引用你、帶來品牌曝光；封鎖，你保住了內容不被免費搬走，但也等於主動退出 AI 搜尋的版圖。這不是一個有標準答案的問題，而是取決於你的商業模式與內容策略。
Google-Extended 與 GPTBot 的兩難
Google 自己也推出了 Google-Extended 這個獨立的 user-agent，讓站長可以單獨決定「要不要讓內容被用於 Google 的 AI 產品（例如 AI Overviews 的模型訓練）」，而不影響傳統的搜尋索引（見 Google-Extended 的官方說明，2025 年 9 月）。這個設計很聰明：它把「被搜尋」和「被 AI 訓練」拆成兩個開關，你可以選擇讓 Google 正常索引你的網站，同時不授權內容用於 AI 模型訓練。
要把這件事想清楚，你需要先認識目前最活躍的幾個 AI 爬蟲 user-agent。以下整理成一張對照表，幫你快速掌握每個的來歷與用途。
| AI 爬蟲 user-agent | 背後的服務 | 抓取內容的用途 |
|---|---|---|
| GPTBot | OpenAI（ChatGPT） | 模型訓練與檢索增強 |
| Google-Extended | Google（Gemini、AI Overviews） | AI 模型訓練，獨立於搜尋索引 |
| CCBot | Common Crawl（開放資料集） | 公開網頁快照，被多家模型間接使用 |
| PerplexityBot | Perplexity | AI 搜尋的即時檢索與引用 |
| Claude-User / anthropic-ai | Anthropic（Claude） | 模型訓練與回覆時的內容擷取 |
這張表透露出一個關鍵事實：不同的 AI 爬蟲，目的不盡相同。有的是純訓練資料採集（Common Crawl），有的是即時搜尋引用（PerplexityBot），有的兩者皆有（GPTBot）。所以「要不要擋 AI 爬蟲」這個問題，其實應該拆解成「擋哪一個、為了什麼理由擋」。
下面用一個簡單的決策框架幫你釐清。第一個問題：你的內容變現模式是什麼？如果你靠廣告、聯盟行銷、品牌曝光獲利，內容被 AI 引用等於多一個免費曝光管道，傾向放行。如果你靠付費內容、會員訂閱、獨家研究獲利，被免費搬走等於稀釋你的商品價值，傾向封鎖。第二個問題：你的品牌在 AI 搜尋結果裡的能見度重要嗎？如果重要，你至少要放行那些會在回覆裡「引用來源」的爬蟲（例如 PerplexityBot），因為這類引用會帶來真實的點擊與品牌觸及。
這個決策跟你整體的 AI 搜尋策略緊緊綁在一起。如果你正在思考「你的內容到底要不要、以及如何被 AI 引用」，建議把視野拉大到整個 AI 搜尋優化的版圖，這篇AI Overviews 與 SEO能給你更完整的脈絡。robots.txt 的 AI 爬蟲設定，只是這盤棋裡的一步。
如果你決定封鎖主要的 AI 爬蟲，常見寫法是這樣，列出你想擋的 user-agent：
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
反過來，如果你想放行，就什麼都不寫，或者明確標示 Allow: /。實務上的建議是：如果你的網站靠內容變現、靠品牌曝光獲客，傾向放行，因為在 AI 搜尋時代，被 AI 引用本身就是新的流量入口，封鎖等於自動棄賽；如果你的內容是付費產品、會員專屬、或具有高商業機密價值，傾向封鎖。這個決策跟整體的 AI 搜尋策略綁在一起，如果你還在摸索 AI 時代的 SEO 方向，可以先讀這篇llms.txt 介紹，它探討的是另一種 AI 時代的實驗性文件，跟 robots.txt 互為對照。
robots.txt 與其他技術 SEO 設定的協同關係
很多人把 robots.txt 當成獨立存在的小檔案，事實上它跟一整套技術 SEO 設定是互相牽動的。搞懂這層協同關係，你才不會在做某一項設定時，不小心把另一項搞壞。以下用幾個常見的搭配情境說明。
第一個搭配是robots.txt 與 canonical 標籤。canonical 的作用是告訴 Google「這幾個網址其實是同一份內容，請以這個為標準版本」。但如果其中某些重複網址被 robots.txt 封鎖了，Google 讀不到 canonical 訊號，合併就會失敗。原則很簡單：需要傳遞 canonical 訊號的頁面，不能被 robots.txt 擋住。想理解 canonical 的完整機制，可以讀這篇Canonical 標籤指南，重複內容的處理觀念也整理在這篇重複內容指南。
第二個搭配是robots.txt 與結構化資料。如果你在商品頁埋了 Schema 標記，卻又把那個頁面的某些資源封鎖，Google 在驗證結構化資料時可能讀不到完整資訊，導致豐富結果（rich result）失效。結構化資料是搶佔搜尋結果版面的利器，別讓一個 robots.txt 規則把它的效果抵銷。完整的觀念可以參考這篇結構化資料介紹。
第三個搭配是robots.txt 與 JavaScript 渲染。現代網站大量使用 JavaScript 來動態產生內容，Google 需要先抓取並執行 JS 才能看懂你的頁面。如果你的 robots.txt 封鎖了 JS 檔案，Google 就只能看到一個空殼，排名自然上不去。這是前面「封鎖 CSS 與 JS」那個錯誤的延伸，想深入了解爬蟲如何處理 JS，這篇JavaScript SEO 介紹講得很清楚。
說到底，robots.txt 是技術 SEO 這台機器裡的一個齒輪。它跟 canonical、結構化資料、JS 渲染、網站架構全部咬合在一起。單獨看它沒有意義，要把它放回整個系統裡檢視，才知道哪裡該封鎖、哪裡千萬不能碰。
三個免費工具幫你驗證 robots.txt
寫完 robots.txt 不代表工作結束，你需要驗證它是否如預期運作。這裡有三個免費工具，是技術 SEO 健檢時最常用的組合。
第一個，直接用瀏覽器打開 /robots.txt。這是最快的檢查方式。在網址列輸入你的網域加上 /robots.txt，按下 Enter，看看回傳的是不是一份純文字、內容正確的檔案。如果看到 404、500、或一堆 HTML 錯誤頁，問題就出在伺服器層，先修這個。這個動作看起來幼稚，卻能過濾掉八成以上的低級災難，健檢通常都從這裡開始。
第二個，Google Search Console 的 robots.txt 報表。登入 GSC（如果你還沒安裝，先看這篇Google Search Console 介紹），在「設定」裡可以找到 robots.txt 報表，它會列出 Google 為你的網站找到的 robots.txt、最後一次抓取的版本、抓取狀態、檔案大小與解析問題，也能回看近 30 天的歷史版本。要注意的是，Google 已在 2023 年底移除舊版的 robots.txt 測試工具，這份報表只能「看」，不能模擬規則；想確認某個網址有沒有被擋，可以改用網址檢查工具看單一網址的檢索狀態，開發者也可以用 Google 開源的 robots.txt 解析庫在本機驗證規則（見 GSC 的 robots.txt 報表說明，2026 年 8 月）。
第三個，爬蟲模擬工具（例如 Screaming Frog）。它能在本地跑一個模擬爬取，把你的整站跑一遍，並標示出哪些網址被 robots.txt 封鎖、哪些被 noindex 標記。這對大型網站特別有用，因為人工檢查幾萬個網址不現實，你需要工具一次性把問題攤開來。Screaming Frog 的完整用法，可以參考這篇Screaming Frog 中文教學。技術 SEO 的全貌遠不止 robots.txt，建議把它放進更大的技術性 SEO 指南框架裡一起檢視。
驗證時要特別留意的三個陷阱
這些工具都以 Google 為主要對象；GPTBot、ClaudeBot 等 AI 爬蟲沒有共用的官方測試器。若要確認封鎖或放行是否生效，可從伺服器日誌驗證 AI 爬蟲的後續請求。
工具會給你結果，但判讀結果需要經驗。以下列出三個驗證時最容易誤判的情況，幫你少走冤枉路。
第一，robots.txt 的快取延遲。你剛改完檔案，立刻去 GSC 的 robots.txt 報表看，可能還是舊版本，因為 Google 抓取的是快取版本。如果你看到結果跟預期不符，先確認是不是還在快取有效期內。耐心等 Google 重新抓取（快取通常約 24 小時），必要時在報表裡請求重新抓取，往往就能解決。
第二，驗證時的 user-agent 對象。Googlebot 有一般 Googlebot、Googlebot-Image、Googlebot-News 等變種，AI 爬蟲又是另一批 user-agent，各自套用的規則可能不同；用爬蟲模擬工具或第三方測試器驗證時，如果你只測了預設值，可能漏掉特定爬蟲被封鎖的情況。建議針對你最在意的爬蟲類型逐一測過。
第三，把「允許抓取」誤當成「保證收錄」。robots.txt 測試通過，只代表 Google「可以」爬這個頁面，不代表它「一定會」收錄。收錄與否還取決於內容品質、搜尋意圖匹配、網站整體權重等數十個因素。如果你測試發現頁面沒被封鎖卻一直沒被收錄，問題通常出在別的地方，要往索引層面去查，可以先看這篇GSC 網頁索引報表的理解方式。
動手前的行動清單
讀到這裡，你應該已經具備寫出一份安全有效 robots.txt 的知識。但知識要變成行動才有價值。下面給你一份六步驟的檢查清單，照著走，今天就能把風險降到最低。
- 立刻打開你的
/robots.txt。在瀏覽器輸入你的網域加上/robots.txt，確認它回傳 200、內容合理。如果看到Disallow: /而你的網站正在追求流量，這就是紅色警報。 - 盤點被 Disallow 的路徑。逐條檢視每一條 Disallow 規則，問自己：「這條路徑真的不該被收錄嗎？」特別留意有沒有不小心封鎖到重要分類頁、商品頁、或 CSS／JS 資源。
- 加上 Sitemap 指令。在檔案最後加上
Sitemap: https://你的網域/sitemap.xml，主動告知你的網站地圖位置。如果你想完整了解 Sitemap 與爬取的關係，這篇網站 Sitemap 入門指南是很好的起點。 - 決定你的 AI 爬蟲策略。想清楚要不要放行 GPTBot、Google-Extended，把決定寫進 robots.txt。這不是工程問題，是商業策略問題。
- 用 GSC 驗證。改完之後，先到 Google Search Console 的 robots.txt 報表確認 Google 已抓到新版本，再用網址檢查工具或爬蟲模擬工具驗證幾個關鍵網址，確認規則如你預期生效。別等流量掉了才回頭查。
- 建立定期複檢的習慣。robots.txt 不是寫一次就永遠正確。每次網站改版、加新功能、換主機、或新增大量頁面類型時，都要回頭檢查這份檔案是否還符合現況。建議把它列進每次技術健檢的固定清單，不依賴記憶。
robots.txt 看起來是技術細節，本質卻是「你如何對搜尋引擎與 AI 爬蟲介紹你的網站」這件事的起點。一份寫得清楚的 robots.txt，等於在大門口掛上一塊清楚、禮貌、有原則的告示牌，讓每一個來拜訪的爬蟲都知道該往哪走、哪裡別碰。這種基礎功做紮實了，後面所有 SEO 與 GEO 的努力才不會被一個低級錯誤抵銷。
實務上還有另一種極端：有人因為害怕寫錯，乾脆什麼都不寫，讓網站完全沒有 robots.txt。這在小型網站上勉強可以接受，因為 Google 會把 404 當成「完全開放」，網站規模小、爬取預算不是瓶頸時影響有限。但一旦你的網站長大，開始出現篩選參數、分頁、搜尋結果頁這類低價值網址，缺乏 robots.txt 等於放任爬蟲把寶貴的爬取額度浪費在垃圾頁面上。不寫本身就把控制權交給別人，談不上真正的中性選擇。
迴避解決不了問題。花十分鐘把這份檔案寫對，才是真正該做的事。你的網站打算長期經營下去的話，這份不到 1 KB 的檔案，值得你今天撥出時間，認真把它看懂、改對。SEO 從來不靠一個大招翻盤，靠的是無數個像這樣的基礎功，一點一滴堆疊出長期的自然流量。現在，輪到你動手了。