Before You Redesign Your Website, Check These 7 Things First

"We're redesigning the website" is one of the most dangerous sentences in a business, said with total confidence and almost no data behind it.

I've been brought in more than once to fix a brand-new redesign that quietly tanked organic traffic, broke a checkout flow, or lost a form integration nobody remembered existed. Every one of those was avoidable. Here's the checklist I run before touching anything.

1. Pull your actual analytics first

Before anyone opens a design tool, look at what the current site is actually doing. Which pages get the traffic. Which pages convert. Which pages rank for keywords you didn't even target on purpose. A redesign based on "I think this page matters" instead of "this page drives 40% of our leads" is a redesign that can accidentally delete your best-performing content.

2. Map every URL that has SEO equity

Google doesn't care how nice your new site looks. It cares whether the pages it already trusts still exist, or redirect properly to something equivalent. Before redesign, export a full URL list from your sitemap and analytics. After redesign, every one of those URLs needs a plan: same URL, or a 301 redirect to its real replacement. "We'll deal with redirects later" is how sites lose rankings that took years to earn.

3. Audit your integrations, not just your pages

Contact forms wired to a CRM. A booking widget. A payment processor. A tracking pixel. A webhook feeding an email tool. None of that shows up in a visual mockup, and all of it breaks silently if the new build doesn't account for it. I keep a literal list of every third-party connection before starting a rebuild, because "it just stopped working" two weeks after launch is a bad way to find one.

4. Decide what "done" actually means, in writing

Redesigns balloon in scope because nobody agreed on the finish line. Is this a visual refresh, or a full re-platform? Are you keeping the CMS? Is content being rewritten or just re-skinned? Put it in writing before development starts, because verbal scope creeps for free and budgets don't.

5. Check your Core Web Vitals baseline

Run your current site through PageSpeed Insights and note the numbers. Not because the old design is sacred, but because "the new site is prettier but slower" is a real, common outcome of redesigns that prioritize visuals over performance. You want to know if you're improving or regressing, and you can't know that without a before number.

6. Plan the content migration like its own project

Don't assume old content just "comes along." Blog posts, case studies, testimonials, downloadable resources, they all need an explicit migration plan: what moves as-is, what gets rewritten, what gets retired (with a redirect). This is usually where redesign timelines quietly double.

7. Have a rollback plan for launch day

Stage the new site fully, test the real forms and real payment flows with real (small) transactions if it's e-commerce, and know exactly how you'd revert if something critical breaks post-launch. A DNS change is fast to make and fast to undo, if you've actually planned for undoing it.

None of this is exciting. It's also the difference between a redesign that grows the business and one that spends the next three months quietly clawing back what launch day broke. Do the boring checklist first. The design work is the easy part.