robots.txt 還是 noindex？爬取與收錄各管一段

在同一個網址設定 robots.txt Disallow 與 noindex，並不會形成雙重索引保護。抓取被封鎖時，Google 可能讀不到新設的 noindex，網址卻仍可能因其他頁面的連結而出現在搜尋結果。

技術 SEO 常見的誤設，是讓 robots.txt 的 Disallow 阻止 Google 抓取同一網址，卻又期待它讀到新設的 noindex。這不是兩者在網站上不能共存，而是抓取限制可能讓索引指令無法被讀取。

這篇會把這件事從底層機制講起，帶你看清楚為什麼這兩個工具會打架、Google 在 2019 年做了什麼關鍵調整、以及你到底該怎麼正確地告訴搜尋引擎「這一頁不要被收錄」。如果你想先弄懂 Google 是怎麼一步步抓取、處理、收錄一個網頁的，可以回頭讀一篇 Google 搜尋運作流程的完整解析，回來看這篇會更有感。

【快速重點，六十秒看完】

• robots.txt 控制爬取，noindex 控制收錄，是兩個不同階段的事。一個站在門外，一個貼在門內。
• robots.txt 若阻止 Google 抓取同一網址，它就無法從這次請求讀到頁面新設的 noindex。
• 被封鎖的網址仍可能被索引；搜尋結果可能缺少摘要，但不一定完全沒有標題。
• 公開頁面若要排除索引，可用 noindex 並允許 Google 讀取指令。私人內容先用登入與權限保護；robots.txt 主要管理抓取。
• Google 自 2019 年起，已不再支援寫在 robots.txt 裡的 noindex 指令。

常見誤設示例：同一網址封鎖抓取又新增 noindex

常見的錯誤，是把開發中的預覽頁、結帳完成後的感謝頁或不想索引的網址，全部丟進 robots.txt 的 Disallow 清單，又在頁面裡加上 <meta name="robots" content="noindex">。看似雙重保險，實際上前一道規則會讓爬蟲讀不到後一道指令。

這兩項設定分別作用在抓取與索引。若 Google 尚未讀到 noindex，就先封鎖該網址的抓取，新的索引指令便無法經由頁面回應送達；不是多加一條規則就會有更強的效果。

要理解這個矛盾，我們得先把這兩個工具各自由管什麼拆開來看。如果你還沒讀過基礎介紹，建議先看過 robots.txt 的完整介紹和 noindex 的作用解析，再往下走會輕鬆很多。

robots.txt 和 noindex，管的根本是兩件事

很多人把這兩者混為一談，其實它們站在 Google 處理網頁的兩個不同關卡上。一個站在門外，決定要不要進來；另一個站在門內，決定要不要把看到的東西記進資料庫。把這層關係想清楚，後面的矛盾就會自動解開。

robots.txt 管的是「要不要來抓」

robots.txt 是網站提供給爬蟲的抓取規則檔案。Googlebot 會依適用規則管理請求，也可能使用已快取的 robots.txt；不能假設每次抓取頁面前都重新下載。其他爬蟲是否遵守與如何解讀，須看各自規範。

robots.txt 管理爬取，不是一般網頁的索引移除工具。若大型網站產生大量不必要的網址，可先查看日誌與抓取狀況，再評估限制路徑。這與爬取預算管理有關，但封鎖某些網址不保證其他頁面因此更快被索引。

小型網站通常不必優先處理爬取預算，但仍應排查伺服器錯誤、存取限制與網址發現問題。頁數少不保證 Google 一定抓完；是否調整 robots.txt，應依實際請求與頁面用途判斷。

noindex 管的是「抓到了要不要收進資料庫」

noindex 的角色完全不同。它是一個放在頁面「裡面」的指令，可以是 HTML 的 meta robots 標籤，也可以是 HTTP 回應標頭的 X-Robots-Tag。它對爬蟲說的是：「你可以進來看，但這一頁不要收進搜尋結果。」

