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

想像一個畫面：你花了一整個下午，把網站上一堆測試頁、後台頁面、過期的活動頁，通通在 robots.txt 裡加上 Disallow，還很謹慎地在每個頁面的 meta 標籤補了 noindex。你心想，雙重保險，總該萬無一失了吧。結果隔週打開 Google 搜尋你的網站，那幾個頁面還是赫然出現在結果裡，標題列僅剩一行冷冰冰的網址，什麼描述都沒有。

這不是 Google 出包，而是你踩中了 技術 SEO 裡最經典、也最反直覺的一個陷阱：robots.txt 與 noindex，根本不能同時對同一個頁面發揮作用。換句話說，當你在 robots.txt 封鎖了某個網址，Googlebot 連進去讀那個頁面的機會都沒有，noindex 這張「禁止收錄」的便條紙，就永遠貼不上去。

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

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

• robots.txt 控制爬取，noindex 控制收錄，是兩個不同階段的事。一個站在門外，一個貼在門內。
• 用 robots.txt 封鎖，Googlebot 看不到頁面上的 noindex，noindex 因此完全無效。
• 被封鎖的頁面仍可能被「僅收網址、不收內容」的方式收進索引，反而留下更難看的搜尋結果。
• 正確做法是：要下架就用 noindex 且允許爬取；要省爬取預算，才用 robots.txt。
• Google 自 2019 年起，已不再支援寫在 robots.txt 裡的 noindex 指令。

一個被「安全感」綁架的真實情境

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

問題是，這份「保險」正好是讓問題發生的原因。直覺錯在哪？錯在你把兩個作用階段完全不同的工具，當成同一件事的兩道鎖。現實裡，門上掛兩道鎖確實更安全，但在 Google 的爬取與索引流程裡，第一道鎖（封鎖爬取）會直接讓第二道鎖（禁止收錄）永遠鎖不上。

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

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

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

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

robots.txt 是一份放在網站根目錄的純文字檔案，它的角色像門口的警衛。當 Googlebot（或 Bingbot、其他爬蟲）來到你的網站，第一件事就是讀這份檔案，看哪些路徑可以抓、哪些不能抓。被 Disallow 的網址，爬蟲會選擇不進去抓取內容。

注意一個重點：robots.txt 控制的是「爬取」（crawl），不是「收錄」（index）。它的核心任務是分配爬蟲的時間與資源，也就是和爬取預算（crawl budget）直接相關。大型網站動輒上百萬個網址，如果讓爬蟲把時間花在沒價值的分頁、篩選器組合、參數網址上，真正重要的內容反而排不上隊被抓。robots.txt 的存在，就是把這些低價值路徑擋在門外，讓爬蟲把力氣花在刀口上。

不過這裡有個規模的門檻要先講清楚。對一個僅有幾十頁、幾百頁的小型網站來說，爬取預算根本不是你需要擔心的問題，Google 有充裕的時間把你整站抓完。這種規模下，過度使用 robots.txt 去封鎖頁面，往往弊大於利，因為你真正在意的多半是收錄控制，爬取效率反而是次要問題，而收錄控制應該交給 noindex 處理。robots.txt 大規模封鎖的價值，是在網址量爆炸的中大型網站才會浮現，例如電商平台那種分頁與篩選器組合出成千上萬個網址的情境。所以判斷要不要動 robots.txt 之前，先誠實問自己：你的網站規模，真的到了需要跟 Google 搶爬取時間的地步嗎？多數時候答案是否定的，那就把這份力氣留給 noindex 與內容品質。

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 標籤，Googlebot 從頭到尾都沒讀到。noindex 完全沒有機會發揮作用，等於白貼了。

這就是「不能同時使用」最精確的技術含義：不是兩個指令會打架報錯，而是第一個指令（封鎖爬取）會讓第二個指令（noindex）永遠無法被讀取，結果你以為的雙重保險，其實僅剩第一道、而且是效果最弱的那一道。

為什麼說是最弱的那一道？這就要接著看下一個關鍵問題。

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

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

當 Google 從這些途徑知道某個網址存在，但 robots.txt 不准它進去抓內容時，Google 會做一件讓很多人意想不到的事：它還是可能把這個網址放進索引，僅是僅存網址、不存內容。在搜尋結果上，你會看到這個頁面以一行網址的形式出現，沒有標題、沒有描述片段，因為 Google 從來沒讀過這個頁面的內容，無從生成摘要。

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

這種狀態在 SEO 圈被稱為「被封鎖卻仍被收錄」（indexed though blocked by robots.txt）。Google 在網頁收錄查詢的報表裡也會明確標示這種情況，提醒你「這個網址被封鎖，但我們還是收錄了它」。換句話說，你想用 robots.txt 把頁面從搜尋結果裡徹底抹掉，結果反而得到一個更難看、更沒資訊的搜尋結果列出現。這完全違背你的初衷。

老實說，這正是這個錯誤最折磨人的地方。你以為自己在「隱藏」頁面，其實是在「公開展示一個空的頁面」。讀者點進去看到的是封鎖訊息或空白，對品牌的傷害比好好處理還大。

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

