網站 sitemap XML 是一份符合標準形狀的 XML 文件，列出站長希望爬蟲知道的頁面 URL——或以 index 形式，列出其他 sitemap 檔的位置——而取得一份，通常不是在眾所周知的路徑找到檔案，就是從你已信任的 URL 複製 XML 文字。無論哪種情況，實際檔案都是純文字，這也是為什麼能在筆電上處理，不必伺服器、部署管線或即時爬取。
XML 到手之後，下一步是用它做點有用的事。原始 sitemap.xml 檔很少本身就是交付物。多數工作流程要的是乾淨、去重、一行一 URL 的頁面清單，以便貼進試算表、爬蟲檢查表、重新導向稽核、紀錄比對或發行審查。把標記轉成那份清單，是小型瀏覽器工具的工作，不是伺服器呼叫，而這正是 Sitemap URL Extractor 的用途。
整個轉換在本機執行。你把一份 urlset 或 sitemapindex 文件的完整 XML 文字貼進編輯器、執行擷取，工具就把直接的 loc 值回傳成去重、已排序的清單——不上傳檔案，也不跟隨它發現的任何連結。之後你可以把清單交給狀態檢查器、canonical 審查器、robots 稽核器，或 search-console 拉取。
XML 內部：urlset 與 sitemapindex
網站地圖協定定義了兩種結構，兩者之間的選擇會形塑下游的一切。urlset 形式是頁面項目的扁平清單；每個 <url> 元素含有直接的 <loc> 子項，存放絕對 HTTP 或 HTTPS URL。sitemapindex 形式是 sitemap 檔的目錄，而不是頁面的遞迴包，其中每個 <sitemap> 項目含有指向另一份 sitemap XML 文件的直接 <loc>。兩種形式都可以使用預設命名空間，或 sm:urlset、sm:url、sm:loc 這類一致的前綴。
像 <?xml version="1.0" encoding="UTF-8"?> 這類 XML 宣告，以及任何註解，都會被忽略。<lastmod>、<changefreq>、<priority> 這類選用子項不會改變擷取出的位置。<image:loc> 這類擴充位置不會用來替代缺失的頁面 loc，因為它們描述的是不同的資源角色。知道你面對的是哪一種根，是擷取器回報的第一件證據，通常也能回答「這個檔應該包含什麼」。
網站上 sitemap XML 的常見位置
多數網站把 sitemap 放在一小組眾所周知的路徑。協定不強制名稱，但 /sitemap.xml 是事實上的預設，也是第一個該檢查的地方。較大的網站把內容拆成多個檔，並在 /sitemap_index.xml 或 /sitemap-index.xml 暴露主索引。常見 CMS 慣例會加上平台前綴：WordPress 在版本 5.5 之後通常發布 /wp-sitemap.xml，Shopware 暴露 /sitemap/shop_index.xml，許多靜態網站產生器預設把 /sitemap.xml 放在網站根目錄。
若明顯路徑回傳 404，第二個該看的地方是 /robots.txt。Sitemaps 協定允許網站在那裡用諸如 Sitemap: https://example.com/sitemap.xml. 這樣的列宣告一個或多個 sitemap 位置。搜尋引擎也會找 rel="sitemap" 的 HTTP Link 回應標頭，不過這比 robots.txt 參照少見。Cloudflare 前置的網站常透過 worker 或 page rule 改寫其中一條路徑，因此檔案可能活在與 CMS 所暗示略有不同的 URL 上。
檔案無法到達時，次佳來源是產出公開檔的 CMS 匯出、建置產物，或測試環境部署。壓縮會造成差異：協定允許 .gz sitemap，且許多工具只提供壓縮形式。在擷取器外把 sitemap.xml.gz 解壓縮，是把 sitemap XML 轉成純文字工作的一部分。任何人若反著跑這套流程——把已審查的 URL 清單轉回 XML——可以用 XML Sitemap Generator 產生符合標準形狀的文件，不必爬取線上網站。
把 sitemap XML 貼進 Sitemap URL Extractor
- 把一份 urlset 或 sitemapindex 文件的完整 XML 文字貼進編輯器。XML 宣告與註解會被忽略，只考慮每個 <url> 或 <sitemap> 項目下找到的直接 <loc> 值。
- 執行擷取。結果會回報偵測到哪種根類型、正規化後接受了多少唯一 URL、移除了多少重複，以及依首次出現順序保留的完整去重清單。
- 用內建複製控制把一行一 URL 的清單複製到剪貼簿，再把該清單分流到分開的即時狀態、canonical、robots 與索引檢查。
擷取結果告訴你什麼
每次成功執行的頂部會出現三項證據。偵測到的 root type 確認貼上的是 urlset 頁面清單還是 sitemapindex 目錄；把這點提前呈現，可避免把 sitemap 檔 URL 當成頁面 URL 的常見意外。unique count 是通過去重後序列化 URL 的數量，以及 duplicate count 則是有多少 loc 值因正規化成文件中稍早已見過的值而被移除。
重複通常是線索，而不是失敗。像 https://Example.com:443/page 與 https://example.com/page 這類預設連接埠或主機大小寫變體，會收斂成同一個值，因為擷取器使用瀏覽器的 WHATWG URL 實作來正規化每個 loc。在試算表審查時把那些重複放在分開的欄，往往能揭示之後又會在爬蟲報告出現的正規化缺口。WHATWG URL 標準是主機如何被轉成小寫、預設連接埠如何被剝除、非 ASCII 路徑字元如何被百分比編碼的底層參照。
這裡有一個單來源失敗情況很重要：當輸入超過 50,000 個唯一 URL 界限，或五百萬個 UTF-16 碼元的輸入界限，整次執行會失敗，而不是回傳截斷清單。這是刻意的，因為把部分清單誤當成完整清單，比一句清楚的「用較小的檔再跑一次」更糟。Google Search Central — Build and submit a sitemap 說明了該限制背後的檔案大小與經由 index 拆分慣例。
擷取器會檢查什麼，對上仍需要線上驗證的是什麼
擷取器對剖析嚴格、對假設寬鬆。它保證 XML 形狀與 loc 值合理，但不會對線上網站如何表現下結論。在清單進入稽核試算表之前，這條分界值得記熟。
| 關注點 | 擷取器處理 | 需要線上網站檢查 |
|---|---|---|
| 有效的 urlset / sitemapindex 結構 | 是 | — |
| 五個預先定義的 XML 實體與有效數值參照已解碼 | 是 | — |
| 僅絕對 HTTP/HTTPS loc 值，少於 2,048 個字元 | 是 | — |
| 依正規化 href 值去重 | 是 — 保留首次出現 | — |
| 50,000 個唯一 URL / 5M 個 UTF-16 碼元上限 | 是 — 整次執行失敗 | — |
| .gz sitemap 解壓縮 | 否 | 是 — 在工具外解碼 |
| 遞迴抓取 sitemapindex 子項 | 否 | 是 — 分開抓取每個子檔 |
| HTTP 狀態、重新導向、canonical 標籤 | 否 | 是 |
| robots.txt 與 meta robots 指令 | 否 | 是 |
| 實際的搜尋引擎索引 | 否 | 是 |
讀這張表是團隊內對齊預期最快的方式。擷取器回答「XML 是否有效、它列出了什麼」，而右欄的一切回答「線上 URL 的行為是否如 sitemap 所暗示」。
貼上之前值得知道的限制
協定把每個 sitemap 上限設為 50,000 個 URL 與未壓縮 50 MB；大型網站遠在這些數字之下就拆內容，並從 sitemapindex 參照子檔。超過擷取器的 50,000 個唯一 URL 界限會讓執行失敗，因此把大檔拆成帶較小子項的 index 是常見作法。任何超過界限的內容，應在重跑前先包裝成 index。
剖析器刻意對一小組邊界情況嚴格。DTD 宣告、自訂實體宣告、<loc> 內的巢狀標記、未知 XML 實體，以及不完整項目，會讓擷取失敗，並帶有指向問題位置的編號參照。拒絕是刻意的：把部分清單當成完整清單呈現，比請使用者修正來源更糟。格式錯誤的 XML 或缺失的結束標籤不會被修復——工具拒絕猜測標籤該落在哪。憑證、URL 片段、相對路徑、非 HTTP scheme，以及反斜線，在 loc 這一側也一律拒絕，任何解碼後長於 2,048 個字元的 loc 都會失敗。
剖析錯誤通常指向兩個地方之一。要嘛檔案從錯誤的根開始——有人貼了 RSS feed、追蹤像素清單，或搜尋結果頁——要嘛命名空間前綴混用不一致（例如多數項目用 sm:url，其中一項卻用 <url>）。在重跑前先修正這些，比切換工具選項更快，而且位置提示夠精確，足以驅動來源文件裡的尋找取代。
把清單拿去用
去重清單一進剪貼簿，工作就轉成線上網站證據。擷取器沒跑的四項檢查——狀態碼、canonical 標籤、robots 指令，以及索引狀態——各自需要自己的工具，也各自回答不同的稽核問題。
- 狀態碼抓住意外的 404、軟 404，以及 sitemap 沒提到卻多一跳的重新導向鏈。對擷取出的清單跑，而不是對內部資料庫跑，才能浮現使用者實際看到的結果。
- Canonical 標籤確認 sitemap 指向的 URL，是否就是頁面宣告為自身的 URL。兩者不符，是中型網站較常見的索引錯誤之一。
- robots.txt 與 meta robots 指令可以在 URL 已出現在 sitemap 時仍悄悄封鎖它。把清單搭配分開的 robots 檢查，能不含糊地揭示那些被擋的項目。
- 搜尋控制台的索引涵蓋範圍，點名搜尋引擎實際收在索引裡的 URL。拿它跟 sitemap 清單比對，能同時找出孤兒頁與過度承諾的檔。
sitemap XML 只證明某個 URL 出現在結構中，並通過擷取器已揭露的驗證；它不證明索引、排名、canonical 化或可爬性。把擷取出的清單當成更廣稽核試算表中的一欄，在決策重要時把它錨在線上爬蟲的證據上，並在測試環境清冊變更時再看一次——上線前的 URL 清冊留在裝置上，除非被複製出去，因為整套工作流程都是純用戶端。
若你正在權衡方案，從 URL 清單建置時的 Sitemap 協定規則 有詳細說明。
若你正在權衡方案，從 Sitemap 擷取所有 URL 成乾淨清單 有詳細說明。