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

extract urls from sitemap api alternative
無需 API 即可從網站地圖擷取 URL

網站地圖擷取的 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。

  1. 從單一 urlset 或 sitemapindex 文件取得 XML 文字。若檔案經 gzip 壓縮,請先將其解壓縮,以便解析器接收純 XML。
  2. 將完整 XML 貼入 Sitemap URL Extractor 的編輯器中。
  3. 執行擷取作業並讀取摘要行。該行會回報根類型(urlset 或 sitemapindex)、接受的唯一數量,以及移除的重複數量。
  4. 檢查輸出內容。系統會保留首次出現的順序,因此結果會鏡像來源順序,方便與原始 XML 進行比較。
  5. 使用複製按鈕複製一行一個 URL 的清單,並將其貼入爬蟲檢查清單、試算表、重新導向稽核、記錄檔比較或遷移審查中。
  6. 針對稽核所需的任何 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 對此有詳細說明。