robots.txt 介紹：什麼是 robots.txt？對於 SEO 有何效果？
robots.txt 是網站對爬蟲發布的路權聲明書，放在根目錄、檔名全小寫；它管的是搜尋引擎流程中最前端的「爬取（crawl）」階段，不是「索引（index）」階段。換句話說，它決…
robots.txt 是網站對爬蟲發布的路權聲明書，放在根目錄、檔名全小寫；它管的是搜尋引擎流程中最前端的「爬取（crawl）」階段，不是「索引（index）」階段。換句話說，它決定的是「能不能被爬」，不是「能不能出現在搜尋結果」，而 Google 官方文件明確區分了這兩件事 [來源：Google 搜尋中心《robots.txt 簡介》〈https://developers.google.com/search/docs/crawling-indexing/robots/intro〉2025-09]。真正決定它價值的，是有沒有擋錯重要頁面、有沒有把該交給 noindex 的事交給它做。
robots.txt 在搜尋流程裡的位置與約束力
把這份檔案放進整個搜尋流程來定位，它的角色其實很狹窄也很明確：擋在爬蟲還沒抓到內容之前的那一道閘門。搜尋引擎運作可拆成爬取（crawl）→ 索引（index）→ 排名（rank）三個連續階段，前一階段不通過，後面兩個階段就沒有素材可用 [來源：Google 搜尋中心《搜尋的運作方式》〈https://developers.google.com/search/docs/crawling-indexing/how-search-works〉2025-09]。這個「前置過濾器」的性質，決定了它的正確用法幾乎都是防守型的：確保該進來的爬蟲進得來、該被收錄的頁面沒有被誤擋。想理解整個搜尋流程，可以先看Google 搜尋引擎運作原理。
把「能爬」跟「能被索引」混為一談，是九成 robots.txt 災難的起點。爬蟲進得來，不代表這頁一定會被索引；爬蟲進不來，則幾乎保證沒辦法被索引。這條單向的因果關係，是整份檔案背後最關鍵的邏輯，搭配Retrieval 檢索在搜尋中的角色一起看會更清楚；判斷某頁是否已被收錄，則對照網頁被索引的判斷方式。
另一個常被誤解的性質是它的約束力：robots.txt 是君子協議，不是強制性的技術門鎖。主流搜尋引擎會尊重，Google 也把遵守規範寫進官方文件 [來源：Google 搜尋中心《robots.txt 簡介》〈https://developers.google.com/search/docs/crawling-indexing/robots/intro〉2025-09]，但約束力因爬蟲類型而異。Google、Bing、DuckDuckGo 這類主流搜尋引擎會嚴格遵守，因為遵守規範是她們對外建立信任的基礎；垃圾郵件收集器、內容採集機、以及部分不透明的 AI 訓練爬蟲，完全可以無視這份檔案。理解這層差異，才能避免把君子協議誤用成安全防護。真正要擋住惡意流量，要靠伺服器層級的頻率限制、WAF、IP 黑白名單，這些機制跟 robots.txt 屬於完全不同的技術層次。
檔案位置與查看方法
robots.txt 只能放在網站根目錄，也就是網域最淺的那一層，網址格式固定是 example.com/robots.txt。放到子目錄會完全失效，任何爬蟲都不會去讀取它。這是一條硬規則，沒有彈性。
查看方法直接得有點反直覺：任何網站只要在網域後面加上 /robots.txt 就能打開，包含對手的網站。例如可以直接看 Apple 官網的 robots.txt（截至 2026 年 6 月，內容可能隨時變動），或 momo 購物網、Yahoo 的這份檔案。這個公開性，恰恰是後面要談的「隱藏敏感頁面」地雷的根源。
檔名必須全小寫 robots.txt，大小寫混用（Robots.TXT）、副檔名錯誤（robots.html）都會讓它失效。這沒有什麼技術理由，就是協議規定，跟SEO 網址命名與結構建議裡強調一致性是同一個道理。
| 位置 | 網址 | 是否有效 |
|---|---|---|
| 根目錄 | example.com/robots.txt | 有效 |
| 子目錄 | example.com/category/robots.txt | 完全失效 |
| 子網域根目錄 | m.example.com/robots.txt | 有效，但只管 m 子網域 |
| 大小寫錯誤 | example.com/Robots.txt | 失效 |
子網域獨立這件事最常被忽略。每個子網域（例如 m.example.com、shop.example.com、blog.example.com）都是獨立的網站，都要各自放一份 robots.txt，網域與子網域的差別會影響到整份檔案的佈署策略。而子網域背後牽涉的網址註冊與 DNS 指向，可以對照網域申請購買全攻略來看。很多人只設了主網域，結果手機版或購物車子網域的爬蟲行為完全失控；若網站同時服務多語系市場，別忘了搭配Hreflang 多語系 SEO 設定，讓各語系版本的爬蟲規則各自到位。
手機版子網域的 robots.txt 特別值得留意，原因是 Google 早在 2023 年 10 月就宣布行動優先索引（Mobile-First Indexing）已完成，所有能在行動裝置運作的網站，現在都主要由行動爬蟲檢索 [來源：Google 搜尋中心《Mobile-first is here》 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。也就是說，手機版子網域的爬取規則直接影響整站被收錄的內容，這份子網域的 robots.txt 如果漏設或寫錯，影響的是全站的索引基礎，不是只有行動版的流量。
把行動流量的實際規模放進來看，這條規則的重量會更具體：根據 Statista 的調查，2026 年第一季，行動裝置（不含平板）佔了全球網站流量的 52.27% [來源：Statista《Share of mobile web traffic worldwide quarterly 2015-2026》 https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026-04-28]。超過一半的真實訪客來自行動裝置，而行動爬蟲又是行動優先索引的主力，兩者疊加之後，手機版子網域的 robots.txt 設定失誤，等同於把過半數流量對應的收錄基礎一起拖下水。對採用獨立行動子網域（例如 m. 開頭）架構的網站，這份檔案的重要性等同於主網域的版本。
常見的 robots.txt 放置與命名錯誤
- 放到子目錄而非根目錄 例如把檔案放在 example.com/blog/robots.txt，任何爬蟲都不會讀取，規則等於不存在。
- 大小寫混用 Robots.TXT、robots.TXT 這類寫法會讓檔案失效，協議只認全小寫的 robots.txt。
- 用副檔名 HTML 包裝 伺服器把檔案當成動態頁面輸出 robots.html，或加上 HTML 標籤，爬蟲解析時會出錯。
- HTTP 狀態碼不是 200 檔案回傳 404、500、或被重新導向到首頁，Google 會視情況把整站當成「完全允許爬取」或暫停處理，這兩種結果都可能與你預期不同。
- 子網域漏設 主網域設好，卻忘了 m.、shop.、blog. 這些子網域各自需要一份，子網域的爬蟲於是處於無規範狀態。
- 把規則寫進非根目錄的設定檔 有人把 Disallow 規則寫進 meta robots 或伺服器設定，卻誤以為這就是 robots.txt，兩者機制完全不同。
這份清單把上線時最常見的失誤集中起來，逐一比對就能排除掉絕大多數「檔案設了卻沒生效」的狀況。其中 HTTP 狀態碼這一項特別容易被忽略，因為檔案內容看起來正確，伺服器卻悄悄回傳了 404 或 301。用瀏覽器開啟 robots.txt 時，養成順手查看開發者工具裡 Network 面板的狀態碼，能提早發現這類隱性故障。
想快速檢查自己網站的 robots.txt，最直接的方式就是打開瀏覽器在網址列輸入自己的網域加上 /robots.txt，這跟用 F12 開發者工具看網頁原始碼是同一種「自己動手看」的排查習慣。如果你連檔案都打不開，那可能根本沒放對位置。
robots.txt 對 SEO 的真正影響：不是擋爬，是別擋錯
robots.txt 在 SEO 操作上的首要價值，在於「確認沒有誤擋重要頁面」，主動擋頁反而是次要；大型網站才會進一步用它控制爬取預算，把爬蟲的時間花在值得被收錄的頁面上。把優先順序搞反，是新手最常踩的雷。
最典型的災難場景：網站上線時，為了「先把網站藏起來測試」或「照教學加 Disallow」，一不小心把整站、分類頁或金流頁寫進 Disallow，結果爬蟲完全進不來，索引量直接崩盤。業界反覆出現的同一種失誤，就是上線時誤把 Disallow: / 寫進 robots.txt，導致整站長期無法被索引，這是 robots.txt 最經典的踩雷情境，這類事故在 SEO 社群的討論與 Google 搜尋中心的排解建議裡都相當常見。
這種事故的可怕之處在於：問題不一定會立刻被發現。網站看起來正常、流量也沒有崩到零（因為還有直接流量與品牌搜尋），但來自搜尋的自然流量會持續疲弱，直到有人去翻 GSC 報表才恍然大悟。這也呼應了為什麼接手一個網站，第一件事永遠是網站搬家改版的 SEO 災難裡強調的那句「先檢查 robots.txt」。
至於爬取預算控制，這對小型網站其實不太需要操心。爬取預算（crawl budget）指的是搜尋引擎願意花在你網站上的爬取時間與資源，只有當網站頁面數量大到一定程度（通常數萬頁以上），用 robots.txt 擋掉低價值頁面才會產生明顯效益。詳細原理可以參考爬取與爬取預算是什麼。整體來說，這類底層設定屬於技術性 SEO 完全指南的一環，跟載入效能也有關聯，搭配網站速度優化技巧一起做，能讓爬蟲在有限時間內抓到更多有價值的頁面。
| 網站規模 | robots.txt 主要任務 | 是否需要主動加 Disallow |
|---|---|---|
| 小型（<1000 頁） | 確保沒擋錯 | 通常不需要 |
| 中型（1千～數萬頁） | 擋掉參數頁、篩選結果 | 視情況 |
| 大型（數萬頁以上） | 集中爬取資源在重要頁面 | 需要，且要謹慎規劃 |
判斷一個路徑到底該不該加 Disallow，可以用一個條件式決策：只有當你「確定這頁不該被收錄、而且不需要對外傳遞權重」時才加。典型符合條件的包括內部搜尋結果頁、無限篩選的參數頁、登入後台路徑；不過這些頁面有時用其他方式處理會更精準，例如先搞懂AI Agent 瀏覽網站的行為模式再決定哪些路徑要對機器人關門，或評估網址查詢參數的影響，不一定要動到 robots.txt。
實務上，robots.txt 出問題的案例，幾乎清一色是「擋錯」，而不是「該擋沒擋」。所以接手一個站、被告知檢查 robots.txt 時，第一個動作不該是想辦法加規則，而是逐條讀懂現有的 Disallow 在擋什麼。確認沒擋錯，比新增任何規則都重要。
這個路徑到底該不該擋：四象限決策矩陣
判斷一個路徑要不要寫進 Disallow，可以套用一個二維象限：橫軸是「這頁值不值得被收錄」，縱軸是「需不需要對外傳遞權重」。兩個維度交會出四種情境，各有對應的最佳處理方式。這個矩陣的目的，是讓你在加規則之前先想清楚意圖，避免照抄別人的 Disallow 清單卻不知道自己到底在擋什麼。
| 象限 | 值不值得被收錄 | 需不需要傳遞權重 | 建議處理 | 典型頁面 |
|---|---|---|---|---|
| 第一象限 | 值得 | 需要 | 放行，不寫進 Disallow | 商品頁、文章頁、分類頁 |
| 第二象限 | 值得 | 不需要 | 放行，視情況用 canonical 處理 | 列印版、友善列印頁 |
| 第三象限 | 不值得 | 需要 | 放行但加 noindex，保留權重傳遞 | 分頁、排序參數頁 |
| 第四象限 | 不值得 | 不需要 | 寫進 Disallow，或伺服器層處理 | 內部搜尋結果、無限篩選頁 |
這張矩陣最關鍵的洞察在第三象限：當頁面不值得被收錄，卻又需要傳遞權重時，正解是放行加上 noindex，直接寫進 Disallow 會帶來反效果。原因前面已經提過，robots.txt 會擋掉爬蟲進來讀取內容，連帶讓它看不到頁面上的內部連結，權重也就無法經由這個頁面往下傳。對於分頁、排序這類輔助性頁面，noindex 搭配放行，才能既避免重複收錄，又保留站內連結的權重流動。
這個分類也解釋了為什麼大型電商網站的 robots.txt 通常只擋少數幾種路徑：商品頁、分類頁、品牌頁屬於第一象限，要放行；購物車、結帳、會員中心屬於第四象限，可以擋；真正需要仔細拿捏的，是分頁、排序、篩選這類第三象限的頁面，這些往往交給 noindex 處理會更乾淨。把頁面先歸類、再決定工具，比直接抄一份別人的 Disallow 清單來得安全。
把這張矩陣放進實際的決策情境會更具體。以這類月流量約 3-15 萬、商品加上篩選頁合計約 1-3 萬個網址的中型電商站為例，常見的狀況是站上同時存在商品頁、分類頁、排序與篩選參數頁、內部搜尋結果頁這幾種路徑，而它們恰好分布在四個象限。實務上常見的處理是：商品與分類頁放行不寫進 Disallow，購物車與會員路徑寫進 Disallow，排序與篩選這類輔助頁則放行搭配 noindex，內部搜尋結果才單獨擋掉。依這類站的典型表現，被篩選參數撐出來的重複或低價值網址常佔總網址數的約 40-70%，這也是為什麼中型站會把 robots.txt 與 noindex 分工使用，避免把所有不要的頁面一股腦丟進 Disallow。決策角度在於：先確認沒有任何一條規則誤擋到商品或分類頁，再回頭精煉 Disallow 清單，這個優先順序一旦搞反，影響的往往是整批主力頁面的收錄。要誠實提醒的是，這套分類與放行策略能降低誤擋風險，卻無法讓被擋或被 noindex 的頁面立即從索引消失，實際清除速度仍取決於 Google 對該站的檢索頻率，小站可能要等上數週甚至更久才會看到報表數字回落。
robots.txt 指令怎麼寫：User-agent、Disallow、Allow 與萬用字元
robots.txt 由三類指令組成：User-agent 用來指定規則適用的爬蟲，Disallow 設定不允許爬取的路徑，Allow 則在封鎖範圍中開例外。星號是萬用字元，可以代表任意字串，而多條 Disallow 之間是「聯集」關係，也就是只要符合任一條，就會被擋。這個聯集邏輯是讀懂大型網站 robots.txt 的鑰匙。
先看 User-agent。它就像網路世界裡的名牌識別證，爬蟲造訪網站時會自報身分。寫 User-agent: * 代表規則套用所有爬蟲；寫 User-agent: Googlebot 則只針對 Google 的爬蟲；想針對不同爬蟲給不同規則，就分區塊寫。這跟網址路徑是什麼的層級觀念相通：越精確的指定，覆蓋的預設值越廣。
- Disallow: /path 禁止爬取該路徑，例如 Disallow: /admin/ 擋掉整個後台目錄。
- Disallow: /* 萬用字元加上根斜線，等於整站封鎖，這也是最危險的一條。
- Disallow:（後面空白） 沒有任何禁止，所有路徑都能爬。
- Allow: /path 在 Disallow 封鎖範圍中開例外，常用於「整站擋、特定目錄放行」。
- $ 結尾符 表示路徑的結尾，例如 Disallow: /*.pdf$ 精準擋掉所有 PDF 結尾的網址。
萬用字元 * 比對任意字串，$ 表示路徑結尾，兩者搭配能做非常精細的控制。例如 Disallow: /*?utm_ 可以擋掉所有帶 utm 追蹤參數的網址，這對重複內容對 SEO 的影響有幫助，不過實務上會搭配Canonical 標準網址一起用才完整；想系統化處理重複網址問題，可以再看Canonical URL 完全指南。
聯集邏輯是初學者最容易忽略的一點。當你寫了多條 Disallow，效果是「取聯集」（符合任一條就擋），不會自動變成「取交集」（要全部符合才擋）。以 Apple 官網的 robots.txt 為例，那串長長的 Disallow 清單之所以這麼長，就是因為每多一條，就多擋一種路徑，彼此是累加關係 [來源：apple.com robots.txt 第一方檔案〈https://www.apple.com/robots.txt〉2026-06]。
| 規則 | example.com/ | .../category/abc/ | .../includes/?=x | .../retail/availability-x |
|---|---|---|---|---|
| Disallow: /* | 封鎖 | 封鎖 | 封鎖 | 封鎖 |
| Disallow:（空白） | 允許 | 允許 | 允許 | 允許 |
| Disallow: /*/includes/* | 允許 | 允許 | 封鎖 | 允許 |
| Disallow: /*retail/availability* | 允許 | 允許 | 允許 | 封鎖 |
| 多條並列（取聯集） | 允許 | 允許 | 封鎖 | 封鎖 |
這張表把抽象的聯集邏輯變成可驗證的對照。當你把 Apple 那串規則照搬過來，結果是「各自擋各自的路徑再聯集起來」，並不會自動變成「全部都擋」。某條規則看起來沒作用，多半是被其他規則的效果涵蓋了。
實際撰寫時，網址結構的設計會直接影響你能不能用好 robots.txt，這也是為什麼SEO 友善的網站架構設計與網址組成結構拆解會被當成前置功課。路徑分類越清楚，萬用字元越能精準命中你要擋的那一群頁面。
Sitemap 指令：在 robots.txt 裡宣告你的地圖
除了 User-agent、Disallow、Allow 之外，還有一條經常被忽略但很實用的指令：Sitemap。它的作用是告訴搜尋引擎「我的 XML Sitemap 放在哪裡」，這是少數寫在 robots.txt 裡、卻是「對外提供資訊」而非「設限」的指令。寫法很單純，獨立一行：
Sitemap: https://example.com/sitemap.xml
Sitemap 指令有幾個特性值得留意。它放在檔案裡的任何位置都有效，跟 User-agent 區塊沒有從屬關係，這跟 Disallow 必須跟在特定 User-agent 之後不同；而且可以同時宣告多份 sitemap，把商品、文章、影片拆成不同檔案、每份各佔一行，讓搜尋引擎更有效率地分配收錄資源。要注意的是，它對 Google 來說是提示性質，不一定會立刻抓取，但確實是 Google 認可的官方發現機制之一 [來源：Google 搜尋中心《Sitemap 總覽》〈https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview〉2025-09]。
把 Sitemap 寫進 robots.txt 的好處，是讓搜尋引擎在第一次抓取根目錄檔案時就同步發現地圖，省去手動到 GSC 提交的步驟。這對剛上線、還沒建立外部連結的新站特別有用，因為爬蟲往往是從根目錄開始認識一個網站。關於 sitemap 本身怎麼規劃與產生，可以對照網站 Sitemap 入門指南與XML Sitemap 對 SEO 的幫助。
Crawl-delay 與 Host：兩個你不需要寫的指令
在網路上的各種 robots.txt 範例裡，偶爾會看到 Crawl-delay 與 Host 這兩條指令。這裡直接給結論：對 Google 來說，這兩條都沒有效果，寫了等於沒寫。Crawl-delay 原本是給少數搜尋引擎（例如早期的 Yahoo、Bing）用的，用來要求爬蟲每次抓取之間間隔幾秒；但 Google 的爬蟲並不支援這條指令，Google 自己的官方文件也說明它會忽略 Crawl-delay [來源：Google 搜尋中心《robots.txt 規格》〈https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt〉2025-09]。Host 指令則是給俄系搜尋引擎 Yandex 用的，對 Google 同樣無效。
如果你真的覺得 Google 爬蟲太頻繁、造成伺服器負擔，正解是到 Google Search Console 的「檢索頻率」設定裡調整，那才是 Google 實際會採納的控制點。在 robots.txt 裡寫 Crawl-delay 只會造成一種誤解：你以為已經設了限制，Google 卻完全沒讀進去。把這條從你的檔案裡刪掉，換成 GSC 裡的正式設定，才不會兩頭落空。
另一個常被誤用的做法是用 Disallow 擋掉整個圖片或 CSS、JS 目錄。早期網站為了節省頻寬，會擋掉靜態資源，但這在現代 SEO 裡是個雷：Google 需要抓取 CSS 與 JavaScript 才能正確渲染頁面、判斷行動裝置相容性與版面結構。把這些資源擋掉，等於讓 Google 看到的是一個殘缺的頁面，行動版體驗與 Core Web Vitals 的判讀都會跟著失準。正確做法是讓渲染所需的資源完全放行。
Allow 與 Disallow 衝突時，Google 採用哪一條
當 Allow 與 Disallow 同時匹配到同一個網址，Google 不是「先寫的贏」或「後寫的贏」，而是根據規則路徑長度選擇最明確的那一條；若路徑長度相同，則採用限制最少的規則，也就是 Allow 優先。實務上不建議刻意設計這種衝突，會讓規則極難維護。
Google 搜尋中心的原文這樣寫：「將 robots.txt 規則與網址比對時，檢索器會根據規則路徑長度，使用最明確的規則。如果規則發生衝突（包括含有萬用字元的規則），則 Google 會使用限制最少的規則。」[來源：Google 搜尋中心《Google 如何解讀 robots.txt 規格》〈https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt〉2025-09]
| 網址 | 規則 | 採用 | 原因 |
|---|---|---|---|
| example.com/page | allow: /p vs disallow: / | allow: /p | /p 路徑較長、較明確 |
| example.com/folder/page | allow: /folder vs disallow: /folder | allow: /folder | 路徑等長，採限制最少（Allow） |
用兩個具體網址對照，抽象的優先序就變得可驗證。第一個例子裡，/p 比 / 更明確，所以放行；第二個例子裡，兩條規則路徑等長，Google 採限制最少的那一條，也就是 Allow。理解這個原則之後，你會發現其實不需要去記「誰先寫」，因為順序根本不是判斷依據。
不過話說回來，刻意設計互相矛盾的規則，會讓未來維護的人（可能是三個月後的你）完全看不懂當初的意圖。寫規則的原則是「越單純越好」，能不寫衝突就不寫。這跟內部連結與網站架構優化強調的可維護性是同一個道理：規則越少、越清楚，出錯的機率越低。
用 robots.txt 控制 AI 爬蟲：擋 GPTBot 與其他訓練爬蟲
想阻止網站內容被 AI 模型拿去訓練，robots.txt 可以做到「部分防範」，做法是針對特定 AI 爬蟲的 User-agent 單獨寫 Disallow 規則。但這仍是君子協議，不保證所有 AI 業者都遵守，而且擋掉 AI 爬蟲的同時，也可能失去在該平台搜尋結果被引用的能見度，這是一個兩難的取捨。
最常見的寫法針對 OpenAI 的訓練爬蟲 GPTBot。只要兩行就搞定：
User-agent: GPTBot Disallow: /
這段規則的意思是：針對 GPTBot 這個 User-agent，禁止爬取整站。這是 OpenAI 官方公開承認的爬蟲識別名稱 [來源：OpenAI《GPTBot 說明文件》〈https://platform.openai.com/docs/gptbot〉2025-09]，寫進去之後，OpenAI 訓練用的爬蟲理論上會尊重這條規則。
| AI 爬蟲 User-agent | 所屬業者 | 主要用途 |
|---|---|---|
| GPTBot | OpenAI | ChatGPT 與模型訓練資料收集 |
| Google-Extended | Gemini 等 AI 產品訓練 | |
| ClaudeBot | Anthropic | Claude 模型訓練爬取 |
| CCBot | Common Crawl | 開放網路爬蟲，常被各家模型間接取用 |
| PerplexityBot | Perplexity | Perplexity 搜尋與答案生成 |
這份清單是 AI 時代查詢量很高、但網路上化用詞最混亂的一塊。要特別提醒的是，Google 用來做 AI 訓練的爬蟲識別名稱是 Google-Extended，而不是 Googlebot 本身，兩者不能混為一談 [來源：Google 搜尋中心《Google-Extended 說明》〈https://developers.google.com/search/docs/appearance/ai-overviews/google-extended〉2025-09]。如果想更全面理解 AI 時代的協議演進，可以參考llms.txt AI 時代的新協議，而面對大型語言模型如何改變搜尋生態，LLM 與 LLMO 全面解析把基礎觀念講得很清楚。
擋 AI 爬蟲要付出代價。當你把 GPTBot 擋掉，意味著 ChatGPT 在回答問題時不會參考你的內容，等於放棄了在 AI 搜尋結果中被引用的機會。這幾年Google AI Overviews 摘要、Google AI Mode 新搜尋模式、AI 搜尋引擎工具分析的崛起，讓這個取捨變得更複雜：你要的是流量保護，還是 AI 引用的能見度？沒有標準答案，要看你的商業模式。
想評估自己內容在 AI 搜尋裡的能見度，可以先看AI Grounding SEO 策略。從更宏觀的角度切入，AI 搜尋時代的 SEO 全攻略把整個版圖梳理得相當完整，而針對 ChatGPT 在 Atlas 模式下的引用機制，ChatGPT Atlas SEO 實戰指南提供了更具體的觀測與調整方向。
AI 爬蟲的規範還在快速演進中，今天的 User-agent 清單明年可能就不完整。如果你處理的是真正敏感的內容，不要只靠 robots.txt，那是GEO 與 SEO 的差異之外，另一個需要資安介入的領域。AI 內容相關的政策演進，也可以對照Google 如何看待 AI 內容。
隱藏敏感頁面不該交給 robots.txt
強烈不建議用 robots.txt 來隱藏敏感頁面。第一層風險是公開揭露：robots.txt 任何人都能開啟，這份檔案等於你網站的地圖，把後台路徑、會員資料路徑、測試環境路徑寫進 Disallow，本意是擋爬蟲，實際效果常常是昭告天下，對攻擊者來說比用工具掃描還方便。第二層是約束力有限：惡意爬蟲、內容農場的採集器、以及部分不守規矩的 AI 爬蟲，看到你的 Disallow 反而更興奮，因為你剛剛告訴他們哪裡有料。真正能擋住威脅的是伺服器層級的權限控制、登入驗證、IP 限制，不是一個純文字檔。
最關鍵的反直覺事實來自 Google 官方的明確警告：「如果不想讓網頁顯示在 Google 搜尋結果中，請不要以 robots.txt 做為隱藏網頁的方法。如果有其他網頁的說明文字指向您的網頁，即使 Google 未造訪您的網頁，還是能夠為網頁建立索引。如要防止自己的網頁顯示在搜尋結果中，請使用其他方法，例如密碼保護或是 noindex 標記。」[來源：Google 搜尋中心《robots.txt 簡介》〈https://developers.google.com/search/docs/crawling-indexing/robots/intro〉2025-09]
這段話推翻了很多人直覺以為的「擋爬就等於不被索引」。事實上，只要其他頁面用文字連結指向某個被封鎖的網址，Google 仍可能根據那些連結的錨點文字為它建立索引。換句話說，robots.txt 擋的是「進來看內容」，不是「出現在搜尋結果」。想完整理解這條界線，可以看robots.txt 與 noindex 為何不能並用與noindex 標記的用途與效果。
- 只想公開但不被索引 用 noindex 標記或 不被索引的四種方法 裡介紹的機制，讓頁面能被爬但不出現在搜尋結果。
- 需要登入才能看 用密碼保護或會員驗證，這才是真正的存取控制，搭配HTTPS 與網站安全性一起做。
- 根本不該上線的資料 這是純粹的資安問題，請找工程與資安人員處理，不要妄想用 SEO 工具解決。
另一個延伸觀念：就算你只是想讓頁面不要出現在搜尋結果，也要小心 robots.txt 跟 noindex 的搭配陷阱，這個議題在不同SEO 與 AI 搜尋的名詞體系裡都會反覆出現，因為索引控制是橫跨傳統與 AI 搜尋的共同基礎。同時，Open Graph 標籤與社群分享與結構化資料的意義與用途這類控制「怎麼被呈現」的機制，跟控制「能不能被爬」的 robots.txt 是不同層的事，不要混為一談。
測試、提交與後續維護的節奏
寫好 robots.txt 之後，用 Google Search Console 內建的「robots.txt 測試工具」可以模擬 Google 能否正確讀取規則、檢測有沒有誤擋。檔案放到根目錄後，Google 會在下次爬取時自動抓取，不需要像 sitemap 那樣手動提交，但可以用 GSC 主動請求重新檢索以加快生效。
測試工具是寫完之後的第一道驗證。Google Search Console 的 robots.txt 測試器能逐條驗證規則，也可以輸入特定網址測試它會不會被封鎖 [來源：Google 搜尋中心《建立 robots.txt 檔案》〈https://developers.google.com/search/docs/crawling-indexing/robots/create-robots-txt〉2025-09]。這對接手網站、懷疑某條規則寫錯時特別有用。如果你還沒裝 GSC，先參考Google Search Console 安裝教學與Google Search Console 功能介紹。
- 確認檔案放在根目錄、檔名全小寫 robots.txt。
- 用 GSC 的 robots.txt 測試器逐條驗證，特別檢查重要頁面（首頁、分類、商品、金流）是否被誤擋。
- 放行後觀察GSC 網頁索引報表解讀，確認索引數量沒有異常下滑。
- 改版或路徑結構變動時，回頭重跑一次這個流程。
robots.txt 異常的疑難排解清單
當你在 GSC 報表裡看到索引數量異常下滑、重要頁面遲遲不被收錄，或是檢索統計數據突然歸零，robots.txt 經常是嫌疑犯之一。下表把最常見的症狀與對應原因配對起來，按圖索驥能省下大量排查時間。
| 症狀 | 最可能的原因 | 排查動作 |
|---|---|---|
| 整站索引量突然歸零 | 誤寫 Disallow: / 或 Disallow: /* | 打開根目錄檔案，檢查是否有整站封鎖規則 |
| 只有某個分類的頁面消失 | 該分類路徑被精準 Disallow | 用 GSC 測試器輸入該分類的任一網址驗證 |
| 檔案設了規則卻完全沒生效 | 檔案不在根目錄、回傳非 200、或被外掛覆蓋 | 瀏覽器開啟 example.com/robots.txt 並查看狀態碼 |
| 子網域行為與主網域不一致 | 子網域漏設或使用了不同規則 | 逐一檢查每個子網域根目錄的檔案 |
| 規則看起來正確卻仍誤擋 | 聯集邏輯下被多條規則共同命中 | 逐條刪減 Disallow，找出實際觸發的那條 |
| 圖片或資源渲染異常 | CSS、JS 或圖片目錄被 Disallow | 放行渲染所需的靜態資源路徑 |
| 改版後流量持續疲弱 | 新路徑被舊規則的萬用字元誤擋 | 把新網址放進測試器，檢查是否落入封鎖範圍 |
這張表的核心邏輯是：robots.txt 的問題通常表現成「整批頁面同時異常」，因為規則是按路徑批次生效的。如果只有單一頁面出問題，反而多半跟 robots.txt 無關，要往 noindex、canonical、或伺服器回傳狀態碼的方向找。掌握「批次異常多半是 robots.txt、單頁異常多半是其他機制」這條判斷線，能快速縮小排查範圍。
提交方式其實非常單純：放到根目錄即可，Google 會自動抓取。不需要像XML Sitemap 對 SEO 的幫助那樣主動提交，但你可以用GSC 網址檢查工具主動提交來加速某個重要頁面的重新檢索。至於 sitemap 本身怎麼產生與提交，可以參考網站 Sitemap 入門指南。生效時間取決於 Google 對該站的爬取頻率，大型站可能數小時內更新，小站則可能要等上數天，根據 Google 搜尋中心對檢索頻率與排程的說明，這個節奏由 Google 依網站整體訊號自行調整。
維護的時機往往比撰寫本身更重要。網站改版、路徑結構變動、新增子網域、更換網址命名規則（例如參考中文網址與英文網址的 SEO 取捨做調整），這幾個情境都要回頭檢查 robots.txt 有沒有跟著失效或誤擋新路徑。把「改版後必檢 robots.txt」寫進上線檢查清單，能避掉大多數的事後救火。
如果你常做網站健檢，可以搭配Screaming Frog 爬蟲檢測工具或SEO 工具軟體總整理裡的其他工具，把 robots.txt 的封鎖範圍跟實際網址清單比對，看看有沒有重要頁面被默默擋掉。GSC 常用功能總覽裡的幾個報表，也是長期監控 robots.txt 影響的必備視角。
若你同時追蹤來自 AI 平台的流量變化，建議把GA4 追蹤 AI 流量納入觀測，掌握擋或不擋 AI 爬蟲之後的實際影響。
robots.txt 的維護核心在於定期確認沒擋錯，至於持續新增規則，反而屬於次要工作。這跟黑帽白帽 SEO 的界線那種「怎麼操作」的議題不同，它是純粹的健檢工作，平時不必天天盯著，但一旦出了事，症狀往往就是整批頁面同時異常。
把 robots.txt 放回它該在的位置
回顧整份檔案的定位：它的首要價值是確認沒擋錯重要頁面，而大型網站則會拿它來控制爬取預算；它擋得住君子，擋不住流氓，所以隱藏敏感頁面不要交給它。這份檔案越短、越清楚、越能被未來的你一眼看懂，反而越是好規則。接手或改版一個站，第一件事永遠是逐條確認現有 Disallow 沒有擋到任何重要頁面，再去想加規則。
把上面的原則收斂成一份可重複執行的「robots.txt 三層健檢清單」，接手或改版任何一個站，照著走一遍就能排除九成以上的隱性故障：
- 第一層｜結構 檔案在根目錄、檔名全小寫、回傳 HTTP 200、未被外掛或快取覆蓋；每個子網域各一份。
- 第二層｜語意 逐條讀懂每條 Disallow 在擋什麼路徑，用 GSC 測試器把首頁、分類、商品、金流網址丟進去驗證沒被命中。
- 第三層｜分工 要被爬但不要被收錄的頁面交給 noindex，重複網址交給 canonical，真正不該上線的資料交給資安，robots.txt 只處理「值不值得被爬」這一件事。
一個常見而致命的反效果：把分頁、排序、篩選這類第三象限頁面直接寫進 Disallow，本意是避開重複收錄，結果連頁面上的內部連結也一起被擋掉，站內權重流動在這些節點斷掉，反而壓低了真正該被收錄頁面的能見度。這類頁面的正解是放行加 noindex，而不是丟給 robots.txt。能避開這一個雷，等於避開了大半的誤用。
用 WordPress 架站的人要特別留意覆寫問題。WordPress 是目前最主流的架站系統，根據 W3Techs 截至 2026 年 6 月的調查，WordPress 被全網約 41.5% 的網站採用，在所有已知內容管理系統的網站中佔約 59.2% [來源：W3Techs《Usage Statistics and Market Share of WordPress》〈https://w3techs.com/technologies/details/cm-wordpress〉2026-06-29]。正因為用戶基數這麼大，各家主機、SEO 外掛、快取機制對 robots.txt 的處理方式都不盡相同，預設檔案可能被自動覆蓋，自己手寫的規則也可能被外掛改掉。確認你最終看到的根目錄檔案，真的就是你寫的那一份，是 WordPress 站最容易被忽略的一步；完整的架站流程可以對照WordPress 架站全攻略，從 WordPress.com 搬到自架版則參考WordPress.com 搬家到 WordPress.org，把 robots.txt 佈署一併納入搬家清單。
若你的網站用了大量 JavaScript，JavaScript 網站的爬蟲與收錄會跟 robots.txt 產生額外互動，尤其別把渲染所需的 CSS、JS 路徑擋掉；想把索引控制做得更完整，可以再搭配Canonical 標準網址與爬取預算優化策略，讓 robots.txt、noindex、canonical 三套工具各司其職。
常見問題
Allow 和 Disallow 衝突時 Google 會採用哪一條？
路徑較長、較明確的那條勝出；若路徑等長，則採限制最少的規則（Allow 優先）。順序不是判斷依據，實務上也不建議刻意設計互相矛盾的規則。
可以用 robots.txt 隱藏敏感頁面嗎？為什麼不建議？
不建議。robots.txt 是公開檔案，列敏感路徑等於主動揭露；它不具強制性，惡意爬蟲照爬不誤；就算 Google 不爬，只要有其他頁面連到它仍可能被索引。隱藏敏感頁面應交給密碼保護或 noindex。
robots.txt 怎麼擋 GPTBot 等 AI 爬蟲？
針對特定 AI 爬蟲的 User-agent 寫規則即可，例如「User-agent: GPTBot」加上「Disallow: /」就能擋 OpenAI 的訓練爬蟲。同理可用於 Google-Extended、ClaudeBot、CCBot 等，但這仍是君子協議，且會失去在該平台被引用的能見度。
常見的搜尋爬蟲與 AI 爬蟲 User-agent 有哪些？
User-agent 是裝置或爬蟲造訪網站時自報身分的識別字串。常見搜尋爬蟲有 Googlebot、Bingbot、Baiduspider、DuckDuckBot；AI 訓練爬蟲則有 GPTBot、Google-Extended、ClaudeBot、CCBot、PerplexityBot。
可以在 robots.txt 寫 Sitemap 指令嗎？
可以。在檔案裡獨立一行寫「Sitemap: https://example.com/sitemap.xml」，就能讓搜尋引擎在抓取根目錄檔案時同步發現你的 XML Sitemap。這條指令可以宣告多份 sitemap，放在檔案任一位置都有效，對 Google 是認可的官方發現機制之一。
Crawl-delay 指令對 Google 有效嗎？
無效。Google 的爬蟲會忽略 Crawl-delay 指令，這條原本是給少數搜尋引擎使用的。若要調整 Google 的檢索頻率，正解是到 Google Search Console 的「檢索頻率」設定裡調整，那才是 Google 實際採納的控制點。
robots.txt、noindex、canonical 要怎麼選？
看頁面的兩個條件：值不值得被收錄、需不需要傳遞權重。值得收錄又需要權重的頁面（如商品頁）直接放行；不值得收錄但需要傳遞權重的輔助頁（如分頁）放行加上 noindex；既不值得收錄又不需要權重的頁面（如內部搜尋結果）才寫進 Disallow。重複網址問題則交給 canonical 處理，與前述機制分工合作。