Key Takeaways
- Protect useful pages and customer journeys before changing the design.
- Keep URLs where possible; map necessary moves to genuinely equivalent destinations.
- Test production crawl access and forms after release, not only the staging preview.
You can reduce the SEO risk of a redesign, but nobody can guarantee unchanged rankings. Treat the redesign as a content and migration project as well as a visual one. Keep a record of what changes so a later traffic movement can be investigated rather than guessed at.
Inventory the pages worth protecting
Combine the current crawl, sitemap, Search Console page performance, analytics landing pages and known backlinks. Include pages that receive enquiries or support a sales conversation even when their search volume is small. Missing analytics data is not proof that a page has no purpose.
For each URL, record its intent, status, canonical, meaningful incoming links and proposed destination. Keep the original URL if it still fits. An article and a service page can share a subject without being duplicates: one may explain a decision while the other offers delivery.
Separate design choices from URL changes
Changing a layout does not require changing its address. Agree which templates, navigation labels, forms and content are changing, and which remain. Avoid combining a domain move, platform migration and full content rewrite unless the brief requires all three.
If the developer is also changing, use the WordPress access and handover checklist. Domain, hosting, email and repository ownership should not be discovered during launch. Agree a freeze window and one release owner.
Map redirects deliberately
| Existing page decision | Appropriate handling |
|---|---|
| Same page and URL retained | Keep it accessible and self-canonical |
| Page moves to an equivalent URL | Use a permanent server-side redirect to that destination |
| Several genuinely overlapping pages combined | Preserve useful material and redirect to the relevant consolidated page |
| Content retired with no relevant replacement | Review its demand and links before allowing an appropriate not-found response |
Do not send every removed article to the homepage. Check Google's site-move guidance when addresses change. Test the actual old URLs, including important linked variants, and update internal links to the final destination.
Keep staging private and production crawlable
A staging restriction must not leak into the production release. Check robots.txt, page robots metadata and X-Robots-Tag headers on representative public pages. Review canonicals and sitemap URLs for staging hosts or obsolete paths.
Use access protection for private staging content; noindex is not an access-control mechanism. Conversely, do not strip restrictions from private proposals or account areas just to make an audit greener. The robots introduction explains why crawling controls and indexing controls are different.
Agree a go or no-go checklist
- Important public pages return the expected status and show the intended main content.
- Titles, descriptions, headings and canonicals describe the correct page.
- Redirects reach a relevant destination without loops, and internal links use it directly.
- Forms deliver a controlled test to the correct destination; failures are visible.
- Analytics respects consent and distinguishes a successful enquiry from a contact click.
- Images, mobile navigation, keyboard use and the editing workflow have been checked.
- Private pages and documents remain protected.
The website-traffic but no-enquiries guide helps separate a measurement gap from a broken journey. Use the Core Web Vitals guide for repeatable performance checks. Do not judge release safety from a homepage screenshot or a single Lighthouse score.
Monitor the release without blaming every fluctuation
Record the production version and release time. Compare complete periods with the same country, device and search-type filters. Segment changed URLs from unchanged ones. Search Console reporting and recrawling take time, so the newest point on a graph is not a complete verdict.
If important pages become blocked, return errors or lose their content, investigate immediately and use the agreed repair or rollback route. A drop with healthy technical checks needs page-and-query analysis, not an automatic rewrite of every title. Keep relevant redirects in place and verify sitemap processing without repeatedly submitting unchanged requests.
Our website redesign service can scope this alongside design and development. The website cost guide explains what to separate in the estimate. Share the existing site and planned changes so migration work is included before launch.
Frequently Asked Questions
Can a redesign guarantee the same Google rankings?
No. Preserve valuable content, crawl access and relevant URLs to reduce avoidable risk, then monitor the changed pages. Search demand and ranking systems also change independently of a release.
Should every old URL redirect to the homepage?
No. Map a moved page to a genuinely relevant replacement. Review demand and backlinks before retiring a page that has no equivalent destination.
Is a staging test enough to approve launch?
No. Recheck production status codes, content, robots controls, canonicals, redirects, forms and private-page protection. Production configuration can differ from staging.
