sitemap 是什麼？產生、提交與 Google 實際會讀的欄位

TL;DR

• sitemap 的作用是幫搜尋引擎「發現」網址，官方明講它不保證這些網址會被收錄
• 四個標籤裡只有 <loc> 是必填，changefreq 與 priority Google 完全不使用
• 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 解決的是發現，不是收錄

多數人對 sitemap 的期待，都比它實際能做的高一點，而這個落差會一路影響後面每個欄位該怎麼填。

Google 官方文件沒有留餘地：「sitemap 可協助搜尋引擎找出您網站上的網址，但無法保證系統會檢索及索引 sitemap 中的所有項目。」

關鍵在「找出」這兩個字。sitemap 是發現階段的工具，它負責讓爬蟲知道有哪些網址存在；至於要不要去抓、抓了要不要收進索引、收了要不要在有人搜尋時拿出來，是後面三道各自獨立的判斷，而 sitemap 一道都插不上手。

既然作用只到「發現」為止，接下來的問題就變成：什麼情況下 Google 靠自己就找得到？同一份文件給了門檻——網站規模小、而且內部連結完整的話，可能不需要 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 明講不使用

這兩個欄位大概是 sitemap 教學裡被寫得最多、實際作用卻最小的部分。Google 在 2023 年 6 月的公告裡沒有留任何模糊空間：「Google 仍然完全不使用 changefreq 或 priority 這兩個元素。」

他們也解釋了為什麼。changefreq（預估更新頻率）跟 lastmod 在概念上是重疊的——既然 lastmod 已經指出上次改動是什麼時候，再補一句「大概多久改一次」就沒有多少額外資訊；至於 priority（頁面相對權重），依他們的內部研究，這個欄位太主觀，通常反映不出一個頁面相對於站內其他頁面的真實重要性。

比較少人注意到的是，協定本身早就把話講在前面了。sitemaps.org 對 priority 的說明白紙黑字寫著「您指派給頁面的優先層級，不太可能影響網址在搜尋結果頁的位置」——它從一開始就只是設計來在你自己站內的頁面之間排順序，不是對外的排名訊號。會被當成排名旋鈕來調，是後來以訛傳訛的結果。

所以這兩個欄位怎麼填都不會有可預期的效果。留著不至於有害，只是不會有作用；本站的 sitemap 目前也還在輸出它們，那是平台的預設行為，我沒有特別去拿掉，因為拿掉同樣不會有任何變化。真正會改變 Google 行為的是下一個欄位。

lastmod 是唯一還有作用的選填欄位

同一份 2023 年的公告裡，Google 對 lastmod 的態度和前兩者相反：他們說現在 lastmod 在許多情況下確實有用，並且會拿它當作訊號，用來排定已發現網址的重新檢索時程。

要讓它真的有用，有兩個條件。第一個是日期格式要對，格式定義在 sitemaps.org，提交之後 Search Console 會告訴你有沒有問題，照著填不太會錯。

第二個條件才是會出事的地方：內容要和事實一致。官方的說法很白——如果你的頁面七年前就沒動過，卻在 lastmod 裡說它昨天改過，最後的結果是他們不再相信你提供的修改日期。這句話在整份公告裡語氣最重，也應該照字面理解：這個欄位帶著信任成本，填錯不是沒效果，是會扣分，而且扣的是整份 sitemap 的可信度，不只那一頁。

還有一個多數教學不會提的定義問題：這裡的「最後修改」指的是最後一次重大修改。如果 CMS 只是改了側欄或頁尾的一段無關文字，不需要更新 lastmod；但如果改的是主要內文、增修了結構化資料、或是調整了連結，就應該更新。

以及一個實用的許可：你可以只對有把握的頁面填 lastmod。 官方明確說，有些網站軟體不容易判斷首頁或分類頁的最後修改時間，因為那種頁面只是聚合其他頁面的內容；這種情況把 lastmod 留空是可以的。

