Search & performance
Website redesign SEO checklist: plan the migration before launch
An actionable redesign plan covering URL inventory, redirect decisions, staging, content checks, launch verification and post-launch monitoring.
Treat a redesign as a content and URL migration as well as a visual change. Save the existing page inventory and agree each destination before switching the site.
Save a baseline you can compare later
Start with the current sitemap, a crawl of reachable pages and available Search Console landing-page data. Include important downloads and campaign links. Record the URLs that receive enquiries or support customers even when they have little search traffic.
A baseline needs a date range and context. Save page-level impressions, clicks and known form problems rather than a single sitewide screenshot. Traffic can fluctuate for reasons unrelated to the redesign, so record promotions, seasonal events and tracking changes too.
Make an explicit decision for each old URL
Keep useful URLs where possible. When a page moves, choose the closest relevant replacement and use a permanent server redirect. Google advises against sending unrelated removed pages to the homepage; where no suitable replacement exists, return an appropriate missing-page response. Update internal links, canonicals and the sitemap to the final URLs.
This simplified example is a planning worksheet. Your real map must come from the old website, not a list invented after launch.
| Old page | Decision | Check |
|---|---|---|
| /services/design | Retain or map to the equivalent service | Content answers the same customer need |
| /old-contact | Redirect to /contact | Form and confirmation still work |
| /expired-offer | Remove if no replacement exists | Return 404 or 410; do not pretend it still exists |
| /guide.pdf | Retain or redirect the download | Saved external links remain useful |
Review a protected preview against the inventory
Approve a migration checklist before the team starts replacing templates. Compare key content, headings, contact details and downloads on the old and new versions. A beautiful layout is not a reason to remove the explanation that helped customers understand a service.
Protect the preview appropriately, then separately check that production is publicly accessible at launch. Test common journeys with realistic content: a long enquiry, a missing required field, an image that loads slowly and a narrow mobile viewport. Define who can stop the release if a critical path fails.
Make the release reversible and observable
Keep a known working version and record what must be restored if the launch fails. If forms, databases or content editors also change, a code rollback alone may not restore the previous state. Agree the recovery procedure and responsible person before deployment.
Check old high-value URLs after release, including redirect destinations and final response status. Confirm new pages use the intended canonical domain. Submit the current sitemap through the verified property and monitor important pages rather than repeatedly requesting the same action.
- Verify representative old URLs and their final destinations.
- Check key service pages, downloads and enquiry delivery.
- Confirm production indexing settings and canonical URLs.
- Record launch time, release version and known issues.
- Review page-level traffic and errors over comparable periods.
Separate migration defects from ranking changes
A redirect loop, missing service page or broken form deserves immediate investigation. A change in average position needs context: which queries, pages, devices and dates changed? Avoid rewriting everything at once in response to a small sample.
No migration plan can promise unchanged rankings. Its purpose is to preserve useful content and working destinations while making the new website easier to use. Keep technical observations and business outcomes in separate columns so the next decision follows evidence.