>_ Website Launch QA Checklist

Short answer

A Website Launch QA Checklist is a list of checks that a team goes through before launching a website, landing page, SaaS product, e-commerce page, or web app. It helps make sure that key pages open correctly, forms work, links point to the right places, the mobile version is stable, analytics collects data, basic SEO settings are in place, and users can interact with the website after launch.

This checklist is especially useful before the first public launch of a website, a new landing page, a redesign, a domain migration, a marketing page launch, or opening a product to its first users.

A website launch checklist does not replace full testing, a security audit, legal review, or an SEO audit. It helps the team check the most important areas before launch and reduce the risk of obvious but costly mistakes.

Quick website launch QA checklist

Use this quick checklist before launching a website:

• check all important pages;
• verify navigation, links, and CTAs;
• review content, pricing, screenshots, and legal text;
• test forms end-to-end;
• check mobile layout and key browsers;
• verify signup and login, checkout, or payments if applicable;
• check SEO basics: title, description, canonical, robots.txt, and sitemap;
• verify analytics and conversion events;
• check performance and critical loading issues;
• run a production and post-launch check.

Track this checklist in qa::checklist

You can use this guide as a manual website launch checklist, or track it in qa::checklist as a QA project. Split checks by page, module, or launch area, mark each item as pass, fail, or pending, add comments, and export the final result to CSV.

When to use a Website Launch QA Checklist

Use this checklist before launching a website or an important web page if it will be available to users, customers, search engines, or paid traffic.

For example:

• a new website is launching;
• a landing page for a product, feature, or campaign is launching;
• the website is moving to a new domain;
• the CMS, frontend, or design has changed;
• the homepage has been updated;
• a new pricing page is launching;
• signup, login, or onboarding flow is launching;
• lead capture forms have been added;
• an e-commerce checkout is launching;
• the website starts accepting payments;
• analytics, ads, or SEO activity is starting;
• the website is opening after a closed beta.

For a small landing page, you can use a shorter version of the checklist. For SaaS products, e-commerce websites, or websites with many pages, it is better to use it as a base for full pre-launch QA.

Full Website Launch QA Checklist

1. Pre-launch preparation

Before starting final QA for a website, it is important to understand what exactly is being launched and what state the project is in.

Check that:

• it is clear which pages are included in the launch;
• there is a list of final URLs;
• it is clear which pages should be public;
• it is clear which pages should be private, hidden, or marked as noindex;
• there is a staging or preview environment;
• the latest changes have been deployed;
• staging matches the future production environment as closely as possible;
• you have access to the admin panel, CMS, test accounts, and test data;
• there is a list of supported browsers and devices;
• it is clear who makes the final launch decision;
• critical scenarios that must not break are known.

If the launch scope is not clear, QA can easily turn into a random review of pages. It is better to define in advance which pages, forms, scenarios, and integrations are required for launch testing.

2. Core pages check

Start with the most important pages of the website. These are the pages users will see first or the pages that will receive the most traffic.

For example:

• homepage;
• landing page;
• pricing page;
• product page;
• signup page;
• login page;
• checkout page;
• contact page;
• blog or guides page;
• help or documentation page;
• privacy policy and terms pages.

Check that:

• the page opens without errors;
• the correct content is loaded;
• there are no empty or unfinished sections;
• there is no placeholder text like "Lorem ipsum";
• there are no temporary images;
• there is no broken layout;
• CTA buttons are visible and work correctly;
• the user understands what to do next;
• the page does not look like a draft;
• the page URL is correct;
• the page is available without unnecessary login if it should be public.

The main question for this part is: can a new user open the website and understand what the product is, what they can do, and where to click next?

3. Navigation and links check

Before launching a website, make sure users can move between pages without friction.

Check that:

• all main menu items open the correct pages;
• footer links work;
• CTA buttons lead to the correct destination;
• links inside the text work;
• links to pricing, signup, login, contact, and docs are correct;
• external links open correctly;
• email links and phone links work, if they are used;
• anchor links lead to the correct section on the page;
• breadcrumbs work, if they are used;
• the logo links to the homepage;
• there are no links to staging, localhost, test domains, or old URLs;
• important pages do not return 404 errors.

Also check the scenario where a user does not arrive from the homepage. For example, if someone lands directly on the pricing page or an article page, they should still understand how to get to the product, registration, or other important sections.

