單一份 sitemap.xml 最多只能裝五萬個網址、未壓縮不超過五十 MB，一旦你的頁面往十萬、幾十萬衝，這份檔案很快就撐不住。這時候真正該做的，是用 sitemap 索引檔把地圖拆成多個子檔，再依內容類型和更新頻率有邏輯地分組。重點不在拆了幾份，而在拆得夠不夠有邏輯，好讓你事後能一眼看出哪一類頁面沒被收。我們處理過從幾百頁到數十萬頁的網站，最常見的毛病不是頁面太多，而是全部擠進一兩份檔案裡，出問題時完全無從診斷。這篇講大型網站該怎麼切 sitemap：每個檔案的上限、依什麼邏輯拆、以及為什麼分割得當能實際幫助大站被索引。
1. 我們什麼時候會決定把 sitemap 拆開
拆不拆 sitemap 不是看心情，是有明確門檻的。我們不會為了幾百頁的網站搞一堆檔案，但也不會硬把幾萬頁塞進一份。
1.1 單一 sitemap 的硬限制，我們一定先確認
單一 sitemap 檔案有兩條上限：最多五萬個網址，且未壓縮檔案大小不超過五十 MB。這是規格層級的限制，不是建議。只要你的網址數量接近五萬、或內容欄位多到檔案偏大，就必須拆。我們的習慣是不等到貼著上限才動手，網址數過了兩三萬我們就會開始規劃分割，留餘裕給日後成長。等到爆檔才處理，往往要在最忙的時候重做結構，不如提早分好。
1.2 sitemap 索引檔是什麼，我們怎麼跟團隊解釋
拆開之後，你需要一個 sitemap 索引檔當總目錄。它本身不列網址，而是列出各個子 sitemap 的位置。搜尋引擎讀索引檔，就能找到底下所有子檔案。我們對團隊的比喻是：索引檔是書的目錄，子 sitemap 是各章節，最終每一章都要能翻到實際的頁面。只要這個層級關係清楚，後續維護和診斷都會省事很多。
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-08-01</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-articles.xml</loc>
<lastmod>2026-08-15</lastmod>
</sitemap>
</sitemapindex>1.3 索引檔本身也有上限，別忘了
索引檔一樣受限：一個索引檔最多列五萬個子 sitemap，大小同樣不超過五十 MB。理論上單一索引檔能涵蓋二十五億個網址，對絕大多數網站綽綽有餘。但如果真的是超大型網站，索引檔也可以分層，用一個上層索引檔指向多個下層索引檔。我們很少需要用到分層，但知道有這條路，規劃時心裡會比較踏實，不會被單一檔案的數字綁住。
1.4 壓縮與編碼，是最容易被忽略的兩個細節
那兩條上限還有兩個常被忽略的前提。第一，五十 MB 指的是未壓縮的大小，sitemap 可以用 gzip 壓縮後再提供，搜尋引擎會自己解壓，所以真正傳輸的檔案可以小很多，但判斷是否超標要看解壓後的大小，而不是壓縮後的大小。第二，檔案必須是 UTF-8 編碼、網址要經過正確的跳脫處理，含有特殊字元或中文的網址若沒編碼好，整份檔案可能被判定無效。我們驗收一份新 sitemap 時，除了看網址數與大小，一定會確認編碼正確、XML 格式沒有殘缺，因為一個格式錯誤，往往讓整份檔案連帶失效，這種問題比單純超過上限更難察覺。
我們驗收一份新 sitemap 時，除了看網址數與大小，還會實際挑幾個含中文或特殊字元的網址，確認它們在檔案裡是經過正確跳脫的。我們診斷過一個情況，整份地圖看起來格式沒問題，卻因為少數幾個網址的編碼沒處理好，讓搜尋引擎把整份檔案判為無效，結果幾十萬個網址一起不被讀取。這種錯誤單看網址數與檔案大小完全看不出來，必須打開檔案本身逐段確認編碼與 XML 格式，才揪得出來。一個小小的格式錯誤，代價可能是整份地圖失效。
2. 我們依什麼邏輯把網址分進不同檔案
能塞進上限只是及格，怎麼分才是關鍵。亂拆和有邏輯地拆，對後續維護與診斷的差距很大。
2.1 依內容類型拆，我們最常用
我們最常用的是依內容類型分割：產品一個檔、文章一個檔、分類頁一個檔、靜態頁一個檔。這樣做的好處是診斷方便。當搜尋引擎回報某類頁面索引率偏低，我們可以直接對照那一個 sitemap 的涵蓋率，一眼看出是哪一類出問題，而不是在幾十萬個混在一起的網址裡大海撈針。依類型拆，等於替每一類內容裝了一個獨立的儀表，哪裡異常一看就知道。
依類型拆還有一個好處是權責清楚。大型網站的內容常由不同團隊維護，產品頁歸電商團隊、文章歸內容團隊，sitemap 依類型切開後，哪個檔案該由誰負責、哪個檔案出問題該找誰，一目了然。我們在跟客戶團隊協作時，這種對應能明顯減少來回確認的時間，也讓每個團隊對自己那份地圖的品質更有責任感。
我們實務上決定拆幾層，會先問一個問題：這個站最想用 sitemap 解決什麼。如果最常被索引問題困擾，依類型拆能讓診斷快速定位；如果痛點是新內容被抓得慢，依頻率拆更對症。我們診斷過一個內容量大的站，原本幾十萬個網址全擠在一兩份檔案裡，出問題時完全無從判斷是哪一類頁面拖累，依類型重新切開後，光是定位問題的時間就省了一大半。拆分的價值不在檔案多，而在每一份都對應到一個可觀測、可究責的單位。
2.2 依更新頻率拆，我們用來管理抓取節奏
第二種邏輯是依更新頻率。變動頻繁的內容（例如每天新增的商品、時常更新的文章）放一組，長期不動的內容（例如公司簡介、條款頁）放另一組。搭配 lastmod，搜尋引擎能把抓取心力放在真的有更新的檔案上。我們處理過一個內容量大的匿名媒體型網站，把高頻更新和低頻更新分開後，新內容被抓到的速度明顯比全部混在一起時來得順。抓取資源有限，把會變的和不會變的分清楚，等於幫搜尋引擎省了重複確認的工。
要提醒的是，更新頻率的分組不是一成不變，它該隨內容的實際節奏調整。一個原本低頻的專區若開始頻繁更新，就該把它移到高頻組；反之，曾經熱門、如今定稿不動的內容，也該移出高頻組，免得搜尋引擎一再回來確認卻發現沒有變化。我們會每隔一段時間回看各組的實際變動情況，確認分組還反映真實的更新節奏，而不是沿用當初設定時的假設。
2.3 兩種邏輯我們怎麼取捨
類型和頻率不是二選一，實務上我們常疊著用：先按類型分大類，同一大類裡再依更新頻率細分。這樣既保留了診斷的清楚，又兼顧了抓取效率。要提醒的是，分得太細也會增加維護負擔，所以我們會依網站實際規模拿捏層數，不是切得越碎越好。選哪種邏輯，最終要回到一個問題：你最想用 sitemap 解決什麼。如果你最常被索引問題困擾，依類型拆能讓你快速定位；如果你的痛點是新內容被抓得慢，依頻率拆更對症。我們不會一開始就套用最複雜的結構，而是從網站當下最迫切的需求出發，先拆出能解決眼前問題的版本，再隨規模成長逐步細分。下面這張表是我們規劃時的對照。
| 拆分邏輯 | 適合情境 | 主要好處 |
|---|---|---|
| 依內容類型 | 頁面種類多、模板差異大 | 診斷索引問題時能快速定位 |
| 依更新頻率 | 部分內容頻繁更新 | 引導抓取集中在有變動的檔案 |
| 類型加頻率混用 | 大型且結構複雜的網站 | 兼顧定位與抓取效率 |
3. 每個子 sitemap 我們要求做到的品質
檔案拆好了，裡面放什麼才是決定 sitemap 有沒有幫上忙的地方。放進去的網址如果品質不齊，反而會拖累判斷。
3.1 只放可索引的最終網址，這條不妥協
sitemap 裡我們只放狀態碼 200、可被索引、標準網址指向自己的最終網址。被標示為不索引的頁、會轉址的網址、標準網址指去別頁的版本，都不該出現在 sitemap。我們看過太多網站的 sitemap 混進一堆 301 或不索引頁面，這等於給搜尋引擎一份充滿雜訊的清單，降低它對你整份地圖的信任。不論你拆了幾層，最後每個子 sitemap 都要能連到真正的頁面。
實務上最常混進雜訊的，是分頁參數、篩選條件、站內搜尋結果這類自動生成的網址。它們數量龐大、內容高度相似，一旦被程式無差別地掃進 sitemap，會瞬間稀釋整份地圖的品質。我們會在產生 sitemap 的規則裡就把這些排除掉，只留下有獨立價值、值得被收錄的最終網址。把關的時機放在產生階段，比事後再回頭清理省事得多，也比較不會漏。
我們在產生 sitemap 的規則裡就會把雜訊排除掉，而不是事後再回頭清。最常被誤掃進來的，是分頁參數、篩選條件、站內搜尋結果這類自動生成的網址，它們數量龐大、內容高度相似，一旦無差別地掃進 sitemap，會瞬間稀釋整份地圖的品質。我們的做法是在產生階段就設好白名單，只輸出有獨立價值、值得被收錄的最終網址。把關的時機放在產生端，比事後再回頭清理省事得多，也比較不會漏掉。
3.2 lastmod 要誠實，我們很在意這點
lastmod 標的是這一頁內容真正被更新的時間，不是你重跑一次程式的時間。如果每次產生 sitemap 都把所有頁面的 lastmod 刷成今天，搜尋引擎很快就會發現這個時間不可信，之後就不太理會它。我們的要求是 lastmod 只在內容確實變動時才更新，讓它保持誠實，這樣它引導抓取的價值才會被保留。一個誠實的 lastmod，比一個天天說謊的時間戳有用得多。
3.3 提交與監控，我們當成例行工作
拆好的 sitemap 索引檔要提交到搜尋引擎的站長工具，並定期看它回報的涵蓋數字。我們看的是「送出的網址數」和「實際被索引的網址數」之間的落差。落差集中在哪一個子 sitemap，就代表那一類頁面有問題，可能是內容太薄、可能是被別的訊號擋住。這種按檔案追的診斷方式，正是我們一開始就堅持依類型拆分的原因。沒有這層分組，落差就只是一個全站的模糊數字，看不出問題出在哪。
3.4 圖片與多語系，我們會用對應的標記處理
如果網站很依賴圖片搜尋，或有多語系版本，sitemap 還能承載額外的資訊。圖片可以在對應網址底下用圖片專屬的標記列出，幫助搜尋引擎發現那些藏在版面裡、不易被爬到的圖片；多語系網站則可以在 sitemap 裡標明每個網址的語言與地區對應關係，減少不同語系版本互相被誤判為重複。這些進階用法不是每個網站都需要，但當內容策略確實依賴圖片或多語系時，把這些對應關係放進 sitemap，會比散在各頁面裡更集中、也更好維護。我們通常會視網站的實際需求決定要不要用，不會為了用而用。
4. 分割做對了，對大站索引的實際幫助
拆 sitemap 不只是為了繞過檔案上限，它對大型網站被索引這件事有實質作用。
4.1 它讓搜尋引擎更快發現新頁與更新
大型網站光靠爬蟲順著連結爬，要爬完所有頁面曠日費時，深層的頁面更容易被漏掉。一份結構清楚、lastmod 誠實的 sitemap，等於直接把「這裡有新東西」「這裡剛更新」告訴搜尋引擎，讓它不必完全依賴自己慢慢爬。對頁面又多又深的網站，這個差別很有感。我們診斷過的案例中，深層商品頁補上正確的 sitemap 後，被發現的速度確實改善。
這裡要避免一個誤會：sitemap 加快的是「發現」，不是「排名」。它讓搜尋引擎更快知道頁面存在、更快注意到更新，但頁面最終排到哪裡，仍取決於內容與整站的其他訊號。我們把 sitemap 定位成縮短發現時間的工具，對更新頻繁、頁面又深的大站特別有價值，卻不會把排名的期待押在它身上。期待放對位置，才不會事後覺得它沒用。
我們診斷過的一個案例裡，一個頁面又多又深的站，深層的商品頁長期被發現得很慢，補上結構清楚、lastmod 誠實的 sitemap 之後，這些深頁被注意到的速度確實改善了。要提醒的是，改善的是被發現的速度，不是排名本身；sitemap 讓搜尋引擎更快知道頁面存在、更快注意到更新，但最終排到哪裡，仍取決於內容與整站的其他訊號。把這個定位講清楚，客戶才不會在排名沒動時誤以為 sitemap 沒用。
4.2 它讓我們能量化診斷，而不是靠猜
依類型拆分之後，每個子 sitemap 就是一個可觀測的單位。哪一類頁面索引率好、哪一類差，數字擺在那裡。我們因此能把有限的優化時間投在真正落後的那一類，而不是憑感覺全站亂改。下面這張表整理我們用子 sitemap 涵蓋率做判斷的方式。
| 觀察到的落差 | 可能原因 | 我們的下一步 |
|---|---|---|
| 某類送出多、索引少 | 內容太薄或高度相似 | 檢查該類內容品質與重複度 |
| 整份索引偏低 | 抓取資源被雜訊消耗 | 清掉 sitemap 內的無效網址 |
| 新內容遲遲未收 | lastmod 不可信或未提交 | 修正 lastmod 並重新提交 |
4.3 它不是索引保證，我們會誠實說清楚
我們要講清楚一件事：把頁面放進 sitemap，不等於它一定會被索引。sitemap 是「發現」的輔助，不是「收錄」的承諾。搜尋引擎仍會依內容品質、重複程度、整站健康度來決定要不要收。sitemap 做得再好，內容太薄或大量重複，該不被收還是不會被收。它的角色是幫好內容被更快找到，而不是替壞內容爭取收錄。我們遇過客戶把幾萬個薄頁全丟進 sitemap，以為送出去就會被收，結果索引率不升反降，因為那份地圖本身就在稀釋搜尋引擎對整站的信任。與其塞好塞滿，不如只放你真心希望被看到、也真的值得被看到的頁面。
4.4 拆分之後，維護的節奏要跟上
sitemap 拆好不是一勞永逸，它需要跟著網站一起維護。新增內容類型時要考慮是否該開新的子檔、某類頁面大量下架時要確認對應的 sitemap 有同步移除失效網址、網站改版或換網址結構時更要整份重新檢視。我們的做法是把 sitemap 的健康檢查排進固定的維護週期，和涵蓋率的監控一起看。一份長期沒人管的 sitemap，很容易累積一堆早已失效或轉址的網址，慢慢又變回當初那份充滿雜訊的清單。維護的節奏跟上了，分割帶來的診斷價值才守得住。
5. 常見問題
5.1 我的網站不到一萬頁，需要拆 sitemap 嗎
通常不需要。單檔上限是五萬個網址，一萬頁一份檔案綽綽有餘。但如果你想用依類型拆分來方便診斷，即使頁數不多也可以主動拆，這是為了管理方便，不是為了突破上限。小站主動拆的好處是日後成長時結構已經就緒。
5.2 sitemap 索引檔要放在哪裡
放在網站根目錄、用固定網址對外，並在站長工具提交這個索引檔的網址即可，不需要一個個提交底下的子 sitemap。搜尋引擎讀了索引檔就會自己去找子檔案。你也可以在 robots.txt 裡標明 sitemap 的位置，讓爬蟲多一個入口能找到它。
5.3 一個網址可以同時出現在兩個子 sitemap 嗎
技術上不會報錯，但我們不建議。同一網址重複列在多個檔案，會讓涵蓋率統計變得難以判讀，也沒有實際好處。我們的原則是每個網址只歸屬一個子 sitemap，清楚不重疊，事後追問題時數字才對得上。
5.4 lastmod 一定要填嗎
不是強制，但我們強烈建議填，而且要誠實填。誠實的 lastmod 能幫搜尋引擎判斷哪些頁面值得優先重新抓取。反過來，如果你填的是假時間或每次都刷成今天，它的參考價值會被搜尋引擎降低，那還不如不填。
5.5 拆成很多小檔案會不會反而拖慢抓取
不會。多讀幾個檔案的成本很低，遠比讓搜尋引擎在一份巨大檔案裡處理來得單純。真正拖慢抓取的是 sitemap 裡塞滿無效網址，而不是檔案數量。重點在內容品質，不在檔案多寡，把無效網址清乾淨比糾結檔案數更實在。
5.6 我可以用程式動態產生 sitemap 嗎
可以，大型網站幾乎都是動態產生的。要注意的是產生邏輯要正確：只輸出可索引的最終網址、lastmod 反映真實更新時間、產生失敗時要有可觀測的錯誤而不是回傳一個壞掉的檔案。動態產生本身沒問題，出問題的往往是產生邏輯沒顧好。
5.7 拆分後要不要保留舊的單一 sitemap？
不建議同時留著。舊的單一檔案如果還掛在站長工具裡，會和新的索引檔各報一套數字，反而讓涵蓋率統計變得難以判讀。我們的做法是拆分上線、確認新索引檔能被正常讀取之後，就把舊的單一 sitemap 從站長工具移除，並讓它回傳正確的狀態碼。過渡期可以短暫並存以確認新結構沒問題，但確認無誤後一定要收掉，免得兩份地圖的數字互相干擾，日後追問題時對不上。