從 URL 清單建立的 XML sitemap 是一個 sitemap.xml 檔案，其中您提供的每個絕對頁面網址會成為單一 條目，依據 sitemaps.org 協定規則進行驗證與序列化，而不是由爬蟲自動探索。從清單到 XML 的工作流程會將每個貼上的網址視為一個明確的編輯決策:您已審核過並決定應出現在搜尋引擎探索結果中的頁面。由於網址是手動輸入的，因此產生的檔案反映的是您對哪些路徑存在、哪些可被索引、以及哪些值得曝光的判斷，而不是依賴自動化連結探索可能一併納入的重新導向、內容貧乏的頁面或遭到封鎖的資源。
這種方式適合維護 CMS 匯出檔、規範頁面路徑的試算表，或人工策劃的行銷登陸頁面清單的團隊。轉換步驟在原理上很單純——在 根元素中，將每一行用 標籤包裹——但 sitemaps.org 協定規則與 XML 跳脫規則會讓手打的草稿變得緩慢且容易出錯。一個在瀏覽器中執行的專用工具可以在單一流程中處理網址序列化、重複去除、實體跳脫以及 UTF-8 位元組測量，讓編輯清單保持在工作流程的核心，而不會被跳脫錯誤所淹沒。
「URL 清單轉 XML Sitemap」真正的含義
這個詞描述的是一種確定性的轉換:您提供的每一行經過驗證、正規化與重複去除後，會在輸出檔案中恰好成為一個 條目。不會擷取任何內容、不會追蹤任何連結、也不會檢查任何 canonical 標籤。這個工具是一個清單轉 XML 的公用程式，而非爬蟲，產生的檔案僅與您提供的網址及任何選用中繼資料一樣準確。
這個工作流程特別適合以下三種反覆出現的情境:
- 您已擁有從分析工具、CMS 或人工維護的試算表匯出的清單。
- 您希望嚴格控制哪些路徑會出現，排除標籤頁、內部搜尋結果或測試環境的網址。
- 您需要為爬蟲無法觸及的網站製作 sitemap，例如靜態匯出、具有受限路由的單頁應用程式，或是位於認證後方的文件網站。
基於清單的產生器 vs 爬蟲
基於爬蟲的 sitemap 反映的是機器人能探索到的內容，包括重新導向、分頁封存、被封鎖的資源以及參數變體。基於清單的產生器則只反映您貼上的內容。對於具有編輯門檻、分面導航或大量低價值網址模式的網站來說，這種編輯控制通常比自動化探索更有價值。
| 面向 | 清單轉 XML 產生器 | 伺服器端爬蟲 |
|---|---|---|
| 網址來源 | 貼上的行，人工策劃 | 擷取頁面時找到的連結 |
| 發出的 HTTP 請求 | 無 | 每頁一個或多個 |
| 是否包含重新導向 | 僅在您列出的情況下 | 可能，取決於重新導向處理方式 |
| 是否讀取 canonical 標籤 | 否 | 通常會 |
| 是否偵測狀態碼 | 否 | 是 |
| 網址清單的隱私性 | 保留在瀏覽器分頁中 | 提交給爬蟲服務 |
| 最適用於 | 已審核的清單、受限網站、靜態匯出 | 可爬網站上的廣泛探索 |
由於清單與產生的 XML 都停留在同一個瀏覽器分頁中，因此在轉換過程中，網址清單不會離開您的裝置。對於處理機密上架頁面或受合規限制區段的團隊來說，這是一個有意義的差異。
產生前準備您的網址清單
三條準備規則能讓產生流程順暢，並讓輸出符合協定規範。略過這些規則是明明有效的清單卻無法通過驗證工具最常見的原因。
每個檔案只放一個主機
sitemaps.org 協定要求每個檔案只能有一個主機，包括任何非預設連接埠。產生器會強制執行這項規則:混用 example.com 與 example.com:8443 會失敗，因為連接埠是序列化主機的一部分。同一個主機的 HTTP 與 HTTPS 網址可放在同一個檔案中，因為協定規則是「一個主機」，而不是「一個來源」。
僅限絕對網址，每行一個
每個非空白行都必須是以 http:// 或 https:// 開頭的絕對網址。裸網域、相對路徑、FTP 網址以及片段會被拒絕，而不是被默默修正。非空白行的開頭或結尾空白會被視為錯誤，而不是悄悄去除，因此複製貼上時多出的空格會立即顯現，而不是被隱藏起來。
決定選用中繼資料是否適用
lastmod、changefreq 和 priority 是選用的協定提示，而不是抓取指令。產生器只有在您提供一個對批次中每個網址都真實適用的值時，才會納入它們。如果您的頁面有一半是昨天更新、其餘是上個月更新，請不要捏造一個共用的 lastmod;將該欄位留空，讓協定預設值生效。
如需從 CMS 或試算表準備乾淨網址清單的操作示範，請參閱手冊的URL 清單轉 sitemap 工作流程。
產生 Sitemap 檔案
產生流程會將您的清單轉換為單一 sitemap.xml 檔案，準備好上傳到所代表網站的根目錄，或透過 Search Console 提交。
- 每行貼上一個絕對的 HTTP 或 HTTPS 網址，每個檔案使用一個主機(含任何非預設連接埠)。空白行與僅含空白的行會被忽略。
- 若要產生僅含 的 XML，請將選用欄位留空;或提供一個對每個條目都真實適用的共用 lastmod、changefreq 或 priority。
- 產生檔案並在下載前檢視渲染後的 XML、唯一網址數、重複數，以及任何逐行的錯誤。
- 下載 sitemap.xml，將其發布到其所代表的網站(通常位於文件根目錄)，並從 robots.txt 引用它，或透過 Search Console 提交。
編輯任何輸入會撤銷先前的下載並清除預覽，因此您保留的檔案永遠與螢幕上目前的行和選項一致。XML Sitemap 產生器在當前分頁中執行所有步驟——行分割、網址序列化、重複去除、跳脫、位元組測量——而不會將清單上傳到任何地方。
選用中繼資料:lastmod、changefreq 與 priority
這三個選用欄位僅作為協定提示。搜尋引擎可能會將 lastmod 作為新近性訊號，並將 changefreq 與 priority 視為軟性建議。它們都無法保證抓取、建立索引或排名。
| 欄位 | 允許的值 | 驗證規則 | 它不是什麼 |
|---|---|---|---|
| lastmod | YYYY-MM-DD 或含秒數與 Z 或 UTC 時差的完整日期時間 | 含閏年與時區檢查的真實西曆日期 | 重新抓取的指令 |
| changefreq | always、hourly、daily、weekly、monthly、yearly、never | 七個值中的恰好一個 | 排名訊號 |
| priority | 0.0 到 1.0 | 範圍內的小數 | 強制讓頁面排名更高的方法 |
如果任何選用值未通過驗證，整個產生作業就會失敗，而不是悄悄忽略錯誤的欄位。這種全有或全無的行為可防止檔案意外混用有無中繼資料的條目，並在您發布前將錯誤凸顯出來。
協定限制與工具預算
sitemaps.org 協定允許每個檔案最多 50,000 個網址與 52,428,800 個未壓縮位元組，每個 loc 短於 2,048 個字元。瀏覽器端的產生器使用較低的預算，以限制預覽記憶體、Blob 配置與解析器的壓力，而無須假裝自己就是協定本身。
| 限制 | 協定最大值 | 本工具的預算 |
|---|---|---|
| 每個檔案的唯一網址數 | 50,000 | 10,000 |
| 檔案大小(未壓縮) | 52,428,800 位元組 | 10,485,760 位元組 (10 MiB) |
| 每個 loc 的字元數 | 少於 2,048 | 最多 2,047 |
| 輸入大小 | 未指定 | 5,000,000 個 UTF-16 碼元 |
若要將位元組預算換算為每個網址的配額，可將上限除以網址上限:10,485,760 位元組 ÷ 10,000 個唯一網址 = 每個網址平均 1,048.576 位元組。實際條目會有所不同;簡短的首頁使用的空間遠少於該配額，而含有許多查詢參數的深層路徑則較接近上限。這個計算只是粗略的平均值;您檔案的精確數字應以產生器的預覽為準。
每個限制都是以全有或全無的方式強制執行。第 10,000 個唯一網址會被接受，而下一個唯一網址則會失敗。剛好達到 10,485,760 位元組的邊界值會被接受;多出一個位元組就會導致整個產生作業失敗。不會回傳截短的 XML、省略符號或部分下載。重复的行不會佔用輸出槽位，因此來源清單中的複製貼上雜訊會被計算在內，但絕不會擴大發布的檔案。
發布檔案前應檢視的項目
產生器不會驗證 sitemap 將托管在哪裡，或是否存在跨網站提交權限。一份簡短的發布前檢查清單能讓檔案與實際網站保持一致:
- 將網址清單與實際網站進行核對，移除清單中仍包含的任何重新導向、被封鎖的頁面、私密頁面或 404 頁面。
- 確認每個檔案只包含一個主機。如果行銷頁面位於不同的網域或連接埠，請為每個主機產生一個檔案。
- 驗證檔案大小與網址數量皆符合協定上限與工具的瀏覽器預算(若您在同一分頁中反覆執行)。
- 在 robots.txt 中以 Sitemap: 一行引用該檔案，或透過搜尋引擎偏好的方式提交。
關於提交流程的搜尋引擎端說明，請參閱Google Search Central 的建立與提交 sitemap 指南，其中涵蓋主機規則、sitemap 索引與重新提交的時機。WHATWG 的URL 標準則是產生器所套用瀏覽器式正規化(小寫主機、移除預設連接埠、插入根斜線，以及非 ASCII 字元的百分號編碼)的參考依據。
請將產生的檔案視為起點，而非最終成品。sitemap 反映編輯意圖，而編輯意圖會隨時間變動。每當網站的資訊架構、重新導向對應或可索引區段有所變動時，請重新檢視網址清單。