The Website Redesign Checklist: Relaunch Without Losing Rankings or Leads

Most redesigns do not fail on design. They fail in the handover: a redirect nobody wrote, a top page quietly deleted, a form that stopped reporting conversions the week the new site went live. The traffic drop gets blamed on the new look, but the cause is almost always migration discipline. This checklist runs in the order projects actually happen, from the first baseline export to the thirtieth day after launch. Work it in sequence and a relaunch becomes a controlled event, not a rescue operation.

Before You Design Anything

The most expensive redesign mistakes are locked in before a designer opens a file. Once layouts are approved and development starts, every structural change costs ten times what it cost on a whiteboard. They take an afternoon.

• Write the goals down in numbers: "More leads" is not a goal. Pick the two or three outcomes the redesign is actually for — qualified enquiries, online sales, calls from a service area — and attach the current baseline to each, so success gets judged later instead of debated.
• Export the analytics baseline: Pull the last 12 months of traffic, conversions, and top landing pages before anyone touches the site. Save the raw exports where the project team can reach them; after launch, this file is the only honest answer to "did the redesign work?"
• Inventory the pages that earn: List every URL with meaningful traffic, backlinks, or revenue. A crawl export plus Search Console data usually surfaces pages the team forgot existed. An old guide quietly sending 15% of organic leads is not a page you redesign blind.
• Snapshot rankings and speed: Record the keywords you rank for and the Core Web Vitals of your main templates. Post-launch comparisons need a "before" picture, and memory is not one.
• Agree a scope freeze date: New requests will arrive mid-build. Decide who can approve additions after the freeze and what they displace, or the launch date absorbs every good idea in the building.

If the budget conversation is still open, settle it at this stage too. Our website cost guide breaks down what actually drives the price, and scope is far cheaper to argue about now than during development.

The SEO Migration Plan

Search engines know your site as a set of URLs, not as a brand. Change the URLs without a mapping and, from Google's side, your proven pages vanish while unproven ones appear in their place. A migration plan is the document that stops it happening.

• Map every old URL to a new one: Build a spreadsheet with three columns: old URL, new URL, action (move, merge, retire). Every row needs a destination or a deliberate decision. Blank rows are where rankings go to die.
• Redirect one-to-one with 301s: Each changed URL gets a permanent redirect to the closest matching new page — not the homepage, not a vaguely related category. Homepage redirects read as soft 404s to Google, and the equity leaks away.
• Keep the URLs that still work: If a URL ranks and converts, changing it "for consistency" is a cost with no buyer. Redesign the page, keep the address, wherever the new structure allows.
• Clean up canonical and sitemap hygiene: On the new site, every page should self-canonical, the sitemap should list only live URLs returning a 200 status, and nothing listed should also be redirected or noindexed.
• Carry the metadata across: Export current titles and descriptions before the build and review them page by page. A migration that resets titles to a template pattern can cost more clicks than a ranking drop.

Test the redirect map on staging, not after launch. Crawl the old URL list against the staging site and confirm every row lands on a live page in one hop. Redirect chains mean the map was written from the new sitemap instead of from the old site's reality.

Content Decisions: Keep, Improve, Merge, Retire

A redesign audits your content library whether you plan it or not. The only choice is whether the decisions happen on purpose. Sort every existing page into four buckets, and record who made each call. "The developer dropped it" is not an acceptable answer for a page holding backlinks.

• Keep: Pages with traffic, links, or conversions move across as they are, design refresh only. These carry the site's equity. Protect them first.
• Improve: Pages stuck on page two, or converting poorly, get rewritten against current search intent. Budget spent here usually outperforms the same budget spent on brand-new pages.
• Merge: Two or three thin pages chasing the same topic become one strong page, with the retired URLs redirected into it. This is where most sites hide their cannibalization problem.
• Retire: Pages with no traffic, no links, and no business purpose get deleted on purpose — with a redirect to the nearest relevant page if they ever earned links, or a clean 410 if they never mattered.

Decide ownership before the sorting starts. In our builds, whoever owns the revenue number owns the retire list, and SEO holds a veto on anything with backlinks. Nobody deletes alone.

Design and Build Checks

Design sign-off is where redesigns feel finished. It is roughly the halfway point. These checks belong in the build contract, not in a hopeful email after development starts.

• Design mobile-first, approve mobile-first: Most local and B2B audiences arrive on phones, yet stakeholders approve desktop mockups. Review the phone layout first: tap targets, sticky contact options, and forms a thumb can complete.
• Set speed budgets per template: Agree numeric budgets — Largest Contentful Paint under 2.5 seconds on a mid-range phone, for example — and test against them during the build, not at the end. Our Core Web Vitals guide shows how each metric is measured and what usually breaks it.
• Cap the heavy assets: Hero videos, carousels, and unoptimized images are the usual suspects when a beautiful new site loads slower than the ugly old one. Every heavy element should have to argue for its place.
• Cover the accessibility basics: Colour contrast that survives sunlight, visible focus states, alt text on meaningful images, forms with real labels. Basics only — but basics skipped here become usability and legal problems later.
• Test with real content: Real headlines are longer than lorem ipsum. Test templates with the longest, ugliest genuine content you have, not the neatest.