換句話說，noindex 作用在「索引」這個階段，而且前提是爬蟲已經成功抓到了這個頁面的內容，才有機會讀到這個指令。這就是兩者最大的分水嶺：robots.txt 擋在門外，noindex 貼在門內。一個讓爬蟲進不來，一個等爬蟲進來了才生效。

把矛盾拆開看：封鎖爬取，等於把 noindex 藏起來

把兩者疊在一起，矛盾就清楚了。假設你在 robots.txt 對 /thank-you 下了 Disallow，同時在這個頁面放了 noindex。接下來會發生什麼事？

若 Googlebot 套用的 robots.txt 規則封鎖 /thank-you，它不會藉由抓取該頁讀到新設的 noindex。先前的索引紀錄或其他來源的連結，仍可能讓網址存在於搜尋結果。

關鍵是同一網址的讀取條件：封鎖仍生效時，Google 無法從頁面回應確認新設的 noindex。兩者可以在同站的不同路徑使用；要靠 noindex 排除公開頁面索引，就必須讓指令可被讀取。

因此，要另外確認網址是否已被索引，不能只憑「抓不到內容」推定它不會出現在結果。

那為什麼被封鎖的頁面還是會出現在搜尋結果？

很多人以為「若 robots.txt 封鎖了，Google 就完全不知道這個網址存在」。這是最大的誤解。Google 認識一個網址的途徑，從來不僅有自己爬到這一條，還包括：從別的頁面的內部連結發現、從外部網站的反向連結得知、從你提交的 XML Sitemap 裡看到、或是過去曾經抓過而留有紀錄。

Google 可能知道某個網址，卻無法抓取目前內容。這個網址仍可能出現在結果，並使用其他公開資訊，例如指向它的連結文字；因此不能斷言結果一定只有網址、完全沒有標題。

你可以把這件事想成：Google 對一個網址的「發現」和「讀取」是兩回事。Google 可以從連結或 sitemap 發現網址；要理解頁面內容，則需要允許爬取。robots.txt 封鎖讀取，卻不保證網址不被索引，因此網址仍可能以沒有摘要的形式出現。

可用 Search Console 檢查是否有已索引、但抓取受到 robots.txt 限制的網址，並核對資料日期。網頁收錄查詢整理了不同檢查方式；報表中的封鎖狀態本身，不代表已完成索引移除。

robots.txt 不會封鎖一般訪客。即使 Google 不能抓取，使用者仍可能直接開啟網址看到完整內容；要保護非公開資訊，必須另外使用登入與權限控制。

Google 在 2019 年早就把 robots.txt 裡的 noindex 拔掉了

Google 早期的解析器曾處理未正式規範的 robots.txt noindex 寫法，但這不是現在可用的索引設定方式。

Google 在 2019 年公告停止支援 robots.txt 中未正式規範的解析規則，例如 crawl-delay、nofollow 與 noindex。現在要設定 noindex，應使用 HTML meta 或 X-Robots-Tag，不能寫成 robots.txt 的 Noindex 行；現行規則可參考Google robots.txt 規格。

這代表什麼？如果你今天還在 robots.txt 裡寫 Noindex: /private/ 這種語法，Google 會直接無視這一行，把它當雜訊處理。你以為設了保護，其實什麼保護都沒發生。正因如此，理解 Google 這幾年對爬取與索引流程的調整，比你死背 robots.txt 語法更重要。語法會被棄用，但「爬取」和「收錄」是兩個獨立階段這個底層邏輯，從來沒變過。

另一個背景是，Google 在 2023 年正式宣告行動優先索引（mobile-first indexing）已全面到位，主要使用手機版內容進行索引與排序。這描述的是索引來源，不是額外排名加分；若行動版與桌機版分開提供，兩邊的 robots meta 設定應保持一致。

meta robots 和 X-Robots-Tag：兩種 noindex，到底差在哪

