核准起始頁，不等於核准所有後續連結
監測工作由核准目錄頁出發，接著可能發現帳號頁、無止盡搜尋參數或其他主機。增加住宅路由無法處理這種範圍擴張。擴大工作量之前，先列出允許請求的集合，並逐一檢查候選URL，而非只核對起始清單。
RFC 9309訂定自動用戶端的robots排除規則，但它不構成存取授權。這一層使用經測試的解析器。本篇另提出應用層閘門，結合明確授權、URL範圍與執行上限；它不替代協定解析器，也不是法律許可判定。
步驟一：把監測需求寫成請求約定
針對自有測試站或明確授權的監測網站，記下允許的通訊協定、精確主機與連接埠、路徑集合、查詢參數及值、用途、有效期限和範圍負責人。第一次執行前設定頁面及請求預算。發現新連結或收到200，都不會自動擴大約定。
自有樣本站可以只允許/catalog/及固定market、page值，排除/account/和/search/。這是應用設定範例，不是98IP或目標站的規則。每份約定有版本號，方便追溯某次判斷所依據的界線。
步驟二：統一比較方式，保留URL語意
以實際文件URL為基準解析相對連結，交由持續維護的URL函式庫處理。主機名稱要按主機欄位比較，不能只找字串是否含有核准名稱。其他網域的標籤就算包含相同文字，也不屬於精確主機名單。子網域與非預設連接埠依約定決定，別直接納入。
可移除片段來建立去重鍵，但路徑大小寫、百分比編碼、重複參數與參數順序，要按目標語意處理。不要一律解碼保留分隔字元，也不要刪除全部參數。無法確定的URL先待確認；為了容易比對而改寫URL，可能變成另一項資源。
步驟三：進佇列與派送前都經過閘門
解析候選連結後，核對明確授權和應用約定的主機、路徑與參數，再用實際爬蟲身分套用適用的robots判斷，最後檢查剩餘預算及有效期限。結果分成可送出、拒絕、待確認，並記錄host_out_of_scope、query_not_approved、policy_expired或policy_unavailable等原因。
連結發現、佇列接納與派送使用相同判斷。昨天接納的項目，在今天約定變更後仍需重新檢查。佇列項保存策略版本，派送時比對目前版本，必要時重算結果。拒絕項不能進入一般網路重試佇列。
步驟四：重新導向前重新核對目的地
自動跟隨重新導向可能在應用程式讀到新目的地之前，就發出下一個請求。驗收時設定用戶端揭露重新導向，解析Location，再交給閘門決定是否繼續。限制鏈長並偵測重複目的地。第一站獲准，並不表示最終站也獲准。
用自有端點分別模擬核准目錄轉往排除的帳號路徑，以及轉往約定外的主機。預期應在發送新請求前停住並留下原因，不能先取回再丟棄。也要確認登入驗證材料不會被轉送到未核准的界線。
步驟五：以小型樣本驗收佇列
準備六類候選：核准目錄URL、排除帳號路徑、禁用參數值、範圍外重新導向、帶舊策略版本的佇列項，以及重複發現的核准URL。事先列出每項預期結果。依選定的正規化規則，重複連結只建立一項接納工作；舊項則以目前策略再判斷。
以來源站存取紀錄或可觀測的本機請求發送器，證明拒絕目的地未收到請求。佇列計數不足以支持這個結論。robots取得、解析或判斷不明時，本文採用的保守應用策略會暫存工作等候審查；這是執行保護選擇，而非所有協定錯誤規則的摘要。
核准樣本取得預期內容、拒絕樣本未送出、待確認項與網路重試分離，且預算達門檻後停止新增請求，才通過驗收。已核准URL的逾時或429屬於路由或目標結果，不應擴張範圍、重設預算，或更換身分來規避拒絕。
何時使用住宅代理路由
授權監測需要觀察指定住宅市場時，可使用98IP動態住宅IP。無論採用哪個出口，都保留同一範圍閘門，先核對觀察到的路由，且只設定帳戶可用選項。代理提供路由，不提供存取許可、不解讀業務約定，也不保證目標接受請求。
擴充規模前，參考98IP操作指南確認接入流程與限制。比較相同工作量下接納的請求及實際帳戶用量；閘門可能減少多餘工作，但不能由本設計推論固定速度、成本節省或目標相容性。
FAQ與執行前檢查
robots允許就足夠嗎？還要有明確許可，並符合應用約定。也不應透過代理避開robots限制或存取拒絕。
拒絕項能換IP再試嗎？範圍拒絕是策略結果，不是出口故障。只有經授權的範圍變更才重新審查；不確定項則等待釐清。
發布前核對：主機與連接埠精確比對；路徑參數語意保留；真實爬蟲身分；策略版本；派送複查；重新導向攔截；拒絕、待確認及重試分開；預算有限；來源站紀錄可驗證。診斷URL不放秘密，敏感參數去識別化；蒐集內容與請求紀錄都要遵守隱私及保留規則。