XML Sitemap 怎麼做：該提交哪些 URL（2026）
XML Sitemap 不是越全越好。本文講清哪些 URL 應該提交，哪些不該進 sitemap，以及提交後怎麼驗證。
XML Sitemap 不是越全越好。本文講清哪些 URL 應該提交，哪些不該進 sitemap，以及提交後怎麼驗證。
很多網站一提 XML Sitemap，就預設它是 SEO 基礎動作，必須有，而且越全越好。這個判斷不算完全錯，但經常太粗。因為 Google 對 sitemap 的態度其實一直很明確：它是一個幫助發現 URL 的工具，不是收錄保證書，也不是排名按鈕。站內結構本身清楚，很多頁 Google 也能自己找到；站內結構混亂，光把 URL 塞進 sitemap 也救不了根本問題。
所以，XML Sitemap 真正值得講的，不是“要不要有”，而是三件事：什麼時候它真的有用，應該把哪些 URL 放進去，哪些看起來像規範做法的欄位其實 Google根本不看。尤其在 2025-2026 這種更強調抓取效率、URL 治理和頁面質量的環境下，sitemap 更像一個治理工具，而不是禮儀動作。
這篇文章就只講一個問題：XML Sitemap 到底該怎麼做，哪些站值得認真維護，哪些 URL 不該放進去，`lastmod` 應該怎麼用，大站又該什麼時候拆分 sitemap index。把這些判斷做清楚，比“網站上線先生成一個 sitemap.xml”更有用。
先把這個結論定住。Google 在 What is a sitemap 和 Build and submit a sitemap 裡講得很清楚：sitemap 可以幫助 Google 更高效地發現你認為重要的 URL，但它不保證這些 URL 一定會被抓取或收錄。
也就是說，sitemap 更像“我建議你優先看這些 URL”，不是“我提交了你就必須收”。如果頁面本身質量差、規範化混亂、重複嚴重、根本不值得索引，放進 sitemap 也不會把壞頁變好頁。
| sitemap 能做什麼 | sitemap 不能做什麼 | 更適合怎麼理解 |
|---|---|---|
| 幫助發現 URL | 不保證一定收錄 | 是發現層工具 |
| 提示哪些 URL 更重要 | 不直接提升排名 | 是抓取輔助訊號 |
| 幫助提交大站和複雜站的 URL 集 | 不能替代站內連結結構 | 要和內鏈一起用 |
不是每個站都同樣依賴 sitemap。Google 官方給的判斷很務實：如果站點很大、很新、外鏈少、媒體內容多，或者有些重要 URL 不容易靠普通內鏈被發現，那麼 sitemap 會更有用。反過來，如果站點很小、結構清楚、重要頁都能透過導航和內鏈穩定到達，sitemap 當然還是可以有，但它不是決定性的。
Google 在文件裡甚至直接說了一個很實用的邊界：大約 `500` 頁以內、而且站內連結做得清楚的小站，可能並不強依賴 sitemap。這個判斷不是鼓勵你刪掉 sitemap，而是提醒你別把它當成第一優先順序。相關邊界在 sitemap overview 裡本來就講得很直白。
| 網站型別 | sitemap 的重要性 | 原因 |
|---|---|---|
| 新站、外鏈少 | 高 | Google 發現路徑本來就少 |
| 大站、URL 多 | 高 | 靠普通內鏈更容易漏頁 |
| 圖片/影片較多 | 中高 | 擴充套件 sitemap 更容易幫助發現媒體資源 |
| 小站、結構清楚 | 中 | 有益，但不是唯一依賴項 |
很多站點的問題，不在於缺 sitemap，而在於 sitemap 太髒。比如把引數頁、標籤頁、搜尋結果頁、分頁變體、canonical 指向別處的頁、`noindex` 頁、軟 404 頁統統塞進去。這樣做的結果，不是“提交更全”，而是向 Google 反覆提交低價值 URL。
Google 在 build sitemap 文件裡寫得很直接：你應該在 sitemap 裡列出你希望出現在搜尋結果裡的 canonical URL。這個口徑其實已經夠用了。凡是不想讓它成為結果頁的 URL，就別往 sitemap 裡硬塞。
這也是為什麼 sitemap 治理，最好和 Index Bloat、引數 URL 治理、Canonical 衝突 放在一起看。你提交給 Google 的 URL 集，本身就代表你對站內價值頁的判斷。
如果要把 sitemap 做乾淨，這個判斷必須先有。通常不建議放進去的，包括：
換句話說，sitemap 不是“站記憶體在過的所有 URL 清單”，而應該更接近“當前值得被 Google 發現和考慮收錄的 URL 清單”。
這個點很重要。Google 在 build sitemap 文件裡明確說明：它會使用 `
更合適的做法是：只有頁面發生了真正重要的變化，才更新 `
| 頁面變化 | 適不適合更新 lastmod | 原因 |
|---|---|---|
| 主內容明顯更新 | 適合 | 對使用者和搜尋結果都有實際影響 |
| 結構化資料或重要內鏈調整 | 適合 | 頁面理解訊號發生變化 |
| 僅改頁尾年份 | 不適合 | 不屬於顯著內容更新 |
| 自動重新生成檔案但內容沒變 | 不適合 | 會降低 lastmod 的可信度 |
很多舊教學還在講 sitemap 裡要認真填 `priority`、`changefreq`。但 Google 的 build sitemap 文件已經寫得很清楚：Google 會忽略這兩個值。也就是說，這兩個欄位不是今天做 sitemap 最佳化的重點。
真正值得花時間的，不是猜“首頁優先順序該填 1.0 還是 0.8”，而是把 URL 集做乾淨，把 canonical 關係做清楚，把 `
如果 sitemap 很大，或者 URL 型別很多，拆分 sitemap index 就很有必要了。Google 官方的限制很明確：單個 sitemap 最多 `50,000` 個 URL，或者 `50MB` 未壓縮大小。超過這個邊界，就該拆分。這個限制和拆分方式，在 large sitemaps 文件裡寫得很清楚。
所以”什麼時候拆”有個硬邊界(接近5萬/50MB必拆),但更實用的拆法是按 URL 型別拆——這不只是為了滿足上限。
更實用的做法，通常不只是因為超限才拆，而是按 URL 型別拆。比如：
這樣做的好處，不只是滿足上限，還方便你在 Search Console 裡分開看不同 URL 集的提交和索引狀態。Google 在 sitemap index file 文件裡，也給了這條路。
WordPress、Shopify、Wix 這類 CMS 確實通常會自動生成 sitemap。Google 也在文件裡提到，很多 CMS 已經會幫你完成這一層。但自動生成，不等於自動正確。尤其當站點本身會生成大量標籤頁、篩選頁、引數 URL、作者歸檔、空分頁時，CMS 自動 sitemap 也可能把不該提交的 URL 一起帶進去。
所以更合適的做法不是“有就行”，而是至少週期性抽查：
這一步和 Search Console 週報工作流 放在一起做，很適合。
如果站點的圖片、影片本身就是搜尋入口，單獨處理媒體 sitemap 會更有意義。Google 在 image sitemaps 文件裡就講得很清楚：如果圖片比較難靠普通 HTML 被發現，image sitemap 能提供額外幫助。影片、新聞也有類似的擴充套件做法。
但前提還是一樣：只有這些媒體資源本身值得被發現、頁面也希望出現在搜尋裡，擴充套件 sitemap 才有意義。不是所有站都需要一上來把所有擴充套件都堆滿。
sitemap 提交上去以後，不要停在“已成功提交”這一步。更有用的觀察方式，是看它有沒有在幫你更快發現和管理 URL。最常見的檢查點包括：
如果 sitemap 裡列了一大堆頁，但 Search Console 里長期顯示這些頁都被排除、被 canonical 到別處、被判低價值，那問題就不在提交動作，而在 URL 集本身。
如果只給企業站一套更實用的順序，我會更建議這樣做：
這套順序的重點，不在“生成一個檔案”，而在“把你希望 Google 優先看的 URL 集治理清楚”。
很多人把 sitemap 當作技術附件。其實不是。你把哪些 URL 放進去，哪些不放，本身就在暴露一件事：你到底知不知道自己站裡哪些頁值得被發現，哪些頁只是系統噪音。
真正有用的 sitemap，不是最大、最全、最花哨，而是乾淨、準確、可信。把這三件事做好，sitemap 才會成為抓取和索引的助力，而不是另一層混亂來源。