網站地圖 URL 萃取」是將每個 <loc> 值從標準的 sitemap.xml 或 sitemapindex XML 文件中拉出來，並轉換成一個乾淨且去重複的 URL 列表，方便你排序、貼入試算表，或交給爬蟲處理的過程。XML 本身是一種機器可讀格式的提示檔，而不是人類可讀的索引——所以將它轉換成每行一個 URL，通常是任何分析、稽核或遷移工作前的第一步。Sitemap URL Extractor 正是執行此作業：貼上 XML 文字，即可獲得一份已移除重複項目的乾淨列表。該工具不會連線到網站、不會爬取網站，也不會下載檔案。你必須自行複製或儲存 XML 文字，然後將其貼到編輯器中。所有作業都在瀏覽器中執行，這能在你工作時，讓私密的測試環境網站地圖、上線前的 URL 清單，以及尚未發布的重新導向，不會出現在任何第三方伺服器上。

extract sitemap from website
從網站萃取網站地圖並產生 URL 清單

工具實際解析的內容

Sitemap URL Extractor 會辨識 Sitemaps XML 通訊協定中的兩種結構：urlset（頁面位置的清單）以及 sitemapindex（網站地圖檔案位置的清單）。對於 urlset，預期每個 <url> 項目會包含一個直接的 <loc> 子元素，其文字內容即為頁面 URL。對於 sitemapindex，預期每個 <sitemap> 項目會包含一個直接的 <loc> 子元素，其文字內容即為另一個網站地圖檔案的 URL。

解析器的設計刻意嚴格。它會忽略 XML 宣告與註解，接受一致的命名空間前綴（例如 sm:urlset、sm:url 和 sm:loc）以及預設命名空間格式，並僅解碼五個內建的 XML 實體，以及有效的十進位或十六進位數字字元參照。未知的實體、DTD 宣告、自訂實體宣告、<loc> 內部的巢狀標記，以及格式錯誤的根元素，都會導致萃取作業失敗，而不是默默傳回部分清單。這是刻意的設計：拒絕 DTD 能讓解析行為保持小巧且可預測，並防止實體擴展演變成隱藏的產品邏輯。

工具不會執行的作業

這是多數讀者最容易搞錯的部分，因此值得明確說明。Sitemap URL Extractor 不會從 URL 擷取網站地圖。它不會下載任何東西、解壓縮 .gz 檔案，也不會跟隨重新導向。如果你想要讀取網站地圖索引，該工具僅會傳回其列出的直接網站地圖檔案位置——每個子檔案都必須另外取得並單獨處理。

它同樣不會檢查頁面是否被爬取、是否為標準網址、是否被索引或排名。根據 Sitemaps 通訊協定及 Google 本身的說明文件，網站地圖是一個探索提示，而非索引保證。萃取只能證明有效的合法 <loc> 出現在貼上的 XML 中，並通過該工具的驗證。爬取狀態、標準網址選擇、noindex 指令、robots 規則，以及搜尋引擎的接受度，都是在你取得清單後另外進行的即時網站檢查。

在瀏覽器中萃取網站地圖 URL 清單

完整的工作流程可分為三個可重複的步驟。請將每個步驟視為一次明確的交接，這樣結果才可驗證，而不是憑空變出來的魔法。

  1. 將一份 urlset 或 sitemapindex 文件的完整 XML 文字貼入編輯器。在任何文字編輯器中開啟來源檔案，從開頭的根標記選取到結尾的根標記，然後複製。如果來源是 .gz 壓縮檔，請先將其解壓縮；壓縮過的位元無法以 XML 文字讀取。
  2. 萃取直接的 loc 值，並檢視根類型、唯一數量、重複數量以及完整輸出。所回報的根類型會告訴你偵測到的是哪種結構；數量會告訴你是否在正規化過程中移除了任何項目；完整輸出即為正式的結果。
  3. 複製每行一個 URL 的清單，然後視需要執行個別的即時狀態、標準網址、robots 及索引檢查。請將這份清單作為大型稽核中的佐證，而非索引的證明。

為何存在兩種不同的網站地圖結構

urlset 與 sitemapindex 之間的差異，是處理真實世界的網站地圖時最常見的混淆來源之一。下表摘要說明兩者各自包含什麼內容，以及萃取工具會為其傳回什麼結果。

根類型 文件包含的內容 工具傳回的內容 套用的限制
urlset 扁平的 <url> 項目清單，每個項目皆包含 <loc> 以及 lastmod、changefreq、priority 等可選的中繼資料 來自每個 <loc> 的直接頁面 URL 最多 50,000 個唯一 URL
sitemapindex <sitemap> 項目的目錄，每個項目皆包含一個指向其他網站地圖檔案的 <loc> 來自每個 <loc> 的直接網站地圖檔案 URL 最多 50,000 個唯一項目；不會擷取子檔案