既然 noindex 才是控制收錄的正確工具，那它到底有幾種寫法？本質上來說就兩種，差別在於「指令放在哪一層」。搞懂這個分別，你才知道每種頁面該用哪一種，才不會明明設對了概念，卻敗在實作位置。

meta robots 標籤：貼在單一 HTML 頁面裡

第一種是放在 HTML <head> 的 <meta name="robots" content="noindex">。可由單頁設定輸出，也可透過 CMS 範本或網站程式套用整類頁面；適用的是 HTML，並不限於少量頁面。

X-Robots-Tag：寫在伺服器回應標頭

第二種是在 HTTP 回應輸出 X-Robots-Tag: noindex。除了 HTML，也能用於 PDF 等非 HTML 資源。可針對單一網址或一組符合條件的檔案設定；規則語法取決於伺服器或應用程式，設定後要抽查目標與例外網址。

↔ 左右捲動檢視完整表格

比較項目	meta robots 標籤	X-Robots-Tag
生效位置	HTML 頁面的 head 區塊	伺服器回應的 HTTP 標頭
適用資源	僅 HTML 頁面	HTML、PDF、圖片、API 回應皆可
控制粒度	可單頁，也可由 CMS 範本或程式批次輸出	可單頁，也可用規則批次套用整個路徑
設定門檻	低，CMS 外掛多半支援	中，需要動伺服器或程式層設定
常見踩雷點	被快取或被主題覆蓋而失效	CDN 快取住舊標頭，改了看不到效果

兩種寫法對 Google 的 noindex 效果相同，依資源類型與你能控制的輸出層選擇。兩者都能精確到單一網址，也能批次套用；同站使用不同方式時，仍應核對最終回應是否符合預期。

這個錯誤最常出現的五個場景

講了這麼多機制，我們來看實務上最容易踩雷的五種頁面類型。你會發現，幾乎每一種都是「本來想保護、結果搞砸了」的典型。

場景一：開發中的預覽環境與測試頁

測試環境若含未公開資料，應先使用登入與權限隔離。只放 robots.txt 或 noindex，不能阻止訪客直接存取；網址也可能由公開連結曝光。網站搬家與改版時，另外檢查正式站是否誤帶測試環境的存取限制與索引設定。

場景二：分頁與篩選器產生的參數網址

篩選網址要先判斷是否有獨立內容與搜尋用途。高度重複版本可評估canonical；限制抓取前，應替重要商品保留其他可爬取的導覽路徑，不能一律指向主分類頁。可搭配重複內容指南與查詢參數說明檢查。

場景三：結帳、登入、會員專屬頁面

購物車、結帳與會員頁的設定應依是否含私人資料而定。私人內容先用身分驗證保護；公開但不宜成為搜尋入口的頁面可用 noindex，並讓 Google 能讀取指令。不能為了移除索引而把原本受保護的私人內容開放給爬蟲。

場景四：分頁（pagination）的第二頁之後

清單頁的分頁 ?page=2、?page=3 不宜直接套用一條規則。Google 建議每一頁使用獨立網址與 self-canonical，不要把後續頁全部 canonical 到第 1 頁。若分頁是發現深層文章或商品的重要路徑，也不該一律 noindex；先確保分頁間有可爬取的 HTML 連結，再搭配網站架構優化檢視。

場景五：需要重新評估用途的舊頁面

標籤頁、作者頁或過期活動頁，不應只按字數決定 noindex。先確認它是否仍有獨立用途，再選擇更新、整合、刪除，或保留公開內容但排除索引。可用網站爬蟲工具盤點回應狀態與指令，再人工判斷內容。

一張表決定你到底該用哪一個

看完五個場景，你大概已經隱約抓到判斷邏輯了。這裡把它濃縮成一張決策表，未來遇到任何一個頁面，照著問自己「這個頁面要的是什麼」就能定案。

↔ 左右捲動檢視完整表格

