noindex 不是排名工具：正確用法與常見地雷

重要頁面搜尋不到時，先確認它是否被設為 noindex。這個指令可能來自文章設定、外掛、網站程式或 HTTP 回應標頭；要查明原因，必須看實際輸出，不能只看後台的勾選狀態。

noindex 讓支援此規則的搜尋引擎排除該網址，但不會替頁面加上登入保護。本文以 Google 為主，說明設定方式、適用情境，以及誤設後的檢查與恢復流程。

閱讀時先區分四個目標：限制抓取、排除索引、整合重複網址，以及保護私人資料。它們需要不同設定，不能只靠一個 noindex 解決。

重點摘述：noindex 可放在 HTML meta 標籤或 HTTP 回應標頭。Google 必須抓到並讀取指令，才能據此移除索引。它不會刪除內容、阻擋一般訪客或直接提高其他頁面的排名。

先講清楚原理：noindex 到底做了什麼

noindex 是排除索引的指令，可用 meta robots 或 X-Robots-Tag 傳送。依 Google Search Central〈封鎖索引〉文件，Googlebot 抓取並讀到指令後，Google 會將該頁從搜尋結果移除。

可以把索引想成公開目錄：移除目錄中的項目，不等於把原始檔案鎖起來。只要網站仍公開提供頁面，知道網址的人就可能直接開啟。

因此，含個資、未公開產品或內部文件的頁面，應先設定登入與權限。noindex 不能代替資料保護。

robots.txt 的 Disallow 用來管理抓取；noindex 用來管理索引。封鎖抓取不保證網址從搜尋結果消失，還可能阻止 Google 讀取剛加入的 noindex。

若網站依賴 JavaScript，應檢查初始 HTML 與渲染後的 robots meta 是否一致。初始回應已有 noindex 時，Google 可能略過渲染；不要期待 JavaScript 稍後移除它就能恢復索引。可在伺服器端直接輸出所需指令，減少不同階段設定不一致的問題。

四個指令常被搞混：noindex、robots.txt、canonical、301 各管一段

這四種設定的目的不同。先確認你要改變的是抓取、索引、標準網址或使用者的存取目的地：

如果 robots.txt 封鎖了某個路徑，而該頁面同時放置 noindex，Googlebot 可能無法抓取頁面並讀到 noindex；網址若從其他來源被發現，仍可能以缺少內容資訊的形式出現在搜尋結果。詳細差異可參考robots.txt 與 noindex 比較。

公開頁面若仍需保留、但不希望被索引，應讓 Google 能重新抓取並讀到 noindex，必要時調整該網址的 robots.txt Disallow 規則。私人內容應先維持權限保護。其他情境可參考noindex 使用方法及301 與 302 轉址指南。

noindex 的用途：控制哪些網址出現在搜尋結果

這是搜尋者最常問、也最容易被誤導的一個問題：用了 noindex，排名會上升嗎？

直接的答案是：不會。noindex 本身不是排名因素，它不會因為你在某一頁加了它，就讓「別的」頁面排名往上爬。它沒有那種神奇的力量，任何告訴你「加個 noindex 就能衝排名」的說法，都可以直接打折。

它更實際的價值，是讓不該出現在公開搜尋結果的網址退出索引。一份大規模研究發現，多數受測網頁沒有取得 Google 自然搜尋流量（見 Ahrefs 2023 年 12 月的研究）。沒有流量不等於沒有價值，也不代表頁面會拖累整站；是否使用 noindex，仍應看頁面用途、重複程度與是否適合公開搜尋。

當你用 noindex 把搜尋者不需要的頁面，例如內站搜尋結果頁、部分篩選參數頁、空標籤頁或感謝頁，從索引裡移除，可以讓搜尋結果少出現無用入口。這不是直接排名訊號，也不能保證其他頁面上升；對大型網站而言，若同時控制網址生成與爬取路徑，才可能改善爬取資源的運用。

大型或更新頻繁的網站較需要留意爬取效率，尤其是篩選器產生近乎無限網址時。noindex 本身仍允許爬取，因此若問題是網址生成量，還要從導覽、參數與系統規則處理；中小網站通常不必把爬取預算當成首要問題。延伸可看爬取預算優化指南。

