先講結論：XML sitemap 裡的 priority 欄位對排名沒有作用，Google 公開講過不看，changefreq 同理。真正還被讀、而且直接牽動 AI 爬蟲抓取效率的，只有 lastmod 一個欄位。如果你的 sitemap 每次產生就把所有網址的 lastmod 蓋成當天，你不是在幫爬蟲，是在訓練它不再相信這份清單。這篇要談的，是怎麼把 XML sitemap 設定成一份爬蟲願意採信的變更紀錄，讓 GPTBot、ClaudeBot、PerplexityBot 用最少的抓取次數，抓到你最新的頁面。
sitemap 的工作不是排名，是抓取與索引效率
sitemap 不會把任何一頁往排名上推，它是一份「這些網址存在、這些最近變過」的清單。頁面數少於幾百、內部連結乾淨的小站，其實有沒有 sitemap 差別不大，Google 爬一爬就找齊了。它真正有價值的場景很集中：網站規模大、有深層或沒人連到的孤兒頁、內容更新頻繁，或者你希望爬蟲盡快注意到某次改動。AI 爬蟲對這份清單特別敏感，因為它們的抓取預算比 Google 更省，也沒有 Search Console 這種後台可以提交，能靠的線索比你想的少。
lastmod：唯一還有人讀、也最容易被搞砸的欄位
Google 這邊的說法很一致：它會參考 lastmod，但前提是這個值誠實。一旦系統發現你每次重新產生 sitemap，就把整站 lastmod 全寫成今天，它會直接把這個欄位的可信度打到零，之後你就算真的改了重要內容，訊號也傳不出去。所以 lastmod 該反映的是內容實質變動的那一刻，不是樣板調整，也不是一次全站重新部署的時間戳。這個分寸，多數 CMS 的預設設定都抓錯。
- 用 W3C Datetime 格式並帶時區，例如 2026-07-02T14:30:00+08:00，不要只寫一個日期。
- 只在內容實質變動時更新：修錯字、換一張裝飾圖、微調 CSS 都不算。
- 別把網站 build 時間或資料庫的 updated_at 直接拿來當 lastmod，那會讓每次部署都謊報整站更新。
- sitemap index 裡每個子檔也要有自己的 lastmod，指向該群組內最近一次真正的變動。
- 如果技術上做不到誠實的 lastmod，寧可整個欄位留空，也好過每天全站報「今天」。
priority 與 changefreq：填了也沒人在看
Google 的工程師在公開場合講得很白：priority 完全不列入考量，changefreq 也一樣，Bing 的態度接近。如果你的 CMS 自動填了這兩欄，留著無妨，但別派工程師去糾結某頁該給 0.8 還是 0.6，那個數字不會改變任何抓取或排名結果。priority 唯一還有點用處的地方，是逼你自己想清楚哪些頁面最重要，而那是給你看的，不是給演算法看的。
AI 爬蟲怎麼找到、怎麼用你的 sitemap
GPTBot、ClaudeBot、PerplexityBot、CCBot、Google-Extended 這些 AI 爬蟲，沒有 Search Console 可以讓你提交網址。它們最穩定的發現管道只有一條：robots.txt 裡的 Sitemap 指令。少了這一行，你就只能指望它們順著連結慢慢摸進來。宣告好之後，準確的 lastmod 會讓它們跳過沒變動的頁面，把有限的抓取次數花在新內容上，這正是你要的，因為 GEO 的目標是被引用，不是被爬到伺服器發燙。
大站怎麼拆 sitemap，把索引效率拉滿
單一 sitemap 檔案有硬性上限：最多 50,000 個網址，或未壓縮 50MB，取先到者。超過就得拆分，再用一份 sitemap index 把它們統整起來，而 index 本身也能容納最多 50,000 個子 sitemap。實務上更好的做法不是等到爆檔才拆，而是一開始就依內容類型分檔，這樣你在 Search Console 能分別看到每一群的索引覆蓋率，哪個內容叢集出了索引問題一眼就看得出來。
- 依內容類型分檔：sitemap-blog.xml、sitemap-docs.xml、sitemap-product.xml，各自獨立回報覆蓋率。
- 每檔守住 50,000 個網址或未壓縮 50MB 的上限，超過再拆，用 sitemap index 統整。
- 大檔用 gzip 壓縮成 sitemap.xml.gz，協定允許，也省頻寬。
- 把最可能被 AI 引用的高價值頁，例如定價、比較、FAQ、案例，集中在更新頻繁、lastmod 最準的那幾檔。
- 別把 noindex、被 canonical 指到別頁、或會回 4xx／5xx 的網址放進來，那會稀釋整份清單的可信度。
別再 ping 了：2023 之後的變更通知怎麼做
Google 已經在 2023 年停用 sitemap 的 ping 端點，Bing 也跟進，現在對著 /ping?sitemap= 打請求不會有任何效果。替代做法有三層：維持準確的 lastmod，讓爬蟲照自己的節奏回訪時能判斷該不該重抓；在 Search Console 提交一次 sitemap，之後不必反覆送；針對 Bing 與 Yandex，用 IndexNow 在網址層級即時推送變更通知。要提醒的是，Google 不吃 IndexNow，AI 爬蟲多半也只靠自己的回訪排程加上你的 lastmod，所以真正一次牽動所有爬蟲的槓桿，還是 lastmod 的紀律。
上線前的 sitemap 檢查清單
- robots.txt 有 Sitemap 指令，指向可公開存取的 sitemap 網址。
- lastmod 反映真實內容變動，格式帶時區，沒有整站同一天的情況。
- sitemap 只收回 200、可索引的頁面，排除 noindex 與被 canonical 指走的網址。
- 單檔沒超過 50,000 網址或 50MB，大站用 sitemap index 依內容類型分群。
- 在 Search Console 提交過一次，並核對「已探索」數字與實際頁數是否吻合。
把這幾件事做對，你的 sitemap 就從一份沒人信的例行檔案，變回爬蟲和 AI 引擎都願意採用的變更來源。多數團隊的問題不在少了哪一頁，而在 lastmod 全站說謊、sitemap 裡混進一堆不可索引的網址，這些從外面用工具掃一遍就會現形。想知道自己的 sitemap 和整體技術 AEO 設定漏在哪，可以預約一場 30 分鐘 GEO 診斷（/contact），我們會直接指出最該先修的幾個點。
