Website redesign SEO checklist before you relaunch
A website redesign should improve how visitors understand and use your business while protecting the pages that already earn attention. Before changing templates, navigation or a CMS, establish what is indexed, which URLs matter and how enquiries currently work. This checklist turns SEO migration into a set of visible deliverables: an inventory, a destination map, a testable build and a launch review with clear owners.
Key takeaways
- Record existing URLs and useful search and enquiry baselines before redesign work.
- Keep valuable URLs where practical and map changed URLs to relevant destinations.
- Test the actual production response, content, navigation and lead flow after launch.
Build a baseline before the old site disappears
Export the current sitemap and collect URLs from navigation, analytics and the CMS. Include important articles, product or service pages, downloadable resources and landing pages still used by campaigns. Record their titles, headings, canonical destinations and current redirect behaviour. Keep a copy of the existing site and configuration so an unexpected loss can be investigated against evidence.
Look at which pages support commercial outcomes, not only which receive the most visits. A service page with a few relevant enquiries may deserve more care than a popular article with unrelated readers. Note seasonal changes and tracking limitations when comparing results. A redesign launch date without a reliable before-and-after record makes it difficult to distinguish migration errors from changes in demand or measurement.
- Inventory URLs from several sources rather than relying on one sitemap.
- Keep a record of key enquiry paths and their current behaviour.
Map changed URLs to useful destinations
Keep existing addresses when the page's purpose remains the same. When a URL must change, give it a specific destination that answers the same need. An old service page should not automatically redirect to the homepage simply because the new design no longer includes it. Decide whether to retain, merge or retire each page according to the content and the visitor's likely expectation.
Google's site-move guidance recommends relevant redirects and checking the new site's canonical and indexing rules. Treat the mapping as a deliverable you can review before launch. Update internal links to the final destinations so the new site does not depend on redirects for ordinary navigation. Inspect a sample manually, including older deep links that are easy to overlook in a visual review.
| Existing page | Redesign decision | Expected result |
|---|---|---|
| Service page with the same purpose | Keep the URL | Updated page returns 200 with its own canonical |
| Old article merged into a stronger guide | Redirect to the matching guide | Visitor reaches equivalent useful content |
| Discontinued content with no replacement | Retire intentionally | A real missing-page response with helpful navigation |
| Duplicate address or old alias | Consolidate consistently | Links and canonical signals point to the chosen URL |
- Give every changed important URL an intentional outcome.
- Avoid redirect chains and broad homepage redirects for unrelated pages.
Review the rendered content and page structure
Compare the new page with the old page's useful information. A visually cleaner layout can accidentally remove service details, product specifications, author context or internal links that helped users understand the business. Rewrite weak material where needed, but preserve the meaning and intent of pages that still have a clear role. Avoid replacing every title with the company name or repeating one description across the site.
Check the page as a visitor and as an HTTP response. Important content, metadata and navigation should be accessible to the systems expected to discover them. Make sure the public pages are not carrying staging restrictions after deployment. Verify that private account or client areas keep their access controls; a redesign is not a reason to expose protected information for the sake of adding more indexable content.
- Check page-specific titles, descriptions, headings and visible service information.
- Verify public and private routes separately during the release review.
Make launch a controlled, reversible change
Agree a launch checklist before the deployment window. Identify who can update DNS or hosting configuration, who checks the redirects and who verifies the contact and payment flows. Save a restorable copy of files and relevant data. Define the problems that would require restoring the previous release, and distinguish those from small visual issues that can be corrected safely afterward.
Use production-like tests for the journeys most likely to create revenue or enquiries. A contact form should confirm receipt rather than show success after a failed request. A store should handle the supported payment outcomes. Test the mobile menu, deep links and any content editor workflow that the owner relies on. A screenshot comparison alone cannot demonstrate that the redesigned site still works as a business tool.
- Check backup and rollback steps before replacing the live release.
- Assign an owner to each high-impact production verification.
Monitor actual changes after release
Compare search performance, landing-page visits and accepted enquiries over sensible periods. A smaller site can have large percentage swings from a handful of visitors, so inspect absolute numbers and the affected URLs. If visits fall, check availability, indexing rules, redirect destinations and tracking before assuming that new design choices or content are the cause. Record the release date and any later fixes.
Use the new sitemap and internal links to make the revised structure discoverable, and review important URLs in the search tools available to the site owner. Discovery requests do not prove that indexing or rankings have recovered. Keep monitoring commercial journeys as well as search reports: a stable visitor count with a broken enquiry form is still a failed launch. The goal is a useful, reachable website with evidence that its core actions work.
- Investigate losses by affected page and traffic source.
- Continue checking real enquiry delivery after the launch day.
Sources and further reading
Primary documentation for the platform-specific details discussed in this article. The planning examples above are illustrative requirements, rather than client case studies.
Planning a redesign with existing traffic?
Send the current website and the changes you want to make. I can help scope the URL inventory, migration responsibilities and launch checks alongside the new design.
Discuss a projectFrequently asked questions
Practical answers to help you plan the next step.
Yes. Rankings can drop when URLs, content, metadata, internal links or performance change without a migration plan.
Only when there is a clear reason. Valuable pages should be preserved, improved, merged or redirected carefully.
From the planning stage. Waiting until launch week usually creates avoidable ranking and tracking risks.
