A website redesign can change templates, navigation, URLs, forms, and measurement in one release window. Without a launch plan, the new theme can go live with broken redirects, missing tracking, blocked staging rules, or a conversion path that no longer matches the live site.
Google processes redesign impact URL by URL rather than as one instant switch. When the redesign changes public URLs, current Search Central guidance still centers the same sequence: map old URLs to new URLs, use permanent server-side redirects, update canonical targets and internal links, keep Search Console ownership working, and submit the new sitemap after launch. When URLs stay the same but hosting changes, the new copy still needs full testing and the temporary crawl blocks must be removed before traffic moves.
Keep the redesign release board focused on one launch decision path: scope, baseline, URL map, staging rule, template QA, search assets, and rollback trigger. If the project also changes domain, CMS, or hosting, record those as separate change tracks and avoid stacking them into one blind cutover unless the business has already accepted the added risk.
Steps to plan a website redesign launch:
- Freeze the release board with one owner, one launch window, the critical page types, and the business path that cannot regress.
Goal | Preserve organic traffic and form submissions during the redesign Launch owner | webmaster@example.com Launch window | Saturday 22:00-23:30 Critical pages | /, /pricing, /contact, /thank-you Critical journey | Landing page -> form submit
- Export the live baseline before design approval is treated as final.
Organic landing pages | exported Top queries | exported Conversions or revenue | exported Form submissions | exported Page speed on critical templates | exported
Pull the baseline from the analytics tool, Search Console, the form or commerce system, and any uptime or performance monitor that proves the site's main business path.
- Inventory the current public URLs and production dependencies.
Included assets | HTML pages, PDFs, images, forms, feeds, structured data, canonicals, analytics tags, consent tags
Start with the URLs that already matter in sitemaps, analytics, server logs, and link reports, then add every dependency that must still work when the new templates go live.
- Separate any domain move, CMS replacement, hosting cutover, and analytics reset from the redesign release if they do not have to ship together.
Current Google site-move guidance recommends changing one major variable at a time where possible. A redesign, domain move, CMS replacement, and measurement reset in the same window makes rollback and diagnosis much harder.
- Build the old-to-new URL map before development is treated as complete.
/services/seo | /services/search-audit /blog/2024/old-guide | /guides/new-guide /summer-promo | 410 Gone
Use permanent server-side redirects such as `301` or `308`, send changed URLs straight to their final destination, and do not collapse unrelated pages into the home page.
Related: website-redirect-test-before-launch
- Decide how staging stays out of search before content review opens.
Preferred control | Password, SSO, VPN, or IP allowlist Public exception | Crawlable noindex only when outside reviewers need open access
Do not rely on robots.txt alone. Google's current guidance says hidden or unfinished pages need password protection or a crawlable noindex rule, because a blocked URL can still appear in search results.
Related: staging-site-block-search
Related: noindex-manage - Lock the template QA list on the exact pages and page types that drive traffic or revenue.
Check | Navigation, titles, meta descriptions, canonicals, hreflang, structured data, forms, consent flow, analytics tags, mobile layout, desktop layout
Review the templates on the real critical pages from the release board instead of checking only the home page.
- Keep Search Console verification and the launch sitemap ready on the production destination.
Verified property | Yes Verification method survives new templates | Yes Launch sitemap ready | https://www.example.com/sitemap.xml
If the redesign also changes domain or subdomain, verify both old and new properties before launch. If it changes hosting without changing URLs, record the DNS TTL reduction and the old-versus-new traffic watchlist before the DNS switch.
- Name the rollback owner, the exact stop conditions, and the decision window before booking launch.
Rollback owner | webmaster@example.com Trigger 1 | Forms fail on production Trigger 2 | Top URLs return 404 or wrong redirect Trigger 3 | Analytics or consent tags missing on critical templates Decision window | First 30 minutes after go-live
The stop conditions need to be measurable enough that the release can pause immediately without debating severity after traffic switches.
- Mark the redesign ready only when every board field shows a named owner and a ready state.
Scope locked | Yes Baseline exported | Yes Inventory checked | Yes URL map approved | Yes Staging rule chosen | Yes Template QA list ready | Yes Search assets ready | Yes Rollback trigger named | Yes
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