4. Content and copy check

During a website launch, a bug is not always a broken button. It can also be incorrect copy, an outdated price, an unavailable feature, or a confusing message.

Check that:

• headings match the meaning of the page;
• copy does not look like a draft;
• there are no typos in key areas;
• there are no internal team comments;
• there is no placeholder text;
• product, feature, and plan names are written consistently;
• prices and plan limits are up to date;
• button text is clear;
• error messages are written in human language;
• email addresses, physical addresses, phone numbers, and social links are correct;
• screenshots and images match the current interface;
• the website does not promise something the product does not actually do;
• dates, versions, or statuses are up to date if they are shown.

Pay special attention to pricing, comparison sections, FAQ, legal pages, and any section where the user makes a decision: sign up, buy, submit a request, or contact the team.

5. UI and responsive layout check

The website should not only open. It should also look stable across different screen sizes.

Check that:

• sections do not overlap;
• text is not cut off;
• images do not stretch or break the layout;
• buttons and fields look consistent in similar areas;
• spacing looks clean;
• long headings do not break cards;
• long plan, feature, or category names are displayed correctly;
• modals open and close correctly;
• dropdowns, tabs, accordions, and sliders work;
• sticky headers or sticky CTAs do not cover important content;
• loading states look correct;
• empty states are clear;
• error states do not look like broken pages.

Before launch, it is important to test not only the ideal version of a page, but also real states: long text, empty lists, form submission errors, slow loading, and missing images.

6. Mobile version check

The mobile version is often one of the highest-risk areas before launch. Users may open the website from a phone even if the team mostly tested it on desktop.

Check that:

• main pages open on a mobile screen;
• content does not go outside the screen;
• there is no unexpected horizontal scrolling;
• the menu opens and closes;
• buttons are easy to tap;
• forms are easy to fill out;
• fields are not too small;
• the CTA button is visible in the right places;
• modals fit on the screen;
• tables, cards, and lists are readable;
• sticky elements do not cover a form or button;
• images and videos adapt to the screen;
• the main user flow can be completed on a phone.

If the website will receive traffic from ads, social media, or email campaigns, mobile testing is especially important. A large share of users may arrive from a phone.

7. Browser and device check

Even if the website looks good in one browser, that does not mean it will work the same way in others.

Check that:

• the website works in the main supported browsers;
• there are no critical differences between Chrome, Safari, Firefox, and Edge;
• the mobile version works in mobile Safari;
• the mobile version works in mobile Chrome;
• forms can be submitted in different browsers;
• interactive elements work in different browsers;
• fonts load correctly;
• images and icons are displayed correctly;
• there are no browser-specific layout bugs;
• there are no critical console errors.

You do not always need to check every pixel in every browser. But before launch, it is important to make sure that key pages and main user scenarios work in the main browsers and on mobile devices.

8. Basic accessibility check

A full accessibility audit is a separate task. But before launching a website, it is worth checking the basics that affect real users.

Check that:

• users can navigate the website with a keyboard;
• focus state is visible on interactive elements;
• buttons and links have clear names;
• forms have labels;
• form errors are clear and connected to the correct fields;
• important images have alt text;
• decorative images do not interfere with screen readers;
• headings follow a logical structure;
• text is readable;
• color is not the only way to communicate important information;
• modals can be closed with the keyboard;
• the page remains usable when zoomed in.

This check is especially important for forms, checkout, signup, navigation, and any page where the user needs to take action.

9. Forms and lead capture check

If the website collects requests, registrations, emails, demo requests, or contact form messages, forms should be tested carefully.

Check that:

• the form opens and displays correctly;
• required fields are actually required;
• optional fields can be left empty;
• email, phone, URL, and other formats are validated correctly;
• errors are shown next to the correct fields;
• error messages are clear to the user;
• the form cannot be submitted with invalid data;
• the form can be submitted with valid data;
• entered data is not lost after an error;
• after successful submission, the user sees a clear confirmation;
• data goes to the right system: email, CRM, database, or admin panel;
• the team receives a notification about a new request, if expected;
• duplicate submit does not create multiple identical requests;
• spam protection works, if it is used;
• privacy consent is shown, if required.

If the website has several forms, test each one separately. For example, a hero section form, footer form, pop-up form, contact page form, and demo request form may work differently on the technical side.

