1. Export and classify old URLs
Gather URLs from the current sitemap, internal links, analytics, and Search Console. Classify each as unchanged, moved, consolidated, or intentionally removed so the team can decide a suitable response for every address.
Export URLs from more than one source because the sitemap may omit retired pages that still receive links. Include analytics, Search Console, server logs if available, and the current site crawl.
2. Choose the closest replacement
Match a moved page to its direct successor. If several pages are consolidated, map each to the new page that preserves its main purpose. Where no useful replacement exists, avoid sending users to an unrelated page just to avoid a 404.
Use a direct replacement only when it satisfies the old page’s main need. For a page with no equivalent, choose an honest not-found or gone response rather than redirecting every retired URL to the homepage.
3. Specify and test each redirect
Record old path, destination, redirect type, and owner in a simple table for whoever controls the server or hosting. Test representative old URLs after implementation and confirm they land on the intended HTTPS page without unnecessary redirect chains.
Record whether each move is permanent or temporary and avoid chains such as old URL to intermediate URL to final URL. Test both destination and response behavior after the rules go live.
4. Keep links and signals consistent
Update navigation, page links, canonical URLs, and the sitemap to use the final destination directly. Redirects are a transition aid; internal links should not keep sending visitors through an old address.
Update internal links to final URLs and remove redirected addresses from the sitemap. For the wider move, pair this redirect table with the website content migration plan and canonical URL guide.
Related official guidance: Google Search Central: Site moves with URL changes.