頁面該不該留在索引？從診斷到驗收的退場判斷流程

先架一個假設情境：傍晚六點，某家公司的專案負責人收到同事傳來的截圖，客戶在 Google 搜到了放在客戶專區裡的結案報告 PDF，同一個結果頁裡還躺著活動上線前的預覽網址。主管只問一句：今晚能不能處理好？

這種時候才回頭查「不想被索引」該靠哪個指令，多半已經來不及。真正要先決定的不是工具，而是這份內容准不准被陌生人找到：公開範圍想清楚了，被 Google 收錄與否就只是那個決策的結果。noindex、robots.txt、Search Console 的移除功能、登入權限，每一種管轄的範圍都不同，亂抓一把往往越弄越亂。接下來用三個診斷問題分級，走進三層處置，再用兩份資料驗收。全程有一條機制線貫穿：頁面能不能退出搜尋結果，關鍵在網址會不會被發現、指令會不會被讀到；指令本身寫得多重，都幫不上忙。

快速重點：先判公開範圍，再選處置層。可公開但不該收錄的頁面交給 noindex，並保持可爬取；robots.txt 只管爬取，別與 noindex 同頁疊用；外流急件先用移除工具換約六個月緩衝，同步補上長期處理；機密內容上權限或下架，事後用報表與爬蟲驗收。

動手之前，先回答三個診斷問題

處置的強弱不該由手邊的工具決定，該由三個問題決定。第一，這一頁准誰看：所有人、特定對象，還是只有內部？第二，萬一外流，最壞的後果是什麼：只是不夠專業，還是商業機密或個資流出？第三，它現在是否已出現在搜尋結果：這一題決定你在預防還是補救。後果越嚴重、時間越急，處置就往越底層走，從索引指令一路升級到權限圍籬。

開場的情境可以拆成兩個貫穿全篇的案例，兩者常被混為一談，等級其實不同。結案報告 PDF 是第一種：檔案可以留在站上，但被收進搜尋結果就是事故，問題出在「公開卻不可搜」。上線前的預覽網址是第二種：整個環境本來就不該被外人逛到，被收錄只說明圍籬沒關好。同樣一句「不想被索引」，診斷之後會走向不同的處置層。

「准誰看」可以粗分成三級，每一級對應不同的索引期待。給所有人看的行銷頁與文章，目標是被收錄、被找到；給特定對象看的頁面，像活動報名的完成頁或團隊共用的草稿，存在是為了完成任務，不是為了被搜尋；僅限內部與客戶的資料，例如結案文件與下載區，本來就該掛上權限。把每一頁放進這三級，再對照後果欄，處置層幾乎就自己浮出來了。

診斷階段有三個常見誤判，先點破，後面的機制才有意義。其一，把「不想被看到」與「不想被收錄」當成同一件事，於是拿索引指令代替登入權限，結果任何知道網址的人照樣讀得到全文。其二，以為用 robots.txt 擋掉就等於隱形，但封鎖爬取不等於封鎖收錄，網址仍可能以只剩連結文字的形態出現。其三，相信沒有連結指到就不會被發現，可是別人的連結、伺服器紀錄與舊快取都可能成為發現管道。三個誤判漏算的是同一件事：訊號要送得到、網址藏不住，處置必須順著這條機制線設計。

↔ 左右捲動檢視完整表格

最壞後果	目前狀態	對應處置層
不夠專業、尷尬（草稿、感謝頁、測試內容）	尚未被收錄	訊號層：noindex
不夠專業、尷尬	已出現，不急	訊號層：noindex 加等待重新檢索
機密外流（客戶資料、個資、未公開價格）	尚未被收錄	圍籬層：權限或下架
機密外流	已出現且時間急	急停層先隱藏，緩衝期內補圍籬
檢索資源被大量系統頁分食	漸進累積	訊號層：爬取管理與網址收斂