你的目標	該用的工具	背後的原因
保留公開頁面但排除索引	noindex（允許爬取）	Google 必須抓到頁面，才能讀到 noindex 並執行下架
阻止爬蟲浪費時間在無價值路徑	robots.txt Disallow	限制指定路徑的抓取，不保證其他網址更快索引
處理重複或近似內容	canonical	提示偏好版本；Google 仍可能選擇其他標準網址
短期維修中的頁面	HTTP 503	表示暫時不可用，可搭配 Retry-After；持續過久仍會影響索引
永久刪除的頁面	無替代頁回傳 404 或 410；有對應替代頁可評估 301	明確告訴 Google 這網址已不存在或已搬家，比封鎖更直接

核心原則是：不要用爬取控制取代索引控制。想控制搜尋索引，應使用 noindex、登入限制、刪除或適當的 HTTP 狀態碼；想限制爬蟲存取路徑，才使用 robots.txt。兩者作用層級不同，設定前應先確認目標是減少爬取，還是讓網址退出索引。

如何幫網站做「不收錄」設定：一套可重複的流程

知道該用什麼之後，還要穩定落實。下面是一套可重複使用的流程。

第一步：先釐清這個頁面要不要被爬、要不要被收錄

很多設定錯誤，根源是沒想清楚頁面的定位。問自己兩件事：這個頁面需不需要被爬蟲抓到內容？需不需要出現在搜尋結果？答案組合不同，工具就不同。「不要出現但可以被抓」用 noindex，「連抓都不必」才用 robots.txt，「兩者都不要」通常代表這個頁面根本不該存在於公開網址上。把這層分類想清楚，後面的設定才不會亂。

第二步：使用 noindex 的公開網址，保留讀取指令的通道

如果頁面允許爬蟲讀取內容、僅是不要被收錄，HTML 頁面可在 <head> 裡加上 <meta name="robots" content="noindex">；非 HTML 資源則在伺服器回應標頭加上 X-Robots-Tag: noindex。follow 是預設值，沒有必要特別寫出來；頁面長期 noindex 後，Google 的爬取頻率仍可能下降，因此重要內容不應僅靠這類頁面連到。更多做法可以參考不被索引的方法整理。

第三步：依抓取需求設定 robots.txt

robots.txt 可管理不必要的抓取路徑，例如大量篩選組合。設定前檢查範圍，保留 Google 理解頁面所需的資源，以及找到重要內容的路徑。私人資料應用登入與權限保護；robots.txt 不是強制存取控制。

第四步：大型網站管理參數網址與 Sitemap

如果是參數爆炸的大網站，單靠 robots.txt 或 noindex 會管不過來。Search Console 的網址參數工具已在 2022 年退場，現在要從參數網址的生成、站內連結、canonical 與 robots.txt 規則一起處理，再用乾淨的網站 Sitemap列出希望索引的標準網址。把「該收的」列清楚，也要避免系統持續產生無限網址。

CMS 自動幫你生的 robots.txt，是另一個隱形地雷

還有一個容易漏查的情況：robots.txt 可能由 CMS、主機平台或 SEO 外掛動態回應，不一定對應網站根目錄裡的實體檔案。因此，檢查時應直接開啟網站實際提供的 /robots.txt，不要僅看伺服器上的檔案清單。

麻煩在於你可能不知道 CMS 正在輸出哪些預設規則。若根目錄已有實體 robots.txt，多數環境會直接提供該檔案，不再走 CMS 的虛擬回應；實際行為仍取決於伺服器設定。不要僅看後台選項，直接開啟網站根目錄的 /robots.txt，確認外部爬蟲真正收到的內容。

實務上的習慣是，碰到任何 robots.txt 的排查，第一步永遠是直接用瀏覽器打開 你的網域/robots.txt，看真實回應的內容長什麼樣，別急著去翻伺服器上的檔案。這兩者在 CMS 環境裡經常不一致。確認過真實回應之後，再決定要改外掛設定、還是上傳實體檔案覆蓋。把這個動作養成反射動作，能幫你省下大量「為什麼改了沒效」的除錯時間。

驗證設定到底有沒有生效

