要找出 XML 站台地圖中列出的每一個 URL，最快的方法就是把完整的站台地圖文字貼到瀏覽器型的擷取工具，它會讀取 loc 元素並回傳一份乾淨的「一行一個 URL」清單。站台地圖檔案遵循 sitemaps.org 所定義的 XML 協定，外層可能是 urlset 包住重複的 url/loc 配對（每個條目對應一個頁面），也可能是 sitemapindex 包住重複的 sitemap/loc 配對（每個條目對應一個子站台地圖檔）。Loc 是「location」的縮寫，它是單一的子元素，用來放置 urlset 中某個頁面的絕對 URL，或 index 中某個子站台地圖檔的絕對 URL。條目中的其他內容——lastmod、changefreq、priority、image:loc——都是選擇性的中繼資料，絕對不會取代 loc 的值。一開始就理解這個結構，就能把「how to find sitemap URL」從憑直覺猜測，變成一個輸入形狀已知、輸出形狀已知、且清楚區分「工具能回答的」與「只有實際抓取才能知道的」的解析工作。
「尋找 Sitemap URL」的兩種含義
搜尋這個詞組的人大多只想要以下兩件事之一。第一種含義是「我的站台地圖檔在哪裡？」——它通常位於可猜測的路徑，例如 /sitemap.xml 或 /sitemap_index.xml，這屬於設定問題而非解析問題。第二種含義是「我已有的站台地圖檔裡列出哪些 URL？」——這是解析問題，也正是 Sitemap URL Extractor 設計來處理的工作。
如果你只需要第一個答案，擷取工具就殺雞用牛刀了。打開你網站的 robots.txt 找 Sitemap: 那一行，或到 CMS 設定中查看該平台產生的路徑即可。如果你需要第二個答案，你手上已經有 XML，只想把每一個 loc 轉成一份可直接複製的純文字清單——不必寫 regex、不必打開試算表，也不必把檔案上傳到任何地方。
為什麼手動解析 Sitemap XML 很快就會出錯
一般站台地圖乍看之下人畜無害：一個外層標籤、重複的 url 區塊，每個區塊底下有一個 loc 子元素。陷阱在於 XML 有一些隨意瀏覽者會略過的邊緣情況。站台地圖可能帶有命名空間前綴，例如 sm:urlset、sm:url、sm:loc，任何解析器都必須同時接受帶前綴的形式與預設命名空間的形式。註解與 XML 宣告需要被丟棄，且不能打亂 loc 的計數。lastmod 與 changefreq 在單一 url 元素中可以出現在 loc 之前或之後，解析器不能把它們誤認為位置。
圖片擴充功能會在 image:image 區塊內放置 image:loc，該區塊又巢狀於 url 之內——這個 loc 描述的是圖片資源而非頁面，當頁面 loc 也同時存在時，擷取工具必須忽略它。未知的實體、格式錯誤的數字字元參考、DTD 宣告以及缺少的結尾標籤，也都會直接讓檔案失效。以上任何一項都可能讓天真的 regex、grep 一行指令，或是把檔案當成純文字處理的匯入作業掛掉。專為此設計的擷取工具天生就能處理這些情況，這也是為什麼把工作交給它比較保險。
如何從任何 Sitemap 取得乾淨的 URL 清單
- 在瀏覽器中開啟 Sitemap URL Extractor，並清除編輯器中的任何範例文字。
- 把一個 urlset 或 sitemapindex 檔案的完整 XML 內容貼到編輯器中。不要貼上遠端 URL——這個小工具不會發出任何網路請求，只會讀取你剪貼簿上的內容。
- 執行擷取。結果面板會回報找到的根類型（urlset 或 sitemapindex）、接受了多少個不重複的 URL，以及移除了多少個重複項目。
- 檢視完整結果：每一行一個絕對的 HTTP 或 HTTPS URL，順序依照它們在來源中首次出現的次序。
- 用複製按鈕複製清單，並貼到試算表、爬檢查表、重新導向稽核表或移轉比對文件中。
- 若是 sitemapindex 輸入，請對清單中列出的每個子站台地圖檔重複執行此流程——擷取工具只回傳檔案位置，不會回傳它們內部的頁面 URL。
| 面向 | urlset | sitemapindex |
|---|---|---|
| 外層元素 | <urlset> | <sitemapindex> |
| 重複的項目 | <url> | <sitemap> |
| 必要的子元素 | <loc>（頁面 URL） | <loc>（子站台地圖檔 URL） |
| 常見的選擇性子元素 | lastmod、changefreq、priority、圖片擴充 | lastmod |
| 擷取工具回傳的內容 | 絕對的頁面 URL | 絕對的子站台地圖檔 URL |
| 需要抓取子檔嗎? | 不需要，清單已是最終結果 | 需要，每個子檔必須分開處理 |
輸出結果能告訴你關於 Sitemap 的什麼資訊
閱讀結果面板時，有三個數字很重要。根類型可以確認你是否貼對了檔案種類——urlset 裝的是頁面 URL，sitemapindex 裝的是子站台地圖檔 URL，把兩者搞混是稽核時常見的錯誤。不重複數量就是你工作清單的大小，也是用來比對預期的數字：如果你的 CMS 回報有 4,200 個已發布頁面，而擷取工具也回傳 4,200 個 URL，就代表站台地圖與資料庫是一致的；差距過大就是展開調查的起點。
重複數量是標準化後的重複統計。主機名會轉為小寫、預設連接埠會被移除、非 ASCII 路徑字元會進行百分號編碼，序列化結果相同的 URL 視為同一個。瀏覽器層級的標準化遵循 WHATWG URL Standard，所以 https://example.com:443/foo 與 https://Example.com/foo 會合併為單一條目。重複數量不為零，通常就是產生器出現預設連接埠變體或主機大小寫不一致的第一個證據，而修產生器通常比重傳檔案更划算。
這個工具刻意不做的事
輸出內容是 XML 中出現且通過擷取工具驗證的位置清單。它並不能證明那些頁面可以被爬取、是標準網址、已被索引或有排名。Sitemaps 協定把站台地圖描述為給爬蟲的探索提示，而不是索引保證——根據 Google 的 sitemap 說明文件，提交的檔案只是請求爬蟲注意，並不保證會被收錄到搜尋結果中。
狀態碼、重新導向鏈、標準網址標籤的選擇、robots 指令、noindex 中繼標籤、頁面內容、所有權，以及搜尋引擎是否接受了來源檔案，都是擷取工具不會執行的獨立即時網站檢查。請把這份清單當成大型稽核中的佐證，再用爬蟲、分析工具或搜尋控制台的匯出資料對這些 URL 本身執行那些檢查。
| 關注點 | 擷取工具是否涵蓋? | 該改用什麼 |
|---|---|---|
| 站台地圖中 loc 的數量 | 是 | — |
| 在標準化後偵測重複 | 是 | — |
| 驗證絕對 HTTP/HTTPS URL 格式 | 是 | — |
| 檢查 HTTP 狀態或重新導向鏈 | 否 | 爬蟲或即時 HTTP 請求 |
| 驗證標準網址標籤的選擇 | 否 | 頁面層級檢查 |
| 檢查 robots 或 noindex 指令 | 否 | robots 檢查加上中繼標籤檢查 |
| 確認搜尋引擎是否接受該檔案 | 否 | 搜尋控制台的 sitemap 報告 |
執行失敗時如何解讀解析器錯誤
擷取工具會讓整次執行失敗，而不是回傳部分清單；錯誤訊息會以編號指出造成失敗的特定 loc 或 item。多數失敗來自少數幾種結構性問題。檔案頂端的 DTD 宣告會被拒絕，因為這個小工具拒絕展開自訂實體——若你掌控來源，請在工具外解壓縮並移除 DTD。根元素或任何 url、sitemap 項目的結尾標籤缺失，會導致執行失敗，而不是猜測標籤該放哪裡。未知的實體、loc 內部的巢狀標籤，或是無效的數字字元參考，也都會以同樣方式失敗。
URL 步驟會拒絕含有驗證資訊、片段、原始空白字元、格式錯誤的百分號跳脫、反斜線、相對路徑，以及非 http 或 https 協定的內容。超過 5,000,000 個 UTF-16 字碼單元或 50,000 個不重複 URL 的輸入，也會刻意失敗而非截斷。請修正被指名的項目後再重跑，不要依賴部分結果，因為部分結果對稽核來說是最糟糕的結果。
隱私、限制與輸出去向
解析完全在瀏覽器中進行，所以私密的測試站台地圖或上線前的 URL 清單只會留在你的裝置上，除非你另外複製到別處。把遠端 URL 貼到編輯器並不會下載任何東西；只會解析你貼上的 XML 文字。.gz 壓縮資料必須在貼上前先解壓縮，因為這個小工具不會自動解開壓縮檔。
超過 2,048 個字元的 URL 會被拒絕，以符合協定的 loc 限制；最多 50,000 個不重複條目的上限，代表非常大的站台地圖索引必須分成多次貼上處理——一次給索引本身，一次給它列出的每個子檔。請把輸出當成比對步驟的輸入：與 CMS 中的標準網址、上一次的爬取結果或前一版的發佈對齊，差異之處就會成為稽核清單。需要同時處理多個子檔的讀者，可以參考 從網站 sitemap 完整擷取每個 URL 的配套工作流程。