從 sitemap 中擷取 URL 代表讀取 XML 檔案，逐一取出每個 <url> 或 <sitemap> 項目內的 <loc> 直接子元素，並將這些值以每行一個乾淨網址的形式輸出，同時依照首次出現的順序去除重複項目。整個操作在本機端進行:既不會上傳，也不會擷取任何資料，解析器採用的是 Google 在 Sitemaps 通訊協定中所描述的相同規則。執行完成後，你可以看到偵測到的根元素類型(urlset 或 sitemapindex)、接受了多少個不重複的 loc 值，以及移除了多少個重複項目。接受清單只需一次點擊即可複製，供後續檢查使用，例如爬蟲驗證、canonical 比對、重新導向稽核、日誌檔差異比對，或上線前審查。由於解析發生於瀏覽器分頁中，預備環境的網址與上線前的盤點資料絕不會離開裝置，除非你自行將其複製出去。
在 Sitemap 情境中「擷取」的真正含義
從 sitemap 擷取 URL 是一項解析工作，而非爬取作業。讀取器將遵循 Sitemaps 通訊協定的 XML 文件交給解析器，解析器再走訪整棵樹，以收集每個容器元素內部的 <loc> 直接值。過程中不會向實際運作的網站發出任何請求、不會跟隨重新導向，也不會啟動無頭瀏覽器。最終結果是一個扁平清單，每行一個網址，你可以將其貼入試算表、爬蟲設定檔或稽核文件。
這項區分很容易被忽略。許多 SEO 從業人員會把「從 sitemap 擷取 URL」與「爬取網站」混為一談，但 sitemap 本身只是一份提示檔案，用於宣告發布者希望爬蟲納入考量的內容;擷取只是讀取該宣告而已。擷取完成後，每個網址仍需個別檢查 HTTP 狀態、canonical 標記、robots 指令，以及實際索引狀態。乾淨的清單是這些檢查的起點，並非結論。
解析器可辨識的兩種 Sitemap 根元素
Sitemaps 通訊協定定義了兩種頂層根元素，任何忽略其中之一的解析器都將在無聲無息中漏掉現實世界裡的一大票 sitemap。在 urlset 中，每個頁面被包覆於 <url> 元素內，而位置資訊位於其直接子元素 <loc> 中。在 sitemapindex 中，每個項目是一個 <sitemap> 元素，其直接子元素 <loc> 存放的是子 sitemap 檔案的網址，而不是頁面網址。這兩種結構並不會嵌套於同一個檔案中;索引檔指向的是包含頁面清單的檔案。
擷取器透過檢查根元素來區分這兩者，接著強制執行對應的直接子元素規則。若根元素為 urlset，則每個 <url> 必須直接包含自己的 <loc>。若根元素為 sitemapindex，則每個 <sitemap> 必須直接包含自己的 <loc>。如 <lastmod> 等選擇性同層元素雖然可以容忍，但會予以忽略。延伸命名空間會被略過:由於 <image:loc> 描述的是不同的資源角色，因此無法用來取代缺少的頁面 <loc>。本工具接受一致的命名空間前綴，例如 <sm:urlset>、<sm:url> 與 <sm:loc>，同時也接受常見的預設命名空間形式。
| 輸入情境 | 偵測到的根元素 | 擷取器回傳的內容 |
|---|---|---|
| 標準頁面清單 sitemap | <urlset> | 檔案中每個頁面 loc 各佔一行 |
| sitemap 檔案目錄 | <sitemapindex> | 每個子 sitemap 檔案各佔一行(而非內含的頁面) |
| 帶命名空間的形式，如 <sm:urlset> | 帶前綴的 urlset | 頁面網址輸出與預設命名空間形式相同 |
| 壓縮的 .xml.gz 封存檔 | 不進行解析 | 請於本工具外部先行解壓縮，再貼上解壓後的 XML |
| 貼入編輯器的遠端網址 | 不會擷取 | 請改貼 XML 文字;小工具不會發出任何網路請求 |
| <loc> 內部出現嵌套標記 | 予以拒絕 | 執行會失敗，並以特定的項目編號指出損壞的項目 |
如何從 Sitemap 中擷取 URL
整個工作流程在本機端進行，於瀏覽器分頁中執行。Sitemap URL Extractor 會讀取貼上的 XML，套用下述驗證規則，並產生一份去除重複的清單供你複製。多數使用情境可透過五個步驟完成。
- 以純文字編輯器開啟 sitemap 來源檔。若持有 .xml.gz 檔案，請先解壓縮，以便貼上底層的 XML。
- 從單一 urlset 或 sitemapindex 文件中複製完整的 XML 文字。小工具每次執行僅處理一份文件。
- 將文字貼入 Sitemap URL Extractor 編輯器，然後執行擷取作業。
- 檢視報表面板。面板會顯示偵測到的根元素、接受了多少個不重複的網址、移除了多少個經標準化的重複項目，以及完整的「首次出現順序」清單。
- 將每行一個網址的清單複製到剪貼簿，再導入即時狀態檢查、canonical 比對、robots 審查、索引稽核或移轉差異比對。這些檢查需另行進行。
解析器在接受 URL 之前所執行的驗證
在 loc 進入輸出結果之前，解析器會依序執行一連串固定的檢查。順序至關重要:即使通過某個階段的 URL 在下一階段失敗，仍會遭到拒絕，且整次執行會失敗，而不會產出部分清單。掌握這些規則，有助於你迅速修正來源檔，而非盲目猜測。規則、限制與輸出指南對每個步驟有更深入的說明，簡要內容則如下所述。
首先，文件必須包含具有正確結構的封閉根元素。前置的位元組順序標記、XML 宣告與註解會被剝除。DTD 宣告與自訂實體宣告會導致執行失敗，因為本小工具並不會執行實體展開。其次，每個 <url> 或 <sitemap> 項目必須包含直接的 <loc>。loc 內部的嵌套標記、缺少 loc 子元素，以及不完整的項目，皆會導致整次執行失敗。
第三，解碼後的 loc 文字必須能夠解析為絕對網址。本小工具採用瀏覽器的 WHATWG URL 實作，因此主機大小寫、百分比編碼與預設埠處理皆依循該標準。含有認證資訊、片段、原始空白字元、格式錯誤的百分比編碼、反斜線、相對路徑，或非 HTTP 配置的網址，皆會遭到拒絕。序列化後的網址長度也必須低於 2,048 字元，以對應通訊協定的 loc 上限。
第四，完成標準化後，小工具會去除重複。兩個序列化為相同網址的 loc 值僅計算一次，僅保留首次出現者，以使輸出順序與來源一致。第五，則是套用大小上限。小工具最多接受 50,000 個不重複的網址，以及五百萬個 UTF-16 輸入碼位元組。超過任一上限將會直接失敗而不進行截斷，因此臨近通訊協定未壓縮位元組上限的正式環境 sitemap，應拆分為較小的檔案，並以索引檔加以引用。
解讀計數:根元素類型、重複項目與輸出
報表面板呈現四項資訊，共同說明解析器的執行結果。根元素類型用以判斷該文件被視為頁面清單或 sitemap 目錄。不重複計數是經標準化與去重後所接受的 loc 值數量。重複計數則是因符合較早條目而在瀏覽器標準序列化下遭到移除的 loc 值數量。完整輸出即為「首次出現順序」的清單本身，可隨時複製。
重複計數往往比看起來更值得關注。在瀏覽器標準序列化中，預設埠變體與主機大小寫變體可能會發生衝突，因為該標準會將主機字串轉為小寫並移除預設埠。重複計數意外偏高，意味著來源產生器輸出了不一致的 loc 字串，這點值得在同一份稽核中加以標記，而不應當作雜訊忽略。
取得清單之後的下一步
擷取屬於探索步驟。輸出結果僅能證明某個網址曾出現於 sitemap 中，並通過解析器的驗證;它並非該頁面可被爬取、具備 canonical、已建立索引或排名的證據。下一階段應進行若干即時網站檢查，這些檢查已超出小工具本身的範疇。
請利用此清單驅動 HTTP 狀態掃描，使 4xx 與 5xx 回應能夠在同一份顯示中浮現。將每個項目與該頁面所回傳的 canonical 標記進行比對，以找出 sitemap 宣稱納入、但頁面本身卻予以否定的條目。並與 robots 指令及 noindex meta 標籤交叉比對，找出 sitemap 列出、但頁面卻要求搜尋引擎略過的網址。將清單與分析工具的到達網頁報表進行差異比對，以確認實際獲得流量的網址皆已涵蓋。若正進行移轉，請將新 sitemap 的擷取結果與前一版進行差異比對，以精確掌握新增、移除或重新序列化的 loc 值。
瀏覽器端解析為何對 SEO 稽核至關重要
許多 SEO 稽核涉及私有的預備環境網址、上線前盤點資料，或屬於客戶機密的路徑，這些資訊不應離開裝置。由於小工具完全在瀏覽器分頁中運作，絕不會上傳 XML，這些清單會保留在本機，除非使用者主動將其複製出去。當稽核屬於受監管的環境，或敏感程度使得伺服器往返需經過簽核時，此特性便顯得格外重要。
瀏覽器端模式同時也使作業具備可重現性。沒有 API 金鑰、沒有速率限制，也無需排隊等待。相同的文字在任何載入此小工具的機器上皆會產生相同的輸出，這對於日後需要捍衛稽核結論的情境非常有助益。結合去重規則與嚴格的項目層級錯誤回報機制，本工具成為一個小巧且可預測的元件，能夠嵌入更大的工作流程之中，而非試圖取而代之。
若你正在權衡各種方案，Sitemap Generator for Website: Build From a Reviewed List 對此有詳細說明。