最常見的一個致命誤會是：想讓某頁從搜尋結果消失，就跑去 robots.txt 加一條 Disallow。結果恰恰相反，這頁可能繼續留在搜尋結果裡，只是沒了描述。原因在於 robots.txt 管的是「爬蟲能不能來抓」，noindex 管的是「這頁能不能被列進搜尋結果」，兩者作用在完全不同的階段。分不清這條界線，就會出現該擋的沒擋、不該擋的擋了的窘境。這篇我們把兩者的分工、各自的使用時機，以及那些我們實際救過的誤設案例講清楚，讓你在放行或封鎖任何一條路徑之前，知道自己到底在對搜尋引擎說什麼。

1. robots.txt 管的是抓取，noindex 管的是收錄

要用對這兩個工具，得先分清楚它們作用在搜尋引擎流程的哪一段。抓取和收錄是兩個不同的階段，對應的控制手段也不一樣。搞混這一點，是後面所有災難的起點。

1.1 兩者作用的階段完全不同

robots.txt 控制的是「爬蟲能不能來抓這個網址」，它擋在抓取這一關；noindex 控制的是「這一頁能不能出現在搜尋結果」，它作用在收錄這一關。一個管門口，一個管櫥窗。理解這個差別，你才會明白為什麼有些頁面明明用 robots.txt 擋了，卻還是出現在搜尋結果裡：門口雖然攔住了爬蟲，但搜尋引擎可以從別的頁面的連結知道這個網址存在，仍然把它的網址列進結果，只是因為沒抓到內容，列出來時沒有描述。

把搜尋引擎處理一個頁面的流程想成一條產線會更清楚：第一站是抓取，爬蟲把頁面內容讀進來；第二站是索引，搜尋引擎決定要不要把它放進資料庫、列進搜尋結果。robots.txt 作用在第一站的入口，noindex 則是一張貼在貨物上的標籤，要爬蟲讀到貨物之後才看得到。如果你在第一站就把爬蟲擋下來，那張貼在第二站才生效的標籤，根本沒機會被讀到。這就是為什麼這兩個工具不能混用、也不能互相替代。

1.2 用 robots.txt 擋收錄是最常見的誤解

很多人想把某頁從搜尋結果拿掉，直覺就是去 robots.txt 加一條 Disallow。問題是，robots.txt 只是請爬蟲不要來抓，它並沒有說「不要收錄」。當這頁被其他頁面連結、搜尋引擎從外部知道它的存在時，它仍可能以一個沒有描述的樣子被列進搜尋結果。更糟的是，因為你擋住了抓取，搜尋引擎讀不到頁面裡的 noindex，反而讓 noindex 失效。想讓一頁不被收錄，正確做法是放行抓取、在頁面裡放 noindex，讓爬蟲讀到後把它移除。

1.3 兩個工具的分工對照

比較項目	robots.txt Disallow	noindex
作用階段	抓取（要不要來讀）	收錄（要不要列進搜尋結果）
放置位置	網站根目錄的 /robots.txt	頁面的 meta 標籤或 HTTP 標頭
能否阻止出現在搜尋結果	不能保證，仍可能被列出	可以，爬蟲讀到後會移出
前提條件	無	該頁必須允許被抓取，爬蟲才讀得到
適合對象	大量無意義網址、後台資源	不希望收錄但需被讀取的頁面

1.4 一個常被忽略的推論：要 noindex 生效，就不能擋抓取

從上面的分工可以推出一個結論，卻是我們診斷案例時最常看到的矛盾：要讓 noindex 生效，前提是爬蟲讀得到這一頁，也就是不能同時用 robots.txt 把它擋在門外。很多人出於謹慎，兩個都用，以為雙保險更安全，實際上是把 noindex 自己廢掉。這個推論看似簡單，但在真實的設定檔裡，它往往藏在兩個不同檔案、由不同人維護，衝突就這樣悄悄形成。

我們在一次診斷裡就碰到這種配置。客戶想把一批過期的活動頁從搜尋結果移除，工程端在 robots.txt 加了 Disallow 擋掉那個目錄，內容端又在每頁掛了 noindex，雙方都以為自己把事情辦妥了。實際上這批頁面在搜尋結果裡一直沒消失，因為爬蟲被擋在門外，永遠讀不到那行 noindex。後來我們把 robots.txt 的那條 Disallow 拿掉，放行抓取，讓爬蟲重新讀到 noindex，過了一段時間這些頁面才陸續退出搜尋結果。這個案例很能說明，兩個工具各有職責，疊在一起不是更保險，而是互相抵銷。

