A successful launch checklist is incomplete if the new site looks right but old customer links lead nowhere. Migration planning needs an inventory, explicit URL decisions, and tests that continue after release.
To reduce SEO risk during a migration, preserve valuable content and URLs where sensible, map changed URLs to relevant destinations, test redirects and indexing signals before launch, validate the deployed site, and monitor old and new URLs afterward. Temporary visibility changes can occur; no process guarantees zero traffic loss.
Identify what is actually changing
A hosting move, domain change, CMS replacement, redesign, and information-architecture change introduce different risks. Write down the scope rather than calling everything a redesign.
Where practical, avoid changing several major systems simultaneously. Google’s site-move guidance recommends separating major changes and describes the processing that follows URL moves. The project plan should allow investigation if a problem appears.
Name release, SEO, development, content, analytics, and rollback owners. Set decision deadlines for content removal and URL changes. A redirect spreadsheet completed after launch is damage control, not a migration plan.
Build the old-site inventory
Combine a crawl with CMS exports, sitemaps, relevant search and analytics pages, known external landing pages, and important downloads. Record provenance so you know which URLs were discovered only in historical data.
For each valuable URL, capture page purpose, current response, intended canonical, important content, internal links, search role, and business importance. Avoid using traffic alone to decide deletion: a low-traffic page may support compliance, customer service, or a valuable niche inquiry.
Inventory images, PDFs, and other linked assets too. Moving HTML while abandoning externally linked downloads can break useful journeys.
Create a decision for every changed URL
| Decision | Appropriate situation | Validation |
|---|---|---|
| Keep | Same useful page and URL | Content and signals remain correct |
| Move | Same purpose at a new URL | Direct relevant permanent redirect |
| Merge | Several pages consolidated usefully | Destination serves the old intent |
| Remove | Content has no useful successor | Appropriate missing-resource response |
Do not default every removed URL to the homepage. Relevance matters. If no equivalent exists, a useful missing-page experience is more honest than a misleading redirect.
Add owner, approval, destination, and test result to the mapping sheet. Resolve duplicate destinations intentionally: several old pages can map to one new page when the new page genuinely covers their purpose, not merely because mapping individually is inconvenient.
Test staging without exposing private work
Protect staging with appropriate access controls. Separately document how production indexing controls will be configured. Do not rely on a robots rule as a privacy mechanism.
Test representative templates for content, navigation, forms, mobile behavior, analytics, metadata, canonicals, structured data, and language alternatives where relevant. Include failure cases such as missing routes and invalid product identifiers.
For JavaScript delivery, compare initial HTML and rendered content. A visually complete page can still omit important text or links during processing. Review Google’s JavaScript SEO guidance for Google-specific behavior.
Prepare launch gates
Before deployment, confirm backups, rollback steps, redirect rules, sitemap generation, production access rules, analytics configuration, and monitoring ownership. Make the launch decision against written acceptance criteria.
Test a representative set of old URLs against the planned routing behavior. Check that destinations exist, serve the intended content, and do not chain through avoidable intermediate redirects. Google’s redirect documentation distinguishes permanent and temporary moves.
Agree which defects block launch. A broken primary inquiry form or inaccessible category template should not be treated as a minor post-launch cosmetic task.
Validate the deployed website
Check production directly. Confirm critical pages return the expected responses and that staging-only restrictions have not reached public templates. Verify canonical destinations, internal navigation, essential content, and contact or purchase flows.
Test old URLs, not just new ones. Check alternate hostnames and important historical entry routes where they are in scope. Update internal links to final destinations so current users do not rely on the redirect layer unnecessarily.
Submit or update relevant sitemaps and use appropriate Search Console migration tools when the type of move supports them. Follow current documentation instead of applying a domain-change procedure to every redesign.
Monitor both sides of the move
Track old and new URLs, errors, important landing-page groups, search observations, and qualified customer outcomes. Annotate release dates and other business changes. Temporary fluctuations are possible while processing occurs.
Keep redirects in place for the period recommended by current guidance and longer where useful for users. Do not remove them merely because a short-term report looks stable. Historical links and bookmarks can remain valuable.
When a problem appears, compare affected templates with unaffected ones. Investigate access, mapping relevance, content differences, and measurement before blaming the domain change itself.
A compact migration runbook
Inventory; decide keep/move/merge/remove; approve mapping; test templates; test redirects; prepare production controls; confirm analytics; establish rollback; launch; verify critical routes; monitor search and customer outcomes; document unresolved issues.
For architecture planning, read the site-structure guide. For routing decisions, use the redirect and 404 guide. If the move is commercially important, request a technical migration review.
Common questions
Can I migrate without losing any traffic?
You can reduce avoidable risk, but cannot guarantee an unchanged search outcome. Plan for monitoring and investigation.
Does a redesign always need redirects?
Only changed or consolidated URLs need corresponding routing decisions. A visual change with stable URLs still needs template and content checks.
Should all old pages redirect to the homepage?
No. Use a relevant successor where one exists; otherwise return an appropriate missing-resource response.
Research checked October 25, 2026. Examples and planning frameworks are illustrative unless stated otherwise. Featured imagery is AI-generated editorial photography, not documentary evidence of clients or projects.
