從 sitemap 中擷取 URL,意即解析搜尋引擎視為探索提示的 XML 文件,讀取 urlset 或 sitemapindex 結構中每個 loc 元素,並產生一份乾淨的「一行一個 URL」清單,以便貼入爬蟲檢核表、試算表或重新導向稽核。輸出內容即來源檔案中所宣告的直接位置值,經由符合瀏覽器標準的 URL 解析器進行正規化,因此因大小寫差異、預設連接埠或零散空白所產生的重複項目會摺疊為同一行。一個正確建置的 Sitemap URL Extractor 會完全在瀏覽器中執行:不會上傳任何資料,XML 從不離開裝置,結果完全反映所貼上文件實際包含的內容。擷取是一項結構性操作,而非搜尋引擎訊號。輸出中出現的一行,代表 XML 內含一組有效的絕對 HTTP 或 HTTPS 位址,且通過了解析器的驗證規則;這並不代表該頁面已被爬取、為標準頁、已被索引或具有排名。
從 sitemap「擷取 URL」實際會回傳什麼
一份 sitemap 檔案屬於 Sitemaps XML 通訊協定所定義的兩種形狀之一。urlset 包裹個別的 url 項目,每個 url 必須包含一個直接的 loc 子元素,內含絕對的網址。sitemapindex 則完全不列出頁面;它包裹的是 sitemap 項目,每個項目都帶有一個指向另一份 sitemap 檔案的直接 loc。當你請解析器從任一種形狀擷取 URL 時,實際上就是請它讀取這些直接的 loc 值、解碼標準的 XML 實體、忽略像 lastmod 這類選用子元素,並將每個位址單獨輸出為一行。
在比較結果時,這個區別非常重要。貼上 urlset,輸出的就是頁面 URL 的清單。貼上 sitemapindex,輸出的則是 sitemap 檔案 URL 的清單,解析器不會去擷取或展開它們。該通訊協定將 sitemap 索引視為一份目錄,而不是遞迴的包裹,因此位於各個子檔案中的頁面 URL,需要針對每個檔案另外執行一次擷取程序。需要逐步走訪巢狀索引每一層的讀者,可以參考 從網站 sitemap 擷取所有 URL 的指南 中所概述的工作流程。
一個可靠的擷取工具也會回報它所找到的內容:辨識到的根類型、接受了多少唯一 URL,以及移除了多少經正規化後的重複項目。這類中繼資料比單純的原始計數更有用,因為重複的移除是正規化的副作用,而不是來源本身刻意存在重複的跡象。
為何僅有擷取並不等於索引檢查
Sitemaps 通訊協定將 sitemap 檔案描述為探索提示,而非索引的擔保。頁面只有在經過一次獨立的爬取後,才會進入搜尋引擎的待處理佇列;而且若該 URL 回傳非成功狀態、被 robots 阻擋、帶有衝突的 canonical,或因低品質而被篩除,搜尋引擎仍可能略過它。從 sitemap 抽出一個 URL,僅能證明該位置在來源檔案中有被宣告;並不能證明該頁面可被連線、為標準版本,或已被任何搜尋引擎接受。
根據 Google Search Central 關於建立 sitemap 的說明文件,出現在有效 sitemap 中的 URL 只是請求被爬取,並非索引的確認。真正能回答那些問題的是即時檢查——例如用 HTTP HEAD 請求檢查狀態、檢視頁面原始碼中的 canonical 標籤、查詢 robots、執行 Search Console 的 URL 審查,或進行 site: 搜尋。
請將擷取出的清單視為大型稽核中的一項證據。將它與資料庫中的標準 URL、與爬取結果、與分析工具中的到達頁面,或與前一版的版本相互對照。預期之外的重複項目,常會揭示主機大小寫變體、預設連接埠項目,或尾端斜線的不一致;預期之外的缺漏,則常會顯示出 sitemap 作者忘了納入,或自檔案產生後已自網站移除的頁面。
如何從 sitemap XML 擷取 URL
- 在純文字編輯器中開啟 sitemap 來源。複製完整內容,若檔案含有 XML 宣告也一併包含。若檔案以 .gz 形式散布,請先將其解壓縮——編輯器只能讀取 XML 文字,無法處理壓縮輸入。
- 將 XML 貼入 Sitemap URL Extractor 的編輯區。此小工具不會發出任何網路請求,因此將遠端 URL 貼入欄位中並不會下載任何東西。
- 執行擷取。檢視所回報的根類型(urlset 或 sitemapindex)、唯一 URL 計數、被移除的重複計數,以及完整的輸出預覽。
- 使用複製按鈕複製「一行一個 URL」的清單。保留首次出現的順序,使輸出易於與原始來源相互比對。
- 針對稽核所關注的 URL,分別執行狀態、canonical、robots 及索引狀態的即時檢查。擷取工具只處理結構層,並不會測試可爬取性。
擷取工具對每個 loc 所強制執行的規則
每個被接受的 loc 必須是絕對的 HTTP 或 HTTPS URL。WHATWG URL 標準 規範解析器如何序列化每個值:主機名稱會被轉為小寫並進行驗證、預設連接埠會被移除、在需要時非 ASCII 的路徑字元會進行百分比編碼,而原始空白、格式錯誤的百分比跳脫序列、以及反斜線會導致拒絕。被序列化為相同值的 URL 會摺疊為同一行輸出,僅保留首次出現者。
幾種看似 URL 的形式會被刻意拒絕:
- 片段(# 之後的任何內容)——它們代表的是子資源,而不是頁面本身。
- 使用者資訊(user:pass@host)——出現在 sitemap 中的憑證幾乎一定是洩漏或錯誤。
- ftp://、mailto:、javascript:、tel: 及其他配置——sitemap 僅描述 HTTP/HTTPS 資源。
- 相對路徑(/page 或 page.html)——該通訊協定要求使用絕對位置。
- 長度超過 2,048 字元的字串——為符合通訊協定對 loc 的限制,任何超過此長度者會使整個執行失敗。
解析器也會拒絕 DTD 宣告與自訂實體宣告,以保持小工具行為的小型化與可預測性。未知的 XML 實體、loc 內的巢狀標記、無效的 Unicode 純量值,以及缺少結尾標記,都會導致擷取失敗,而非產生不完整的清單。像 lastmod 或 priority 這類選用子元素並不會改變擷取出的位置;像 image:loc 這類擴充標記,並不會被用來替代缺漏的頁面 loc,因為它們描述的是不同的資源角色。
對 sitemap 大小與 URL 數量的限制
此小工具單次執行最多接受 50,000 個唯一 URL,以及五百萬個 UTF-16 輸入碼位。超出任一上限即會失敗,而不會截斷。這呼應 Sitemaps 通訊協定本身的限制:單一 sitemap 檔案最多允許 50,000 個 URL,解壓縮後上限為 50 MB。若實際運作的 sitemap 已逼近這些上限,請驗證實際未壓縮的位元組大小,並考慮將其拆分為較小的檔案,再以 sitemap 索引加以引用。
大型 sitemap 也很常帶有經正規化後的重複項目:同一頁面一次以 HTTPS、一次以 HTTP 列出;一次帶尾端斜線、一次不帶;或一次帶明確的 :443 連接埠、一次不帶。一個建置良好的擷取工具會靜默地移除這些項目並回報重複計數,而這往往是來源檔案需要清理、而非工具需要調整的第一個訊號。
壓縮輸入依設計是在小工具之外處理。請先在磁碟上將 .gz sitemap 解壓縮,再貼上解壓後的 XML,並保留原始封存檔作為稽核的佐證。
將擷取出的清單用於後續稽核
取得一份乾淨的清單後,下一步取決於你所稽核的內容。若是重新導向檢查,請將清單貼入狀態檢查工具,並將 HTTP 200 的列與先前的爬取結果進行比對。若是進行遷移,請比對新舊兩份清單之間的差異,並追蹤所有消失為 301 或 410 的 URL。若是檢視爬取預算,請將清單與伺服器紀錄中 Googlebot 實際請求的 URL 進行比對,並觀察其中的落差。
| 問題 | 是否能由 URL 擷取回答? |
|---|---|
| 來源 XML 中是否含有此 URL 的有效 loc? | 是 |
| 是否有兩個項目正規化為相同位址? | 是(以重複項目回報) |
| 該 URL 目前是否可連線(HTTP 狀態、重新導向)? | 否——需另做即時檢查 |
| 此是否為該頁面的標準版本? | 否——需檢視頁面原始碼 |
| 該 URL 是否被 robots.txt 阻擋? | 否——需查詢 robots 規則 |
| 搜尋引擎是否已索引該頁面? | 否——需使用 Search Console 或 site: 查詢 |
| 該頁面是否有任何排名? | 否——需參考排名報告 |
由於此小工具僅在用戶端運作,私密的預備環境位置與上線前的 URL 清單都會保留在裝置上,除非使用者自行將其複製到他處。這使得擷取步驟可安全地用於內部 sitemap,但後續的檢查仍須對實際運作的網站,或能解析這些主機的受控環境進行。