2. robots.txt 該開放什麼、該封鎖什麼

robots.txt 的原則其實只有一句：凡是你希望帶來流量的內容，路徑一律開放；凡是純功能性、對搜尋沒有價值的路徑，才考慮封鎖。把這句話記牢，大半的設定判斷就有了依據。

2.1 主要內容路徑一律保持開放

文章、產品、服務、分類這些會被搜尋、也應該被搜尋到的頁面，它們的路徑絕對不能被 robots.txt 擋住。這聽起來是常識，但我們在診斷時仍常遇到因為一條範圍過大的規則，把整個內容目錄一起掃進封鎖名單的情況。每次改動 robots.txt，我們都會反問一句：這條規則除了我想擋的，有沒有順手擋掉別的。這個習慣救過不少網站，因為一條看似無害的萬用規則，往往在你看不到的地方連累了一整批該被收錄的頁面。

2.2 後台、登入、購物車這類路徑才該封鎖

該擋的是那些對搜尋引擎沒有意義、甚至涉及隱私的路徑，例如後台管理、登入頁、購物車、站內搜尋結果頁。這些頁面被抓取只會浪費爬蟲的預算，也不會替你帶來任何搜尋流量。把它們擋掉，反而能讓爬蟲把資源留給真正重要的內容。我們的習慣是把要擋的路徑列得明確、範圍小，而不是用一條大範圍規則圖方便，那往往是災難的開始。

要特別提醒一點：robots.txt 不是用來藏機密的工具。它的內容是公開的，任何人都能打開來看，把敏感路徑列在裡面，等於昭告它們的位置。真正需要保護的內容，該靠權限控管或登入機制擋住，而不是指望 robots.txt 讓爬蟲繞道。robots.txt 處理的是「哪些路徑值不值得被抓」，不是「哪些路徑不能被看到」，這兩件事要分開想。

2.3 一份中規中矩的 robots.txt 長這樣

User-agent: *
Disallow: /admin/
Disallow: /login
Disallow: /cart

Sitemap: https://example.com/sitemap.xml

這份範例放行了所有主要內容，只擋掉後台、登入與購物車，並在最後指向 sitemap，方便爬蟲找到你希望被收錄的所有網址。我們的建議是 robots.txt 寧可寫得保守一點，擋的路徑列得明確、範圍小，也不要用一條大範圍規則省事。一旦寫出範圍過大的封鎖，受影響的頁面往往不是一頁兩頁，而是一整片。

3. noindex 的正確使用時機

noindex 是用來精準地把某些頁面排除在搜尋結果之外，前提是這些頁面仍然可以被抓取。用對地方，它能讓你的收錄清單保持乾淨，把品質訊號集中在真正想被搜尋到的內容上。

3.1 哪些頁面適合掛 noindex

適合 noindex 的，通常是有存在必要、但不需要出現在搜尋結果的頁面。例如站內搜尋結果頁、篩選後產生的重複參數頁、感謝頁、內容過於單薄的自動生成頁。這些頁面若都被收錄，反而會稀釋整站的品質評價。用 noindex 把它們排除，是在替搜尋引擎減少雜訊，讓它更容易判斷你網站的重點在哪裡。我們在協助客戶盤整收錄清單時，常把這類頁面一次圈出來統一處理。

這裡有個容易被忽略的判斷點：該用 noindex 的頁面，和該直接用 robots.txt 擋掉的頁面，其實不完全重疊。差別在於「你想不想讓權重透過它流動」。站內搜尋結果頁、篩選參數頁這類，你通常希望頁面上的連結還能被跟著爬、把權重導向真正的內容頁，這時 noindex 配合 follow 最合適。相對地，後台、購物車這類純功能頁，你連抓都不想讓它抓，直接 robots.txt 擋掉更省爬蟲預算。先想清楚「要不要被讀、要不要傳權重」，工具的選擇就清楚了。

還有一種情況值得單獨提：分頁列表。一個分類底下有幾十頁的商品列表，第二頁之後要不要 noindex，沒有一刀切的答案。我們的做法是看這些分頁本身有沒有獨立的搜尋價值，如果只是同一批內容的延伸、使用者不會直接搜尋到它，適度 noindex 可以讓收錄清單更乾淨；但要記得保留 follow，讓爬蟲仍能透過這些分頁把深層的商品頁都爬到。這種細節沒有標準答案，重點是想清楚每一頁對搜尋的實際價值，再決定怎麼處理。

3.2 robots meta 的標準寫法

最直接的做法，是在該頁的 <head> 裡加一行 meta 標籤：

