Preserve a clear map from important old URLs to their relevant replacements when launching a rebuilt WordPress website. Visitors may arrive from bookmarks, email campaigns and search results long after the new design goes live.
IN THIS ARTICLE
01 Build a redirect inventory
Collect URLs from the old sitemap, analytics, existing redirect rules and known campaigns. Include important files and landing pages as well as ordinary posts. For each old URL, record the new equivalent, whether the old URL still exists, and which system will own the redirect. Keep this map as part of the deployment record.
02 Implement the reviewed mapping
- Retain existing URLs when the content purpose has not changed and there is no reason to alter them.
- Map moved content to its closest useful replacement rather than sending every old URL to the homepage.
- Choose the appropriate permanent redirect for a permanent move and configure it in one supported location, such as the server, CDN or a maintained redirect tool.
- Test individual rules and broader patterns on staging or a controlled preview.
- Deploy the rules with the new website and update internal links to point directly at final URLs.
What about pages with no replacement?
Do not invent an unrelated destination solely to avoid an error status. A genuinely removed page may appropriately return a not-found or gone response. Review valuable old content before retiring it and give visitors a useful navigation path on the site's error page.
How do redirect chains appear?
A new rule may send an old path through an intermediate URL that already redirects again. Hostname and HTTPS rules can add more steps. Test the complete response chain and point old URLs directly to the final suitable destination where the configuration permits. Check for loops caused by conflicting rules in multiple systems.
03 Monitor after launch
Test a sample of exact old URLs, including query strings when they matter to the application. Review not-found logs and search reporting to find missed routes, then add targeted corrections. Keep the old domain and its HTTPS service working if redirects depend on it. Preserve the redirect inventory during future redesigns so each launch does not discard the routing work from the previous one.