表格先把骨架立起來。三個處置層各自的能力邊界，加上最容易出錯的細節，依序在後面展開。診斷的產出要落成一張清單：每頁的用途、准看的人、目前是否被收錄、對應的處置層。這張清單是後面所有動作的輸入，也是收尾驗收時的抽樣母體。

訊號要被讀到才有效：noindex 與 robots.txt 的責任分界

這一節先給結論：noindex 管網址進不進索引，robots.txt 管網址爬不爬得到，責任範圍剛好錯開。想讓某一頁退出搜尋結果，正確組合是頁面保持可爬取、回應裡帶著 noindex；robots.txt 留給成段大量低價值路徑的爬取管理，兩者疊在同一頁反而讓收錄控制失效。還不熟這兩個名詞的讀者，可以先看noindex 的觀念解析與robots.txt 的設定規則再回來。

noindex 有兩種落地方式。網頁可以在 HTML 開頭的 robots meta 標籤裡宣告，這是內容管理系統裡最常見的設定位置；伺服器也能在回應標頭直接輸出 X-Robots-Tag，適用對象是 PDF、試算表、圖片這類沒有 HTML 開頭可改的檔案。貫穿案例裡的結案報告 PDF 正屬於後者：你無法在 PDF 裡塞標籤，但伺服器送出檔案時可以一併附上不要收錄的指令。兩種寫法的官方定義與細節，見 Google Search Central 的封鎖索引說明。

指令由誰輸出，同樣影響可靠度。由伺服器在初始回應就帶出，比交給前端腳本事後注入穩：注入多了一個執行環節，腳本出錯、載入順序變動或快取差異，都可能讓指令在某些請求裡缺席，而爬蟲不一定每次都等渲染完成。這也是驗收時要看原始碼、不只看畫面的原因。

時效的預期也要先設好。noindex 不是按下就瞬間生效的開關，而是在下次被檢索時才被採納：已收錄的頁面要等搜尋引擎再次造訪、讀到指令，才會從索引移出，熱門頁面可能幾天內完成，冷門角落可能拖上數週。這段等待期正是急停工具存在的理由，許多人誤判它「沒效」，實情多半是指令還沒被讀到。

robots.txt 單獨使用時，有個常被漏掉的結果：它擋的是爬取，不是收錄。若其他網站用連結指到這個網址，Google 仍可能把它列入索引，只是結果裡少了標題與摘要，僅剩網址與外部連結提供的文字線索。所以想讓頁面完全不出現，單靠 robots.txt 做不到；想讓 noindex 生效，反而必須放行爬取，讓搜尋引擎真的讀到指令。

同一頁同時掛封鎖規則與 noindex，就是兩個目標互相抵銷的範本：爬蟲被擋在門外、進不了頁面，頁面上的 noindex 永遠不會被讀到，指令形同未送出，收錄與否退回外部訊號決定。判斷標準因此很單純：要控制收錄，頁面必須可爬取並輸出 noindex；要省下大量低價值路徑的造訪量，才動用 robots.txt，而且不要讓兩者落在同一個網址上。這對組合的細節與常見事故，可以接著讀兩種指令不能疊用的完整解析。

用貫穿案例走一遍就能看清分界。結案報告 PDF 已被收錄，目標是退出索引：檔案路徑保持可爬取，回應標頭帶上排除指令，等重新檢索生效。同一時間不該做的，是在 robots.txt 把整個檔案目錄封起來：爬不進去，指令就永遠送不到，收錄狀態原地不動。一個看起來更保險的動作，剛好把正確的動作抵銷掉。

兩個補充經常被忽略。WordPress 站台的設定裡有個用來勸退搜尋引擎的全站勾選，測試站勾了、搬到正式網域忘了取消，全站會帶著排除指令上線，是新站收不到流量的經典原因之一。規模面則要看檢索資源：搜尋引擎造訪每個網站的次數有限，大量低價值路徑會吃掉重要頁面被造訪的機會，這層取捨就是檢索預算的核心，noindex 與 robots.txt 的分配都繞著它轉。