更實際的判斷標準，是每個網址是否有獨立用途。重複、空白或不該成為搜尋入口的頁面可以排除；內容有價值但暫時沒有流量，不能僅因流量低就 noindex。Google 沒有公開「提高索引平均品質就能拉升整站排名」這種機制，因此成效應回到個別頁面的索引狀態、爬取紀錄與搜尋需求驗證。

noindex 的兩種寫法：meta 標籤和 X-Robots-Tag，差別在哪

多數人接觸到的 noindex，都是寫在 HTML 裡的 meta 標籤，長相是 <meta name="robots" content="noindex">。這是最常見、也最直覺的寫法，因為它就嵌在頁面的原始碼裡，打開檢視原始碼就能看到。

但很多人不知道，noindex 還有第二種寫法，是放在 HTTP 回應標頭裡的 X-Robots-Tag: noindex。這兩種寫法對 Google 來說效力是一樣的，差別僅在於它們適用的場景。

meta 標籤僅能用在 HTML 頁面上，因為它本來就是 HTML 的一部分。可是你網站上被索引的資源，不僅有 HTML。PDF、圖片、試算表、影片檔，這些都可能出現在搜尋結果裡，而它們沒有 HTML 可以讓你塞 meta 標籤。這時候就要靠 X-Robots-Tag，在伺服器回應這個檔案時，於 HTTP 標頭裡直接宣告 noindex。

例如，一份型錄 PDF 仍供訪客從產品頁下載，但不希望它單獨成為搜尋入口，可以只在該 PDF 網址的回應中加上 X-Robots-Tag: noindex。先測試目標檔案與其他 PDF 的標頭，避免把單份型錄的需求套用到全站檔案。

WordPress 文章可透過網站程式或外掛輸出 meta robots；下載檔案則仍可能需要 HTTP 標頭。排查時要同時檢查兩個位置，以免只改了外掛選項，卻漏掉伺服器或 CDN 的規則。

兩種方式都能批次設定：CMS 範本可替一組 HTML 頁面輸出 meta，伺服器或應用程式也能替指定路徑加入回應標頭。差別在輸出層與資源類型；批次操作前，先確認規則範圍並抽查例外網址。

六種值得檢查索引用途的頁面

講完原理，來談實戰。接下來這六類，是在幫網站做 技術 SEO 健檢時，會優先檢查、也常常建議蓋上 noindex 的頁面類型。我並非說每一種都要無條件蓋上，但這些類型最常出問題，值得你逐一檢視。

1. 內站搜尋結果頁。這類 URL 可能大量生成，也常缺乏穩定的獨立價值，多數網站會選擇 noindex。若站內搜尋頁經過編輯、具固定需求與獨立內容，仍應個別評估，不能無條件套用。
2. 篩選與排序參數頁。先判斷是否有獨立需求與內容。高度重複版本可評估 canonical；公開但不適合成為搜尋入口的版本可評估 noindex。不要把所有參數網址一律排除，也不要把內容不同的頁面全部 canonical 到主分類。
3. 空的或僅掛一篇文章的標籤與分類彙整頁。WordPress 預設會為每個標籤建立彙整頁，許多標籤僅連到一篇文章。若這類頁面沒有獨立搜尋用途，可考慮 noindex；但不要宣稱它會因「薄」而連帶處罰整站。
4. 感謝頁、結帳成功頁、登入後頁面。公開的通用感謝頁可依用途設為 noindex；含訂單、會員或其他私人資料的頁面，必須先做好登入與權限控制，不能只靠索引指令。
5. 測試環境、預覽頁、暫存版本。未公開資訊應用存取權限隔離。noindex 只能輔助控制可被爬取內容的搜尋呈現，不能防止知道網址的人開啟，也不能當成草稿的保密措施。
6. 純排序或篩選造成的列表變體。Google 對一般分頁的建議，是每頁使用獨立網址與 self-canonical，不要把第 2 頁以後一律 noindex 或 canonical 到第 1 頁。真正需要排除的是沒有獨立價值的排序與篩選變體，並確保 Google 仍能透過 HTML 連結找到後續內容。

