Website testing before launch: a practical checklist

Why testing before launch matters so much

Mistakes after launch cost more than mistakes before it. A form that never arrives costs you enquiries without you noticing. A payment step that gets stuck costs orders. And a disappointing first impression makes visitors wary.

With software that has logins or sensitive data, there is an extra risk: a mistake in permissions can mean one customer sees another customer's data. That is really not something you want to discover after going live.

Work with a test environment

A test environment, often called staging, is a copy of your site or application at a separate address, just for you and your developer. You can try everything there without customers noticing. Keep in mind:

• Make sure Google does not index the test environment.
• Use test data, not real customer data. That also helps with GDPR (AVG in Dutch).
• Use your payment provider's test mode, so no real money is charged.
• Keep the test environment as close to the live environment as possible, with the same settings and integrations.

Making a test plan for your website

A test plan sounds like a big thing, but it is simply a list of what you want to check. Write it as scenarios from the user's point of view. For example:

• A new visitor finds the right service via the homepage and requests a quote.
• A customer creates an account, logs out and logs back in.
• A customer orders three products, changes the quantities and pays.
• A staff member changes some text in the CMS and sees the result on the site.
• Someone fills in a form incorrectly and gets a clear error message.

For each scenario, note what should happen and what actually happened. That way you quickly see what is not right yet, and you can test it again after the fix.

Checklist: website testing before launch

Features and content:

• All pages are there, with no placeholder text or empty spots.
• All links work, including in the menu and footer.
• Forms arrive at the right address, and the visitor gets a confirmation.
• Payments, orders and bookings go all the way through, including confirmation emails.
• Logging in, logging out and forgotten password all work.
• Users only see what they are allowed to see.

Devices and speed:

• The site works on phone, tablet and desktop, in the common browsers.
• Buttons are big enough to hit with a thumb.
• Pages load fast. Google uses the Core Web Vitals: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. Read more in Core Web Vitals explained.
• Images are not unnecessarily large.

Visibility, privacy and accessibility:

• Every page has its own title and description.
• Old URLs redirect to new pages. The SEO checklist for launch is handy for this.
• The site is no longer blocked for search engines, as it was during testing.
• There is a privacy statement, and the cookie banner works as intended.
• The site can be used with a keyboard and has enough contrast. Since 28 June 2025, the European Accessibility Act applies to certain digital services.
• Analytics tracks visits and conversions.

Usability testing and acceptance testing

You and your developer know the site too well. That means you no longer see where a new visitor gets stuck. So let two or three people who do not know the site use it. Give them a task, such as booking an appointment, and watch without helping. Where they hesitate, there is often something to improve.

Then comes the acceptance test. That is the moment you check whether the site does what was agreed and sign it off. You can read how to record that properly in agreements with your web agency.

Software testing: extra points to watch

A web application, customer portal or booking system involves more than an ordinary website:

• Permissions and roles: test with every type of user, such as admin, staff member and customer.
• Edge cases: what happens with empty input, a very long name, or two people booking the same thing at once?
• Integrations: does data arrive correctly in your accounting, CRM or email software? And what happens if that integration is briefly down?
• Data migration: has existing data been moved over completely and correctly?
• Automated tests: good developers write tests that run again with every change, so old bugs do not come back.
• Recovery: is there a backup, and do you know how to roll back if things go wrong? Read backups and recovery.

Common mistakes at launch

• Going live on a Friday afternoon, just before the weekend.
• Forgetting to remove the block on search engines.
• Leaving payments in test mode.
• No redirects from old pages, so visitors land on an error page.
• Not testing on a real phone, only in a shrunken browser window.

So plan the launch for a quiet moment, early in the week, and make sure your developer is available that day. Right after launch, run through the main scenarios once more on the live site, because the live environment sometimes behaves slightly differently from the test environment.

How Violexa tests before launch

At Violexa we test every custom web application and website in a separate test environment before it goes live, and we walk through the main scenarios together with you. A custom project starts from €1,799 excl. VAT (€2,177 incl. VAT). After launch, updates, backups and monitoring can be covered by a maintenance plan from €179 excl. VAT (€217 incl. VAT) per month.

Is your launch coming up and do you want to be sure you have not forgotten anything? Book a free quickscan. In 30 minutes, online or on site, we look at your project together. Afterwards you get short written advice with a price estimate, with no obligation.

Frequently asked questions