從 sitemap 中擷取所有 URL，代表的是將單一 XML 文件轉換成一份乾淨、一行一個 URL 的清單，並去除周圍的標記。最終結果是純文字，人類可以快速掃讀、試算表可以匯入，或爬蟲檢查清單可以拿來與前一版釋出內容比對。Sitemap XML 檔案或 sitemap index 本質上是一個圍繞著重複出現的 loc 元素的小型外殼；一旦把那些 loc 值抽取出來，其他欄位在擷取 URL 的目的下就變成了雜訊。Sitemap URL Extractor 會在您的瀏覽器中以本地方式處理這項轉換，方式是辨識 Sitemaps 通訊協定所定義的兩種結構、解碼合規檔案所使用的有限實體集、以瀏覽器的 URL 解析器正規化每個 URL、依照首次出現的順序去除重複項目，最後將完整清單放到剪貼簿中。不會上傳任何資料，因此私密的測試環境 sitemap 都會留在裝置上，而下方所述的接受大小與結構規則，說明了這個本地管線在實際運作時的行為。
擷取作業實際回傳的內容
每份標準 sitemap 都屬於下列兩種根元素類型之一：urlset，列出頁面層級的位置；或 sitemapindex，列出其他 sitemap 檔案。擷取工具會讀取根元素，然後直接走訪每個 loc 子元素。對 urlset 而言，這代表每個 url 項目的直接 loc 子元素會成為一行輸出。對 sitemapindex 而言，同樣的規則套用於每個 sitemap 項目的直接 loc 子元素，因此輸出的是 sitemap 檔案 URL 的清單，而非這些檔案中所包含的頁面。
解碼後的值會先通過瀏覽器的 WHATWG URL 解析器才會被接受。解析器會將主機名稱轉為小寫、移除預設埠號、視需要將非 ASCII 的路徑字元進行百分比編碼，並拒絕任何非絕對 HTTP 或 HTTPS URL 的內容。任何帶有憑證、片段識別符、原始空白字元、格式錯誤的百分比編碼、反斜線，或非網頁協定的項目都會被直接捨棄，而不是嘗試修復。工具會回報找到了哪一種根元素類型、接受了多少個不重複的 URL，以及在正規化過程中移除了多少個重複項目，因此只要快速看一下面板，就能知道來源是乾淨的 urlset、子檔案的索引，還是解析器無法接受的內容。
| 根元素 | 來源 XML | 您會得到的內容 |
|---|---|---|
| urlset | url 項目清單，每個都帶有直接 loc 子元素 | 每個頁面層級位置一行，已去除重複 |
| sitemapindex | sitemap 項目清單，每個都帶有直接 loc 子元素 | 每個子 sitemap 檔案 URL 一行；不會展開這些檔案中所包含的頁面 |
首次出現的順序會被保留下來，因此輸出結果仍然容易與來源比對：結果中的第 N 行對應到解析器所遇到的第 N 個有效 loc。如果重複數量意外偏高，常見的原因包括預設埠號變體（例如 example.com:80 對 example.com）、主機名稱大小寫混用（例如 Example.com 對 example.com），以及 WHATWG 解析器會正規化掉的尾端斜線或百分比編碼差異。每次執行時追蹤重複數量，也是快速發現從不一致來源重建而成 sitemap 的好方法。
工具接受與拒絕的輸入
擷取工具刻意保持精簡，因此它的輸入契約相當明確。工具接受來自單一 urlset 或單一 sitemapindex 文件的完整 XML 文字。像是 sm:urlset、sm:url 與 sm:loc 這種一致的命名空間前綴會與預設命名空間形式一樣受到支援。XML 宣告與註解會在解析前先被移除。五個預先定義的 XML 實體 — <、>、&、' 與 " — 以及有效的十進位或十六進位數字字元參考會被解碼；除此之外的任何內容，包含自訂實體宣告與 DTD，都會被拒絕。
通訊協定樣式的限制會被當作嚴格上限強制執行。每個序列化後的 URL 必須少於 2,048 字元，以符合通訊協定的 loc 限制。小工具最多接受 50,000 個不重複的 URL 以及五百萬個 UTF-16 輸入碼位；超過任一上限會讓執行失敗，而不是截斷輸出。壓縮的 .gz 資料必須在工具外部解壓縮，而在編輯器中貼上遠端 URL 並不會下載任何東西 — 工具只處理 XML 文字。
如何從 sitemap 中擷取所有 URL
- 在文字編輯器中開啟單一 sitemap 檔案或 sitemap index 的原始 XML，然後複製完整內容 — 從開頭的 <urlset> 或 <sitemapindex> 一路到結尾標籤 — 到擷取工具的編輯器中。如果檔案有壓縮，請先解壓縮 .gz。
- 執行擷取作業，並查看回報根元素類型、接受的不重複 URL 數量、正規化過程中移除的重複數量，以及下方完整輸出的面板。
- 使用複製按鈕將完整的一行一個 URL 清單放到剪貼簿上，然後匯入試算表、貼到爬蟲檢查清單中，或儲存起來與前一版釋出內容比對。
- 另外針對 HTTP 狀態、canonical 選取、robots 指令與索引狀況執行獨立的即時檢查，因為擷取只能確認該位置確實出現在來源 XML 中。
擷取清單之後仍需要的即時檢查
擷取出來的清單只能證明「存在」，並非已建立索引的證明。Sitemaps 通訊協定與 Google 的說明文件都將 sitemap 描述為探索提示，因此一次乾淨的擷取是更大規模稽核的起點，而非結束。一旦手上有了這份清單，剩下的問題就屬於另一個獨立、針對上線網站的檢查流程。
針對清單上的每個 URL，請確認即時回應回傳 2xx 狀態、會跟隨任何重新導向鏈到穩定的目的地，並且該目的地的 rel=canonical 與您預期的 URL 一致。將擷取出的 URL 與 robots.txt 規則、頁面本身的 meta robots 以及任何 noindex 指令交叉比對。把清單與資料庫中、先前爬取結果中，或分析工具登陸頁面中的 canonical URL 進行比對，以找出因預設埠號或主機大小寫變體所造成的重複項目。如果正式環境的 sitemap 接近通訊協定的未壓縮位元組大小上限，請驗證實際檔案大小，並考慮將其拆分為較小的檔案，再以 sitemap index 來引用。
這些檢查不需要同時執行。小型網站可以人工抽樣檢查；大型清單則更容易與無頭瀏覽器、日誌檔或分析工具匯出的 CSV 進行比對，因為其中每一列都已經帶有狀態碼或 canonical 目的地。重點在於：擷取只給您一份候選清單，除此之外什麼也沒有 — 清單上的每個 URL 仍然必須通過同一組關卡，才能算是上線、可連線且可被索引。
擷取與建立 sitemap：兩個方向、一種格式
擷取是建立的反向操作。同樣的 urlset 結構既可由這個工具讀取，也可以由 XML Sitemap Generator 從經過審核的頁面 URL 清單產出，而 sitemapindex 則可以從一組較小的 sitemap 檔案組合而成。在進行網站遷移、拆分過大的 sitemap，或從已知良好的 URL 清單重建過期檔案時，理解這兩個方向都會有所幫助。
| 面向 | 從 sitemap 擷取 URL | 從 URL 清單建立 sitemap |
|---|---|---|
| 方向 | XML loc 值 → 純文字清單 | 經審核的 URL 清單 → 合規的 XML |
| 輸出形式 | 每行一個 URL，已去除重複 | 一個 urlset 或 sitemapindex XML 檔案 |
| 常見用途 | 稽核、遷移、爬蟲檢查清單 | 發布 sitemap 供爬蟲擷取 |
| 如何驗證成功 | 不重複數量符合預期；重複項目有合理解釋 | 檔案通過通訊協定驗證並回傳 200 |
這兩種流程共用同樣的硬性限制。每個 url 項目的 loc 必須少於 2,048 字元，且必須指向公開可連線的 HTTP 或 HTTPS 資源，而非相對路徑或非網頁協定。Sitemap index 對每個子 sitemap 檔案 URL 也有相同的上限，但另外繼承一條規則：單一 sitemap 檔案預期包含少於 50,000 個 URL，且未壓縮大小保持在 50 MB 以下，這也是為什麼正式環境的網站常會將大型清單拆分到多個子檔案中。XML Sitemap Generator 在產出輸出時會強制採用相同的結構，因此今天擷取出的清單，明天可以重新輸出成合規檔案，無需手動重寫。
導致執行失敗的錯誤
解析器刻意對接受的內容設下明確規範，因此失敗時會指出有問題的 loc 或項目編號，而不是默默地略過錯誤輸入。DTD 宣告與自訂實體宣告會導致執行失敗，因為拒絕這些內容可以讓小工具的行為保持精簡且可預期，並避免實體展開變成隱藏的產品邏輯。未知實體、無效的 Unicode 純量值、loc 內部的巢狀標記、缺少 loc 子元素，以及不完整的項目，都會因為相同原因導致執行失敗：以不完整的清單冒充完整清單，會比沒有清單更糟糕。
解析器不會修復格式錯誤的 XML，也不會猜測缺少的結尾標籤應該放在哪裡。像是 image:loc 這類擴充位置並不會在缺少頁面 loc 時被取代，因為它們描述的是不同的資源角色。如果 sitemap index 看起來意外地短，原因幾乎都是擷取工具回傳的是直接的子 sitemap 檔案位置 — 那些檔案必須另外取得並處理，才能顯示其中的頁面 URL。
若需要更深入的規則說明，Google Search Central 的建立與提交 sitemap 指南以及 WHATWG URL 標準，是上述驗證行為背後的兩份權威參考文件。