設定做完不等於做完，你得驗證 Google 真的讀懂了你的意思。這一步很多人省略，結果設了等於沒設，問題三個月後才爆發。下面三個檢查方法，是每次設定完都值得跑一遍的。

用網址檢查工具即時確認狀態

在網址檢查工具（URL Inspection）比較已索引版本的抓取日期、爬取限制與索引結果，再以即時測試查看目前回應。即時測試通過不代表已經收錄，也不能預測 Google 最終選擇的 canonical。初次操作可看Search Console 基本介紹。

用索引報表掌握全站收錄健康度

網頁索引報表可按索引狀態與原因抽查網址，例如遭 robots.txt 封鎖、偵測到 noindex 或重複版本。它的更新與範例數量有限，不能當成完整即時清單；重要網址仍須單獨核對。更多用法見Search Console 進階技巧。

用瀏覽器開發者工具檢查回應標頭

使用F12 開發者工具的 Network 面板查看目標請求的 Response Headers，確認 X-Robots-Tag 是否符合設定。若與伺服器設定不同，再檢查應用程式、代理與 CDN 快取；是否快取舊標頭取決於實際規則，不能只因用了 CDN 就判定原因。

noindex 生效的時間表：為什麼它不是立刻見效

新增 noindex 後仍看到搜尋結果，可能是 Google 尚未重新處理，也可能是指令或抓取條件有問題。先核對輸出、robots.txt 與抓取日期，再判斷是否需要等待，避免把設定錯誤一律當成時間差。

Google 重新抓取網址的時間沒有固定保證，會受網址重要性、更新訊號、伺服器狀況與 Google 的排程影響。noindex 必須等 Google 再次抓取並讀到指令後，才會反映在索引中；若需要較快暫時隱藏自己管理的網址，可使用 Search Console「移除」工具，效果通常維持約六個月，但仍應同步刪除內容、設定 noindex、加上存取限制或回傳適當狀態碼，才能處理長期結果。

移除 noindex 後，Google 仍需重新抓取與評估頁面，恢復索引沒有固定保證。這不是需要重新累積「信任」的處罰；應核對內容、存取與 canonical 是否符合預期。可在SEO 年度盤點中保留 noindex 清單，定期確認每個設定的用途。

四個常見問答，把剩下的疑問收尾

那能不能同時下 noindex 又保留 robots.txt 允許爬取？

這才是正確的組合。允許爬取（不在 robots.txt 封鎖）加上 noindex，等於對 Google 說「你來看、你看完、但這一頁不要收進搜尋結果」。這個組合完全沒有衝突，而且是處理「不要收錄」最標準的做法。會打架的，永遠是「封鎖爬取」加「期望 noindex 生效」這組。把這個區別記住，你就不會再把兩個工具搞混。

已經被封鎖又收錄的頁面，要怎麼救？

若已索引網址又被 robots.txt 封鎖，先核對內容是否可公開。適合使用 noindex 的公開頁面，應解除相應抓取限制、輸出指令並等待重新處理；比對 URL 檢查中的抓取日期與即時測試，不假定一定出現某個過渡狀態。

noindex 會不會傷害頁面或網站其他頁面的排名？

noindex 針對單一頁面，不會因為這個指令而對整站施加處罰。follow 本來就是預設值，不寫也不等於切斷連結；但頁面長期 noindex 後，Google 可能降低爬取頻率，所以重要內部連結仍應放在可索引、會持續被爬取的頁面上。連結如何安排，可以進一步看內部連結的完整解析。

noindex 和 canonical 可以同時用在同一個頁面嗎？

noindex 控制索引資格，canonical 提示重複內容的偏好版本。Google 不建議用 noindex 來阻止選取某個站內 canonical；若要整合版本，應維持內容與各種訊號一致，不能假定固定的先後處理順序。詳見canonical 的用途與限制。

Google AI 搜尋的索引資格與控制範圍

