What to Test Before You Launch a Website or Web App

Launch day is fun. The site looks great on your screen, every button you click does what it should, and you're ready to tell the world.

Then a real person shows up and does something you never tried.

I learned that one the hard way. I built an inbox for Ideal Homeschool, and it had a pretty painful gap. A session timed out and a long draft disappeared. Somebody sat there writing a thoughtful message, stepped away or took a little too long, and when they hit send, it was gone.

We fixed it. Drafts, autosaves and session memory all went in after that showed up. But the bigger lesson stuck with me, and it's now on my checklist for every build: test what happens when somebody gets interrupted or loses a session. There's a lot more to the experience than the path where everything goes right.

So here's what I test before I launch a website or web app. Some of it is the obvious stuff. Some of it is the stuff that only bites you after real people start using it.

Start with the "happy path," then break it on purpose

The happy path is the version of the visit you had in mind when you built it. Someone lands on the homepage, reads, clicks the main button, fills out the form, gets a thank-you message. Test that first. If the happy path doesn't work, nothing else matters.

Then try to break it. Not with hacker tricks. With normal human behavior:

Click the submit button twice.
Hit the back button in the middle of a form.
Leave a required field empty, or type a phone number with dashes, spaces and parentheses.
Paste a long block of text into a box that was designed for one line.
Open the same page in two tabs and do something different in each.
Refresh the page right after submitting.

Every one of those is something a real visitor will do in the first week. Your job is to find out what happens before they do.

Test interruptions, timeouts and lost sessions

This is the one most checklists skip, and it's the one that cost me.

People don't use your site in one clean sitting. They get a phone call. The kids need something. The laptop goes to sleep. The Wi-Fi drops in the car line. They come back 40 minutes later and expect to pick up where they left off.

Here's what I check now:

Leave a long form half-filled and walk away. Come back after your login session would normally expire. Is the work still there? If they get logged out, do they lose everything?
Close the tab by accident. Does the browser warn them before they lose unsaved work? Browsers support a "leave site?" warning through the beforeunload event, and it's worth using on pages where people type a lot.
Lose the connection mid-submit. Turn off Wi-Fi, hit send, turn it back on. Does the message go through, fail with a clear error, or silently vanish?
Log in on a second device. Does anything get overwritten?

The fix is usually some mix of autosaved drafts, a session that lasts long enough for real life, and an error message that tells people what happened instead of a blank screen. None of that is fancy. It just has to be on the list.

Test every form like a customer would

Forms are where websites make money or lose it. A contact form, a quote request, a checkout, a signup. If it breaks, you may never know, because the person who hit the problem just leaves.

Before launch, I fill out every form myself and then confirm:

The message actually arrives where it's supposed to, and not in a spam folder.
The person who submitted it sees a clear confirmation.
Any auto-reply email goes out and reads right.
Required fields are really required, and optional ones really are optional.
Error messages say what's wrong in plain English, right next to the field.

Then I do it again from my phone. You'd be surprised how often a form works on a desktop and fails on mobile because of one hidden field or a keyboard covering the button.

Test on real phones, not just a resized browser

Shrinking your browser window is a good start. It isn't the same as using a phone.

Grab whatever phones you can find, yours, your spouse's, an old one in a drawer, and use the site with your thumb. Can you tap every button without zooming? Does the menu open and close? Does the text fit without scrolling sideways? Do pop-ups have a close button you can actually reach?

For a lot of small businesses, most visitors are on a phone. That makes the phone version the real website. The desktop version is the backup.

Test speed with real tools

A slow site loses people before they read a word. I wrote a whole post on how to speed up a small business website, so I'll keep this short.

Run your main pages through PageSpeed Insights. Google's Core Web Vitals give you three targets to aim for. Largest Contentful Paint should happen within 2.5 seconds. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should be 0.1 or less.

Don't chase a perfect score. Look for the big problems. Huge images, a pile of scripts nobody needs, and a page that jumps around while it loads are the usual suspects.

Test that Google can actually find it

This one gets people all the time. While a site is being built, it's common to hide it from search engines so the half-finished version doesn't show up in Google. Then the site launches, and nobody removes the setting.

Before launch, check for a leftover "noindex" setting on your pages and anything in your robots.txt file that blocks the whole site. Google's noindex documentation points out something that trips people up: for a noindex rule to work, the page can't be blocked by robots.txt, because if the crawler can't get to the page, it never sees the rule. Mixing the two up can leave you with pages stuck in a state you didn't intend.

