Websites and deployment
Build a redirect map before changing website URLs
Preserve visitors and search signals with one-to-one permanent redirects and post-launch crawl checks.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Map each important old URL to the closest equivalent new resource and use a single permanent redirect hop. Do not send every removed page to the homepage; keep content that still satisfies the intent or return an honest gone/not-found response.
What this means in plain English
When URLs change, old bookmarks and search results need a clear destination. Map each valuable old page to the closest new page and use one permanent redirect. Sending every missing page to the homepage confuses visitors and search engines.
Build the list from the old sitemap, analytics, server logs and a site crawl. Test for loops, chains and pages accidentally left behind after launch.
Where should every valuable old URL land?
| Coverage | Traffic, backlinks and indexed old URLs included |
|---|---|
| Relevance | Destination satisfies the same intent |
| Quality | One hop without loops or chains |
A simple example
Old /services/web-design moves to /website-design, so it receives a direct permanent redirect. An old event page with no useful replacement returns a real not-found or gone response instead of pretending the homepage is the same content.
What to do, step by step
1. Export routes from sitemap, analytics, logs and crawl data.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on coverage: traffic, backlinks and indexed old urls included. Write the result down so you can compare it later.
2. Assign exact destinations and owners.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Test the map before DNS cutover.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Crawl old URLs after launch and monitor 404s.
Finish by checking the result against quality: one hop without loops or chains. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Keep redirects after the migration traffic appears quiet. Old links can remain in documents, emails and other websites for years.
Common mistakes and how to avoid them
Wildcarding every path to home.
This gives a misleading or unsafe result because it leaves out coverage. A better approach is to export routes from sitemap, analytics, logs and crawl data, then check the result before making the change permanent.
Creating redirect chains.
This gives a misleading or unsafe result because it leaves out relevance. A better approach is to assign exact destinations and owners, then check the result before making the change permanent.
Dropping query-dependent landing pages without review.
This gives a misleading or unsafe result because it leaves out quality. A better approach is to test the map before dns cutover, then check the result before making the change permanent.
Words explained
- DNS
- The system that connects a domain name to the service or server that should answer for it.
Quick checklist
- Export routes from sitemap, analytics, logs and crawl data.
- Assign exact destinations and owners.
- Test the map before DNS cutover.
- Crawl old URLs after launch and monitor 404s.
Common questions
What is the simple answer?
Map each important old URL to the closest equivalent new resource and use a single permanent redirect hop. Do not send every removed page to the homepage; keep content that still satisfies the intent or return an honest gone/not-found response.
What should I check first?
Start with coverage: traffic, backlinks and indexed old urls included. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Export routes from sitemap, analytics, logs and crawl data. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Wildcarding every path to home. Avoiding that one mistake makes the rest of the comparison much more trustworthy.