這幾年搜尋生態正在快速轉變，Google AI Overviews 與各類生成式搜尋逐漸成為讀者獲取答案的新入口。這對 robots.txt 與 noindex 的選擇，多了一層你必須知道的影響。

Google 說明，頁面要成為 AI Overviews 或 AI Mode 的支援連結，必須可被索引、符合一般搜尋技術要求，且能顯示摘要。若 robots.txt 阻止 Googlebot 抓取內容，頁面就無法靠該內容取得支援連結資格；但網址本身仍可能以沒有摘要的形式被索引。因此，robots.txt 既不是搜尋結果移除工具，也不是機密內容的保護措施。

Google 讀取並處理 noindex 後，頁面不再符合 AI Overviews 與 AI Mode 支援連結的索引資格。其他 AI 產品可能使用不同爬蟲與規則，不能由此推論全部產品都不會讀取。真正需要隔離的資料仍應使用驗證與權限控管；相關概念可搭配爬取、索引與檢索的差異閱讀。

一個對照範例：錯誤與正確的設定長什麼樣

以下是公開且不含個人訂單資料的通用感謝頁示例，網址為 /checkout/thank-you。頁面仍供訪客開啟，但不希望它成為搜尋入口；含私人資料的結帳頁應另外使用權限保護。

錯誤做法（雙重保險的反效果）：
robots.txt 寫 Disallow: /checkout/thank-you，同時頁面放 noindex。
結果：Googlebot 不爬這頁，noindex 讀不到；頁面仍可能以「僅有網址」的狀態被收錄。

正確做法（讓 noindex 真正生效）：
robots.txt 不要封鎖這條路徑，頁面放 <meta name="robots" content="noindex, follow">。
結果：Googlebot 正常爬取、讀到 noindex、把頁面從索引移除；follow 是預設值，不能保證任何固定的連結權重；私人結帳資料另需權限保護。

這個範例雖然簡單，卻濃縮了整篇文章的核心：把爬取通道留給 noindex，讓收錄指令有機會被讀到。若這個原則顧住，其他頁面類型都能用同一套邏輯推導出正確設定。

現在就動手：四步檢查清單

讀到這裡，理論讀再多，都不如現在就打開自己的網站做一遍。接下來這四步，是建議你今天就完成的動作。

1. 盤點你的 robots.txt。打開 /robots.txt，把每一條 Disallow 拿出來問自己：這條路徑是要管理爬取，還是其實是想讓它不要被收錄？後者請改用 noindex。若要確認全站有哪些頁面受影響，可用網站爬蟲工具協助盤點。
2. 檢查「被封鎖但已索引」的網址。進 Google Search Console 的索引報表，找出那些被 robots.txt 封鎖卻仍被收錄的網址，這就是你的優先修復清單。
3. 依內容用途修正設定。公開且需保留的頁面可用 meta robots 或 X-Robots-Tag 排除索引，並讓 Google 能讀取指令。私人內容維持權限保護；已刪除頁面則使用適當 HTTP 狀態碼。
4. 用網址檢查工具驗證。針對你改過的每一個網址，用網址檢查工具確認 Google 回報的狀態符合你的預期：允許爬取、偵測到 noindex、接著逐步從索引移除。

保留每次修改的網址範圍、預期結果與驗證日期。把抓取回應、頁面指令與索引資料分開記錄，才能確認限制是否生效，以及 Google 是否已重新處理。

把這件事弄對，是技術 SEO 最基本、也最容易被低估的功夫之一。如果你正在系統性地整理網站的技術體質，站內 SEO 的整體框架可以從這篇站內 SEO 完整攻略開始，把 robots.txt、noindex、canonical 標籤、HTTPS、sitemap 這些技術環節串成一條完整的線。技術 SEO 從來不是單點的設定，而是一套彼此牽動的系統，搞懂其中一個環節，往往能順手解掉其他兩三個你以為不相關的問題。把爬取和收錄的界線畫清楚，就是這條線上最關鍵的第一個結，解開它，後面的設定會變得清爽許多。