這一點反過來說更重要：與其讓系統對全站每個頁面都塞一個不準的日期，不如只填得出來的那些。常見的錯誤做法是每次重新產生 sitemap 就把所有頁面的 lastmod 設成今天，這正是會讓 Google 停止採信的行為。

怎麼產生：內建、外掛、線上產生器

把上面兩節的結論放在一起看，你要的其實是一份「網址列得齊、lastmod 講實話」的檔案。依照網站的狀況，能達成這件事的做法有三種。

網站平台內建。 多數 CMS 與網站建置平台會自動產生並持續更新，網址固定在 /sitemap.xml。這是最不費工也最不容易出錯的一種，因為它跟著內容資料庫走——新增一篇文章，sitemap 下一次被讀取時就有了。如果你的平台有這個功能，其他兩種都不用考慮。

CMS 外掛。 WordPress 這類系統如果核心產生的 sitemap 不夠用（例如要排除特定文章類型、或要加圖片與影片的擴充欄位），會用外掛處理。要注意的是不要同時開兩套——兩個外掛各自產生一份、或核心與外掛同時輸出，會出現內容不一致的兩個檔案。

線上 sitemap 產生器。 輸入網址、它幫你爬過一遍、產出一個檔案讓你下載，再自己上傳到網站根目錄。這類工具有一個限制必須先講清楚：它產出的是一次性的快照。 網站之後新增或刪除頁面，這個檔案不會跟著變，需要重新產生、重新上傳。它適合的情境因此限縮在純靜態網站、或是拿來做一次性的檢查（例如比對「以為存在的頁面」和「實際爬得到的頁面」差在哪裡），不適合當作長期方案。

免費版通常另外有頁數上限，超過的部分直接被截斷，而它不會提醒你——用之前先確認頁數在額度內，否則產出來的是一份缺頁的 sitemap。

ping 端點已經停用，提交只剩三條路

檔案準備好之後才輪到提交，而這一步的資訊過時得最嚴重——網路上多數中文教學教的方法，現在按下去只會拿到 404。

過去可以用一個 HTTP 網址直接通知 Google 你的 sitemap 更新了，格式是 google.com/ping?sitemap=...。這個端點已經停用。 Google 在 2023 年 6 月 26 日的公告宣布廢止，六個月後停止運作，文件上現在標示的狀態是「已完成」，而實際去打那個網址，拿到的是 404。

停用的理由講得相當坦白：這種不需驗證身分的提交方式已經沒什麼用處，而且以 Google 搜尋的情況來說，絕大多數的提交都是垃圾訊息。任何人都能替任何網域按下那個按鈕，這種設計在 2005 年還行得通，放到今天就只剩被濫用的價值——公告裡也提到，Bing 觀察到的情況是一樣的。

一個附帶的好消息是，如果你的網站或外掛裡還留著呼叫這個端點的程式碼，不必急著改——官方說既有的程式碼不會對 Google 搜尋造成問題，只是那個呼叫不會有任何作用。

現在能用的方式，官方文件列出這幾種：

robots.txt 的寫法是在檔案裡任何一行加上：

Sitemap: https://example.com/sitemap.xml

這一行加下去幾乎沒有理由不加：它不需要驗證擁有權，而且其他搜尋引擎的爬蟲在讀 robots.txt 時一樣會看到，等於一次對所有人宣告。robots.txt 本身的語法與常見錯誤，另見 robots.txt 怎麼寫？語法、常見錯誤與 AI 爬蟲。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，AI 爬蟲的行為不同：本站 30 天的紀錄裡，sitemap.xml 的爬取有近八成來自 AI 爬蟲，詳見 AI 爬蟲實測：sitemap.xml 的爬取有近八成來自 AI 而非搜尋引擎。

參考來源

• Sitemap 簡介 - Google 搜尋中心
• 建立及提交 sitemap - Google 搜尋中心
• Sitemaps ping endpoint is going away - Google 搜尋中心網誌，2023 年 6 月 26 日
• sitemaps.org 協定
• 告知 Google 網頁的本地化版本 - Google 搜尋中心