小網站一份 sitemap.xml 就夠用，但當頁面數量往上衝，單一檔案很快就撐不住。我是吳承學，做 SEO 二十年，經手過從幾百頁到數十萬頁的網站。這篇要談的是大型網站該怎麼用 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。理論上單一索引檔能涵蓋二十五億個網址，對絕大多數網站綽綽有餘。但如果真的是超大型網站，索引檔也可以分層，用一個上層索引檔指向多個下層索引檔。我很少需要用到分層，但知道有這條路，規劃時心裡比較踏實。
2. 我依什麼邏輯把網址分進不同檔案
能塞進上限只是及格，怎麼分才是關鍵。亂拆和有邏輯地拆，對後續維護與診斷的差距很大。
2-1 依內容類型拆，我最常用
我最常用的是依內容類型拆分：產品一個檔、文章一個檔、分類頁一個檔、靜態頁一個檔。這樣做的好處是診斷方便。當搜尋引擎回報某類頁面索引率偏低，我可以直接對照那一個 sitemap 的涵蓋率，一眼看出是哪一類出問題，而不是在幾十萬個混在一起的網址裡大海撈針。
2-2 依更新頻率拆，我用來管理抓取節奏
第二種邏輯是依更新頻率。變動頻繁的內容（例如每天新增的商品、時常更新的文章）放一組，長期不動的內容（例如關於我們、條款頁）放另一組。搭配 lastmod，搜尋引擎能把抓取心力放在真的有更新的檔案上。我處理過一個內容量大的匿名媒體型網站，把高頻更新和低頻更新分開後，新內容被抓到的速度明顯比全部混在一起時來得順。
2-3 兩種邏輯我怎麼取捨
類型和頻率不是二選一，實務上我常疊著用：先按類型分大類，同一大類裡再依更新頻率細分。下面這張表是我規劃時的對照。
| 拆分邏輯 | 適合情境 | 主要好處 |
|---|---|---|
| 依內容類型 | 頁面種類多、模板差異大 | 診斷索引問題時能快速定位 |
| 依更新頻率 | 部分內容頻繁更新 | 引導抓取集中在有變動的檔案 |
| 類型加頻率混用 | 大型且結構複雜的網站 | 兼顧定位與抓取效率 |
3. 每個子 sitemap 我要求做到的品質
檔案拆好了，內容本身的品質才是決定 sitemap 有沒有幫上忙的地方。放進去的網址如果品質不齊，反而會拖累判斷。
3-1 只放可索引的最終網址，這條不妥協
sitemap 裡我只放狀態碼 200、可被索引、canonical 指向自己的最終網址。被 noindex 的頁、會轉址的網址、canonical 指去別頁的版本，都不該出現在 sitemap。我看過太多網站的 sitemap 混進一堆 301 或 noindex 頁面，這等於給搜尋引擎一份充滿雜訊的清單，降低它對你整份地圖的信任。不論你拆了幾層，最後每個子 sitemap 都要能連到真正的頁面。
3-2 lastmod 要誠實，我很在意這點
lastmod 標的是這一頁內容真正被更新的時間，不是你重跑一次程式的時間。如果每次產生 sitemap 都把所有頁面的 lastmod 刷成今天，搜尋引擎很快就會發現這個時間不可信，之後就不太理會它。我的要求是 lastmod 只在內容確實變動時才更新，讓它保持誠實，這樣它引導抓取的價值才會被保留。
3-3 提交與監控，我當成例行工作
拆好的 sitemap 索引檔要提交到搜尋引擎的站長工具，並定期看它回報的涵蓋數字。我看的是「送出的網址數」和「實際被索引的網址數」之間的落差。落差集中在哪一個子 sitemap，就代表那一類頁面有問題，可能是內容太薄、可能是被別的訊號擋住。這種按檔案追的診斷方式，正是我一開始就堅持依類型拆分的原因。
4. 分割做對了，對大站索引的實際幫助
拆 sitemap 不只是為了繞過檔案上限，它對大型網站被索引這件事有實質作用。
4-1 它讓搜尋引擎更快發現新頁與更新
大型網站光靠爬蟲順著連結爬，要爬完所有頁面曠日費時，深層的頁面更容易被漏掉。一份結構清楚、lastmod 誠實的 sitemap，等於直接把「這裡有新東西」「這裡剛更新」告訴搜尋引擎，讓它不必完全依賴自己慢慢爬。對頁面又多又深的網站，這個差別很有感。
4-2 它讓我能量化診斷，而不是靠猜
依類型拆分之後，每個子 sitemap 就是一個可觀測的單位。哪一類頁面索引率好、哪一類差，數字擺在那裡。我因此能把有限的優化時間投在真正落後的那一類，而不是憑感覺全站亂改。下面這張表整理我用子 sitemap 涵蓋率做判斷的方式。
| 觀察到的落差 | 可能原因 | 我的下一步 |
|---|---|---|
| 某類送出多、索引少 | 內容太薄或高度相似 | 檢查該類內容品質與重複度 |
| 整份索引偏低 | 抓取資源被雜訊消耗 | 清掉 sitemap 內的無效網址 |
| 新內容遲遲未收 | lastmod 不可信或未提交 | 修正 lastmod 並重新提交 |
4-3 它不是索引保證，我會誠實說清楚
我要講清楚一件事：把頁面放進 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 反映真實更新時間、產生失敗時要有可觀測的錯誤而不是回傳一個壞掉的檔案。動態產生本身沒問題，出問題的往往是產生邏輯沒顧好。