基於瀏覽器的網站地圖 URL 擷取工具,可在裝置上完整解析 XML,以取代 API 呼叫,並回傳去重複、一行一個 URL 的清單,無需權杖、伺服器請求或檔案上傳。與由 API 驅動的工具(從遠端端點擷取網站地圖、在伺服器上解碼,並透過權杖驗證的用戶端回傳 JSON 或 CSV)不同,本機擷取工具接受貼上的 XML 文字,並在用戶端套用 Sitemaps 通訊協定規則。其結果是一種私密、可重複的擷取作業,可處理測試環境的網站地圖、內部 QA 檔案或上線前的 URL 清單,而無需將其暴露給第三方服務。由於解析作業在裝置上進行,因此無需管理 API 金鑰、無需追蹤使用配額,也無需在處理逼近通訊協定 50,000 個 URL 上限的大型網站地圖時處理速率限制回應。輸出為純文字,設計用於直接貼上至爬蟲檢查清單、試算表或重新導向稽核,而非需要額外解碼的 JSON 信封。對於已付費使用爬蟲軟體的團隊而言,本機步驟仍然物超所值,因為它能將網站地圖與稽核的其餘部分隔離,並在任何爬蟲作業開始前產生經過驗證的來源清單。

網站地圖擷取的 API 替代方案
「API 替代方案」一詞通常代表三件事:無帳號、無按次計費、無網路躍點。套用於網站地圖擷取時,這意味著將權杖驗證的端點——無論是付費爬蟲、從 URL 擷取資料的 npm 套件,或消費網站 URL 的託管服務——替換為在本地執行相同解析任務的小工具。讀者的任務是從 urlset 或 sitemapindex 文件中取出所有 loc 值,並在後續檢查之前加以檢視;而 API 替代方案消除了配置憑證、支付配額費用,或將可能包含團隊不想分享之 URL 的正式環境網站地圖託付給廠商的摩擦。
基於 API 的擷取工具通常預期接收網站 URL 作為輸入,然後擷取網站地圖、追蹤任何巢狀索引項目、在伺服器端解壓縮 .gz 檔案,並回傳 JSON 酬載。本機替代方案則翻轉了該工作流程:由使用者負責取得 XML 文字、視需要進行解壓縮,並將其貼入編輯器。解析器接著在瀏覽器內執行相同的結構檢查——根類型、loc 子元素、命名空間處理、實體解碼——而無需離開瀏覽器。此轉變在程式碼層面微不足道,但在資料暴露層面具重要意義,因為 XML 從未穿越廠商網路。
基於瀏覽器的擷取工具與 API 端點的差異
API 與本機解析器之間的實務差異可歸納為幾個可預測的類別。下表將其摘要整理,以便在開始任何擷取作業前明確權衡取捨。
| 層面 | API 端點 | 基於瀏覽器的擷取工具 |
|---|---|---|
| 驗證 | 權杖、API 金鑰或帳號 | 無需驗證 |
| 網路請求 | 從使用者輸入擷取網站地圖 URL | 無網路請求;XML 直接貼入 |
| 壓縮 .gz 處理 | 伺服器端解壓縮 | 請先在工具外解壓縮 |
| 網站地圖索引展開 | 通常會跨子檔案遞迴 | 僅限直接子 loc,不進行擷取 |
| 資料暴露 | 網站地圖文字傳送至廠商伺服器 | 保留在瀏覽器分頁內 |
| 輸出格式 | JSON 或 CSV 信封 | 一行一個 URL 的純文字 |
| 速率限制或配額 | 由提供者定義並計費 | 每次執行 50,000 個唯一 URL |
| 失敗模式 | 部分 JSON、靜默略過或 HTTP 錯誤 | 編號 loc 錯誤;整個執行失敗 |
本機解析器將輸入與輸出保留在同一個瀏覽器內容中,這就是為何測試環境的網站地圖與上線前的清單會留在裝置上,除非使用者將結果複製到他處。這與從網站 URL 自動爬取的託管擷取工具形成對比——後者可能會將 URL 儲存或記錄下來作為其服務的一部分。
如何在不使用 API 的情況下擷取網站地圖 URL
請依照下列步驟將網站地圖轉換為去重複的 URL 清單,且無需叫用遠端 API。
- 從單一 urlset 或 sitemapindex 文件取得 XML 文字。若檔案經 gzip 壓縮,請先將其解壓縮,以便解析器接收純 XML。
- 將完整 XML 貼入 Sitemap URL Extractor 的編輯器中。
- 執行擷取作業並讀取摘要行。該行會回報根類型(urlset 或 sitemapindex)、接受的唯一數量,以及移除的重複數量。
- 檢查輸出內容。系統會保留首次出現的順序,因此結果會鏡像來源順序,方便與原始 XML 進行比較。
- 使用複製按鈕複製一行一個 URL 的清單,並將其貼入爬蟲檢查清單、試算表、重新導向稽核、記錄檔比較或遷移審查中。
- 針對稽核所需的任何 URL,執行個別的即時檢查——HTTP 狀態、標準網址標記、robots 指令與索引狀態。本機擷取工具僅驗證 XML 結構,並不會觸及實際網路。
本機解析器強制執行的驗證規則
本機解析器會拒絕格式錯誤的 XML,而非靜默略過錯誤項目,並會記錄拒絕原因,以便在重新擷取前修正來源檔案。
| 輸入特性 | 行為 |
|---|---|
| XML 宣告、註解、位元組順序記號 | 在解析前予以移除 |
| DTD 或自訂實體宣告 | 整個執行失敗 |
| 未知的具名 XML 實體 | 整個執行失敗 |
| loc 元素內的巢狀標記 | 整個執行失敗 |
| 不完整的 url、sitemap 或根元素 | 整個執行失敗 |
| 命名空間前綴 (sm:urlset, sm:url, sm:loc) | 一致時予以接受 |
| 標準具名實體 (amp, lt, gt, quot, apos) | 予以解碼 |
| 有效的十進位或十六進位數字字元參考 | 予以解碼 |
| 副檔元素,例如 image:loc | 作為頁面 loc 替代項目予以忽略 |
| 選用子元素,例如 lastmod | 予以忽略 |
URL 層級的規則同樣嚴格。每個解碼後的 loc 必須為絕對的 HTTP 或 HTTPS 值;相對路徑、片段、原始空白字元、憑證、格式錯誤的百分比編碼、反斜線以及其他通訊協定皆會遭到拒絕。WHATWG URL 標準所記錄的瀏覽器標準序列化作業會將主機名稱小寫化、移除預設連接埠,並於必要時對非 ASCII 路徑字元進行百分比編碼。序列化為相同值的 URL 會被視為重複,僅會回傳首次出現的項目。每個 URL 的長度必須短於 2,048 個字元,以符合通訊協定的 loc 限制。跨越 50,000 個唯一 URL 上限或五百萬個 UTF-16 碼位輸入上限將導致整個作業失敗,而非靜默截斷結果。
輸出所確認的內容,以及未確認的內容
擷取作業證明了某個 loc 值出現在所貼上的 XML 中,且通過了解析器的結構與 URL 層級檢查。但它並未證明可爬取性、標準網址選用、索引狀態、排名、頁面內容品質或 HTTP 狀態。Sitemaps 通訊協定與 Google 的網站地圖說明文件將網站地圖描述為探索提示而非索引保證,因此乾淨的擷取結果是較大稽核中的證據,而非索引完成的證明。
此清單在與其他真實來源進行比對時最為有用。請將擷取出的 URL 與內容資料庫的標準網址、 analytics 中回報的登陸頁面、前一版的網站地圖或全新的爬取結果進行交叉比對。預期外的重複項目通常會揭示預設連接埠變體 (https://example.com:443/ 與 https://example.com/) 或主機大小寫變體 (https://Example.com/ 與 https://example.com/),而 URL 標準會將其摺疊為相同的序列化形式。相比之下,遺漏的 URL 通常指向未被貼上的網站地圖片段——這是正式環境網站提供網站地圖索引、而團隊僅檢查單一子檔案時常見的模式。
取得清單後的後續檢查
一旦取得清單,下一步取決於稽核目標:
- 重新導向稽核:將清單貼入重新導向檢查工具,確認每個 URL 皆以正確的狀態碼解析至其預定目的地。
- 標準網址審查:將擷取出的 URL 與每個頁面所發出的標準網址標記進行比對;不符之處表示可能存在網站地圖錯誤或範本錯誤。
- robots 與 meta robots 審查:確認稽核希望被索引的頁面並未遭 robots.txt 或 noindex meta 標記封鎖。
- 記錄檔比對:將清單載入記錄檔分析工具,識別在比較期間內哪些擷取出的 URL 接收到了自然搜尋或爬蟲流量。
- 遷移審查:將新清單與舊清單進行差異比對,確認在 CMS 轉換或平台遷移期間未遺漏任何重要的 URL。
對於同時需要從經審查的頁面 URL 清單建立網站地圖的團隊,XML Sitemap Generator 涵蓋了反向作業。若目標是為測試而非發布用途,以程式化方式產生大型 URL 集合,Bulk URL Generator API Alternative for Browser-Side Lists 教學文件涵蓋了類似的本地優先模式,適用於範本化 URL。
若您正在權衡各種方案,Bulk URL Generator on Windows: Build and Export Lists 對此有詳細說明。