This is the pre-launch QA checklist we actually run at aimEncoders: a written test plan, functional and cross-browser passes, performance measurement, SEO and content review, security and accessibility basics, and a full re-test after fixes — with Playwright-based automated checks running alongside manual testing so regressions get caught before launch, not after a customer reports them.
Most websites do not fail on launch day because the design was bad. They fail because nobody checked the boring things: the form that never sends, the checkout button that breaks on one phone, the page that takes nine seconds to load on mobile data, the title tag that still says "Home."
A real QA process is not a quick scroll through the homepage five minutes before launch. It is a structured, repeatable pass over the whole site — every page, every form, every device you can reasonably test — with bugs logged, fixed, and re-tested before anyone outside the team sees it. This is the process aimEncoders runs before a website goes live, and it is the reason our launches are quiet instead of frantic.
If you are hiring an agency, or launching a site your own team built, use this article as your checklist. If a step below is missing from your launch plan, close that gap before you press publish.
1. Start with a launch checklist, not a gut feeling
QA without a checklist is just browsing. Before testing begins, we write down exactly what will be checked: every page URL, every form, every integration (contact forms, WhatsApp buttons, payment gateways, booking tools, maps), and every device and browser combination in scope.
That list becomes the test plan. Each item gets a pass or fail, and every failure gets a bug report with the page, the device, the browser, and steps to reproduce it. "The form is broken" is not a bug report. "On the contact page, using Chrome on Android, tapping Submit shows no confirmation and no email arrives" is — because a developer can actually fix it.
A checklist also protects you from the most common launch mistake: testing only the pages the team remembers. The forgotten pages — the thank-you page, the 404 page, the old blog post with a broken image — are exactly where embarrassing bugs hide.
2. Functional testing: does everything actually work?
Functional testing answers the simplest question: when a visitor clicks something, does the right thing happen?
We click every link and button, submit every form with valid and invalid data, and test every interactive element: menus, dropdowns, sliders, search boxes, filters, and carts. A form must do three things: validate bad input clearly, confirm success when it works, and actually deliver the message — to the right inbox, not just to a screen that says "Thank you."
We also test the unhappy paths: a form submitted with a missing field, a failed payment, a search with no results. Visitors will find these paths whether you test them or not, and a graceful error message beats a blank screen.
This is also where integrations get checked: does the contact form reach the right inbox, does the booking request land in the right calendar, does the payment gateway complete a real test transaction? A button that looks fine but connects to nothing silently loses customers.
3. Cross-browser and cross-device testing: the site your visitors actually see
Your website does not have one version. It has as many versions as there are combinations of devices, screen sizes, and browsers your visitors use — and the version you see on your own laptop is rarely the one most of them see.
We test on current Chrome, Safari, Firefox, and Edge, and on real phones and tablets, not just a resized desktop window. Mobile gets extra attention because for most small businesses, most traffic is mobile.
4. Performance testing: speed is part of quality
A slow website is a failed website, even if every feature works. Visitors leave, search rankings suffer, and ad money gets wasted on people who never wait for the page.
Before launch, we measure real load times on mobile and desktop, check image sizes, and look for the usual culprits: uncompressed images, oversized hero videos, too many third-party scripts, and render-blocking code. The goal is not a perfect score on a testing tool. It is a site that feels fast on an ordinary phone on an ordinary connection — because that is how your customers will experience it.
Performance testing also covers pages beyond the homepage. A fast homepage and a slow checkout still loses sales, so every key conversion page gets measured.
5. SEO and content checks: can Google — and humans — understand the site?
QA is not only about code. Before launch, we check that every page has a unique, descriptive title and meta description, that headings follow a logical order (one H1, then H2s and H3s), that images carry descriptive alt text, and that internal links point to live pages, not dead ends.
We also proofread. Twice. Typos, placeholder text ("Lorem ipsum" still live on a real page is more common than anyone admits), wrong phone numbers, outdated prices, and stock photos with watermarks all get caught here. Content errors damage trust faster than almost any technical bug, because every visitor can see them.
Finally, we check the technical SEO basics: a sitemap listing the real pages, a robots file that does not accidentally block the whole site, and pages returning proper status codes. Launching a site search engines cannot crawl is launching a site nobody will find.
6. Security and accessibility: the checks that protect everyone
Security testing before launch is mostly about the basics done properly: the site loads over HTTPS with no mixed-content warnings, forms are protected against spam and abuse, admin areas are not left on default credentials, and software and plugins are up to date. Nobody expects a small business website to be Fort Knox, but the basics stop the vast majority of automated attacks — and a hacked site days after launch is a nightmare no founder needs.
7. The final pass: re-test everything you fixed
Here is the step most teams skip, and the one that matters most. After bugs are fixed, we re-test every fix — and we run the full checklist once more over the pages that changed. A fix for one bug regularly creates another: a layout repair on mobile breaks the desktop view, a form fix changes the confirmation message, a speed fix removes a script something else depended on.
This is why QA-tested website development is a process, not a single afternoon. At aimEncoders, no site ships until its checklist is green end to end, including the re-test. Our Playwright-based automated checks run alongside manual testing so that regressions — bugs that come back after being fixed — get caught before launch, not after a customer reports them.
A launch day with no surprises is not luck. It is what a checklist, a full test pass, and a disciplined re-test produce.
Frequently asked questions
How long should website QA take? For a typical small-business website, plan at least a full day of structured testing plus time to fix and re-test. Rushing QA to hit an arbitrary launch date is how launch-day bugs happen.
Is automated testing enough? No. Automated tests catch regressions well, but they cannot judge whether a page looks right or feels usable. Real QA combines automated checks with a human using the site like a visitor would.
What should I ask my agency about QA before launch? Ask three questions: Do you have a written pre-launch checklist? Will you test on real phones, not just a desktop browser? And will you re-test after fixes before launch? If the answer to any of them is vague, keep asking.
Can I do a basic QA pass myself? Yes. Walk through your site on your phone, submit every form, click every link, and read every page out loud. You will be surprised what you catch. But a self-check supplements professional QA, not replaces it — you already know what the site is supposed to do, so you will miss what a first-time visitor trips over.
Conclusion
A website launch is not the end of a project. It is the moment your business starts being judged by strangers, and first impressions do not get a second run. A real QA process — a written checklist, functional testing, cross-device testing, performance checks, SEO and content review, security and accessibility basics, and a disciplined re-test — is what stands between a smooth launch and a week of apologetic fixes.
If your current site went live without that process, run the checklist now and fix what it finds. If you are planning a new website, make QA a line item in the plan, not an afterthought in the last afternoon.
About the author: Muhammad Asad Ullah is the founder of aimEncoders, a web development agency building custom websites, web applications, and QA-tested digital products for small businesses. The aimEncoders team tests every website like it is going to break on launch day — so it does not.
Top comments (1)
The retest step is the important one: a checklist is only evidence if a fix re-enters the affected paths. A practical addition would be to link every reported defect to the checklist cases it invalidates, then require those cases to be rerun before the defect closes. That creates a small trace from symptom to fix to verification, especially for mobile and integration failures that are easy to declare done too early.