內容管理系統的外掛多半也提供單頁開關，編輯畫面勾一下就能排除單一頁面，方便之餘有個副作用：太容易按，就容易忘。被標記的每一頁若留下一行原因與日期，半年後回頭檢查時，才記得當初為什麼這樣設。

↔ 左右捲動檢視完整表格

面向	noindex 指令	robots.txt 封鎖
頁面能不能被爬取	可以，而且必須可以	不能
網址會不會進索引	不會，前提是指令被讀到	仍可能，只剩網址層級的項目
適合的用途	逐一指定網址，控制該頁是否收錄	整段路徑、成批低價值網址的爬取管理
生效條件	搜尋引擎重新檢索並讀到指令	下次讀取 robots.txt 時

今晚就要下架的頁面，先用移除工具急停

網址已經躺在搜尋結果上、而且正在外洩，處理節奏就得換檔。前兩種手段都屬於「等搜尋引擎下次來讀才生效」的慢性設定，可能是幾天，也可能更久。Search Console 後台的移除報表提供急用的一手：暫時移除的申請通過後，網址很快會從結果頁隱藏，隱藏期大約六個月。急停的用途是爭取處理時間，不是終點，長期處置仍要在緩衝期內補完。

名字相近的兩種申請，入口與身分不同，送對才對症。暫時移除在 Search Console 的移除報表裡提出，需要站方權限，面對的頁面還在線上，作用是把結果頁上的曝光先壓下來；過時內容更新則走另一個公開工具，不要求站方身分，任何使用者都能針對已刪除或已改版、結果頁卻仍顯示舊標題舊摘要的殘影提出，目的是催搜尋引擎刷新紀錄。資格與流程的官方版本，見Search Console 的移除工具說明。

不是每個收錄異常都值得急停，判斷的槓桿還是後果。一般重複頁或過時頁交給訊號層慢慢退場就好，移除申請的名額與管理成本，應該留給真正會受傷的情況：個資外流、錯誤價格被大量點擊，或網站被入侵後一夜冒出的垃圾頁。被駭情境還有個實用細節，暫時移除支援一次隱藏整段前綴的網址，面對數百個異常頁時逐頁申請並不切實際；止血與除根是並行線：一邊用前綴把整批壓出結果頁，一邊修補被入侵的源頭，兩件事不必分先後。

申請單裡最值得停下來看的一欄是範圍。移除標的有兩種指定方式：填單一網址，只有那一頁被隱藏；改用共同前綴，整段路徑下的網址會一次從結果頁消失。前綴像一次撤掉整排貨架：機密檔案集中在同一個目錄、數量又多時，逐頁申請太耗時，用前綴省事；但範圍切得太寬，會連沒打算隱藏、甚至依靠搜尋流量的頁面一起押下去。送出前把受影響的網址攤開核對一遍，確認沒有誤傷再送。

暫時移除的「暫時」是實實在在的計時器。隱藏效期以約六個月為限，期限一到，頁面本身若沒有改變，網址可能重新出現在結果裡。Google Search Central 的官方教學影片對這套工具的示範也是同一個基調：把它當緩衝，緩衝期內完成 noindex、下架或權限保護，再讓搜尋引擎重新處理一次，結果才會穩定。跳過長期處理的急停，等於把同一次事故排到半年後重播。

急停與長期處理的銜接處，常見一個疑問：頁面都已經刪除了，為什麼還要申請？原因在兩套機制的時間差。索引庫的更新要看重新檢索的排程，結果頁的隱藏則由移除機制直接處理，後者通常快得多。急件用快的管道先擋，慢的管道讓狀態自然收斂，兩條線各自跑完，事情才算結束。

申請送出後仍要回頭看報表。每筆申請的狀態與到期時間都列在移除報表裡，誤傷了需要保留的頁面，取消申請可以提早恢復；長期處置完成、網址退出索引之後，申請留著或取消都不影響結果。真正要避免的是申請堆成一張沒有人再看的老清單。

指令之外的圍籬：權限、下架與隔離