<meta name="robots" content="noindex, follow">

這裡的 follow 通常保留，意思是「這頁別收錄，但頁面上的連結還是可以跟著爬」，讓連結的權重仍能傳遞下去。相對地，重要頁面一定要反過來確認自己沒有被誤掛 noindex。我們診斷時只要看到主力頁面的 meta robots 出現 noindex，心裡都會先響起警鈴，因為這往往是開發環境的設定殘留到了正式站。

3.3 非 HTML 檔案改用 HTTP 標頭控制

meta 標籤只能放在 HTML 裡，遇到 PDF、圖片這類非 HTML 檔案就派不上用場。這時要改用 HTTP 回應標頭：

X-Robots-Tag: noindex

它的效果和 meta robots 相同，但作用在伺服器回應的層級，能套用在任何檔案類型上。很多人不知道有這個選項，結果讓一堆本該排除的 PDF 悄悄進了搜尋結果。如果你的網站有大量不想被收錄的文件檔，這個標頭值得納入上線檢查的固定項目。

4. 我們看過最容易釀成災難的兩種設定錯誤

這一節講的都是真實會發生、而且代價很高的錯誤。它們的共通點是「一行設定，全站受害」，而且往往拖了好幾週才被發現，因為網站表面上一切正常。我們之所以反覆強調上線檢查，正是因為這些錯誤的代價不對稱：設定只花一秒，修復與等收錄回穩卻要耗上數週，中間流失的流量再也補不回來。

4.1 一條 Disallow 誤封整個網站

最經典的意外，是 robots.txt 裡出現這一行：

User-agent: *
Disallow: /

這一斜線代表封鎖全站，爬蟲從此不再抓取任何頁面。它常常是從測試環境的設定檔一路帶上正式站的。我們遇過一個客戶流量連續兩週緩跌，查到最後就是上線時把測試站的 robots.txt 原封不動搬了過來。改回來之後花了不少時間才等收錄慢慢回穩，這種代價完全可以在上線前一次檢查就避免。這類錯誤最麻煩的地方在於，它不會跳出任何錯誤訊息，網站照常運作，只有搜尋流量默默消失。

除了整條斜線，另一種變形更難察覺：規則寫得太寬。例如本來只想擋掉某個參數頁，卻用了一條涵蓋範圍過大的路徑規則，結果把整個產品目錄一起掃進去。這種錯誤不像 Disallow: / 那樣一眼就看得出來，它只擋掉一部分頁面，流量是分批、緩慢地流失，更容易被當成季節性波動而忽略。我們的建議是每條 Disallow 都盡量指向明確、具體的路徑，能列單一路徑就不要用萬用寫法，範圍越小，誤傷的機率越低。

4.2 上線忘了拿掉測試站的全站 noindex

另一個常見錯誤，發生在 noindex 這一側。開發階段為了不讓測試站被收錄，常會在全站模板掛上 noindex，這本身是對的。麻煩的是正式上線時忘了拿掉，於是整個正式站對搜尋引擎宣告「請不要收錄我」。這種錯誤最陰險的地方在於，網站表面上一切正常，使用者瀏覽毫無異狀，只有搜尋流量默默歸零。所以我們把「移除全站 noindex」列為上線檢查清單的固定一項，不靠記憶。

4.3 又用 robots.txt 擋、又想靠 noindex 的自相矛盾

還有一種是邏輯打架：想讓某頁不被收錄，於是同時在 robots.txt 擋它、又在頁面掛 noindex。結果是爬蟲被 robots.txt 擋在門外，根本讀不到頁面裡的 noindex，noindex 自然失效，這頁反而可能繼續掛在搜尋結果上。要 noindex 生效，就得放行抓取，兩件事只能擇一，不能疊加。這也是第一節那個推論在實務上最常見的翻車方式。

5. 上線前的 robots 與索引驗收

前面那些災難，幾乎都能靠一套固定的上線前檢查擋下來。我們把它壓縮成三個動作，不需要花俏工具。

5.1 直接抓取 robots.txt 確認狀態與規則

打開 https://example.com/robots.txt，先確認它回應 200、內容讀得到，再逐行看規則。重點是確認沒有 Disallow: / 這種全站封鎖，也沒有把內容目錄整個掃進去。這一步花不到一分鐘，卻能擋掉最嚴重的那類事故。我們會養成習慣，每次重大改版後都親手打開這個網址看一眼，而不是假設它沒被動過。