10. Signup, login, and account check, if applicable

If the website is connected to a product, user account, or private area, make sure to check the account flow.

Check that:

• the user can sign up;
• the user can log in;
• the user can log out;
• email confirmation works, if used;
• password reset works;
• an expired reset link is handled clearly;
• an incorrect password shows the correct error;
• the user cannot access private pages without logging in;
• after login, the user lands on the correct page;
• after logout, private pages are no longer available;
• direct URLs do not open private pages without permission;
• a user with one role cannot access functionality intended for another role;
• onboarding flow works, if it exists.

For launch QA, it is important to check not only a new registration, but also the behavior of an existing user: login, logout, password reset, session expiration, and account access.

11. Checkout, payment, or order check, if applicable

If the website accepts payments, orders, subscriptions, or bookings, this section should be one of the highest priorities.

Check that:

• the user can add a product or service to the cart;
• the price is displayed correctly;
• discounts, promo codes, and taxes are calculated correctly;
• the checkout flow works from beginning to end;
• required fields are validated;
• shipping or billing information is saved correctly;
• successful payment shows the correct confirmation;
• failed payment is handled clearly;
• declined payment does not create a successful order;
• order confirmation is sent to the user;
• the order appears in the admin panel or order management system;
• payment status is correct;
• subscription status is correct, if subscriptions are used;
• refund or cancellation flow is clear, if it is included in the testing scope.

Payment is an area where "looks fine" is not enough. Amounts, statuses, taxes, discounts, and confirmations should be compared with expected values.

12. Email, notifications, and integrations check

Many websites depend not only on the frontend, but also on external services: CRM, email providers, payment systems, analytics, support tools, APIs, and webhooks.

Check that:

• registration email is delivered;
• email after form submission is delivered;
• order confirmation is delivered, if orders exist;
• emails do not contain test copy;
• links in emails work;
• form data goes to the CRM;
• the lead receives the correct status;
• webhooks are sent, if needed;
• the external system returns the expected response;
• an integration error does not break the entire user scenario;
• the user sees a clear message when there is a problem;
• internal team notifications are sent to the right place;
• there are no test recipients in production settings.

For integrations, always check more than the happy path. For example, what happens if the CRM is temporarily unavailable, an email is not sent, or the payment provider returns an error?

13. SEO basics check

Before launching a website, make sure that pages intended for indexing are actually available to search engines and that technical settings do not block organic traffic.

Check that:

• important pages have unique title tags;
• important pages have clear meta descriptions;
• each important page has one main H1;
• headings follow a logical structure;
• canonical URLs are configured correctly;
• pages that should be indexed are not blocked with noindex;
• robots.txt does not block important pages;
• sitemap.xml is available and contains the correct URLs;
• internal links point to current pages;
• there are no links to staging or old domains;
• old URLs redirect to new URLs, if there was a migration;
• 404 pages are handled correctly;
• images have meaningful alt text where it matters;
• the main page content is available in HTML and not hidden entirely behind interactive elements;
• structured data is added only where it is actually needed and matches the page content;
• Open Graph / social previews are configured for important pages.

For a website that is launching with organic traffic in mind, SEO basics should be checked before launch, not after. A mistake like an accidental noindex on an important page can be costly.

14. Analytics and tracking check

Before launch, make sure the team will be able to see what users are doing after the website goes live.

Check that:

• the analytics script is installed on the right pages;
• page views are sent;
• main conversion events are configured;
• signup event is sent, if there is signup;
• form submit event is sent, if there are forms;
• purchase or checkout events are sent, if there is payment;
• CTA clicks are tracked, if they are important;
• events are not duplicated;
• events have clear names;
• test traffic can be separated from real traffic, if needed;
• ad pixels are installed, if they are included in scope;
• UTM parameters are not lost;
• cookie consent does not conflict with tracking logic;
• analytics does not break page loading.

The main question for this part is: after launch, will the team be able to understand how many people came to the website, what they did, and where problems happened?

15. Performance check

Poor website speed can damage a launch even if there are no functional bugs. A user may leave before they see the page or complete a form.

Check that:

• main pages load fast enough;
• heavy images are optimized;
• video does not block page loading;
• fonts do not create noticeable display issues;
• there are no overly heavy third-party scripts;
• lazy loading works where needed;
• critical content appears without a long delay;
• the page does not jump during loading;
• the mobile version loads acceptably;
• loading states are clear;
• analytics and marketing scripts do not slow down the critical flow.

Pay special attention to the homepage, landing page, pricing page, signup, checkout, and any pages that will receive paid or SEO traffic.

16. Error handling and edge cases

Before launch, make sure the website does not break when the user or the system behaves in a non-ideal way.

Check that:

• the 404 page looks acceptable;
• the user can return from a 404 page to a useful page;
• the 500 error page does not show unnecessary technical information;
• slow internet does not break the main scenario;
• repeated form submission does not create duplicates;
• refreshing the page does not break the state;
• empty states are displayed clearly;
• very long values do not break the layout;
• invalid data is not saved;
• the user sees a clear error message when there is a problem;
• the user can continue the scenario after an error;
• there is no endless loader;
• there are no critical console errors.

Edge cases do not always need deep testing for a small landing page. But for signup, payment, lead forms, and account flows, they are required.

17. Security and access check

Website launch QA does not replace a security audit, but basic security checks are always needed before launch.

Check that:

• the website works over HTTPS;
• there are no mixed content warnings;
• staging, admin, or test pages are not publicly available unless they should be;
• private pages require authentication;
• direct URLs do not open private data;
• production does not contain test users with simple passwords;
• debug messages are not shown in production;
• there are no secret keys in HTML, console, or network responses;
• forms are protected from obvious spam or abuse, if needed;
• users cannot see other users' data;
• roles and permissions work correctly;
• test data has not appeared on public pages;
• files that should not be public are not accessible.

Pay special attention to admin panels, preview pages, hidden pages, API responses, uploaded files, and any pages with user data.

18. Legal, cookies, and privacy check

Legal requirements depend on the product, market, and type of data, so this section should be reviewed with the responsible person on the team. But basic elements can still be checked during launch QA.

Check that:

• privacy policy is available;
• terms of service are available, if needed;
• cookie notice or cookie banner is shown, if expected;
• the user can accept or configure cookies, if required;
• links to legal pages work;
• forms include required consent text, if needed;
• marketing subscription is not enabled without the required consent;
• unsubscribe link works for marketing emails, if they are sent;
• company information is correct;
• contact information is up to date;
• legal pages are not accidentally hidden from users;
• texts do not contain outdated company, product, or jurisdiction names.

This section should not turn QA into legal review. The QA goal is to check that agreed legal and privacy elements are actually present and working on the website.

19. Final production check before launch

Before the website is officially opened to users, run a short final check on production or on an environment that is as close to production as possible.

Check that:

• the production domain opens;
• the SSL certificate works;
• redirects from HTTP to HTTPS work;
• www / non-www versions go where they should;
• main pages are available;
• main CTA buttons work;
• forms can be submitted;
• signup or checkout works, if available;
• emails are delivered;
• analytics receives events;
• sitemap is available;
• robots.txt is configured correctly;
• there are no links to staging;
• there is no test content;
• feature flags are configured correctly;
• responsible people know that the website is ready to launch.

The final check is not bureaucracy. It helps catch issues that are not always visible on staging: wrong domain settings, production configuration, SSL, analytics, email delivery, redirects, or access issues.

20. Post-launch check

After the website goes live, run a short check on the real environment and real domain.

Check that:

• the website opens for external users;
• main pages are available;
• the key CTA works;
• forms can be submitted;
• requests go to the right system;
• signup or login works;
• checkout or payment works, if available;
• emails and notifications are sent;
• analytics collects data;
• ad and tracking events work, if needed;
• there is no sudden increase in errors;
• there are no widespread user complaints;
• search engines are not accidentally blocked;
• important pages are not blocked from indexing;
• the team knows where to look if something goes wrong.

A post-launch check should be short. Its purpose is to quickly confirm that real users can do what the website was launched for.

Common mistakes

1. Checking only the visual design

A website can look beautiful, but forms may not submit, analytics may not work, links may point to staging, and CTA buttons may open the wrong page. Before launch, it is important to test not only the design, but also real user scenarios.

2. Not checking the mobile version

Teams often review a website on a large screen, while users arrive from phones. If the mobile menu, form, or CTA does not work, the launch can fail even with a good desktop design.