回到診斷的結論：內容本身不能讓陌生人看到時，例如合約、個資、客戶下載區，任何索引指令都只是聲明，不是保護。這一層用的工具是圍籬：登入牆、密碼、內部網路，或直接下架。判準一句話就夠：指令需要搜尋引擎配合才成立，圍籬不需要任何人配合。

下架有自己的語意。伺服器持續回傳 404，Google 會在幾次重新檢索後逐步把網址移出索引；410 在 HTTP 語意上明確表示資源已永久移除，不過對索引的處理效果與 404 相近，差別主要是對瀏覽器、快取與其他工具的宣告。兩者都不是加速捷徑，關鍵在「持續」：今天回刪除狀態、明天又恢復正常，系統只會當成暫時不穩而遲遲不放手。也要當心 soft 404 的陷阱：頁面內容早已清空，伺服器卻仍回報一切正常，畫面上只留一行找不到資料的訊息；這種頁面常被判成實質不存在，而這個判定偶爾會波及真正想保留、內容偏薄的頁面。原則很乾淨：要刪就持續回傳刪除狀態，要留就給完整內容；刪掉的網址若有真正能接手的替代內容，再用 301 轉址。

還要對下架的殘影有預期。頁面刪除後，結果頁的標題與摘要可能還留著舊內容，點進去才看到刪除狀態，這是索引更新的時間差，不是清理失敗；等不及自然更新時，過時內容的申請就是為此設計的。反方向也成立：內容其實還有價值、只是表現不如預期時，優先考慮更新與整併，別急著整批下架。刪除是留給「任務已結束」的頁面，不是留給「表現不好」的頁面。

登入牆與帳號密碼是另一種圍籬，適用會員內容、客戶專區、內部公告這類「特定人才看得到」的頁面。爬蟲遇到要求登入的回應，原則上不會收錄其內容，這正好接回貫穿案例：結案報告若一開始就放在需要登入的專區、檔案也不開放直接連結，搜尋結果裡根本不會有它。活動前的預覽網址還有更細的解法：改用預先簽署或設有到期時間的分享連結，過了有效期自動失效，臨時分享的便利與曝光風險就能一起收住。

規模更大的組織還有更內層的選項：把資料放進只有內部網路才連得到的系統，或讓對外站台與後端資料分離，查詢一律經過要求登入與授權的介面，未通過驗證的請求在閘道就被拒絕。有一條界線要先畫清楚：架構分離本身不是存取控制，介面若開放匿名查詢，資料照樣拿得到；這層投資換來的不是「沒有入口」，而是入口後面多一道誰都繞不過的驗證，成本高，適合機密度最高、曝光後果最重的資產。

全站層級的圍籬時機在搬家與改版。新的正式環境上線前，整站上鎖或全站宣告不要收錄，開張當天再一次解除；順序顛倒的代價是測試網址先被收錄，上線後得花好幾輪移除才清得乾淨，這也是網站搬遷最常見的前置疏失。圍籬在這類情境裡的角色比指令更根本：它不假設搜尋引擎守規矩，也不依賴任何檢索排程。

你沒有建立過的頁面，為什麼出現在索引裡？

手動建立的頁面再多也就幾百頁，真正讓索引狀態失控的，是系統自動產生、數量不受控制的網址：篩選器、排序、分頁、追蹤參數、站內搜尋，每一種都能把一個網址變成一整族變體。處理順序是先盤點產源，也就是導覽列、篩選器與搜尋框這些製造網址的源頭，再談排除；見一頁擋一頁，只會一直追著系統跑。

分頁：最容易做反的一段

分頁的官方建議常被做反。Google 把分頁序列裡的每一頁當成獨立網址，對一般分頁的處理原則是：每一頁保留自己的網址、宣告指向自己的 canonical，頁與頁之間維持一般 HTML 連結，讓爬蟲能一路走下去。把第二頁以後整批指向第一頁，或將後續頁一律加上排除指令，都會切斷這條發現路徑。商品或文章若靠分頁被找到，貿然收掉後續頁等於自斷通路；正確順序是先保留可爬取的結構，再針對排序或篩選產生的變體逐一處理。

