Robots.txt 與 noindex 有什麼不同？別把爬取規則當成收錄開關
Robots.txt 管理爬蟲能否存取路徑，noindex 管理已讀取資源是否出現在搜尋結果。本文比較兩者、登入保護與移除方式，並提供可重複的驗證流程。
先說結論：robots.txt 管「能不能來讀」，noindex 管「讀完要不要收錄」
robots.txt 與 noindex 位在不同關卡。robots.txt 是放在網站根目錄的爬取規則，用來告訴指定爬蟲哪些路徑可以或不可以存取；noindex 是頁面或伺服器回應裡的索引規則，搜尋引擎必須先取得它，才知道不要讓該資源出現在搜尋結果。
因此，若目標是讓一個仍公開可開啟的網頁退出搜尋結果，通常應允許爬取並提供 noindex。不要同時在 robots.txt 阻擋該頁，否則爬蟲可能無法看到移除指令。若內容涉及個資、內部文件或付費權限，兩者都不是安全措施，應改用登入、授權或直接移除。
可以先用目的分流：
- 減少不重要路徑的爬取：評估使用
robots.txt。 - 保留公開頁面，但不要出現在搜尋結果：使用可被爬取的
noindex。 - 非 HTML 檔案不要被索引：在 HTTP 回應加入
X-Robots-Tag: noindex。 - 內容不能讓未授權者看到：使用登入與伺服器端權限控制。
- 資源已永久不存在：回傳正確的 404 或 410；若有真正等價的新位置，才做永久轉址。
為什麼 robots.txt 擋住頁面，網址仍可能出現在搜尋結果？
搜尋引擎不只從頁面內容得知一個 URL，也能從站內連結、外部連結、Sitemap 或過去爬取紀錄發現它。Google 官方明確說明：被 robots.txt 禁止爬取的網頁，內容不會被 Googlebot 讀取，但若其他地方仍連向該 URL，網址本身仍可能被索引；結果可能只顯示網址或外部可得資訊，沒有正常摘要。
這不是 robots.txt 失效，而是它完成的任務只有「不要取得這個路徑」。網際網路工程任務組制定的 Robots Exclusion Protocol 也把這套規則定位為爬蟲被要求遵守的存取規範，並提醒它不是授權機制。robots.txt 本身是公開檔案，把敏感路徑寫進去反而可能讓路徑更容易被看見。
最小的規則可以長這樣：
User-agent: *
Disallow: /internal-search/它表示符合這組規則的爬蟲不應存取 /internal-search/ 開頭的路徑。檔案必須放在對應主機的根目錄，例如 https://example.com/robots.txt；規則只作用於同一協定、主機與連接埠的範圍。Google 的解讀規格採用最具體的路徑匹配，同長度的 Allow 與 Disallow 衝突時採用 Allow，所以不應只憑肉眼猜測大型規則的結果。
還要注意三項限制：
- 合規搜尋爬蟲通常會遵守規則，但惡意或不支援的爬蟲不一定遵守。
- 禁止爬取頁面，也可能連帶讓搜尋引擎看不到頁面引用的重要圖片、樣式或腳本。
- 規則更新有快取與重新抓取時間，不是存檔後所有爬蟲立即切換。
noindex 要能被讀到，才有機會生效
HTML 頁面最常見的寫法，是在文件 <head> 放入：
<meta name="robots" content="noindex">這項規則要求支援它的搜尋爬蟲不要在搜尋結果呈現該頁。頁面仍然可以由知道 URL 的使用者直接開啟，也可能被其他網站連結；noindex 管的是搜尋索引，不是網路存取權。
若資源不是 HTML，例如 PDF、圖片或伺服器產生的檔案，無法放入 meta element，可以在 HTTP response header 使用：
X-Robots-Tag: noindexGoogle 與 Bing 的官方文件都說明其支援方式。實作後仍要看正式伺服器的實際回應，不能只檢查 CMS 後台的開關。快取代理層、反向代理、部署環境或版型條件都可能讓正式 header 與預期不同。
最常見的矛盾組合是：
User-agent: *
Disallow: /preview/<meta name="robots" content="noindex">如果同一個 /preview/ 頁面同時套用兩者，爬蟲先被擋在外面，就可能永遠讀不到 HTML 裡的 noindex。Search Console 的 Live Test 甚至會在這種情況下顯示「Crawl allowed? No」，但「Indexing allowed?」可能仍是 Yes，原因正是 Google 無法取得頁面來判讀 noindex。
六種方法解決六種不同問題
| 真正目標 | 優先方法 | 搜尋爬蟲能否取得內容 | 一般使用者能否開啟 | 主要限制 |
|---|---|---|---|---|
| 減少特定路徑的爬取 | robots.txt | 符合規則者不應取得 | 可以 | URL 仍可能從其他訊號被發現或顯示 |
| 公開頁保留，但不出現在搜尋結果 | noindex meta tag | 必須可以取得 | 可以 | 需等待重新爬取與處理 |
| 非 HTML 資源不出現在搜尋結果 | X-Robots-Tag: noindex | 必須可以取得回應 | 可以 | 要確認正式 header 真的存在 |
| 內容只給特定成員 | 登入與授權 | 未授權者不能取得 | 僅授權者可以 | 需要正確的權限與快取設計 |
| 資源永久消失、沒有替代內容 | 404 或 410 | 取得不存在狀態 | 不可以 | 站內連結與 Sitemap 也要清理 |
| 舊位置永久搬到等價新位置 | 301 或 308 轉址 | 會前往新位置 | 會前往新位置 | 不能把不相關舊頁一律轉到首頁 |
canonical 也不是其中任何一項的替代品。它用於一組重複或非常相似網址的代表版本選擇，不是保密、禁止爬取或刪除指令。若問題是參數版與乾淨版重複，先讀canonical 與重複網址的處理方法；若頁面根本不應出現在搜尋結果，才回到 noindex 或移除。
完整案例：同一個課程站，需要三種不同控制
以下是虛構教學案例，用來示範工具選擇與驗證，不是 MKT Notes 或任何網站的實際索引資料。
一個線上課程站有 60 篇正式教材、24 個站內搜尋結果頁、12 份可公開下載的 PDF 講義、會員訂單頁，以及一個會依輸入持續產生建議結果的查詢端點。團隊一開始在 robots.txt 同時封鎖搜尋結果、PDF、會員區與查詢端點，然後發現部分舊搜尋結果 URL 仍在 Google 顯示。
問題不是規則數量不夠，而是四類資源的目標不同：
| 資源 | 團隊真正想要的結果 | 合理處理 | 驗證重點 |
|---|---|---|---|
| 60 篇正式教材 | 可爬取、可索引 | 允許存取，維持可索引 | Live Test 可取得；主要頁在 Page indexing 逐步正常 |
| 24 個站內搜尋結果頁 | 使用者可開啟，不進搜尋結果 | 移除 robots 阻擋，輸出 noindex | 原始 HTML 與正式回應有規則；重新爬取後退出索引 |
| 12 份 PDF 講義 | 可下載，不進搜尋結果 | 回應加入 X-Robots-Tag: noindex | curl -I 或瀏覽器網路回應可看到 header |
| 會員訂單頁 | 未登入者不能讀取 | 伺服器端登入與授權 | 無登入狀態不能取得個人內容，不能只靠 robots |
| 查詢建議端點 | 不需要搜尋爬蟲反覆請求 | robots.txt 阻擋對應路徑 | 規則只涵蓋端點，不誤擋正式教材資源 |
這裡有一個可驗算的差異：真正需要 noindex 的公開 HTML 是 24 個頁面，需要 HTTP header 的非 HTML 是 12 份檔案，兩者合計 36 個可公開取得但不希望出現在搜尋結果的 URL。會員訂單不是第 37 種 noindex 頁面，而是存取權問題；查詢端點也不是等待移除的內容頁，而是爬取管理問題。
團隊先解除 24 個搜尋結果頁的爬取封鎖，確認它們回傳 200 且含 noindex，再讓搜尋引擎重新取得。舊結果不會在部署瞬間全部消失，因為系統要重新爬取與處理；若特定 URL 有急迫下架需求，可由已驗證站長在 Search Console 使用 Removals 工具暫時隱藏，但 Google 說明這只維持約六個月，仍須搭配永久方法。
八步檢查流程：從目的、正式回應到索引狀態
1. 先寫出預期狀態
對每類 URL 記錄「是否允許匿名開啟、是否希望被爬取、是否希望被索引、是否有等價新位置」。不要從標籤名稱反推需求。
2. 建立實際 URL 樣本
從路由、Sitemap、站內連結、伺服器紀錄與 Search Console 各取樣。參數、大小寫、子網域與檔案版本可能是不同 URL，不能只測一個乾淨範例。
3. 檢查 robots.txt 的作用範圍
直接開啟正式站根目錄的 /robots.txt，確認回應成功、規則屬於正確主機，並抽查最具體的 Allow／Disallow 結果。不要假設測試站與正式站使用同一份檔案。
4. 檢查 HTML 與 HTTP header
HTML 頁查看正式原始碼與呈現後頁面結構；非 HTML 資源查看 response header。若 meta 與 header 同時存在，確認沒有不同環境輸出互相衝突的指令。
5. 排除存取控制錯用
用未登入、無特殊 Cookie 的狀態打開敏感 URL。只要仍能看到內容，就代表 robots 或 noindex 沒有完成保護任務；應回到驗證與授權層修正。
6. 用 URL Inspection 分開看三個問題
Live Test 依序查看 Crawl allowed?、Page fetch 與 Indexing allowed?。前者回答爬取規則，後者回答是否讀到索引限制；有效的 Live Test 只表示現在可能可索引，不保證最後一定進入索引。
7. 修正後安排重新處理
對少量重要 URL 可要求重新建立索引；大量頁面則確保內部連結與 Sitemap 符合預期，等待正常重爬。若要讓頁面退出索引，不要修正 noindex 後又立刻重新加回爬取封鎖。
8. 記錄索引結果與例外
保存修改日、規則版本、樣本 URL、最後爬取日與 Page indexing 原因。把「預期排除」和「錯誤未索引」分開統計，不追求所有可發現 URL 都被收錄。
六個常見誤判與限制
robots.txt 寫了 noindex 就能移除頁面
Google 多年前曾處理過非標準寫法，但現行官方文件要求使用 meta tag 或 X-Robots-Tag。不要在 robots.txt 自創 Noindex: 欄位，也不要把歷史行為當成跨搜尋引擎標準。
同時 Disallow 與 noindex 是雙重保險
這兩項不是疊加保護。前者可能讓爬蟲無法取得後者，造成頁面遲遲不能依 noindex 更新索引狀態。
noindex 可以保護機密內容
知道 URL 的人仍可能直接開啟頁面，其他服務也不一定遵守索引規則。個資、合約、後台與付費內容必須使用真正的身分驗證與權限控制。
移除工具等於永久刪除
Search Console Removals 是快速、暫時的搜尋結果隱藏工具，不會刪除網站內容。若沒有同步改成 404、410、登入保護或可讀取的 noindex，期限過後仍可能重新出現。
URL Inspection 顯示可索引，就保證一定收錄
Live Test 不檢查所有條件，也不能預測重複頁與 canonical 最終選擇。它適合驗證現在能否取得與是否讀到規則，不是收錄保證書。需要完整理解時，可搭配爬取、索引與排名的三關診斷。
為了節省爬取，把所有腳本與樣式都擋掉
若重要內容或版面需要這些資源才能正確呈現，搜尋引擎可能難以理解頁面。先用伺服器紀錄找出真正大量、低價值的路徑，再做窄範圍控制；不要用一條寬泛規則換來不可見的呈現問題。
最後帶走：先選目標，再選控制層
robots.txt管理合規爬蟲對路徑的存取，不是可靠的搜尋結果移除工具。noindex管理頁面或資源是否出現在搜尋結果，但爬蟲必須取得規則。- HTML 使用 robots meta tag；非 HTML 資源可使用
X-Robots-Tagresponse header。 - 私密內容使用登入與授權，不能依賴爬蟲自律。
- 永久移除使用正確的 404、410 或等價頁永久轉址；急迫時再把暫時移除工具當過渡。
- 驗證時要同時看正式
robots.txt、HTML、HTTP header、未登入存取與 Search Console 狀態。
真正穩定的做法，是把爬取、索引、存取權與資源生命週期分開設計。只要先回答「誰可以讀、爬蟲需不需要來、搜尋結果要不要顯示、原位置是否仍存在」，就不會再把同一個控制項硬套到所有問題，也能讓內部連結與網站架構維持清楚、可驗證的搜尋脈絡。
SOURCE LOG
資料來源
- Google Search Central：robots.txt 的用途與限制
- Google Crawling Infrastructure：建立與提交 robots.txt
- Google Crawling Infrastructure：Google 如何解讀 robots.txt 規則
- 網際網路工程任務組：Robots Exclusion Protocol 第 9309 號標準
- Google Search Central：Robots meta tag 與 X-Robots-Tag 規格
- Google Search Console：URL Inspection 工具
- Google Search Console：Removals 工具與永久移除方法
- Bing Webmaster Tools：支援的 robots meta tag 與屬性