以下是排查示例：若商品分類在改版後失去搜尋曝光，應檢查新版範本與外掛是否改變了索引指令，再與 Search Console 的抓取日期及索引資料比對。流量下滑本身不足以證明是 noindex，需以實際回應確認。

不要只按篇幅或流量判斷內容品質。先確認頁面能否回答搜尋需求，再決定補強、整合、保留或排除索引。

判斷 noindex 的重點是頁面是否適合成為公開搜尋入口。對站內流程有用的頁面，未必需要獨立搜尋曝光；反過來，流量不高的說明頁也可能有明確用途。記錄各類頁面的決策理由，方便改版時重新核對。

noindex 與 follow：不能當成長期連結傳遞保證

很多老派的 SEO 教學會教你把指令寫成 noindex,follow，意思是「不要索引這個頁面，但繼續爬取它，並且跟著頁面上的連結走出去」。背後的邏輯聽起來很合理：這頁我不想要排名，但頁面上的內部連結還是要繼續傳遞權重給其他頁面，不要浪費。

follow 是預設行為，單寫 noindex 並不等於另外設定 nofollow。不能據此保證頁面會持續以固定頻率被抓取，或保證所有連結長期得到相同處理。

noindex,follow 與單獨 noindex 並沒有預期中的額外「保留權重」開關，因為 follow 本來就是預設值。頁面抓取頻率和連結處理另受搜尋系統安排影響，不宜寫成固定期限後自動轉為 nofollow。

網站應直接從可存取且相關的頁面連到重要內容，不要把長期 noindex 頁面當成唯一入口。這是導覽與發現性的實作選擇，不能用來推算 Google 會如何分配每條連結的權重。

若重要頁面僅能從 noindex 頁找到，應補上來自可索引頁面的正常內部連結。canonical 僅適用於重複或高度相似內容，不應為了傳遞連結訊號而指向不相關頁面，也不是 noindex 的替代品。

關於連結權重與反向連結的整體經營，可以參考我寫的 反向連結完整指南，那裡把外部與內部連結的權重流動講得更完整。

同一個頁面同時放 noindex 又寫 canonical，Google 會聽誰的

這是進階題，也是實務上很容易踩到的一個坑。

情境是這樣：一個頁面上同時放了 noindex 指令，又放了 canonical 指向另一個網址。很多人以為 canonical 會自動「把權重導過去」，所以安心地同時蓋上 noindex，覺得兩全其美，既不會被索引，權重又能順利搬走。

noindex 是排除索引的指令，canonical 則是標準網址提示。兩者同時出現時，不應假設 Google 會先合併所有訊號、再移除該網址。若目標是合併重複版本，用一致的 canonical、內部連結與 sitemap；若目標是讓網址退出結果，使用 noindex。

正確的分工應該是這樣的：

• 整合重複或高度相似的版本：用 canonical 提示偏好網址，並保持內部連結與 sitemap 一致。Google 仍會自行選擇標準網址，不保證完全依照指定結果。
• 保留公開頁面但排除索引：使用可被讀取的 noindex。它不是連結訊號合併工具，不宜據此推算其他頁面的權重變化。
• 同一頁同時出現兩者：先釐清排除索引與整合版本的目的。Google 不建議用 noindex 阻止選取某個站內 canonical，也不要假定系統一定先合併訊號再排除該頁。

同一查詢出現多個網址時，先確認各頁用途，再決定是否整合。noindex 會排除該頁的搜尋資格，不能保證另一頁因此獨占排名；canonical 則只用於重複或高度相似內容。可參考關鍵字蠶食診斷與Canonical URL 的適用條件。

WordPress 站長最容易踩的 noindex 地雷

使用 WordPress 時，要分開查看「設定 → 閱讀」的搜尋引擎可見度、SEO 外掛規則、文章個別設定及程式輸出。WordPress 提供加入 noindex 的功能，但最終頁面是否帶有指令，仍須檢查實際回應。

