Reduce migration risk by limiting simultaneous changes, capturing the current search baseline, mapping every URL, preserving valuable content and metadata, implementing direct redirects, testing before launch and monitoring after search engines recrawl the new site.
Key takeaways
- Change only what has a clear reason.
- Build and test the URL map before launch.
- Keep staging inaccessible to indexing without blocking production.
- Expect monitoring and correction after release.
Who this is for: Engineering, SEO and marketing teams moving a website to a new CMS, design, URL structure or domain.
Identify the migration type
A visual redesign with stable URLs carries less search risk than changing domain, CMS, content and information architecture together. List every changing layer and remove changes that do not create clear value.
- Domain or protocol
- URL structure
- CMS or rendering architecture
- Content and metadata
- Navigation and internal links
- Structured data
- Hosting/CDN
- Analytics and consent
Capture and map
Export the old site's evidence and create a one-to-one decision for every indexable URL.
- 1Crawl the current site and export status, canonical and metadata.
- 2Add organic entrances, queries, conversions and external-link evidence.
- 3Classify each URL as keep, improve, consolidate or retire.
- 4Map old URLs directly to the closest new equivalents.
- 5Review mappings with content, SEO and engineering owners.
Prepare the new site
Test production-like behavior before cutover.
| Area | Pre-launch validation | Production validation |
|---|---|---|
| Crawl | Templates and directives | Robots and status codes |
| URLs | Redirect rules and canonicals | Priority old URLs |
| Content | Parity and intended changes | Rendered critical content |
| Links | No staging/legacy targets | Crawl for broken links |
| Measurement | Test events | Real submissions/events |
| Performance | Representative templates | Field monitoring begins |
Controlled cutover
Create a content freeze, final data sync, backup, rollback decision point and named launch owner. Keep the old environment available privately for diagnosis without leaving it publicly indexable.
freeze -> final crawl -> backup -> deploy -> redirect test
-> robots/canonical test -> analytics/form test -> sitemap
-> monitoring -> rollback decision window
Post-launch monitoring
Track priority URLs, crawl errors, indexing, impressions, clicks, conversions and server logs where available. Correct systemic issues quickly and avoid reacting to a single day of volatility without diagnosis.
How to use this guide with your team
Technical search work should be translated into user and business consequences. A redirect is not merely a status code; it determines whether a customer or search engine reaches the correct replacement for an old resource.
Create a shared validation sheet that content, SEO and engineering teams can understand. Mark the expected behavior, actual result, owner and resolution instead of exchanging screenshots without decisions.
Monitor after release because crawling, indexing and user behavior continue beyond launch day. A technically correct configuration still needs production evidence.
Practical next steps
Use the following actions as a short working session. Record decisions, owners and unresolved questions so the article becomes an implementation aid rather than passive reading.
- 1Explain every technical task in business terms.
- 2Test representative URLs and templates.
- 3Record expected and actual behavior.
- 4Assign resolution ownership before launch.
- 5Monitor search and conversion evidence afterward.
Frequently asked questions
Should we change URLs during a redesign?
Only when the new structure provides meaningful user or maintenance value. Stable, useful URLs reduce migration work and risk.
Can redirects fix missing content?
No. A redirect transfers users and signals to a destination, but the destination must still satisfy the original intent where preservation is expected.
Sources and further reading
Last reviewed: September 1, 2026
