判斷一個頁面該不該進 sitemap，其實只要問一句話：一個陌生人從 Google 搜尋進到這頁，合理嗎？答案是否的頁面，就該從 sitemap 拿掉。後台管理頁、使用者設定頁、簽署流程的中間步驟頁，全都過不了這一關。很多 SaaS 網站的 sitemap 一打開，塞滿了這類對搜尋使用者毫無意義的功能頁，等於主動邀請 Google 來爬一堆不該被索引的東西。這篇把該排除哪些功能頁、為什麼要排除，以及 crawl budget 這件事到底該怎麼取捨講清楚，順便說明排除之後還要配哪些設定才算做完，讓你不會只做了一半就以為收工。
1. sitemap 不是網站地圖，而是一份「推薦清單」
先破除一個觀念。sitemap 不是要你把網站上每一個網址都列進去的「全站目錄」，它是一份你交給 Google 的推薦清單，意思是「這些頁面值得你來看、值得被索引」。當你把後台頁、設定頁也放進去，你傳遞的訊號是「這些也值得索引」，而它們根本不該出現在搜尋結果裡。搞清楚這個定位，排除的標準就清楚了。
1.1 該進 sitemap 的是內容頁，不是功能頁
判斷標準很簡單：一個頁面如果是給搜尋使用者看的內容，例如產品介紹、功能說明、部落格文章、定價頁，它該進 sitemap；如果它是給已登入使用者操作的功能介面，例如後台、帳號設定、簽署流程的某一步，它就不該進。我們的做法是先問一句「陌生人從 Google 搜尋進到這頁，合理嗎？」答案是否定的，就從 sitemap 拿掉。這個問句幾乎能解決九成的判斷，剩下的才需要個別斟酌，省去一條一條去查規則的力氣。
1.2 轉址頁與無效網址是在浪費爬取
我們在實務上看過一款電子簽章 SaaS 的 sitemap，裡面含有大量帶特定前綴的網址，像是 /admin/、/settings/、/integration/ 底下的路徑。Google 去爬這些網址時，不是被轉址，就是撞到根本不存在的頁面。每一次這樣的爬取都是白工，爬蟲花在無效網址上的力氣，就是它沒花在你真正想被索引的內容頁上的力氣。sitemap 裡每一條無效網址，都是在替真正重要的頁面扣分。更糟的是，如果 sitemap 裡大量網址回傳的是轉址或錯誤狀態碼，Google 對這份清單的信任也會下降，連帶影響它對其中正常頁面的處理意願，等於一顆老鼠屎壞了一鍋粥。
1.3 sitemap 乾淨，本身就是一種品質訊號
一份只收錄有價值內容頁的 sitemap，等於告訴 Google 這個網站清楚自己哪些內容值得被看見。反過來，一份混雜大量功能頁、轉址頁的 sitemap，會讓 Google 對整站的內容品質產生疑慮。我們整理 sitemap 時，會把它當成網站對外的一份自我介紹：列進去的每一頁，都要你願意它出現在搜尋結果裡。這份清單的乾淨程度，某種程度上反映了你對自己內容的把握。
1.4 很多功能頁是外掛或框架自動產生的
功能頁會大量混進 sitemap，多半不是有人刻意加的，而是網站框架或外掛自動產生的。很多 CMS 與 SaaS 框架預設會把所有可公開存取的路徑都丟進 sitemap，包含那些其實只給系統或登入使用者用的頁面。我們在診斷時，通常會先打開實際的 sitemap 檔案，把網址依前綴分組看一遍，一眼就能看出哪些前綴明顯是功能頁在大量灌水。找到產生這些網址的來源之後，正確做法是從 sitemap 的產生規則去排除，而不是一條一條手動刪，否則下次系統重新產生又會跑回來。這一步是讓 sitemap 保持乾淨的治本辦法。很多 SEO 外掛也提供依文章類型、頁面類型排除的設定，善用這些規則，就能讓新產生的功能頁自動被擋在 sitemap 之外，不必每次人工維護。
2. 這幾類功能頁，請一律從 sitemap 排除
根據我們實際處理過的 SaaS 網站，以下幾類頁面幾乎都該排除。它們的共通點是：面向已登入使用者、屬於操作流程的一環、或本身就會轉址。這些頁面進 sitemap 沒有任何好處，只有壞處。
2.1 後台管理頁與使用者設定頁
後台管理頁，像是權限設定、使用紀錄、群組管理、組織設定、報表這類 /admin/ 底下的頁面，全部是登入後才有意義的介面，對搜尋使用者零價值。使用者設定頁也一樣，帳號設定、授權清單、偏好設定、個人資料、簽名檔管理這些 /settings/ 底下的頁面，同樣該排除。它們不但不該被索引，若被爬到還可能有隱私與安全上的疑慮，因為這些頁面常牽涉個人資料。這裡要特別提醒一點：這類頁面真正該靠的是登入驗證把關，而不是單純不被索引。就算你把它從 sitemap 拿掉、也加了 noindex，它該有的權限控管一樣不能少，否則只是沒出現在搜尋結果，資料本身還是暴露的。SEO 設定與存取控制是兩層防護，不能互相取代。
2.2 建立任務、簽署流程與範本的中間步驟頁
SaaS 產品常見的操作流程，例如建立任務時的「指定欄位」「準備文件」步驟頁、簽署流程的中間頁、範本編輯的各步驟頁，這些都是流程進行中的暫態頁面。它們沒有獨立的搜尋價值，使用者也不可能直接從 Google 搜尋進來。放進 sitemap 只會製造一堆瘦內容頁，稀釋整站的品質訊號，還會讓爬蟲在這些沒有意義的暫態頁上空轉。這類頁面還有一個麻煩：它們常常因為流程狀態不同而衍生出大量網址，內容卻幾乎一樣，對 Google 來說就是一堆重複又單薄的頁面。與其讓搜尋引擎去消化這些暫態頁，不如把精力放在寫一頁把這個功能的用途、使用方式、能解決什麼問題講清楚的內容頁，那頁才是真正能從搜尋帶來訪客的資產。
2.3 整合介面頁與嵌入用的 frame 頁
整合功能常會有一批 /integration/ 底下的頁面，像是授權驗證、綁定、以及各種內嵌用的 frame 頁面。這些頁面是設計給系統之間串接或嵌入其他平台用的，不是給人直接瀏覽的。它們出現在搜尋結果裡不但沒幫助，還會讓使用者一頭霧水，點進去看到的是一個半截的介面或空白頁。這類頁面一律排除，沒有例外。要區分的是，介紹「我們支援哪些整合、怎麼串接」的說明頁是有搜尋價值的內容頁，該保留；真正要排除的是那些實際執行串接、嵌入動作的技術性頁面。兩者容易被混為一談，判斷時還是回到那句老問題：陌生人從搜尋進到這頁，看得懂、用得上嗎。
2.4 一張清單快速判斷
| 頁面類型 | 典型網址前綴 | 是否放進 sitemap | 原因 |
|---|---|---|---|
| 後台管理 | /admin/… | 排除 | 登入後介面，對搜尋無價值 |
| 使用者設定 | /settings/… | 排除 | 個人操作頁，含隱私疑慮 |
| 建立任務流程 | /create-task/… | 排除 | 流程中間步驟，瘦內容 |
| 整合介面 | /integration/… | 排除 | 系統串接用，非給人瀏覽 |
| 範本編輯 | /template/… | 排除 | 操作暫態頁，無獨立價值 |
| 簽署流程 | /sign-and-send/… | 排除 | 流程頁，無法從搜尋進入 |
| 產品、功能、文章 | /features/、/blog/… | 保留 | 面向搜尋使用者的內容 |
3. crawl budget 到底要不要在意
談到排除功能頁，一定會有人問：我的站又沒幾萬頁，crawl budget 有差嗎？這是個好問題，答案要看規模，但方向不變。我們先把實話講在前面，再說為什麼排除這件事不只跟 crawl budget 有關。
3.1 中小型網站的 crawl budget 影響確實有限
我們先講實話。crawl budget 的緊繃程度跟網站規模高度相關。如果你的網站總頁數沒有超過一萬頁，Google 通常有足夠的爬取能力把該爬的都爬完，清掉幾百個功能頁，對整體爬取效率的提升不會立竿見影。這一點我們不會誇大。如果有人告訴你，小站清一清 sitemap 就能讓排名大漲，那多半是把因果講過頭了。排名是內容品質、相關性、連結、體驗等眾多因素共同作用的結果，sitemap 整理頂多是把基礎整乾淨，讓該被看見的內容不被雜訊拖累，它不是一個能單獨拉動排名的槓桿。把它放在正確的期待值上，才不會做了沒效果就誤以為白忙一場。
3.2 但排除功能頁的理由不只是 crawl budget
重點來了。就算 crawl budget 對你不是瓶頸，排除功能頁還是該做，因為它牽涉的是索引品質而非只是爬取效率。功能頁被索引會帶來三個問題：一是瘦內容與重複內容拉低整站的品質評價，二是後台與設定頁被索引有隱私與安全風險，三是使用者從搜尋點進一個操作頁面會困惑，傷害體驗。這三件事跟你有幾頁沒關係。所以我們的建議一向是：即使影響不大，還是修，因為成本很低而風險實在。小投入、低風險、明確有益，這種事沒有不做的理由。
3.3 大型網站則要把 crawl budget 當資源分配來管
當網站成長到數萬、數十萬頁，crawl budget 就會從「不太需要在意」變成「必須主動管理」。這時候你要把爬蟲的每一次來訪當成有限資源來分配。我們的做法是讓 sitemap 只保留真正想被索引、且會定期更新的內容頁，把爬蟲的注意力集中導向這些頁面，讓新內容跟更新能被更快發現。爬蟲的力氣花在哪，你的重要內容就在哪被優先處理，這在大型網站上是實打實的差別。
3.4 真正吃掉 crawl budget 的往往是參數網址
大型網站的 crawl budget 殺手，常常不是功能頁，而是帶參數的網址。篩選、排序、分頁、追蹤參數這些組合，會讓同一批內容衍生出成千上萬個幾乎一樣的網址，爬蟲一個個去爬，力氣全耗在重複內容上。我們處理大型站時，除了排除功能頁，更會花心力在收斂這些參數網址，例如用 canonical 指回乾淨的主網址、避免產生無意義的參數組合連結。如果你的站規模夠大又有大量篩選功能，這部分對爬取資源的影響，往往比功能頁大得多，值得優先檢查。
4. sitemap 排除之後，還要配套哪些設定
把功能頁從 sitemap 拿掉只是第一步，單靠 sitemap 不會阻止 Google 爬到或索引這些頁面。你還需要幾個配套，否則排除等於只做了一半。
4.1 sitemap 移除不等於禁止索引
我們在實務上看過有人以為「從 sitemap 拿掉，Google 就不會索引了」，這是誤解。sitemap 只是推薦清單，拿掉頁面只代表你不再主動推薦，但 Google 若透過站內連結還是爬得到，照樣可能索引。要真正阻止索引、讓頁面不該出現在搜尋結果，該用的是 noindex 標籤；要阻止爬取，才用 robots.txt。兩者用途不同，別搞混，這是整個配套裡最容易出錯的一環。實務上，這些功能頁往往被站內的按鈕、選單、流程連結指來指去，Google 光靠這些站內連結就能一路爬進去，sitemap 有沒有列它根本不是重點。所以正確的做法是把 sitemap 移除、頁面 noindex 兩件事一起做，前者不再主動推薦，後者才真正擋住索引，缺了後者，前者等於白做。
4.2 noindex 與 robots.txt 的取捨
這裡有個常被弄反的細節：如果你在 robots.txt 裡封鎖了某個路徑，Google 連進去讀 noindex 標籤的機會都沒有，反而可能因為外部連結而把這個「被封鎖但有連結」的網址收進索引，只是不顯示內容。我們的做法是：想讓頁面確實不被索引，先允許爬取並掛 noindex，等索引清乾淨後，再視情況用 robots.txt 節省爬取。順序反了會弄巧成拙，這是經驗裡反覆驗證過的坑。換個方式理解這兩者的分工：noindex 管的是「要不要出現在搜尋結果」，robots.txt 管的是「要不要讓爬蟲進來」。一個頁面要真正消失在搜尋裡，關鍵動作是 noindex，而 noindex 必須被讀到才有效，所以在清索引的階段，千萬別急著用 robots.txt 把門關上。等到確定索引裡已經沒有這些頁面，而你又想進一步省下爬取，再封鎖也不遲。
4.3 lastmod 要誠實，不要每頁都標今天
sitemap 裡每條網址可以附上 lastmod，告訴 Google 這頁最後更新的時間。這個欄位要誠實反映實際的更新時間，因為 Google 會參考它來決定要不要重新爬。我們看過有些系統把全站每一頁的 lastmod 都自動標成當天，結果 Google 很快就學會不信任這個訊號，因為它顯然不是真的。正確做法是讓 lastmod 對應內容真正被修改的時間，沒更新的頁面就維持舊日期。一份誠實的 lastmod，能幫爬蟲把力氣花在真正有變動的頁面上，這跟排除功能頁其實是同一個目的：讓爬取資源用在刀口上。
4.4 用 Search Console 驗證成效
設定完之後，我們會定期看 Search Console 的「頁面索引」報告，確認那些功能頁有沒有從索引裡逐步退出，以及 sitemap 提交的頁面有沒有被正常收錄。這個報告是你判斷設定有沒有生效最直接的依據，別靠感覺，要靠數據。看到功能頁陸續退出索引、內容頁穩定被收錄，才代表整套配套從移除、標記到驗證真的做對了。報告裡若出現「已檢索但未建立索引」或「已找到但未建立索引」這類狀態，也值得一併觀察，它們往往透露出還有哪些頁面被 Google 認為價值不足，順著這些線索回頭看，常能發現漏網的功能頁或瘦內容頁。
5. 常見問題
5.1 網站頁數不多，還需要整理 sitemap 嗎
需要。就算 crawl budget 對小站影響不大，把功能頁排除仍能避免瘦內容拉低品質評價、避免後台頁被索引的隱私風險，也讓使用者不會從搜尋點進操作頁。這些理由跟頁數多寡無關，而修正成本很低。小站不做的唯一理由是覺得沒差，但它其實有差，只是差在品質與安全，不在爬取效率。而且小站因為頁數少，每一頁在整站品質評價裡的比重反而更高，混進一批瘦內容功能頁，拉低的幅度可能比大站更明顯，所以小站更沒有省略這一步的理由。
5.2 從 sitemap 移除頁面，Google 就不會索引它了嗎
不會。sitemap 只是推薦清單，移除只代表不再主動推薦。只要站內有連結指過去，Google 仍可能爬到並索引。要確實不被索引，需要對頁面加上 noindex 標籤，sitemap 移除只是其中一環。把這兩件事當成同一件事，是排除功能頁最常見的失誤。
5.3 該用 noindex 還是 robots.txt 擋這些功能頁
看目的。想讓頁面不出現在搜尋結果，用 noindex，而且要讓 Google 爬得到才讀得到這個標籤；想單純節省爬取，才用 robots.txt。若先用 robots.txt 封鎖，Google 讀不到 noindex，反而可能收錄一個沒有內容的網址。建議先 noindex，索引清乾淨後再考慮封鎖爬取。很多情況下，功能頁其實本來就被登入驗證擋在外面，Google 根本看不到內容，這時候 sitemap 排除加 noindex 就足夠，不一定非得動到 robots.txt。先用最單純、最不容易出錯的組合，有需要再往上加，是比較穩的順序。
5.4 簽署流程或建立任務的中間頁，真的一頁都不留嗎
這些流程中間頁對搜尋使用者沒有獨立價值，使用者也不會從 Google 直接進入某個操作步驟，所以我們建議一律排除。真正該保留並經營的，是介紹這個功能怎麼用、能解決什麼問題的內容頁，而不是流程本身的暫態頁面。把力氣放在內容頁，而不是替暫態頁爭取曝光。判斷的準則始終一致：這頁是讓已經在產品裡的人操作用的，還是讓還在搜尋的人認識產品用的，前者排除、後者保留，不會有太多灰色地帶。
5.5 crawl budget 有沒有辦法直接看到數字
可以參考 Search Console 的「檢索統計資料」報告，裡面有每天的檢索要求數、回應時間等指標。它不會給你一個叫做 crawl budget 的數字，但能讓你觀察爬蟲來訪的頻率與花費，判斷爬取資源是否吃緊。對大型網站來說，這份報告是評估要不要進一步管理爬取的重要依據。如果看到回應時間拉長、或檢索要求數碰到明顯的上限，通常就是該認真處理爬取效率的訊號了。
5.6 整理好 sitemap 後，多久會看到效果
爬取效率的變化通常不會立即反映，Google 需要時間重新檢索與更新索引，一般數週內會在「頁面索引」報告看到功能頁陸續退出索引。與其等某個時間點，不如把這份報告當成觀測窗口，看趨勢往乾淨的方向走就對了。索引品質的改善是逐步的，耐心看趨勢比盯著單日數字有意義。要退出索引的頁面數量越多，整個過程拖得越久，因為 Google 是依自己的節奏逐批重新檢索這些頁面的，你無法強迫它一次處理完。這段期間只要確認方向對、功能頁在往外退、內容頁穩定留著，就不需要反覆調整設定，頻繁變動反而會打亂它的判斷。