分頁的原理也適用於換了包裝的同類問題。無限捲動、「載入更多」按鈕或下拉選單，若沒有在 HTML 裡留下真實可跟隨的連結，爬蟲同樣走不到第二頁以後的內容。看得見不等於爬得到，介面上的操作替代不了原始碼裡的連結。

參數與追蹤碼：先分流，再收斂

參數頁要先判斷有沒有獨立的搜尋價值：顏色或尺寸的篩選頁可能有，純排序或工作階段參數通常沒有。有價值的用各自的網址經營，沒有價值的用 canonical 收斂回乾淨版本，同時統一站內連結與網站地圖，別讓變體持續被自己的網站送到搜尋引擎面前。更細的判斷流程可以接著讀網址參數的處理。工具面要留意：Search Console 早期的網址參數設定已經退場，這類問題只能在網站本身解，沒有後台開關可以倚賴。

追蹤參數的紀律更簡單：UTM 這類標碼用在對外連結，不要掛在自己網站的內部連結上，否則每一頁都會被自己製造出帶參數的分身。已經存在的帶參數版本，讓它們透過canonical 指回不帶參數的原始網址，並修掉產生它們的連結點。大量內容近似的變體放著不管，會累積重複內容的管理負擔，也讓檢索資源被同一份內容的不同版本分食。篩選、排序、分頁三個維度相乘，是網址組合膨脹的典型來源：一個列表頁配上三種篩選兩種排序，網址數量先翻好幾倍，內容卻沒有多出一個字。

站內搜尋頁：價值最低、最容易被忽略

使用者輸入的每個查詢字串，很多網站都直接變成網址參數，長出一個可以被爬取的頁面。這類結果頁內容空洞、彼此相似，還常被垃圾連結攻擊者當成免費的植入入口。原則上它們不該進索引，做法上建議兩手並行：先從搜尋框與表單設定收斂產源，再排除結果頁本身。排除之後也回頭看一眼入口：搜尋框若放進全域導覽，等於每頁都有一條連結指著這些結果頁，產源收斂了、入口還開著，爬蟲還是會不斷被請進來。

內容長在別人的網站上，申訴管道怎麼走

有時你想移除的內容根本不在自己網站上：論壇舊文、被轉載的個資、冒用名義的頁面。管道有兩條：聯繫站方，或向 Google 申訴。常見做法是先聯繫站方，源頭下架了，搜尋結果會在重新檢索後自然跟上，多數情況連申訴都不必走；但聯繫站方並非必要前置，屬於個資或敏感內容等政策明列的類型時，可以直接提出申請。申訴與網站管理端的移除報表是兩套管轄，互不取代。

真的要申訴，類型大致分兩組：隱私個資類，像未經同意刊出的聯絡方式或敏感影像；法律權利類，像侵權重製、商標爭議或法院命令。送件前把證明備齊：你是誰、內容在哪、侵害什麼權利，缺項會直接拉長審核時間。入口與各類資格在Google 的移除申請專頁。心理建設也要有：申訴由專人逐一審核，結果不一定全數通過。

送出之後的節奏很單純：進度會在申請帳號裡回報，被駁回時通常附有原因，按原因補件再送，比換一個管道重頭來得快。整個過程想達成的從來只有兩件事之一：讓內容從源頭消失，或讓搜尋結果不再展示它；做到了第一種，第二種通常會自然跟上。

生效了沒有，用兩份資料交叉驗證

設定做完不等於生效，驗收要靠兩份資料交叉：Search Console 記錄 Google 實際怎麼處理你的網址，爬蟲掃描記錄你的網站現在真正輸出什麼。兩份資料回答不同的問題，時間點也可能對不上，只看一邊容易誤判。

