批次 URL 清單的可靠度，完全取決於產生它的算術序列與驗證規則，這也是為什麼採用「先驗證再產生」的工作流程，幾乎能在任何一行網址離開瀏覽器之前就抓到所有錯誤。要透過 批次 URL 產生器 走最乾淨的路徑，必須在完整輸出出現之前，讓輸入經過三個嚴謹的檢查：範本必須至少包含一個字面意義的 {n}，而且能被解析為絕對的 HTTP 或 HTTPS 網址；起始值、結束值與步進值必須在單一方向上彼此一致；以及必須檢查一小段樣本中的第一個、中間與最後一個值。這三項檢查各自都有工具明確定義的失敗模式，因此格式錯誤的輸入會以明顯的方式被拒絕，而不是產出悄悄被截斷或空白檔案。請把那段短樣本視為一份合約：如果第一筆、中間一筆與最後一筆不符合目標伺服器上真實的命名慣例，那麼整份匯出也絕對不會符合。一旦樣本通過，再把範圍放大到 10,000 筆 URL 的輸出上限，就只是單純的放大作業，而不是靠猜測。
為什麼批次 URL 產生器在產生前會先進行驗證
以樣式為基礎的 URL 工具常見兩種失敗模式：不管公式產生什麼都直接寫入，包括無效的網址；或是只要其中一個連結出錯就什麼都不寫。批次 URL 產生器採用了第三條路徑。瀏覽器會把每一個代入的值都解析為絕對 URL，只接受 http: 與 https: 這兩種協定，內嵌的使用者名稱或密碼會直接被拒絕。整個操作會直接失敗，而不是悄悄地把破壞樣式的那一行給丟掉。方向也有一樣的硬規則：正的步進不能朝較小的結束值移動，負的步進不能朝較大的結束值移動，而且不允許步進為零，因此方向相反的範圍會產生錯誤訊息，而不是空清單。整個序列完全在瀏覽器中以安全整數 (safe integer) 執行，這代表十進位數字、無限大以及不安全整數會在輸入階段就被過濾掉，根本進不到迴圈裡。當輸入通過後，每個產生的 URL 也會經過瀏覽器的 URL 實作進行序列化，依據 WHATWG URL 標準 來標準化主機大小寫與預設連接埠。
六個會大聲失敗而非悄悄出錯的常見錯誤
這些輸入在筆記本上看起來都很合理，但在產生器中卻永遠產不出乾淨的清單。下表中每一列都把錯誤的輸入、產品文件中記載的失敗模式，以及能解決問題的最少修改並列在一起。
| 錯誤 | 工具的行為 | 最少修改 |
|---|---|---|
| 範本缺少 {n} | 拒絕執行，不產生任何輸出 | 在路徑或查詢字串中至少加入一個字面意義的 {n} |
| 協定為 ftp:// 或 mailto: 連結 | 在 URL 解析時拒絕每一列 | 僅使用 http:// 或 https:// |
| 範本包含 user:pass@ | 因為內嵌了認證資訊而拒絕該 URL | 把認證資訊移出，改用標頭或 token 參數 |
| 起始值 10、結束值 4、步進 1 (方向錯誤) | 因為步進無法往下移動而立即停止 | 將步進設為 -1 或其他負整數 |
| 起始值 1、結束值 6、步進 2 (無法整除的範圍) | 產生 1、3、5，並在超出結束值之前停止 | 確認這個偏離樣式的落差是否符合真實的命名規則，或把結束值延伸到 7 |
| 步進為小數，例如 0.5 | 因為需要安全整數而拒絕輸入 | 使用整數的步進值，必要時另外安排 {n} 的位置 |
無法整除的情況值得花點時間說明，因為它看起來不像錯誤。從 1 到 6、步進為 2 的範圍會得到 1、3、5，而不會是 6；產生器會以步進推進，並在會越過結束值之前停下來。如果線上伺服器只會產生偶數，那麼起始值就必須是偶數，讓步進的算術真的能走到這些數字；或是把執行範圍拆成兩個較小的範圍。這兩種做法都很明確，而這正是重點。
一步步建立乾淨的 URL 清單
- 把基礎 URL 輸入為完整的絕對網址，然後在變動數字應該出現的位置放上一個字面意義的 {n}。當同一個值同時屬於路徑與查詢字串時，預留位置可以出現不只一次。
- 選擇包含首尾的起始值與結束值，使其符合伺服器上第一個與最後一個真實的識別碼，即使這些邊界看起來與步進大小並不相等。
- 設定步進。當結束值大於起始值時使用正整數，當結束值小於起始值時使用負整數；不接受 0。
- 只有在伺服器預期固定寬度的數字時才設定補零，例如把檔名 5 寫成 005。補零是最小寬度，永遠不會截斷較大的值。
- 產生一個涵蓋大約前五個值與最後一個產生值的短樣本，然後對照真實的 URL 樣式把這些行逐列唸出來檢查。
- 一旦樣本通過，就把邊界擴大到完整範圍。硬性上限是 10,000 筆 URL 以及 4,000 個字元的範本，因此方向相反或極端的範圍不可能悄悄產出失控的清單。
- 把以換行分隔的輸出複製到檔案，或使用下載選項，並把原始範本放在同一處保存，讓這次轉換得以重現。
若想了解不同範本如何對應到不同輸出形狀的逐步示範，可在 一份範本產生的七種樣式 一文中，看到同樣的控制項在升冪、降冪、補零與重複預留位置等情境下的設定方式。
先檢查樣本，再匯出
樣本的存在是為了回答一個問題：這個樣式是否符合伺服器實際的情況？從短樣本中挑出三個值，通常是第一個、中間一個，以及最後一個產生的值，然後對每一個值送出一個真實請求進行比對。如果某個補零後的值在頁面上顯示為 005，但線上 URL 卻需要 5，那就是補零造成的，把補零移除就是修正方式。如果降序範圍因為步進會越過而結束在 4 而不是 5，請先判斷伺服器實際上是否真的發佈 4，再決定是否匯出完整清單。這一步只花一分鐘，卻能避免發佈一份包含 200 個偏離樣式項目的 2,000 行網站地圖所帶來的更大成本。當任何一個代入的值無法被解析為 URL 時，整個作業會立刻停止而不會繼續，這也是樣本檢查可以很快的結構性原因：壞掉的樣式在第一行就會一目了然。
工具不會為你做的事
產生動作只能證明樣式計算與 URL 文法是正確的。批次 URL 產生器並不會對任何產生的網址發出請求、爬取、開啟或測試，因此語法上有效的 URL 仍可能回傳 404、轉向、需要驗證，或指向不該被索引的內容。當線上狀態很重要時，請使用獨立的受控檢查工具，並且絕對不要用產生的網址來捏造頁面、提交不存在的內容，或在未經授權的情況下探測系統。輸出也只是純粹的 URL 行，並非 XML 網站地圖，因此若要做探索檔案，必須再交給能處理 XML 的工具。內嵌的查詢參數會在瀏覽器序列化後保留，但以字面輸入的字元在周遭情境需要時，可能會被瀏覽器進行百分比編碼 (percent-encoding)；如果下游系統預期的是非標準的預先編碼結果，請先測試一小段樣本，逐位元組比對，不要假設所有後端都會以同樣方式解讀這個網址。
把範本與你交付的檔案保存在一起
具決定性的清單產生工具之所以有價值，是因為下一個人能夠重現它。請把範本、起始值與結束值、步進、補零寬度，以及匯出日期，存放在與 URL 檔案或網站地圖輸入相同的資料夾中，可以是檔案頂端的一行註解，也可以是附屬的 readme 檔案。重現之所以重要，有兩個原因。第一，當三個月後伺服器的重新命名或轉向政策改變時，團隊可以用相同的範本與相同的邊界再跑一次，產生一份新的清單，而不必去猜原始數字是怎麼來的。第二，搜尋引擎與爬蟲會對真實 URL 集合的變動做出反應，因此稽核紀錄正是讓批次 URL 匯出在索引審查中站得住腳的依據。產生器本身是本機且無狀態的，所以重現性完全取決於你所保存的檔案，而非工具本身。
想深入了解，可參閱 Canonical 標籤產生器：避免這些輸入錯誤。