第一個雷，是 SEO 外掛的全域預設。這類外掛通常提供「分類彙整、標籤彙整、作者彙整、日期彙整是否 noindex」的全域開關。不能一概把所有標籤與日期彙整設成 noindex；應先確認每個開關的影響範圍與頁面是否具獨立搜尋價值，避免連重要分類頁一起排除。

第二個檢查位置是文章或頁面的個別 SEO 設定。不同外掛的介面與預設值不同；批次編輯或套用範本後，抽查重要頁面的實際 robots meta，不要只憑印象判斷開關狀態。

第三個檢查位置是自訂文章類型與網站程式。服務頁、作品集與案例頁可能使用不同範本或外掛規則，應逐類抽查；不能單憑它不是部落格文章，就推定應該排除索引。

給 WordPress 站長一個實用的檢查方向：挑選 SEO 外掛時，務必花時間弄懂它的全域 noindex 設定到底涵蓋哪些頁面類型，可別一鍵套用預設值就收工。各家外掛在這些細節上的差異，其實會直接決定你網站的索引健康度，我整理在 WordPress SEO 外掛完整評測 裡，可以對照著看你手上的外掛落在哪一種設計邏輯。

維護模式也要確認實際回應。正式站短暫停機可評估 HTTP 503，避免把全站加上 noindex 當作通用維修方式；503 若持續過久也會影響索引。上線後，檢查應公開索引的重要頁面是否恢復正常，原本有意排除的私人流程頁則按用途保留設定。

檢查 noindex 設定的四步流程

那要怎麼知道網站有沒有誤設？下面四步可涵蓋常見檢查面向，但不能宣稱固定抓出某個比例的問題；大型網站仍需要抽樣、爬蟲報表與 Search Console 交叉驗證。

第一步，挑出你網站上最重要的十個頁面。通常是首頁、主力商品或服務頁、主要分類頁、以及流量最高的幾篇文章。這些是你的命脈，優先確認它們。

第二步，檢查初始與渲染後 HTML 的 robots meta，以及 HTTP 回應中的 X-Robots-Tag。想索引的頁面不一定要明寫 index,follow；重點是沒有意外限制。max-image-preview 控制圖片預覽，不能覆蓋 noindex。

第三步，使用 Search Console 的 URL 檢查，比對已索引版本的抓取時間與即時測試。前者反映 Google 已處理的版本，後者檢查目前能否存取與索引；即時測試通過不代表已經收錄。操作可參考Google Search Console 完整教學。

第四步，查看 Search Console 的「網頁索引」報表，依未索引原因抽查網址範例。報表與範例有數量及更新限制，不是全站所有網址的完整清單；重要頁面另用 URL 檢查核對。

如果你想更系統化地把 noindex 這類技術性問題，連同網站架構、爬蟲溝通一次盤點清楚，建議把視角拉高到整體的技術性 SEO 架構，把單點的 noindex 問題放回更完整的脈絡裡檢視，才不會見樹不見林。

被 noindex 的頁面，要怎麼救回 Google 索引

最終一個情境，也是最讓人焦慮的一個：發現重要頁面被 noindex 了，要怎麼救回來？

救援的流程其實不算複雜，但需要耐心，因為即使你做對每一個動作，Google 重新處理還是要時間。正確的順序是這樣的：

1. 移除誤設的 noindex。先確認此頁應公開索引，再檢查初始 HTML、渲染 HTML 與 X-Robots-Tag，修正產生指令的外掛、範本或伺服器規則。
2. 確認 Google 能存取頁面。檢查 robots.txt、HTTP 回應與其他存取限制。不要為了索引而解除私人資料原有的保護。
3. 到 Search Console 的 URL 檢查工具，按下要求建立索引。這個動作會主動通知 Google 重新處理這個網址。這是重新處理請求，不保證較快抓取或重新索引。
4. 記錄修改並追蹤索引資料。比較後續抓取日期與網頁索引報表。移除 noindex 不保證收錄，也沒有固定恢復期限；反覆要求索引不會保證更快處理。
5. 提供相關的正常內部連結。從適合的分類頁或相關文章連到重要內容，幫助讀者與搜尋引擎找到它；不必為了連結而塞進不相關的首頁區塊。