索引報表把每個網址歸進幾種狀態。被排除的頁面會連同原因列出，看到因 noindex 排除，代表指令被讀到而且生效；反過來，應該排除的頁面還列在已建立索引那側，就是指令還沒被讀到，值得用單頁工具追原因。有兩種狀態常被過度解讀：已檢索但未建立索引，代表抓過但目前選擇不收，官方不為單一網址提供更細的理由；宣告的 canonical 未被採用，代表 Google 自行選了別的版本，屬於重複網址的合併判斷，不是處罰。報表數字用來對照自己的設定即可，不必逐項推演出品質結論。

單一網址的即時確認走兩條路。網址檢查能看 Google 上次抓到的版本，也能現場測試即時回應，指令有沒有被讀到、狀態是否如預期，一次看完；檢視原始碼則用瀏覽器開發者工具確認伺服器送出的初始回應裡指令確實存在，而不是被腳本事後補上。要快速確認某網址還在不在結果頁，site: 查詢可以當第一道快篩，但它本來就不是完整的索引清單，查無結果不等於沒被收錄，最終以收錄狀態查核與報表為準。

想一次檢查整個網站，就換全站掃描上場。用爬蟲工具把全站抓一遍，能盤點目前實際輸出的設定：哪些頁面帶著 noindex、哪些網址回刪除狀態、canonical 宣告是否一致。但爬蟲報表看到的是你的網站說了什麼，Google 的索引庫記錄的是搜尋引擎採信了什麼，中間隔著檢索排程，本來就會有時間差。重要網址的最終狀態仍要以 Search Console 核對，兩份資料互補，沒有誰取代誰。

驗收有節奏比有工具重要。小型網站每季跑一輪，中大型、特別是靠篩選與分頁撐起規模的電商站，每月看一次報表變化。盯的焦點是異常而非總量：被排除的數量突然暴增，通常表示網站又自動長出一批沒人預期的網址，值得回頭查產源。

讓節奏發揮作用的方法是留下基準線。每輪驗收簡單記幾個數字：已建立索引的頁數、被排除的頁數、前幾大排除原因。有了上一輪的紀錄，暴增或驟減才有對照組；改版、外掛更新或新功能上線後的幾週尤其值得多看一眼，輸出的設定常在這些時候被悄悄改掉。

從判斷到落地：四步收尾

整篇收斂成本週就能執行的流程：先把頁面依「最壞後果乘上時間壓力」分級，再逐層套處置，收尾用兩份資料驗收。四步各帶完成判準，指派一個負責人、排定一個時段，本週就能走完一輪。

↔ 左右捲動檢視完整表格

處置層	適用條件	完成判準
正常收錄	內容公開且有搜尋價值	報表列為已建立索引，標題摘要正常
訊號層（noindex）	可公開，但不該成為搜尋入口	報表顯示因 noindex 排除，且頁面未被 robots.txt 封鎖
急停＋長期處理	機密或錯誤內容已出現在結果頁	移除申請生效，緩衝期內完成下架、權限或 noindex
圍籬或下架	陌生人看到內容本身就是事故	未登入的存取被拒，或網址持續回傳刪除狀態

1. 盤點清單：客戶專區、感謝頁、測試環境、參數與站內搜尋頁全部列出。完成判準：每頁都寫得出用途與准看的人。
2. 逐頁標記處置層：對照分級表指定 noindex、急停或圍籬。完成判準：沒有任何一頁停在「之後再說」。
3. 檢查指令衝突：要輸出 noindex 的網址，逐一確認沒有同時被 robots.txt 封鎖。完成判準：衝突清單歸零。
4. 抽驗重要網址：首頁、主要服務頁、交易流程頁用網址檢查確認狀態符合預期。完成判準：抽查全數一致，異常項排入下一輪。

要讓這件事不再反覆發生，把對照表寫成內部規範：頁面用途對應公開範圍與索引設定，新頁面照規則走，就不必每次靠事故提醒。處置的目的是讓搜尋結果與頁面用途一致，把不該出現的移開、該出現的留下；它不直接兌換成其他頁面的排名或流量，也不該用這種期待評估成效。想把這套判斷放回更大的架構，可以接著讀技術 SEO 指南，檢索、索引與網站架構會在那裡串成完整的全貌。