逐行看的時候，除了找明顯的全站封鎖，也要留意那些範圍模糊的規則。一條看起來只擋某個資料夾的 Disallow，可能因為路徑寫法的關係，實際涵蓋的範圍比你想的大。遇到拿不準的規則，可以用搜尋主控台的 robots.txt 測試功能，輸入幾個你希望被收錄的重要網址，確認它們都是被允許的。把主力內容頁一個個試過，比單憑肉眼讀規則更不容易漏掉意外的封鎖。

5.2 抽樣檢查主要模板的 meta robots

用檢視原始碼，分別抽首頁、列表頁、詳情頁，搜尋頁面裡有沒有 noindex 字樣。主力頁面出現 noindex 就是紅燈，要立刻追查是不是測試設定殘留。這一步和 robots.txt 的檢查互補：一個看抓取、一個看收錄，兩關都過才算安全。特別提醒，要看的是機器實際讀到的原始碼，不是瀏覽器渲染後的結果，兩者有時並不一致。

5.3 用搜尋主控台交叉確認實際狀態

設定對不對，最終要以搜尋引擎的認定為準。我們會用 Google Search Console 的網址檢查，看它回報這頁是「可被索引」還是被某條規則擋住，再對照自己的預期。工具說的和你以為的不一致時，以工具為準去追原因。這一步能抓到那些肉眼看不出、卻真實影響收錄的設定衝突，例如某個上層目錄的規則意外涵蓋了這一頁。

我們還會善用搜尋主控台的涵蓋範圍報告，把被標為「已封鎖」或「已找到但尚未索引」的頁面清單拉出來掃一遍。這份清單常常藏著意外：本該被收錄的主力頁出現在封鎖名單裡，或是一堆該排除的參數頁反而被收了進去。report 看的是搜尋引擎實際的處理結果，比你憑記憶推測設定對不對可靠得多。我們的習慣是把這份報告當成上線後幾週的固定觀察項，而不是等流量出事了才回頭查。

6. 常見問題

6.1 用 robots.txt 擋住的頁面，為什麼還是出現在搜尋結果

因為 robots.txt 只管抓取、不管收錄。當這頁被別的頁面連到，搜尋引擎就算沒抓內容，也可能把這個網址列進結果，只是沒有描述。想讓它完全不出現，要放行抓取並在頁面掛 noindex，讓爬蟲讀到後把它移除。

6.2 我想讓一頁不被收錄，該用 robots.txt 還是 noindex

用 noindex，而且要確保這頁沒被 robots.txt 擋住。noindex 是明確告訴搜尋引擎不要列出這頁，但前提是爬蟲讀得到它。兩者同時使用反而會讓 noindex 失效，這是最常見的誤用。如果這頁上的連結還想讓爬蟲跟著爬、把權重傳遞下去，記得用 noindex, follow。

6.3 robots.txt 要放在網站的哪個位置

它必須放在網域根目錄，也就是 https://example.com/robots.txt，而且要能回應 200。放在子目錄或回應錯誤狀態碼，搜尋引擎都不會採用。上線前直接在瀏覽器打開這個網址確認，是最保險的做法。另外要注意子網域各自獨立，部落格若掛在不同的子網域，它需要有自己的 robots.txt，主網域那份管不到它。

6.4 全站流量突然大跌，第一個該檢查什麼

先看 robots.txt 有沒有出現 Disallow: /，再抽查主要模板的原始碼有沒有殘留 noindex。這兩個是上線意外最常見的來源，也最容易在搬移設定時被一起帶過來。排除這兩項之後，再往其他方向查，例如伺服器回應的狀態碼、近期有沒有改過網址結構。先從最常見、影響最大的兩項查起，能省下很多冤枉路。

6.5 PDF 或圖片這類檔案要怎麼設 noindex

這類非 HTML 檔案放不了 meta 標籤，要改用 HTTP 回應標頭 X-Robots-Tag: noindex，在伺服器層級控制。效果和頁面裡的 meta robots 一樣，能套用在任何檔案類型上。如果站上有大量這類文件，建議把它納入固定的上線檢查。同樣要注意的是，這個標頭也要確保該檔案沒被 robots.txt 擋住，否則爬蟲讀不到標頭，排除一樣不會生效，道理和頁面的 noindex 完全一致。

6.6 改了設定之後，多久會看到搜尋結果的變化

沒有固定時程。無論是移除 noindex 還是放開 robots.txt 的封鎖，都要等搜尋引擎重新抓取與評估，才會反映在搜尋結果上，可能是幾天也可能更久。改完之後別因為隔天沒動靜就反覆調整，可以用搜尋主控台的網址檢查追蹤它重新抓取後的狀態，比盲等更有依據。