sitemap 是什麼？產生、提交與 Google 實際會讀的欄位
TL;DR
- sitemap 的作用是幫搜尋引擎「發現」網址，官方明講它不保證這些網址會被收錄
- 四個標籤裡只有
<loc>是必填，changefreq與priorityGoogle 完全不使用 lastmod是唯一還有作用的選填欄位，但填不實會被降低信任，不確定就留空- 提交 sitemap 的 ping 端點 2023 年已停用，現在只剩 Search Console、Search Console API、robots.txt 三條路
- 用
xmllint可以自己驗證格式，但有一種錯誤是正常的，不能一律當成問題
目錄
sitemap 解決的是發現，不是收錄
一份 sitemap 的結構，以及四個標籤裡的必填項
changefreq 與 priority，Google 明講不使用
lastmod 是唯一還有作用的選填欄位
怎麼產生：內建、外掛、線上產生器
ping 端點已經停用，提交只剩三條路
自己驗一次：xmllint 與兩種要分開讀的錯誤
提交 2,059 個網址之後實際發生的事
引言
sitemap（網站地圖）是一個看起來很單純的東西：一個 XML 檔，裡面列出網站有哪些網址。多數網站平台會自動產生，網址通常就是 你的網域/sitemap.xml。
麻煩的地方在於，這個檔案的規格是 2005 年訂的，十五年沒有改過，但搜尋引擎實際會讀哪些欄位，這些年一直在變。結果是網路上多數的 sitemap 教學裡，有相當比例的內容在講已經沒有作用、甚至已經被移除的東西。
這篇把三件事分開講：規格怎麼寫、Google 實際上讀什麼、以及提交之後你能自己驗證到什麼程度。
sitemap 解決的是發現，不是收錄
先把期待調對，後面的操作才有意義。
Google 官方文件的說法很直接：「sitemap 可協助搜尋引擎找出您網站上的網址，但無法保證系統會檢索及索引 sitemap 中的所有項目。」
換句話說，sitemap 是發現階段的工具。它讓爬蟲知道有哪些網址存在，至於要不要抓、抓了要不要收進索引、收了要不要拿出來給人看，是後面三道各自獨立的判斷，sitemap 一道都管不到。
同一份文件也給了一個判斷要不要做的門檻：如果網站規模小、而且內部連結完整，可能不需要 sitemap。官方對「小」的定義是大約 500 頁以內。
這個門檻的意思不是「500 頁以下就別做」。內部連結完整是前提——如果有些頁面只能從網址直接進入、沒有任何頁面連過去，那不論網站多小，爬蟲都沒有路徑走過去。sitemap 在這種情況下是唯一的發現管道。
實務上做一份的成本很低（多數平台自動產生），而它換來的是 Search Console 裡多一個檢查點：你可以看到 Google 讀到了幾個網址、有沒有解析錯誤。這個檢查點本身比 sitemap 的排名作用有價值得多。
一份 sitemap 的結構，以及四個標籤裡的必填項
一份最小可用的 XML sitemap 長這樣：
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
<lastmod>2026-08-28</lastmod>
</url>
</urlset>
依照 sitemaps.org 的協定，<urlset>、<url>、<loc> 三個是必要的，<lastmod>、<changefreq>、<priority> 都是選填。也就是說，一個網址真正非填不可的，只有網址本身。
幾個規格層面的限制值得記住：
- 單一檔案上限 50,000 個網址，或 50MB（未壓縮），兩個條件先到的算。超過就要拆成多份，再用一個 sitemap 索引檔（sitemap index）把它們列起來，提交索引檔即可。
- 檔案必須是 UTF-8 編碼。
- 位置決定管轄範圍：協定的規定是，放在
http://example.com/catalog/sitemap.xml的 sitemap，可以列http://example.com/catalog/底下的網址，但不能列http://example.com/images/底下的。Google 的文件也提到，除非是透過 Search Console 提交，否則 sitemap 只影響上層目錄的子項目。所以放在網站根目錄是最單純的做法。
還有一個細節每隔一陣子就有人問：xmlns 那串網址寫的是 http:// 而不是 https://。這是正確的，不用改。那串字是給解析器辨識命名空間用的識別字，不是要連過去的網址。Google 在公告裡特地為這件事寫了一句「請不要再回報這個文件問題」。
changefreq 與 priority，Google 明講不使用
這一段的結論最單純。
Google 在 2023 年 6 月的官方公告裡寫得毫無模糊空間：「Google 仍然完全不使用 changefreq 或 priority 這兩個元素。」
理由也有講。changefreq（預估更新頻率）在概念上和 lastmod 重疊；priority（頁面相對權重）則是一個高度主觀的欄位，依他們的內部研究，它通常無法準確反映一個頁面相對於站內其他頁面的實際重要性。
其實協定本身早就把話講在前面了。sitemaps.org 對 priority 的說明是：「您指派給頁面的優先層級，不太可能影響網址在搜尋結果頁的位置。」它的原始設計只是用來在你自己站內的頁面之間排順序，從來就不是對外的排名訊號。
所以調 priority 這件事沒有可預期的效果。留著不會有害，只是不會有作用——本站的 sitemap 目前也還在輸出這兩個欄位，那是平台的預設行為，我沒有特別去拿掉，因為拿掉同樣不會有任何變化。真正值得花時間的是下一個欄位。
lastmod 是唯一還有作用的選填欄位
同一份 2023 年的公告裡，Google 對 lastmod 的態度和前兩者相反：他們說現在 lastmod 在許多情況下確實有用，並且會拿它當作訊號，用來排定已發現網址的重新檢索時程。
要讓它真的有用，有兩個條件。一是日期格式要對，格式定義在 sitemaps.org，提交之後 Search Console 會告訴你有沒有問題；這一項照著填不太會錯。
真正會出事的是第二項：內容要和事實一致。官方的說法很白，如果你的頁面七年前就沒動過，卻在 lastmod 裡說它昨天改過，最後的結果是他們不再相信你提供的修改日期。這是整份公告裡語氣最重的一句，值得照字面理解——這個欄位是有信任成本的，填錯不是沒效果，是會扣分。
還有一個多數教學不會提的定義問題：這裡的「最後修改」指的是最後一次重大修改。如果 CMS 只是改了側欄或頁尾的一段無關文字，不需要更新 lastmod；但如果改的是主要內文、增修了結構化資料、或是調整了連結，就應該更新。
以及一個實用的許可：你可以只對有把握的頁面填 lastmod。 官方明確說，有些網站軟體不容易判斷首頁或分類頁的最後修改時間，因為那種頁面只是聚合其他頁面的內容；這種情況把 lastmod 留空是可以的。
這一點反過來說更重要：與其讓系統對全站每個頁面都塞一個不準的日期，不如只填得出來的那些。常見的錯誤做法是每次重新產生 sitemap 就把所有頁面的 lastmod 設成今天，這正是會讓 Google 停止採信的行為。
怎麼產生：內建、外掛、線上產生器
依照網站的狀況，實際上只有三種選擇。
網站平台內建。 多數 CMS 與網站建置平台會自動產生並持續更新，網址固定在 /sitemap.xml。這是最不費工也最不容易出錯的一種，因為它跟著內容資料庫走——新增一篇文章，sitemap 下一次被讀取時就有了。如果你的平台有這個功能，其他兩種都不用考慮。
CMS 外掛。 WordPress 這類系統如果核心產生的 sitemap 不夠用（例如要排除特定文章類型、或要加圖片與影片的擴充欄位），會用外掛處理。要注意的是不要同時開兩套——兩個外掛各自產生一份、或核心與外掛同時輸出，會出現內容不一致的兩個檔案。
線上 sitemap 產生器。 輸入網址、它幫你爬過一遍、產出一個檔案讓你下載，再自己上傳到網站根目錄。這類工具有一個必須先講清楚的限制：它產出的是一次性的快照。 網站之後新增或刪除頁面，這個檔案不會跟著變，需要重新產生、重新上傳。所以它適合的情境是純靜態網站、或是拿來做一次性的檢查（例如比對「我以為有的頁面」和「爬得到的頁面」差在哪裡），不適合當作長期方案。
免費版通常也會有頁數上限，超過的部分會被截斷，這一點在使用前值得先確認。
ping 端點已經停用，提交只剩三條路
這是目前中文教學裡過時比例最高的一段。
過去可以用一個 HTTP 網址直接通知 Google 你的 sitemap 更新了，格式是 google.com/ping?sitemap=...。這個端點已經停用。 Google 在 2023 年 6 月 26 日的公告宣布廢止，六個月後停止運作，文件上現在標示的狀態是「已完成」。現在打那個網址得到的是 404。
停用的理由講得相當坦白：這種不需驗證身分的提交方式已經沒什麼用處，而且以 Google 搜尋的情況來說，絕大多數的提交都是垃圾訊息。公告裡也提到 Bing 有相同的觀察。
一個附帶的好消息是，如果你的網站或外掛裡還留著呼叫這個端點的程式碼，不必急著改——官方說既有的程式碼不會對 Google 搜尋造成問題，只是那個呼叫不會有任何作用。
現在能用的方式，官方文件列出這幾種：
| 方式 | 適用情況 |
|---|---|
| Search Console 的 Sitemap 報表 | 一般網站的主要做法，可以看到讀取時間與解析錯誤 |
| Search Console API | 要用程式自動提交時 |
| robots.txt 加一行 | 不需要登入任何後台，也適用於 Google 以外的搜尋引擎 |
| WebSub | 只適用於 Atom 或 RSS 形式的 feed |
robots.txt 的寫法是在檔案裡任何一行加上：
Sitemap: https://example.com/sitemap.xml
這一行無論如何都值得加：不需要驗證擁有權，其他搜尋引擎的爬蟲讀 robots.txt 時也會看到，等於一次對所有人宣告。Search Console 那邊則另外提交一次，換取那個看得到錯誤訊息的檢查點。
要在 Search Console 提交，前提是網站已經完成驗證。這一步如果卡住，可以參考 Search Console 驗證教學；資源類型的選擇與報表怎麼讀，在 Search Console 設定教學。
至於 sitemap 之外的即時通知，目前的替代方案是 IndexNow——由 Microsoft Bing 與 Yandex 提出的協定，內容新增或更新時主動推送一次。它和 sitemap 是互補關係，不是取代。
自己驗一次：xmllint 與兩種要分開讀的錯誤
sitemap 有官方的 XML Schema（XSD，一份用來定義「這種 XML 該長什麼樣」的規格檔），所以格式對不對是可以在本機直接驗的，不必等 Search Console 回報。
macOS 與多數 Linux 內建 xmllint：
curl -sO https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd
curl -s https://example.com/sitemap.xml -o sitemap.xml
xmllint --noout --schema sitemap.xsd sitemap.xml
寫這篇時我拿本站的 sitemap 跑了一次，結果沒有通過，訊息有兩種。這兩種的意義完全不同，值得分開講——因為驗證不通過本身，不一定代表有問題。
第一種是元素順序。 XSD 對 <url> 底下的子元素用的是 xsd:sequence，也就是有規定順序：loc → lastmod → changefreq → priority，其他命名空間的元素排在最後。本站的產生器把 lastmod 寫在 changefreq 與 priority 之後，所以每一個網址都被判定為「不預期的元素」。
這是實實在在的規格偏差。Google 的解析器夠寬鬆，這些網址一直都被正常讀取，實務上沒有造成後果——但排錯順序沒有任何好處，還會讓驗證輸出被大量雜訊灌滿，真正該修的問題反而看不到。所以這個順序已經修掉了，改完之後這一類錯誤全部消失。
第二種是 hreflang。 多語言網站會在 sitemap 裡用 <xhtml:link rel="alternate" hreflang="..."> 標示各語言版本，這是 Google 官方文件建議的做法。但 sitemap 的 XSD 對外來命名空間用的是 processContents="strict" 的萬用字元——白話說就是「這裡可以放別的命名空間的元素，但我必須查得到它的定義」，而 sitemap 的 schema 並沒有引入 xhtml 的定義，所以查不到、直接判錯。
所以修完順序之後再驗一次，lastmod 那一類錯誤消失了，hreflang 那一類原封不動還在。也就是說：只要用了 Google 自己建議的 hreflang 寫法，這份 sitemap 就不可能通過官方 XSD 的嚴格驗證。 這不是可以修好的東西，是兩份規格對不起來。
結論是驗證工具的輸出要逐條看，不能只看最後那句「fails to validate」。順序、日期格式、網址跳脫這類是真的要修；hreflang 造成的那一條是兩份規格之間的落差，不必處理，更不需要為了讓驗證通過而把 hreflang 拿掉。
提交 2,059 個網址之後實際發生的事
最後回到第一段那句「sitemap 不保證收錄」。這句話在多數文章裡是一句免責聲明，但它的實際比例長什麼樣，很少有人給數字。
我手上有一個規模夠大的例子。一個我自己經營的台南在地目錄網站，sitemap 目前列出 2,059 個網址。從 2026 年 7 月 5 日到 8 月 27 日這 54 天裡，Search Console 的搜尋成效報表中曾經出現過的頁面是 1,332 個，累計 18,678 次曝光、285 次點擊。
也就是說，提交的網址裡約有 65% 在這段期間至少被人在搜尋結果裡看到過一次。剩下的 727 個沒有出現。
這個差額要謹慎解讀，它不等於「727 頁沒被收錄」。有曝光的頁面一定在索引裡，但反過來不成立——一個頁面可能已經被收錄，只是這段期間剛好沒有人搜到會讓它出現的字。要精確區分，得逐一用網址審查工具查，那是另一回事。
即便如此，方向是清楚的：提交網址與拿到曝光之間，有一段相當長的距離，而 sitemap 只負責最前面那一小段。
另一個對照更極端。本站在 2026 年 8 月 27 日完成 Search Console 設定並提交 sitemap，裡面有 6 個網址。隔天查，搜尋成效報表回傳的資料是 0 筆——不是數字小，是連一列都沒有。新資源的資料不會回填，所以在那之前的空白也補不回來。
這不是設定有問題，是新網站本來就會經過的一段。把它記下來的用意是給後面的觀察一個基準點：提交是 8 月 27 日，那天全站曝光為 0。之後第一筆曝光出現在哪一天、多久之後開始有連續的資料，會是這個站接下來會持續記錄的東西。
sitemap 該做，五分鐘就能做完，而且是後面所有觀察的起點。但它能為你做的，就只有「讓爬蟲知道這些網址存在」這一件事。
參考來源
常見問題
小網站也需要做 sitemap 嗎？
Google 官方文件的說法是，如果網站規模小而且內部連結完整，可能不需要 sitemap，對「小」的定義是大約 500 頁以內。
但「內部連結完整」是前提。若有頁面只能透過網址直接進入、站內沒有任何連結指過去，爬蟲就沒有路徑可走，這時不論網站多小，sitemap 都是唯一的發現管道。做一份的成本很低，換來的是 Search Console 裡多一個可以看到讀取狀況與解析錯誤的檢查點。
changefreq 與 priority 要怎麼設定？
不需要設定。Google 在 2023 年 6 月的官方公告中明確表示，仍然完全不使用 changefreq 與 priority 這兩個元素。
sitemaps.org 的協定本身也寫明，指派給頁面的 priority 不太可能影響網址在搜尋結果頁的位置，它原本只是用於同一網站內部頁面之間的相對排序。留著這兩個欄位不會有害，但調整它們沒有可預期的效果。
還可以用 ping 網址通知 Google sitemap 更新嗎？
不行。Google 於 2023 年 6 月 26 日公告廢止 sitemap 的 ping 端點，六個月後停止運作，目前請求該網址會得到 404。理由是這種不需驗證身分的提交方式已無實際用處，且絕大多數提交屬於垃圾訊息。
現行的方式是 Search Console 的 Sitemap 報表、Search Console API，以及在 robots.txt 加上 Sitemap: 一行。若既有程式碼還在呼叫舊端點，官方表示不會造成問題，只是不會有任何作用。
sitemap 提交之後多久會被收錄？
沒有可承諾的時間，而且提交本身不保證收錄——這是官方文件的明文說明。sitemap 只負責讓搜尋引擎「發現」網址，要不要檢索、要不要納入索引、要不要在搜尋結果中呈現，是後續各自獨立的判斷。
以一個列出 2,059 個網址的目錄網站為例，54 天內在 Search Console 搜尋成效報表出現過的頁面是 1,332 個，約六成五。全新網域的網站則可能在提交後數日內完全沒有任何資料，這屬於正常情形。
sitemap 用 xmllint 驗證沒通過，一定要修嗎？
要看錯誤類型。元素順序錯誤（官方 XSD 規定的順序是 loc、lastmod、changefreq、priority）、日期格式錯誤、網址未正確跳脫，這些是真的要修。
但如果錯誤來自 <xhtml:link rel="alternate" hreflang="...">，那是規格之間的落差：sitemap 的 XSD 對外來命名空間使用 processContents="strict" 的萬用字元，而它並未引入 xhtml 的定義，因此會判錯。這個寫法本身是 Google 官方文件建議的做法，不需要為了讓驗證通過而移除。
留言討論
只有會員能留言（防止垃圾訊息），留言顯示於此頁。