Before you launch or pay for traffic
Website redesign checklist: what breaks signups
You are changing a site that brings in sign-ups and sales, and one change could break a path that works. This shows what a stranger meets first on the new version, and how to run it before you switch.
What should I check on a live site before I launch a redesign?
Check the path a stranger takes on the new version, in the order they meet it: old addresses, the first screen, pricing, sign-up and the confirmation email. Compare each step with the old site, since a redesign changes them all at once. A simulated test runs that path on a preview and shows where visitors stop and what they read.
What this looks like in a report
“I saved this page to sign up for the plan. The menu has no pricing now, so maybe they stopped selling it. I will just go.”
The fix. Redirect the old pricing address to the new plans page, and put the pricing link back in the top menu under its old name. Then load the old address and confirm it lands on the plan table.
An illustration. Run a test to see your own.See a real sample report
A redesign changes the paths that already worked
A redesign changes addresses, navigation, copy and forms in one release. A visitor who knew the old site meets each change where their habit stops working. An old bookmark or search result points at an address that no longer exists, so they land on an error page. A pricing link that sat in the top menu may now hide behind a mobile menu. A rebuilt sign-up form may add a field the old one never asked for. Testing the pages you built misses the path an old visitor takes.
- Every address that still gets traffic loads its new page, or redirects to one.
- The first screen repeats the promise of the ad or link that sent the visitor.
- Pricing is one click from the homepage, under the label your visitors already use.
- The sign-up form asks for no new fields, and an empty submit names the field it needs.
- The confirmation email links to the live domain, not the preview or staging address.
Old addresses come first
Visitors reach your site through addresses the design work does not know about. Old ads, emails and bookmarks keep pointing at the old paths. Start from the landing pages report in your analytics for the months before launch. Keep every address that brought people in, and send each one to the same page or a permanent redirect. Then load each old address on the preview and check that it lands on the right page, not an error.
The first screen has to match the reason they came
The headline on a redesign is often written for the brand, not for the ad or search that sent the visitor. If the ad promised invoicing for small firms and the new hero says 'Get paid, simply', the visitor has to work out whether they are in the right place. Put the old ad text next to the new first screen. Check whether the product noun and the main promise appear without scrolling. A visitor who sees a slogan instead of the product name is guessing.
The menu and the sign-up form
Navigation is the quiet break. A label such as Pricing becomes Plans, or moves into a menu that only opens on a phone, and the visitor who came for the price has to hunt. Walk the old path on the preview and count the clicks from the homepage to the price. Compare that count with the live site. One extra click on a phone can be enough to lose them.
A rebuilt sign-up form can add a required field, change which fields show for a plan, or drop the hidden field your signup tool needs. Submit it with a blank field and then with a valid one, and read each message. A message that names the field tells the visitor what to fix. 'Something went wrong' sends them away. Each simulated visitor has a working inbox, so the test can follow the confirmation link.
Use the funnel to find the broken step
The owner can see one thing the test cannot: the numbers before and after the switch, step by step. Open the same funnel for the month before launch and the month after, with homepage visits, pricing visits, sign-up visits and completed sign-ups. Find the first step where the count falls. A drop at the homepage points at addresses or the first screen. A drop before the sign-up page points at navigation. A drop after it points at the form.
Ways to check a redesign before the switch
| Method | Finds | Misses |
|---|---|---|
| Analytics before and after launch | The step where the numbers fell | Why the visitor left at that step |
| Clicking the old path yourself | Addresses you already know are broken | How a stranger reads a new headline |
| Simulated visitors on a preview | Where a visitor stops, and what they read | How many real people convert |
| Recruited user test | Why a person hesitates, in their own words | How often each break happens to real visitors |
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A menu or sign-up change can break the old path again
A redesign is a series of small fixes, and each one can break the step before it. Rerun the same visitors after every fix, on each preview: the old-address visitor and the sign-up visitor. Protected previews and sign-in pages need a test account, which comes with paid credits.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Should I keep the old addresses after a redesign?
Yes, for every address that still brings visitors. Keep the same page where you can, and use a permanent redirect where it moved. Old ads and bookmarks never change, so a removed address stays broken for everyone who clicks it.
How do I test a redesign before it goes live?
Put the new site on a preview address, then run the paths your visitors use: the old pricing address, the homepage, the sign-up form and the confirmation email. A simulated test shows where each visitor stops. It does not predict how many real people convert, so keep your analytics for rates.
Can the test go through checkout and the payment step?
It goes up to the payment step and stops there. Visitors cannot pay with a real card, so the test shows whether the payment page loads and what it asks for. Place a real test order in your payment provider's test mode to check the charge.
How do I find which change caused a drop in sales?
The test cannot tell you that from the numbers. Compare the same funnel before and after the switch, step by step, and find the first step where the numbers fall. Then run a simulated visitor through that step on the preview.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.