Before you launch or pay for traffic
New website launch checklist: check it live
This is the first time the site faces strangers, so the leftovers from building it matter most. Mimiq runs simulated visitors from a public address through the paths a new customer would use and shows where each one stops.
What should a new website launch checklist cover on the day it goes live?
Cover the leftovers from building the site, the addresses people already know, and the forms that send mail. Sites often carry preview settings into the live version, such as a tag that keeps search engines out or a form that still sends to a developer's inbox. Check each one on the live address, the way a new visitor reaches it. Mimiq runs a visitor from a public address through those paths and shows where each one stops.
What this looks like in a report
“The directory sent me to an error page. Is the bakery closed, or is this the wrong site? I will call the number in the listing instead. I wanted to order online, so this is a loss.”
The fix. Add a permanent redirect from the bare domain to the www version, then load both on a phone. Replace every menu and footer link to the preview address with the live address, and search the page source for noindex before launch.
An illustration. Run a test to see your own.See a real sample report
Build settings and old addresses break first
A site built on a preview address is set up for that address. Its links point to it, its forms send to a test inbox, and its search tags may still tell search engines to skip the page. Those settings travel with the files when the site goes live, and nobody notices, because the owner tests the pages they know. A new visitor reaches the site through an address the owner never tried, such as the bare domain without the www, or an old link from a directory, and they see whatever the preview left behind.
- Search tags: does the live page's source still say noindex, or block search engines?
- Addresses: do the bare domain and the www version both load, with one redirecting to the other?
- Forms: does a test submission reach the inbox the owner reads, not a developer's?
- Links: does any link in the menu or footer still point at the preview address?
- Confirmation email: does its link open the live domain, and does it land in the visitor's inbox?
Start with the tags the builder left behind
Check the live homepage before anything else. Open the page source in your browser and search it for noindex, and look for a robots file that blocks the whole site. A site copied from a preview can keep a line that tells search engines to skip every page. The owner can see it only in the source, so ask whether the site is indexed a few days after launch and treat a no as a warning. Also check the sitemap address, since an old sitemap can list preview links that no longer belong to the site.
Old addresses that visitors already have
A new site still gets visitors through addresses the owner never created. Directory listings, maps, old emails and social profiles point at the domain as it was entered, with or without the www, and some use plain http. Make each version reach the same live page with one permanent redirect, and check the final address in the browser bar on a phone. A visitor who hits an error on the first tap does not look at the other pages. They leave, or they call the number on the listing to ask whether the shop is open.
Forms and mail that reach the right inbox
Send a test message through every form on the live address, then read it in the inbox the owner uses. The recipient can still be set to a developer's address, a shared inbox nobody checks, or a placeholder. Confirmation emails have their own settings: the sender, the reply address and the link inside the message, which can still point at the preview. Look in the spam folder too. A booking request that lands in spam is a lost customer, and the owner would never know it was sent.
The first screen for someone who has never heard of you
A new visitor knows only what the link or listing said. The first screen has to name the business and the one thing they came for, such as the opening hours or the order form. Launch leftovers show up here first: a banner that still says coming soon, a slider of template photos, or placeholder text the builder never replaced. Check it on a phone at its normal size, not on the wide screen where the owner designed it. The hours and a contact method should be visible without a scroll, and a slider of photos with no words leaves the visitor guessing which business this is.
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 later redesign can bring a preview tag back onto the live site
Sites change after launch: a redesign, a new form, a move to another host, a renewed domain. Each change can copy a preview setting back into the live pages. Run the launch path again after each release that touches the page head, the forms or the domain, and compare the stops. Test any page behind a login with a test account, and check the confirmation email again whenever the sending address changes.
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 launch on the day the build is finished, or wait?
Launch when the paths pass on the live address, not on the preview. Whether to add more features later is a separate decision. This checklist asks only what a new visitor needs on the first day, and whether each path reaches the right page.
How do I check for preview settings without a developer?
Open the live homepage, choose view source in your browser, and search the text for noindex. If it is there, ask the builder to remove it, then check again on the live address. Searching for the site name after a few days shows whether search engines can reach it.
Does the test tell me whether search engines will index the site?
No. It shows what the page says to a visitor and what the source contains. It does not predict search results or when indexing happens, and it does not read your search console.
What can the test not tell me about launch day?
It does not check your domain provider's settings, hosting uptime or how the site handles many visitors at once. A load test is a separate job. It cannot pay with a real card or sign in with Google, and a CAPTCHA can stop it.
Can I run this before the domain moves?
Yes, on a preview or staging address. Then run it again on the live address after the switch, because the bare domain, the email links and the form recipients often change at that point.
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.