While you're there, give each important page a real title and a real description. If you need help with that, here's how to write a meta description that gets clicks. And if you want the bigger picture of being found in Google and in AI answers, read how to get your business found in AI search.

Test the basics of accessibility

Accessibility sounds like a big technical topic, and parts of it are. But a first pass is something anyone can do. The W3C has a page called Easy Checks that walks through quick checks like page titles, image text alternatives, headings, contrast and keyboard access.

My quick version:

Put the mouse away and try to use the site with only the Tab and Enter keys. Can you get to everything? Can you see where you are?
Make sure images that matter have alt text that describes them.
Check that light gray text on a white background is actually readable.
Zoom the browser to 200 percent and see if the page still works.

This makes the site better for everybody, not just people using assistive tools.

Test the security basics

You don't need to be a security expert to catch the obvious stuff. Before launch:

Make sure every page loads over https, with no warning in the browser.
Remove test accounts, sample content and any "admin/admin" style logins.
Make sure only the right people have admin access, and that each one uses two-factor sign-in where it's offered.
Confirm that someone who is logged out can't reach pages that should require a login, just by typing the address.
Turn off detailed error messages that show code or file paths to visitors.

If you're building something with logins, payments or personal data, have whoever built it walk you through how they handled the common risks. The OWASP Top 10 is the standard list developers use for that conversation, and it's a good sign if your builder knows it.

Test the boring links and pages

Click every link in the menu and the footer. Every one. Broken links and empty pages make a new site feel unfinished fast.

Check that your contact info is right everywhere it appears, your phone number is tappable on mobile, your address matches your Google listing, and your legal pages (privacy policy, terms) are there if you need them. If you're not sure which pages a small business site should have at launch, I covered that in what pages a small business website should have.

Also check the 404 page. Type a nonsense address on your own domain and see what shows up. A helpful 404 page with a link back home beats a blank error screen.

Have someone else test it

You know where everything is. That makes you the worst person to test your own site.

Hand it to a friend, a customer, or a family member who has never seen it. Give them one task, like "find out how to book a call" or "send us a message about pricing," and then be quiet and watch. Don't help. Wherever they hesitate, that's something to fix.

If you're building a web app, try to get a few real users in before the big announcement. A small soft launch catches the things nobody on your team thought to try. That's exactly where problems like my disappearing draft show up.

Make a short launch-day plan

Testing doesn't stop when you flip the switch. On launch day:

Submit every form one more time on the live site.
Check that your analytics and Search Console are set up and receiving data.
Keep a quick list of anything people report in the first few days.
Know how to roll back or fix something fast if a key page breaks.

And don't let the testing list become an excuse to never launch. I've written before about having a pile of half-built projects that never launched. Testing is about launching with confidence, not stalling forever. Fix what would really hurt a visitor, write down the rest, and ship it.

Final thoughts

Most launch problems aren't hard to fix. They're just hard to see from the builder's chair. The happy path will almost always work, because it's the one you clicked through a hundred times while building.

The real test is the messy stuff. The interrupted session. The double click. The phone with the giant keyboard covering the button. The setting left over from development that hides your site from Google.

Put those on your list and you'll catch most of the problems before your customers do. If you'd like a second set of eyes on a site or app before it goes live, that's part of what I do with Built by Knup. And if you're still picking who will build it, start with how to choose a web designer for your small business.

FAQ

What should I test before launching a website?

Test the main path a visitor takes, every form, mobile layout on real phones, page speed, search settings like noindex and robots.txt, basic accessibility, security basics like https and admin access, every link, and the 404 page. Then have someone who has never seen the site try a simple task while you watch.

How long should website testing take before launch?

It depends on the size of the site. A small business site with a handful of pages and one contact form can usually get a solid pass in an afternoon. A web app with logins, saved data or payments needs more time, and a short soft launch with a few real users is worth it.

What is the most commonly missed thing in website testing?

In my experience, it's anything outside the happy path. Interrupted sessions, timeouts, double clicks, the back button and lost connections. Close behind that is a leftover setting from development that blocks search engines.

Why isn't my new website showing up on Google?

New sites can take time to be crawled and indexed. Also check for a leftover noindex tag or a robots.txt rule blocking the site. Google says that for a noindex rule to be seen, the page can't be blocked by robots.txt, so check both. Verifying the site in Google Search Console will show you what Google sees.

Do I need a professional to test my website?

Not for a first pass. You can do most of this list yourself. For web apps with logins, payments or personal data, it's worth having your developer walk you through how they tested security and edge cases.