講到這裡，一定有人想問：那直接把 noindex 寫在 robots.txt 檔案裡，總可以吧？畢竟早期 Google 確實支援過這種寫法。

答案是不行，而且早在 2019 年就正式不行了。Google 在當年宣布，不再支援寫在 robots.txt 裡的 Noindex 指令，以及其他幾個過去曾經「能用」的實驗性指令（像是 Noarchive、Nosnippet）。這是 Google 對 robots.txt 規格的一次重大收斂，把它的職責明確限縮在「爬取控制」這一件事上，收錄相關的控制全部交給頁面層級的機制（meta robots、X-Robots-Tag）處理（見 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 的 <meta name="robots" content="noindex">，放在頁面 <head> 區塊裡。它僅對「這一個 HTML 檔案」有效，控制粒度最細，適合用在你能逐一編輯、且數量不多的頁面上，例如特定的感謝頁、某幾篇過時的部落格文章。大多數 CMS 與 SEO 外掛都能讓你針對單篇文章切換 noindex，操作門檻很低。

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

第二種是 HTTP 回應標頭的 X-Robots-Tag。它的優勢是不受頁面類型限制，PDF、試算表、圖片、API 回應這類沒有 <head> 可以塞 meta 標籤的資源，全部都能靠它控制。它也支援用規則一次套用整個資料夾或整組網址，例如在伺服器設定檔裡對 /documents/*.pdf 統一下 noindex，省去逐檔處理的麻煩。如果你經手的網站有大量非 HTML 的可下載資源，X-Robots-Tag 幾乎是唯一可行的選擇。

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

兩種寫法的核心邏輯完全一致：都是告訴爬蟲「抓到了，但這個資源不要收進索引」。差別純粹在於實作層與適用對象。一個實務上的原則是：能精確控制的就用 meta robots，需要批次或非 HTML 資源的就用 X-Robots-Tag，兩者也可以同時存在於同一個網站的不同區塊，互不衝突。

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

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

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

開發團隊最喜歡在 robots.txt 把整個測試網域或 /staging 路徑封鎖，再補上 noindex。問題是，測試環境如果被內部連結、GA 追蹤碼、或第三方抓取意外曝光，Google 一樣可能僅收網址不放內容。更糟的是，測試環境一旦臨時上線又忘記解封，正式內容也會跟著被封鎖。網站搬家與改版期間，這類問題是流量驟降的常見元兇，不少站長在改版上線後才發現整個分類頁被 staging 規則連坐封鎖。

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

電商網站的分類頁常常因為篩選顏色、尺寸、排序方式，跑出幾十種網址組合。很多人直接在 robots.txt 封鎖這些參數網址。但如果這些網址同時是產品頁的內部連結來源，封鎖爬取會讓 Google 更難找到深層產品頁。這種狀況真正該用的是 canonical 標準網址，把收錄權重集中回主分類頁；若某些參數網址確實完全不需要收錄，再單獨用 noindex 處理，但不要把 noindex 與 canonical 疊在同一個頁面上。想更了解重複內容的處理邏輯，可以讀這篇重複內容指南；參數本身的運作，則可以看網址查詢參數的基礎介紹。

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

購物車、結帳流程、會員中心這類頁面，被收錄對搜尋流量毫無價值，還會佔走爬取資源。正確做法是用 noindex 讓 Google 知道「抓到了但別收錄」，千萬別再用 robots.txt 整條封死。整條封死的後果，就是這些頁面可能以「僅有網址」的陽春狀態出現在搜尋結果，反而洩漏了你不想要的 URL 結構，甚至把結帳流程的網址參數攤在陽光下。

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

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

場景五：內容農場式的薄內容頁

網站經營久了，難免累積一批僅有一兩段話的標籤頁、作者檔案頁、過時的活動頁。用 robots.txt 封鎖是最直覺的反應，但這些頁面如果已經被收錄，你要做的是明確告訴 Google「這頁不要收錄」，把它交給 noindex 處理。這時 noindex 才是對的工具。如果不確定全站哪些頁面需要檢查，可用網站爬蟲工具盤點 noindex、canonical 與回應狀態，再人工判斷內容用途。

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

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

你的目標	該用的工具	背後的原因
完全移除已收錄頁面	noindex（允許爬取）	Google 必須抓到頁面，才能讀到 noindex 並執行下架
阻止爬蟲浪費時間在無價值路徑	robots.txt Disallow	把爬取預算留給重要頁面，這才是它真正的職責
處理重複或近似內容	canonical	指定偏好的標準網址並合併重複訊號
短期維修中的頁面	HTTP 503	告訴爬蟲服務暫時不可用，並可搭配 Retry-After
永久刪除的頁面	410 Gone 或 301 轉址	明確告訴 Google 這網址已不存在或已搬家，比封鎖更直接

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

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

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

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

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

第二步：該用 noindex 的，就僅下 noindex，別碰 robots.txt

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

第三步：僅有確認「完全不需要爬蟲進來」時，才動 robots.txt

真正適合 robots.txt Disallow 的，是大量、對搜尋引擎沒有用途且會消耗爬取資源的路徑，例如內部搜尋的無限參數組合或系統產生的暫存網址。後台與機密內容不能僅靠 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 真的讀懂了你的意思。這一步很多人省略，結果設了等於沒設，問題三個月後才爆發。下面三個檢查方法，是每次設定完都值得跑一遍的。

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

打開 Google Search Console，把你想檢查的網址貼進網址檢查工具（URL Inspection）。它會告訴你這個網址目前「允許爬取嗎」「已索引嗎」「Google 最終一次抓取是什麼時候」「偵測到哪些 meta robots 指令」。這是判斷你的 noindex 或 robots.txt 到底有沒有被正確讀取的最快方法。如果你還沒開始用 GSC，先看過Search Console 的基本介紹再回來操作，會踏實很多。

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

單一網址的檢查之外，更要定期看網頁索引報表。這份報表會把全站網址分成「已索引」「已爬取但未索引」「被封鎖但已索引」「重複而未選為標準」等幾個狀態分類。其中「被封鎖但已索引」這一欄，就是今天這個問題的直接證據區。如果這裡的數字不尋常地高，代表你網站上有大量「被 robots.txt 封鎖、卻還是被 Google 收錄」的網址，正是我們今天談的典型錯誤。這份報表也和Search Console 的進階技巧息息相關，值得花時間熟悉。

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

如果你的設定走的是 X-Robots-Tag 這條路（也就是用 HTTP 標頭，不靠 meta 標籤），你可以用瀏覽器的F12 開發者工具，在 Network 面板找到該請求的 Response Headers，確認 x-robots-tag: noindex 確實有被伺服器送出。這一步能抓出「你以為伺服器有設、其實設錯位置或被快取蓋掉」的隱形錯誤。快取 CDN 是 X-Robots-Tag 設定無聲失效的常見兇手，因為它會把舊的標頭快取住，讓你怎麼改伺服器設定都看不到效果。

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

很多站長把 noindex 設下去，隔天就焦急地去搜尋結果翻，發現頁面還在，於是懷疑自己設錯了。其實這幾乎都是時間問題，不是設定問題。noindex 從你貼上去到頁面真正從索引消失，中間隔著一個關鍵動作：Googlebot 必須重新爬取這個頁面，才有機會讀到新的指令。

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

還有一個容易略過的細節：頁面從索引移除之後，如果你哪天又把 noindex 拿掉，Google 並不會自動「記得」它曾經是 noindex。它需要重新爬取、重新評估這個頁面值不值得收錄，整個流程等於從頭來過。所以 noindex 的使用要謹慎：確定不要被收錄再下，不要因為「暫時不想讓人看到」就隨手加上，否則日後想恢復，得花時間把爬取與收錄的信任重新建立回來。這也呼應了 SEO 年度盤點的觀念：定期回頭檢視哪些頁面還掛著 noindex，避免長期遺漏。

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

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

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

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

先解除 robots.txt 的封鎖，讓 Googlebot 能重新抓到頁面內容並讀到 noindex 指令。接著耐心等待 Google 重新爬取，通常需要幾天到幾週不等，視網站權重與爬取頻率而定。等它重新抓取並讀到 noindex 後，頁面才會真正從索引移除。在這之前，你會在網址檢查工具看到「已索引、偵測到 noindex」這種過渡狀態，是正常的，不代表設定失敗。

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

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

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

技術上可以同時存在，但它們在傳遞矛盾的訊號，不建議這麼做。canonical 是在告訴 Google「這個頁面和其他頁面重複，請把權重併到指定的標準網址」；noindex 則是在說「這個頁面不要收錄」。當兩者同時出現，Google 會優先尊重 noindex，直接不收錄這個頁面，於是你本來想透過 canonical 集中權重的目的也跟著落空。正確的分工是：要解決重複內容就用 canonical（搭配允許收錄），要徹底不收錄就用 noindex，兩者各管一件事，不要疊在同一個頁面上。這個細節和canonical 標籤的運作息息相關，搞混了會讓你的權重集中策略無聲失效。

AI 搜尋時代，被封鎖的內容連 AI 也讀不到

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

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

noindex 的影響邊界較精確：Google 必須先爬到指令，才會把頁面排除在搜尋結果之外。被 noindex 的頁面不符合 AI 功能支援連結的索引資格；不要把「Google 曾爬過內容」解讀成內容仍可能被 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. 把該下架的頁面改成 noindex。解除 robots.txt 封鎖，改用 meta robots 的 noindex, follow，或 X-Robots-Tag，然後允許 Googlebot 重新爬取。
4. 用網址檢查工具驗證。針對你改過的每一個網址，用網址檢查工具確認 Google 回報的狀態符合你的預期：允許爬取、偵測到 noindex、接著逐步從索引移除。

SEO 裡有很多工具看似做同一件事，其實各管一段路。robots.txt 和 noindex 正是最經典的一對：一個守在爬取階段，一個守在收錄階段。把它們搞混，不僅達不到你要的效果，還會創造出比什麼都不做更尷尬的搜尋結果。把它們分清楚，你對整個網站「要不要出現在 Google、以什麼姿態出現」的掌控力，會立刻提升一個檔次。

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