移除誤設指令後，也要檢查頁面內容、HTTP 狀態、canonical 與導覽連結。網址不再有 noindex，只代表這項限制已解除；Google 是否選擇索引與呈現，還涉及其他條件。

恢復索引沒有固定期限。移除 noindex 後，確認頁面可存取、內容與 canonical 正確，再用 URL 檢查提出重新處理請求並觀察結果；重複提交不會保證更快處理。

XML sitemap 適合列出希望被索引的標準網址，應與頁面設定保持一致。它是協助發現網址的提示，不是保證收錄的指令，也不能覆蓋 noindex。

若系統不斷產生新的篩選組合，應同時檢查網址生成與站內連結。參數本身不是問題；要處理的是不必要的重複網址，以及是否保留通往重要內容的正常路徑。

noindex 是正常的索引管理工具，與操弄排名是不同問題。若需要一併了解搜尋政策與違規手法，可參考黑帽 SEO 與風險解析。

AI 搜尋時代，noindex 的影響比你想的更大

最終我想補一個多數 noindex 教學沒提到、但在 2026 年已經無法迴避的視角。

就 Google 的 AI Overviews 與 AI Mode 而言，頁面必須已被索引、符合一般搜尋技術要求，且可顯示摘要，才有資格成為支援連結。Google 也明確表示不需要特殊 Schema。一個被 noindex 的頁面會失去這項資格，這是 noindex 對 Google AI 搜尋最可確認的影響。

因此，誤設 noindex 會同時排除一般自然結果與 Google AI 功能中的支援連結資格。這不代表已索引頁一定會被 AI 採用或推薦；可確認的僅是資格差異。

反過來說，這也是為什麼「精準地使用 noindex」比以前更值得投入心力。當內容被引用的管道變多，被索引這件事的價值就變高，那麼「哪些頁面該被索引、哪些該被排除」這個判斷，也值得做得比以前更細。把該藏的藏好、把該露的露對，這件基本功，在 AI 搜尋時代非但沒有過時，反而變得更關鍵。

如果你對「怎麼讓內容被 AI 主動引用」這件事有興趣，那是另一個獨立的主題，noindex 僅是其中一塊地基。先把索引的地基顧好，再談如何在上面蓋 AI 友善的內容。

把這篇變成行動：一個你可以今天就做的清單

開始處理時，可以用五步行動逐項檢查，不需要付費工具，只要備妥網站權限、瀏覽器與 Search Console 帳號即可。順序是先處理誤設的重要頁面，再做全站健檢並建立規範；想判斷免費工具要用到什麼程度、哪些訊號出現後才值得升級，可以參考SEO 工具什麼時候才值得升級到付費的判斷標準。

1. 列出重要商品、服務、分類與文章頁，先挑一組有代表性的網址，按前面的流程確認索引設定。
2. 登入你的 SEO 外掛，把全域的 noindex 設定從頭到尾走一遍，搞清楚每一個開關實際涵蓋哪些頁面類型。如果你說不出「我的標籤頁現在到底有沒有被索引」，那就還沒走完。
3. 查看 Search Console 網頁索引報表，依原因抽查不符合預期的網址；重要頁面另用 URL 檢查核對。
4. 針對內站搜尋頁與篩選參數頁，依內容是否有獨立搜尋價值決定 noindex 或 self-canonical／canonical，並同步整理 sitemap 與內部連結。
5. 養成一個習慣：每次網站改版、外掛大更新、或套用新範本之後，重新跑一次那十個主力頁面的 URL 檢查。noindex 的問題，多半不是誰故意造成的，而是某個你沒注意到的開關，被預設值悄悄勾走了。

每次改版都應保留索引設定的檢查紀錄：哪些頁面預期可被索引、哪些需排除、修改由誰負責。出現異常時，這份紀錄能幫助比對變更，而不必重新猜測原本的用途。

若需要協助盤點索引問題，可由 Whoops SEO 技術健檢檢查網站回應、索引指令與 Search Console 資料。先確認問題與影響範圍，再決定修正順序。