很多 SaaS 網站的 sitemap 我一打開,裡面塞滿了後台管理頁、使用者設定頁、簽署流程的中間步驟頁,甚至還有一堆會直接轉址的網址。這些頁面對搜尋使用者毫無意義,卻大剌剌地被列進 sitemap,等於主動邀請 Google 來爬一堆不該被索引的東西。我是吳承學,做 SEO 二十年,這篇要談 sitemap 該排除哪些功能頁、為什麼要排除,以及 crawl budget 這件事到底該怎麼取捨。
1. sitemap 不是網站地圖,而是一份「推薦清單」
先破除一個觀念。sitemap 不是要你把網站上每一個網址都列進去的「全站目錄」,它是一份你交給 Google 的推薦清單,意思是「這些頁面值得你來看、值得被索引」。當你把後台頁、設定頁也放進去,你傳遞的訊號是「這些也值得索引」,而它們根本不該出現在搜尋結果裡。
1.1 該進 sitemap 的是內容頁,不是功能頁
判斷標準很簡單:一個頁面如果是給搜尋使用者看的內容,例如產品介紹、功能說明、部落格文章、定價頁,它該進 sitemap;如果它是給已登入使用者操作的功能介面,例如後台、帳號設定、簽署流程的某一步,它就不該進。我的做法是先問一句「陌生人從 Google 搜尋進到這頁,合理嗎?」答案是否定的,就從 sitemap 拿掉。
1.2 轉址頁與無效網址是在浪費爬取
我在實務上看過一款電子簽章 SaaS 的 sitemap,裡面含有大量帶特定前綴的網址,像是 /admin/、/settings/、/integration/ 底下的路徑。Google 去爬這些網址時,不是被轉址,就是撞到根本不存在的頁面。每一次這樣的爬取都是白工,爬蟲花在無效網址上的力氣,就是它沒花在你真正想被索引的內容頁上的力氣。
2. 這幾類功能頁,請一律從 sitemap 排除
根據我實際處理過的 SaaS 網站,以下幾類頁面幾乎都該排除。它們的共通點是:面向已登入使用者、屬於操作流程的一環、或本身就會轉址。
2.1 後台管理頁與使用者設定頁
後台管理頁,像是權限設定、使用紀錄、群組管理、組織設定、報表這類 /admin/ 底下的頁面,全部是登入後才有意義的介面,對搜尋使用者零價值。使用者設定頁也一樣,帳號設定、授權清單、偏好設定、個人資料、簽名檔管理這些 /settings/ 底下的頁面,同樣該排除。它們不但不該被索引,若被爬到還可能有隱私與安全上的疑慮。
2.2 建立任務、簽署流程與範本的中間步驟頁
SaaS 產品常見的操作流程,例如建立任務時的「指定欄位」「準備文件」步驟頁、簽署流程的中間頁、範本編輯的各步驟頁,這些都是流程進行中的暫態頁面。它們沒有獨立的搜尋價值,使用者也不可能直接從 Google 搜尋進來。放進 sitemap 只會製造一堆瘦內容頁,稀釋整站的品質訊號。
2.3 整合介面頁與嵌入用的 frame 頁
整合功能常會有一批 /integration/ 底下的頁面,像是授權驗證、綁定、以及各種內嵌用的 frame 頁面。這些頁面是設計給系統之間串接或嵌入其他平台用的,不是給人直接瀏覽的。它們出現在搜尋結果裡不但沒幫助,還會讓使用者一頭霧水。
2.4 一張清單快速判斷
| 頁面類型 | 典型網址前綴 | 是否放進 sitemap | 原因 |
|---|---|---|---|
| 後台管理 | /admin/… | 排除 | 登入後介面,對搜尋無價值 |
| 使用者設定 | /settings/… | 排除 | 個人操作頁,含隱私疑慮 |
| 建立任務流程 | /create-task/… | 排除 | 流程中間步驟,瘦內容 |
| 整合介面 | /integration/… | 排除 | 系統串接用,非給人瀏覽 |
| 範本編輯 | /template/… | 排除 | 操作暫態頁,無獨立價值 |
| 簽署流程 | /sign-and-send/… | 排除 | 流程頁,無法從搜尋進入 |
| 產品/功能/文章 | /features/、/blog/… | 保留 | 面向搜尋使用者的內容 |
3. crawl budget 到底要不要在意
談到排除功能頁,一定會有人問:我的站又沒幾萬頁,crawl budget 有差嗎?這是個好問題,答案要看規模,但方向不變。
3.1 中小型網站的 crawl budget 影響確實有限
我先講實話。crawl budget 的緊繃程度跟網站規模高度相關。如果你的網站總頁數沒有超過一萬頁,Google 通常有足夠的爬取能力把該爬的都爬完,清掉幾百個功能頁,對整體爬取效率的提升不會立竿見影。這一點我不會誇大。
3.2 但排除功能頁的理由不只是 crawl budget
重點來了。就算 crawl budget 對你不是瓶頸,排除功能頁還是該做,因為它牽涉的是索引品質而非只是爬取效率。功能頁被索引會帶來三個問題:一是瘦內容與重複內容拉低整站的品質評價,二是後台與設定頁被索引有隱私與安全風險,三是使用者從搜尋點進一個操作頁面會困惑,傷害體驗。這三件事跟你有幾頁沒關係。所以我的建議一向是:即使影響不大,還是修,因為成本很低而風險實在。
3.3 大型網站則要把 crawl budget 當資源分配來管
當網站成長到數萬、數十萬頁,crawl budget 就會從「不太需要在意」變成「必須主動管理」。這時候你要把爬蟲的每一次來訪當成有限資源來分配。我的做法是讓 sitemap 只保留真正想被索引、且會定期更新的內容頁,把爬蟲的注意力集中導向這些頁面,讓新內容跟更新能被更快發現。爬蟲的力氣花在哪,你的重要內容就在哪被優先處理。
4. sitemap 排除之後,還要配套哪些設定
把功能頁從 sitemap 拿掉只是第一步,單靠 sitemap 不會阻止 Google 爬到或索引這些頁面。你需要幾個配套。
4.1 sitemap 移除不等於禁止索引
我在實務上看過有人以為「從 sitemap 拿掉,Google 就不會索引了」,這是誤解。sitemap 只是推薦清單,拿掉頁面只代表你不再主動推薦,但 Google 若透過站內連結還是爬得到,照樣可能索引。要真正阻止索引,對不該出現在搜尋結果的頁面,該用的是 noindex 標籤;要阻止爬取,才用 robots.txt。兩者用途不同,別搞混。
4.2 noindex 與 robots.txt 的取捨
這裡有個常被弄反的細節:如果你在 robots.txt 裡封鎖了某個路徑,Google 連進去讀 noindex 標籤的機會都沒有,反而可能因為外部連結而把這個「被封鎖但有連結」的網址收進索引,只是不顯示內容。我的做法是:想讓頁面確實不被索引,先允許爬取並掛 noindex,等索引清乾淨後,再視情況用 robots.txt 節省爬取。順序反了會弄巧成拙。
4.3 用 Search Console 驗證成效
設定完之後,我會定期看 Search Console 的「頁面索引」報告,確認那些功能頁有沒有從索引裡逐步退出,以及 sitemap 提交的頁面有沒有被正常收錄。這個報告是你判斷設定有沒有生效最直接的依據,別靠感覺,要靠數據。
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,索引清乾淨再考慮封鎖。
5.4 簽署流程或建立任務的中間頁,真的一頁都不留嗎
這些流程中間頁對搜尋使用者沒有獨立價值,使用者也不會從 Google 直接進入某個操作步驟,所以我建議一律排除。真正該保留並經營的,是介紹這個功能怎麼用、能解決什麼問題的內容頁,而不是流程本身的暫態頁面。
5.5 crawl budget 有沒有辦法直接看到數字
可以參考 Search Console 的「檢索統計資料」報告,裡面有每天的檢索要求數、回應時間等指標。它不會給你一個叫「crawl budget」的數字,但能讓你觀察爬蟲來訪的頻率與花費,判斷爬取資源是否吃緊。
5.6 整理好 sitemap 後,多久會看到效果
爬取效率的變化通常不會立即反映,Google 需要時間重新檢索與更新索引,一般數週內會在「頁面索引」報告看到功能頁陸續退出索引。與其等某個時間點,不如把這份報告當成觀測窗口,看趨勢往乾淨的方向走就對了。