3. Leaving links to staging

This is one of the most common and frustrating launch mistakes. Production may accidentally contain links to staging, test domains, preview pages, localhost, or old URLs.

4. Forgetting to test forms

A form may look correct but fail to send data, send it to the wrong place, lose some fields, or fail to notify the team. Every form should be tested end-to-end before launch: from entering data to receiving the request.

5. Not checking SEO settings

A website may be ready for users but closed to search engines. For example, because of an accidental noindex, incorrect robots.txt, missing sitemap, or links to an old domain.

6. Not checking analytics before launch

If analytics and conversion events do not work from day one, the team loses important launch data. This is especially critical if paid traffic is going to the website.

7. Testing only the happy path

Before launch, test not only the ideal scenario, but also errors: invalid data, failed payment, double submit, slow loading, expired session, 404 pages, and empty states.

8. Making the launch checklist too large

If a checklist becomes huge and identical for every project, the team stops using it. It is better to have a required base checklist and additional sections for more complex websites: e-commerce, SaaS, login, payments, and integrations.

FAQ

What is a Website Launch QA Checklist?

A Website Launch QA Checklist is a list of checks before launching a website, landing page, or web product. It helps make sure that pages open correctly, main scenarios work, forms submit, the mobile version is stable, analytics collects data, and the website is ready for users and search engines.

How is a website launch checklist different from a release QA checklist?

A website launch checklist is used before launching a website or an important web page. It includes not only functional checks, but also content, links, SEO basics, analytics, performance, cookies, privacy, and production readiness.

A release QA checklist is usually used before shipping a new version of a product. It focuses more on functionality changes, bug fixes, regression smoke checks, and release readiness.

In simple terms: a website launch checklist answers "is the website ready for public launch?", while a release QA checklist answers "is the new product version ready to ship?"

Who should use a Website Launch QA Checklist?

A website launch checklist is usually used by a QA Engineer or Manual QA. But it is also useful for a Product Manager, Founder, Project Manager, marketer, designer, or developer if the team does not have a dedicated QA.

In a small team, this checklist helps avoid keeping all checks in someone's head and reduces the risk of missing important details before launch.

Do you need to complete the full checklist for a small landing page?

Not always. For a simple landing page, you can use a shorter version: main pages, links, forms, mobile version, SEO basics, analytics, production check, and post-launch check.

For a SaaS product, e-commerce website, website with payments, account area, or many pages, it is better to go through the full checklist.

What should be checked before launching a website?

At minimum, check:

• main pages;
• navigation and links;
• CTA buttons;
• forms;
• mobile version;
• main browsers;
• content and copy;
• SEO basics;
• analytics;
• performance;
• legal pages, if needed;
• production domain;
• post-launch behavior.

How do you test forms before launching a website?

Forms should be tested end-to-end. This means filling out the form, submitting it, seeing the confirmation message, checking validation, making sure the data arrived in the CRM, email, database, or admin panel, and verifying that the team received the right notification.

It is also worth checking error cases: empty required fields, invalid email, too-long text, double submit, and repeated submission.

Do you need to check SEO before launching a website?

Yes. Even if QA is not responsible for SEO strategy, basic technical SEO should be checked before launch: title, description, H1, canonical, robots.txt, sitemap, noindex, internal links, redirects, and whether the main page content is available.

This helps avoid a situation where the website is launched but important pages are accidentally blocked from indexing.

Do you need to check analytics before launch?

Yes. Analytics should be checked before launch, especially if the website will receive paid traffic or the team wants to measure conversion.

At minimum, check page views, form submit, signup, checkout, or other key conversion events. It is also important to make sure events are not duplicated and have clear names.

How do you know if a website is ready to launch?

A website is ready to launch when:

• main pages open correctly;
• key user scenarios work;
• forms submit and data reaches the team;
• the mobile version is not broken;
• important links are correct;
• there is no test content;
• SEO basics are configured;
• analytics collects data;
• the production domain works;
• there are no blocker or critical bugs;
• the team understands known risks;
• there is a plan for a quick post-launch check and response if something goes wrong.

Create a website launch checklist

Use this website launch QA checklist as a starting point for your next launch. In qa::checklist, you can organize checks by page or module, track pass/fail status, add comments, and export the completed checklist to CSV.