兩種形式都會經過相同的 URL 正規化處理：主機名稱會轉為小寫並進行驗證、移除預設連接埠、在必要時將非 ASCII 路徑字元進行百分比編碼，並拒絕含有認證資訊、片段、未處理的空白字元、格式錯誤的百分比跳脫、反斜線以及相對路徑的內容。序列化後的重複項目會以首次出現的順序進行去重。任何未通過驗證的內容都會停止整個執行作業，而不是產生部分結果——當結果要作為稽核依據時，部分答案比沒有答案更糟糕。

為何解析器選擇快速失敗而非猜測

會猜測的網站地圖解析器，是會隱藏 bug 的解析器。如果 <loc> 在某個項目中遺失、根元素不完整、數字字元參照指向有效的 Unicode 範圍之外，或是輸入超過 50,000 個唯一 URL 的上限，或是超過五百萬個 UTF-16 程式碼單位的輸入上限，整個作業便會失敗。該解析器用來正規化每個 <loc> 的依據是 瀏覽器 URL 標準，該標準預期絕對的 HTTP 或 HTTPS URL 長度應短於 2,048 個字元——此長度符合通訊協定本身的 loc 限制。

解析器會明確指出是哪一個 <loc> 或項目導致失敗，以便你能修正來源，而不是默默略過。這就是驗證器與轉換器之間的實際差異：轉換器會樂於傳回它能讀取的所有項目；驗證器則會告訴你文件已損壞，以及損壞的位置。對於大型或正式環境的網站地圖而言，這項差異就是一份值得信賴的稽核，與一份建立在假設上的稽核之間的差別。

萃取清單的後續應用

一旦 URL 以每行一個的格式整理好，它們便可用於最初促使你進行搜尋的各種作業。最常見的用途包括：

  • 遷移期間的爬蟲檢查清單：將清單貼入你的爬蟲或測試環境驗證工具，並與新環境實際提供服務的 URL 進行比對。
  • 重新導向稽核：將清單與重新導向對照表進行交叉檢查，找出遺漏的 301、重新導向鏈或過時的目的地。
  • 試算表匯入：每一列都會成為一筆紀錄，你可以標注狀態碼、標準網址、是否可索引以及 lastmod。
  • 日誌檔案比對：將清單載入日誌分析工具，查看爬蟲實際上對每個 URL 提出請求的頻率。
  • 標準網址審查：將清單與資料庫中的標準網址、分析工具的到達網頁以及前一個版本的標準網址進行比對，以便找出重複項目及主機名稱大小寫的變體。

對於上述每一項用途，萃取出的清單是網站地圖所宣稱內容的事實來源，而即時檢查則是網站實際行為的事實來源。將這兩種角色混為一談，正是稽核報告不知不覺出錯的原因。Sitemaps 通訊協定與 Google 說明文件皆將網站地圖描述為探索提示——萃取只能確認某個位置出現在貼上的結構中，並通過該工具已揭露的驗證。它並不代表該 URL 可被爬取、是標準網址、有價值、已被索引或排名。

貼上之前值得了解的限制

幾項作業上的界線決定了該工具能接受何種輸入。解析器最多接受 50,000 個唯一 URL，以及五百萬個 UTF-16 輸入程式碼單位。超過任一上限都會直接失敗，不會進行截斷。每個解碼後的 <loc> 都必須是長度少於 2,048 個字元的絕對 HTTP 或 HTTPS URL。含有認證資訊、格式錯誤的跳脫、未處理的空白字元、片段以及非 HTTP 協定的內容皆會遭到拒絕。壓縮的 .gz 資料必須在工具之外先行解壓縮。此外，將遠端 URL 貼入編輯器並不會下載任何東西；該小工具僅會讀取你貼上的文字。

如果正式環境的網站地圖接近通訊協定限制，請在磁碟上驗證實際的未壓縮位元組大小，並考慮將其拆分為較小的檔案，再以網站地圖索引加以引用。Sitemaps 通訊協定之所以將網站地圖檔案上限設為 50,000 個 URL 及 50 MB 未壓縮大小是有原因的。拆分也能在單一檔案失效時縮小影響範圍——只有該檔案的項目會使解析器失敗，不會影響網站其餘的涵蓋範圍。

相關閱讀：在 iPhone 上產生大量 URL：透過 Safari 執行。

相關閱讀：合併關鍵字清單：順序、分隔符與配對數量。