很多網站整理出完整的 URL 清單後，就停在一張很長的試算表。真正困難的是下一步：哪些網址算重複、改名要不要轉址、轉到哪裡、轉完怎麼確認。本篇用清單式步驟，把這些決定拆成可以逐項勾選的工作。
處理重複、改名與轉址之前，要先替清單上的每一個網址標上明確的狀態，否則後面所有決定都會混在一起。建議至少使用五種狀態：保留、合併、改名、下架、待查。每個網址只能有一種狀態，不能出現「可能合併」這種模糊標記。標完狀態後，再按狀態分批處理，工作才不會在幾百列之間來回跳。
清單的欄位也要在這一步定下來。常用的欄位包括：網址、頁面標題、主題分類、最近九十天自然搜尋點擊、外部連結數、內部連結數、狀態、目標網址、負責人、處理日期、驗證結果。點擊與連結數的用途，是在決定合併時判斷哪一個版本該留下；後面四欄則是讓整個處理過程可以被追蹤。
重複內容的判斷標準是「搜尋意圖是否相同」，而不是標題或字面是否相似。兩篇文章標題很像，但一篇回答入門問題、一篇處理進階操作，它們服務的是不同階段的讀者，不應該合併。反過來，兩篇標題完全不同，卻都在回答同一個問題，那才是真正的重複。
另一種常見的重複是技術性的：同一頁面因為參數、大小寫、結尾斜線、有無 www 等差異，產生多個網址。這類重複通常不需要合併內容，只要透過正規網址標記或伺服器設定統一即可，處理方式和內容重複不同，清單上最好分開標示。
選擇保留版本的原則，是保留累積價值最多、網址最乾淨的那一個，再把其他版本的精華內容併進去。累積價值可以從三個面向看：外部連結數量、自然搜尋點擊、以及在網站內部被引用的次數。如果三個指標指向不同頁面，優先考慮外部連結，因為外部連結最難重新取得；點擊與內部連結則可以在合併後重建。
最後一點經常被忽略。轉址雖然能讓舊連結繼續運作，但網站內部仍然大量指向舊網址，會增加不必要的轉址跳轉，也讓後續維護更困難。合併完成後，用清單上的舊網址反查全站內部連結，逐一改掉。
合併時也要注意節奏。一次合併太多組，若之後發現排名或流量出現異常，會很難分辨是哪一組造成的。建議先挑兩三組價值中等、風險較低的重複頁面試做，觀察四週左右，確認流程與轉址都正常，再分批處理其餘組別。價值最高的核心頁面放在最後，等流程已經跑熟再動。每一批處理完，都在清單上註明批次編號與上線日期，日後比對數據時才能對應。這種分批方式雖然比較慢，但每一步都可以回溯，出問題時也只需要回頭檢查一小批，而不是整站翻找。
網址改名時，每一個舊網址都要以永久轉址指向內容最相關的單一新網址，不要把大量舊網址一次導向首頁或分類頁。導向首頁看似省事，但對讀者來說是找不到原本要看的內容，對搜尋引擎來說也可能被視為軟性的找不到頁面，舊網址累積的價值很難轉移。
改名前先問一個問題：這次改名是否真的必要？網址只是一個識別碼，如果舊網址雖不好看但仍能正確描述內容，維持不動往往是風險最低的選擇。適合改名的情況包括：網址中有錯字、包含已經過期的年份或活動、或者網站整體結構重整需要統一規則。為了「好看一點」而大規模改網址，通常得不償失。
改名後的轉址要避免形成鏈條。例如甲頁過去已經轉到乙頁，現在乙頁又改名為丙頁，就應該把甲直接轉到丙，而不是甲到乙再到丙。清單中的「目標網址」欄位要永遠填寫最終網址，每次改名時，回頭檢查是否有其他舊網址的目標等於這次被改名的網址，一併更新。
不是每個下架頁面都需要轉址。判斷原則是：如果網站上有內容相近、能滿足原讀者需求的頁面，就轉址過去；如果沒有，讓它回應找不到頁面或已移除的狀態碼，比硬轉到不相關的頁面更誠實。例如一場已結束的活動報名頁，若網站上有同類活動的總覽頁，可以轉過去；若該類活動已完全停辦，就讓它自然下架。
下架前還有一個檢查：這個頁面是否有外部網站連結進來。若外部連結多且品質好，即使沒有完全對應的新頁面，也值得考慮轉到最接近的主題頁，或者乾脆保留一個簡短的說明頁，告訴讀者內容已移除並提供替代資源。
轉址設定完成不等於生效，一定要逐一驗證。驗證的方法可以分成三層。
驗證結果要回填到清單的「驗證結果」欄，失敗的項目標紅並指定負責人重新處理。建議在上線後的第一週、第四週各做一次完整批次檢查，之後每季抽查。網站改版或更換主機時，轉址規則最容易被意外清除，這時候清單就是恢復設定的唯一依據。
這套流程最適合頁面數量在數百到數千之間、內容結構相對清楚的網站。頁面數量達到數萬以上時，逐列人工判斷不再可行，需要依網址規則批次處理，並接受一定比例的誤判。另外，本文談的轉址與狀態碼屬於通用原則，實際設定方式依網站平台與主機環境而異，執行前應與負責的工程人員確認，並先在測試環境驗證。最後，清單只能處理已知的網址；若網站過去曾有多次改版而沒有留下紀錄，外部世界可能還流傳著你清單上沒有的舊網址，這些只能從伺服器紀錄或外部連結工具中慢慢找回。