Redesign planning board mapping existing URLs to their replacements

Web Design•August 31, 2026•8 min read

Website Redesign Checklist: What to Do Before You Rebuild

The pre-launch checklist that keeps a redesign from losing rankings and conversions — baselines, URL inventory, redirects, and what to verify after launch.

Space Agency

Nearshore web design, development and SEO studio serving US businesses. Senior engineers working US hours, delivering measurable results.

#Website Redesign#SEO#Migration#Checklist

Key Takeaways

✓Capture traffic, ranking, and conversion baselines before any design work starts — without them the redesign cannot be evaluated.
✓Inventory every URL from a crawl, Search Console, and the sitemap; forgotten pages are what gets lost.
✓Keep URLs unless there is a real reason to change them, and map every change before launch.
✓Avoid 301-ing pages into a generic destination — Google can read it as a soft 404 that half-ranks for weeks.
✓Expect a short post-launch dip; a dip that has not recovered by week six is a problem, not patience.

Most redesigns that go wrong do not fail on design. They fail because nobody wrote down what the old site was doing before it was replaced — so nobody noticed what stopped working. This checklist is organised around that risk.

Before anything is designed

Capture the baselines

Capture a traffic and ranking baseline. Export at least the last 12 months from Search Console: queries, landing pages, impressions, clicks, and average position. Without this you cannot tell afterwards whether a drop was the redesign or the season.
Capture a conversion baseline. Inquiries or sales per month, by landing page. This is the number the redesign is actually accountable for.

Build the inventory

Inventory every existing URL. Not the pages you remember — a crawl plus the Search Console page list plus the sitemap, deduplicated. Old campaign pages and orphaned posts are exactly what gets lost.
Identify your top pages by traffic and by conversion. These two lists are rarely the same, and both constrain the redesign.
Record what currently ranks and for what. A page ranking in the top ten is an asset; changing its URL, title, or main content is a decision with a cost, not a detail.

During design and build

Keep URLs unless there is a reason to change them. "The new CMS does it differently" is not a reason. Every changed URL spends equity on a redirect.
Map every old URL to its replacement in a spreadsheet, before launch, with a decision for each: keep, 301, or retire. Anything without an equivalent destination should be a considered retirement rather than a redirect into a generic page — a 301 that Google reads as non-equivalent behaves like a soft 404 and keeps half-ranking for weeks.
Preserve the content that earns the rankings. A page that ranks because it answers a question thoroughly will stop ranking if the redesign cuts it to three sentences for visual balance.
Carry over titles and meta descriptions deliberately, improving them where there is a reason — not regenerating them from a template.
Keep the conversion paths that work. If a particular form or CTA placement produces most inquiries, that is evidence, not legacy.
Plan analytics before launch, so the new site starts measuring on day one rather than a month later.

Pre-launch verification

Every redirect tested, including trailing-slash and case variants
No redirect chains — old URL to final destination in one hop
Canonical tags pointing at the live URL, not a staging or legacy path
Staging blocked from indexing, and that block removed at launch
XML sitemap regenerated and free of retired URLs
robots.txt reviewed
Core Web Vitals measured on the new build, not assumed
Forms tested end to end, including the notification actually arriving
Structured data validated

The first 30 days after launch

Submit the new sitemap and watch coverage reports for spikes in errors
Check server logs or Search Console for 404s and fix the ones with inbound links
Compare rankings against your baseline weekly, not daily — short-term volatility after a migration is normal
Compare conversions against baseline, separately from traffic
Expect a dip of a few weeks; treat a dip that has not recovered by week six as a problem to diagnose

The one that matters most

If you only do one thing on this list, do the baseline. A redesign without a before-picture cannot be evaluated, which means nobody can tell whether it worked — and any problem it introduced will be discovered months later, by accident.

Preserving rankings through a rebuild is a specific discipline rather than a side effect of good design. It is the core of how we approach website redesign services, and it is worth reading alongside what a redesign actually costs.

Frequently Asked Questions

How long does a website redesign take?

For most business sites, four to eight weeks from kickoff to launch. The migration planning — URL inventory, redirect mapping, and baseline capture — runs in parallel with design rather than after it.

Will a redesign hurt my SEO?

It can, and most of the damage is avoidable. Losses come from changed URLs without redirects, removed content that was earning rankings, and regenerated titles. A redesign that preserves those deliberately usually holds its rankings.

Should I change my URLs during a redesign?

Only where there is a reason beyond the new system's defaults. Every changed URL costs some equity through the redirect, so the burden of proof sits with changing it.

How long after launch should rankings recover?

A dip of two to four weeks is normal as Google recrawls and reprocesses. If rankings have not substantially recovered by week six, treat it as a migration problem to diagnose rather than something to wait out.

What is the most commonly skipped step?

The baseline. Teams launch without exporting the previous site's traffic, rankings, and conversions, and then have no way to tell whether the redesign helped or hurt.