企業網站上線或改版時，經常會遇到三個設定：robots.txt、noindex 與 Sitemap。它們都與搜尋引擎有關，卻不是同一種開關，也不能互相取代。
把頁面放進 Sitemap，不代表 Google 一定收錄；在 robots.txt 封鎖路徑，不代表內容已經保密；加上 noindex，則需要搜尋引擎能取得指令，才能依指令處理。
最重要的區別是：robots.txt 管理檢索，noindex 管理是否索引，Sitemap 提供網址發現與主要版本的線索。 企業不必先學會所有語法，但應知道每個設定要解決什麼問題，以及如何核對工程交付。
robots.txt、noindex 與 Sitemap 差在哪？先分清楚檢索與索引
能抓取不等於會收錄，未收錄也不代表被封鎖
檢索，是搜尋引擎嘗試取得網址與內容；索引，則是處理內容並決定是否加入搜尋索引。一般所說的 Google 收錄，主要是在談索引，不是只要網頁能被抓取就完成。
頁面能被檢索，但仍可能因重複、noindex 或其他原因沒有索引。相反地，沒有索引也不一定是存取遭封鎖，可能只是尚未被處理，或另一個版本被選為主要頁面。
因此，企業不要只問「搜尋引擎有沒有打開」，而應說清楚：哪些網址需要公開、哪些希望出現在搜尋中，以及哪些內容根本不能讓未授權的人存取。
網站發現、存取與索引是不同環節
搜尋引擎需要先知道網址，再嘗試取得與處理內容。內部連結與 Sitemap 可以提供發現線索；網站回應、存取限制與 robots.txt 會影響檢索；noindex 則表達不希望內容被索引。
以下是入門比較，不是完整技術規格，也不是設定完成後的成果保證：
| 設定 | 主要用途 | 不能拿來代替什麼？ |
|---|---|---|
| robots.txt | 向遵守規則的檢索器管理網址存取 | 不能代替保密、登入驗證或網頁移除保證 |
| noindex | 讓支援的搜尋引擎不要索引內容 | 不能代替存取控制，也不等於禁止檢索 |
| Sitemap | 提供希望被發現與呈現的網址清單 | 不能強迫收錄、解除封鎖或保證排名 |
設定應搭配頁面用途，不是三項都啟用就比較安全。如果互相矛盾，反而可能讓搜尋引擎讀不到企業真正想表達的指令。
robots.txt：控制哪些路徑可被檢索
適合哪些檢索管理情境，不是保密機制
Google 的 robots.txt 說明指出，這個檔案用來告訴檢索器可以存取哪些網址，主要用途包括管理檢索流量，而不是確保網頁不出現在 Google。
網站存在大量不重要或相似路徑時，可以由了解網站架構的人評估檢索規則。不是每個小型企業網站都需要複雜封鎖，也不要為了「節省檢索」就阻擋重要內容或理解頁面所需的資源。
例如正式服務頁需要載入特定程式與樣式，若相關資源遭封鎖，可能影響 Google 理解頁面。應先確認用途與影響，再修改規則，而不是從網路複製一份通用封鎖清單。
robots.txt 也無法強制所有檢索器遵守，更不能阻止人直接開啟網址。敏感資料應使用真正的權限與存取控制，不靠搜尋設定保護。
被擋網址仍可能出現在搜尋，不能當成移除保證
Google 官方提醒，即使網頁被 robots.txt 阻擋，網址仍可能因其他網站的連結等資訊出現在搜尋中。這不表示 Google 已正常取得頁面內容，而是封鎖檢索不等於封鎖索引。
如果目的是讓公開頁面不出現在搜尋中，應評估可被讀取的 noindex；如果內容不能公開，則應先做存取限制。不要把「禁止檢索」當成所有隱藏需求的共同解法。
同樣地，頁面已出現在搜尋時，事後加入 robots.txt 封鎖，也不能視為完成移除。需確認真正的目標，再依相應方式處理。
noindex：表達不希望頁面被索引
設定在頁面或回應中，搜尋引擎需能取得指令
Google 的 noindex 文件說明，可以透過頁面的 meta 標記，或 HTTP 回應標頭設定 noindex。對 Google 而言，在 robots.txt 寫入 noindex 並不是支援的做法。
對 HTML 頁面，網站系統可能提供對應的索引設定；對 PDF 等非 HTML 資源，則可能需要由伺服器回應中的 X-Robots-Tag 處理。企業可以交辦設定需求，但實際方法要由網站負責人依系統與內容類型確認。
noindex 不代表頁面不再公開，也不阻止訪客透過連結開啟。它處理的是搜尋索引，不是內容的閱覽權限。
另外，搜尋引擎需要重新取得指令後才能處理。設定發布與搜尋結果變更，是不同階段，不能只因後台開關已切換，就宣稱已立即從搜尋中移除。
同時用 robots.txt 擋住時，可能無法讀到 noindex
這是常見的矛盾：企業希望某頁不要索引，於是同時加上 noindex，又在 robots.txt 封鎖它。但封鎖檢索後，Google 可能無法取得頁面中的 noindex。若要確認不同轉址的差異與適用情境，可參考〈301、302、307、308 轉址的差異〉。
Google 官方文件明確要求，要讓 noindex 生效，頁面或資源不能被 robots.txt 阻擋，且必須能被檢索器存取。
若是公開但不希望出現在搜尋的頁面，可以安排可被取得的 noindex。若是機密資料，則不應為了讓搜尋引擎讀指令而解除必要的保護；要優先採取權限控制，並另行處理已曝光的搜尋資訊。
Sitemap：提供希望被發現的網址清單
列入可存取、主要且適合索引的網址
Sitemap 可以理解為提供給搜尋引擎的網址清單。它不是一般訪客使用的網站選單，也不能取代頁面之間合理的內部連結。
Google 的 Sitemap 建立說明建議使用完整的絕對網址，並列出希望出現在搜尋中的主要版本。相同內容有多種網址時，不必全部列入。
企業可以先核對清單是否混入測試站、舊版路徑、錯誤頁、重新導向網址，或本來就設定 noindex 的頁面。這些矛盾不應靠增加提交次數解決，而應回到網站產生清單的規則。
若提供 lastmod 更新資訊，也應反映實際重要修改，而不是每次產生檔案就將所有頁面日期改成當天。準確的資料，比看起來每天更新更值得維護。
提交有助發現，不保證收錄或排名
Sitemap 可以透過 Search Console 提交，或依官方方式讓 Google 發現。提交後，要確認檔案是否可取得，以及是否有處理錯誤，而不是只截圖「已提交」作為驗收。若發現頁面沒有被 Google 收錄，想知道排查順序，我們在〈網站沒有被 Google 收錄的排查步驟〉中有進一步說明。
Google 官方說明也提醒，提交 Sitemap 只是提示，不保證 Google 下載檔案，或用它檢索清單中的網址。因此，更不能由提交成功推導出所有頁面已收錄或即將排名。
如果重要頁面仍未索引，要另外檢查該網址的狀態、內容與設定。Sitemap 不會替頁面解除 noindex、登入限制或 robots.txt 封鎖。
不同情境該用什麼，哪些需要另外處理？
測試站、登入內容及不希望搜尋的頁面各怎麼判斷？
先問「內容可不可以公開」，再問「需不需要出現在搜尋」。這兩個決定不要倒過來。
以下是假設性的情境判斷，不是適用所有網站的固定設定：
| 情境 | 優先處理方向 | 要避免的誤解 |
|---|---|---|
| 正式服務頁希望被搜尋 | 正常存取、無誤設 noindex，提供內部入口與正確 Sitemap | 放入 Sitemap 就一定收錄 |
| 公開頁面但不希望被索引 | 評估可被取得的 noindex，避免相互矛盾的封鎖 | noindex 會讓訪客無法閱讀 |
| 含未公開內容的測試站 | 優先使用驗證或存取限制，管理測試與正式環境差異 | robots.txt 已經保護機密 |
| 客戶或內部文件 | 使用適當的登入、授權與檔案存取控制 | 只要搜尋不到就安全 |
| 大量相似網址的檢索管理 | 先確認主要版本與架構，再評估規則 | 所有未索引網址都是錯誤 |
重複網址的主要版本選擇，還可能涉及 Canonical 與轉址；頁面已移除，則需要核對回應與替代安排。這些需求不應全部交給三種設定處理。若遇到重複內容或多個網址版本，想了解處理原則，可參考〈Canonical 與重複內容的處理〉。
真正敏感資料使用存取控制，不只依賴搜尋設定
只要知道網址就能取得的文件，即使沒有搜尋曝光，也可能被轉寄、分享或直接存取。noindex 與 robots.txt 都不能代替授權驗證。
網站與安全負責人應確認敏感資料是否受適當保護，包括直接檔案網址、附件與相關資源，而不只檢查前台頁面有沒有登入畫面。
如果資料已意外公開，應先停止未授權存取，再核對搜尋移除、外部副本與事件處理需求。不能只刪除 Sitemap 裡的網址，或添加一個搜尋設定，就認定外洩風險已解除。
設定後怎麼驗收，不只看後台開關？
核對實際檔案、頁面回應與主要網址
後台顯示已關閉索引，不代表所有頁型都已輸出正確指令；robots.txt 修改完成，也可能受部署、快取或不同主機設定影響。
驗收應回到實際網址：檔案內容是否正確？指定規則影響哪些路徑？頁面標記與回應標頭是否一致？Sitemap 裡的網址是否符合預期主要版本？若正在規劃改版或換網址，想確認上線前後的檢查項目，下一步可以看〈網站改版避免 SEO 流量流失的檢查清單〉。
| 設定 | 建議驗收資料 |
|---|---|
| robots.txt | 實際檔案、適用主機與路徑、受影響頁面及資源 |
| noindex | 目標網址、HTML 或回應標頭、是否能被取得 |
| Sitemap | 檔案網址、處理狀態、主要版本與排除規則 |
| 存取控制 | 未授權存取測試、直接附件與資源檢查 |
這份表是工作核對清單，不代表 Google 已完成重新處理。工程交付與外部結果，仍需分開記錄。
搭配 Search Console 檢查，記錄測試及生效限制
可以搭配網址檢查與網頁索引報表，確認重要網址的歷史狀態與目前測試結果；Sitemap 則查看相應報表中的處理資訊。
Google 的網址檢查工具說明區分索引資料與即時測試。剛修改設定時，兩者可能不同：即時測試有助核對現在的存取條件，但不能代替索引結果，也不能保證未來收錄。
保存檢查時間、部署版本與結果，才能知道是在修正前還是修正後觀察。若需要重新處理，可依工具與官方流程提出請求，但不承諾固定天數生效。
企業與工程如何維持設定一致？
指定環境、路徑、用途、負責人與驗收方式
交辦不要只寫「設定 SEO 開關」，而應寫出環境、網址或頁型，以及想達成的用途。例如正式服務頁需公開且適合索引，客戶附件需受權限保護，測試站不應成為公開內容來源。
企業負責確認公開與搜尋需求，工程負責實作與存取測試，SEO 或網站管理人員核對搜尋相關訊號。涉及敏感資料時，也應有適當的安全或資料負責人參與。
每項設定都要留下主責、核准者、修改日期與驗收方式。不是因為某條規則存在很久，就認定它仍符合目前網站需求。
上線及改版前後檢查，避免測試限制留到正式站
測試環境與正式站往往有不同設定。上線前，要確認測試用的全站 noindex、檢索封鎖、測試網域或驗證要求，沒有被錯誤帶到正式公開頁面。
也要避免相反問題：部署正式站時，連帶移除測試站的保護，讓未公開資料可被存取。部署流程應分別檢查兩種環境，不以「正式站開了」取代全部驗收。
上線後，再檢查代表性頁面、附件、robots.txt 與 Sitemap。共用模板或插件更新時，也應重測相關設定，避免原本正確的指令被覆蓋。
robots.txt 回答「哪些網址可被檢索」，noindex 回答「哪些內容不應被索引」，Sitemap 提供「希望被發現的主要網址」。敏感資料是否安全，則需要另外的存取控制。
企業把這四種需求分清楚，才能正確交辦、核對網站設定，也能避免用錯工具，造成重要頁面無法被搜尋，或誤以為未收錄的資料已受到保護。