Tracking and Forms

The cruelest redesign bug looks like a marketing problem: leads "dry up" in launch week because the new forms fire no conversion events. The enquiries were still arriving. Nobody could see them, so budgets got cut in a panic.

• Rebuild the tag plan on the new site: List every tag, event, and pixel the old site carries, and confirm each exists on the new build. Template changes break data layer naming more often than any other single cause.
• Verify events in debug mode: Submit every form yourself on staging and watch the events land in analytics and the ad platforms. "The tag is installed" is not evidence. A received test conversion is.
• Test forms like a hostile user: Wrong formats, missing fields, mobile keyboards, the thank-you redirect, the notification email to the sales inbox, the CRM entry. A form can appear to work on screen and still drop the lead after submission.
• Reconnect call tracking: If you use dynamic number swapping, the new site needs the tracking script reinstalled and the number pools re-pointed. Call volume falling to zero overnight is almost always this, not demand.
• Protect the thank-you pages: If conversions are measured on a confirmation URL, that URL must survive the migration with its path intact — or the measurement method changes before launch, not after.

None of this shows in a design presentation, yet all of it is where redesigns quietly succeed or fail. It is a standard phase in our web design and development process, not an optional extra.

Staging QA: The Final Sweep

Staging is where the new site can be crawled, clicked, and broken in private. A structured QA pass in the final week catches defects that otherwise announce themselves in Search Console three weeks after launch.

• Crawl the whole staging site: Run a full crawl and fix broken internal links, redirect chains, orphan pages, and duplicate titles before anyone discusses launch dates.
• Audit metadata page by page: Titles and descriptions get carried across or rewritten — never template-generated duplicates. Check social sharing tags on the pages most likely to be shared.
• Validate the schema: Structured data copied from the old site often points at old URLs or old business details. Re-validate your Organization, LocalBusiness, and service schema against the new pages.
• Check robots and the staging noindex: The classic. Staging sites are noindexed for good reason, and that setting has a habit of riding along into production. Confirm the live robots.txt allows crawling and no template-level noindex survives. Search engines cannot rank what they are told to ignore.
• Retest forms and the 404 page: Submit the forms once more on the final build, and make sure the 404 page helps a lost visitor instead of dead-ending them.

Launch Day and the First 30 Days

Launch day is a monitoring exercise, not a celebration. Assign one person to watch, one who can fix, and keep the old site's files and database untouched for a month. A rollback you never need is still cheaper than a rebuild you do.

1. Launch morning: Deploy in a low-traffic window. Immediately re-run the old-URL crawl against the live site: every legacy URL should take one 301 hop to a live page. Submit the new sitemap in Search Console and request indexing for the homepage and your top money pages.
2. Days 1–7: Check Search Console coverage and crawl errors daily. Watch the 404 report closely — every entry is either a missed redirect or an external link pointing at a page you moved. Fix them in hours, not at month-end.
3. Days 8–30: Compare rankings and organic conversions against the baseline snapshot weekly. Small dips on changed URLs are normal while Google re-crawls. A sustained drop on an unchanged section means something structural was missed — the baseline tells you where to look.

Keep a change log for the month. When a number moves, it tells you whether the cause was the redesign, a search update, or seasonality — three problems with three different fixes.

Website Redesign FAQs

How much traffic loss is normal after a redesign?

A small, temporary dip on changed URLs is normal while Google re-crawls and re-scores the new pages — days to a few weeks. A large or lasting drop is not a redesign tax; it is a symptom. In almost every post-mortem the cause is unglamorous: missing redirects, dropped pages, or tracking that broke and made healthy performance look bad.

Should we change URLs during a redesign?

Only when the current structure hurts you: meaningless parameters, duplicated sections, names that no longer match the business. Every changed URL spends some of the equity the old one earned, even with a perfect redirect. Keep the addresses that work, fix the ones that do not, and never change a URL just to make the sitemap look tidy.

When is the best time to launch a redesigned site?

In your quietest trading window, early in the week, with the fixing team available. Avoid peak season and Friday afternoons: a fault appearing at 4 p.m. on a Friday sits in front of your whole weekend audience. Early week in a slow period means problems surface while everyone is at their desk.

How long before rankings settle after a relaunch?

Expect four to eight weeks for a fair reading on most pages; longer for large sites. Judge it on the baseline comparison at day 30 and day 90, not the first anxious week. If a high-value page has not recovered by week six, audit that page directly — title, content changes, internal links, and redirect path — instead of waiting and hoping.