Before you touch anything: audit what currently exists
1. Document every current URL that gets meaningful traffic
Pull a list of your top pages by traffic and search rankings from your analytics tool before the old site disappears. Every one of these needs a working destination on the new site, whether that's the same URL restructured or a proper redirect. Skipping this step is the single biggest cause of a traffic collapse after a redesign.
2. Note every existing tracking and pixel code installed
Google Analytics, Meta Pixel, Google Ads conversion tracking, any chat widget or CRM integration, all of these live somewhere in your current site's code and need to be reinstalled on the new one. It's extremely common for one of these to get missed, meaning weeks of blind marketing data before anyone notices.
Technical foundations that determine whether Google trusts your new site
3. Set up 301 redirects for every URL that's changing
If any URL structure is changing (and it usually is during a redesign), a 301 redirect from the old URL to its new equivalent tells Google "this page moved, transfer its ranking here" instead of "this page is gone." Missing this step means starting your SEO rankings from zero on every page that moved.
4. Resubmit your sitemap to Google Search Console
Once the new site is live, generate a fresh XML sitemap and submit it through Search Console. This speeds up how quickly Google discovers and re-indexes your new pages instead of waiting weeks for a natural recrawl.
5. Check that robots.txt isn't accidentally blocking the new site
A shockingly common launch mistake: a "disallow all" rule left over from a staging environment gets pushed live with the new site, telling search engines not to index anything at all. Always verify robots.txt allows crawling before and after launch.
Speed and mobile, because most of your traffic isn't on a desktop
6. Test actual load time on a mid-range mobile phone, not just your laptop
A redesign with heavier animations, larger images or more embedded scripts often loads noticeably slower than the site it replaced, especially on a mid-range Android phone over a mobile network rather than office wifi. Test on an actual phone, on mobile data, not just a fast office connection.
7. Compress every image before upload, not after
Large uncompressed images are the most common cause of slow page loads on a redesigned site, especially with new photography or graphics from the redesign process. Compress and correctly size every image before it goes into the CMS, rather than relying on the platform to compress it automatically after the fact.
8. Actually test every form and button on a real phone
Buttons and forms that work perfectly with a mouse on a desktop sometimes have tap targets too small or too close together on a touchscreen. Have someone genuinely fill out your contact form, click through your navigation, and complete a checkout (if applicable) on their actual phone before launch, not just in a desktop browser resized smaller.
Content and conversion elements that actually drive revenue
9. Verify every internal link and call-to-action button
A redesign often means restructured navigation and moved pages, which frequently breaks internal links pointing at old URLs. Click through every button and menu item on the new site before launch, this is tedious but catches broken links before customers do.
10. Confirm your contact information and forms actually reach someone
Test every contact form, live chat widget and phone number link end to end. It's not uncommon for a form to silently stop sending emails after a redesign because a backend email address or API key wasn't migrated correctly, meaning leads vanish with no error message on either end.
11. Check that your meta titles and descriptions are actually in place
It's common during a redesign for meta titles and descriptions, the text that shows up in Google search results, to get accidentally wiped or left as generic CMS defaults ("Home | Page 1") across dozens of pages at once. Audit every important page's meta title and description before launch, since this directly affects click-through rate from search results.
12. Have someone outside the project test the whole site cold
Everyone who worked on the redesign is too familiar with it to notice confusing navigation or a missing element. Have someone with no context click through the site on their own phone and try to complete your main goal (book a call, make a purchase, fill a form) without any guidance. Watch where they hesitate.
What to do in the first 48 hours after launch
Monitor Google Search Console daily for a spike in crawl errors or a sudden drop in indexed pages, both are early warning signs of a redirect or robots.txt problem that's easy to fix quickly but expensive to leave unnoticed for weeks. Also watch your analytics for any unusual drop in conversions on key pages (checkout, contact form, signup), which often points to a broken form or tracking code rather than an actual drop in customer interest.
Why most redesign disasters are entirely preventable
Nearly every website redesign horror story we've seen (a client suddenly ranking nowhere, a form silently going dark for weeks, months of blind marketing spend with broken analytics) traces back to one of the twelve items above being skipped under launch-day time pressure. None of these require advanced technical skill to check, they require someone deliberately going through the list before hitting publish, not after a client calls asking why leads stopped coming in.
Building a realistic launch timeline around this checklist
Trying to complete all twelve checks the night before launch is exactly how items get skipped. A more realistic timeline spreads this work across the final two weeks of a project.
Two weeks before launch
Complete the audit items: document current URLs and rankings, note every tracking code currently installed, and finalise the list of redirects needed for any changed URLs. This is research work that doesn't depend on the new site being finished yet, so it can happen in parallel with final development.
One week before launch
Move into the technical and mobile testing phase on a staging version of the new site: check load speed on an actual phone, compress any images that weren't optimised during development, and test every form and button personally rather than assuming the developer already checked.
Launch day itself
Focus purely on the go-live technical steps: confirm redirects are active, verify robots.txt allows crawling, resubmit the sitemap, and do one final click-through of the live site (not the staging version) to catch anything that broke specifically during deployment.
First 48 hours after launch
This is when the outside tester should do their cold walkthrough, and when someone should be actively watching Search Console and analytics for the early warning signs described above, rather than assuming the migration went smoothly just because the site loads.
Common excuses that lead to skipped steps, and why they don't hold up
"We'll fix redirects after launch if anything breaks." By the time a drop in rankings is visible in analytics, real traffic and revenue have already been lost for days or weeks, and rankings often take longer to recover than they took to lose.
"The developer already tested it." Developers test functionality, does the button work, does the form submit, not always SEO continuity or marketing tracking, which are frequently outside their scope unless explicitly included in the project brief.
"It's a small site, this level of care isn't necessary." Smaller sites often have less analytics history to fall back on if something breaks, meaning a missed redirect or lost tracking code is actually harder to notice and diagnose quickly on a smaller site than on a larger one with more historical data to compare against.
Who should own this checklist on your project
Ideally, one person, whether that's your marketing lead, your developer, or your agency's project manager, is explicitly responsible for working through every item on this list and confirming it's done, rather than assuming it's someone else's job. On multi-vendor projects (a separate developer, designer and marketing team), this checklist is exactly the kind of task that falls through the cracks between teams unless one person owns it end to end.
