Website Testing Before Launch

Pre-launch testing should demonstrate that the website can perform its important business tasks safely. Run it on the final release candidate with realistic content and configuration. Record results and retest fixes; do not rely on verbal assurance that features have been checked.

Release control

• ☐ Confirm the version being tested is the version intended for launch.
• ☐ Freeze untracked design and content changes during final testing.
• ☐ Assign an owner and expected result for each test area.
• ☐ Define defects that block launch.
• ☐ Confirm backup, deployment and rollback procedures.

Content and business information

• ☐ Business name, address, telephone and email are consistent.
• ☐ Services, products, prices and availability are accurate.
• ☐ Claims, testimonials and images have evidence or permission.
• ☐ Placeholder and draft content is removed.
• ☐ Dates, opening hours and service areas are current.
• ☐ Privacy, cookies, terms and other required pages match the real operation.
• ☐ Links and downloads lead to the intended destinations.

Navigation and discovery

• ☐ Main and mobile menus expose the priority routes.
• ☐ Breadcrumbs and related links are correct.
• ☐ Search and filters return useful results and a helpful empty state.
• ☐ The logo and home links behave consistently.
• ☐ The 404 page is useful and returns HTTP 404.
• ☐ No important page is isolated from normal navigation.

Forms and enquiries

• ☐ Required and optional fields are accurate.
• ☐ Labels remain visible and instructions are clear.
• ☐ Invalid entries produce specific accessible errors.
• ☐ Correct data remains after an error where appropriate.
• ☐ Successful submission produces a clear confirmation.
• ☐ Notifications arrive at the correct address.
• ☐ Reply handling and spam controls work.
• ☐ Submitted personal data is stored and retained as intended.

Bookings, payments and accounts

• ☐ Availability, price, taxes and charges are correct.
• ☐ Test and live modes are not confused.
• ☐ Successful and failed payment routes behave safely.
• ☐ Confirmation emails contain correct information.
• ☐ Cancellation, refund and account-recovery processes work.
• ☐ Webhooks and external systems receive the right events.
• ☐ Duplicate submission or refresh does not create unintended duplicate transactions.

Mobile and browser coverage

• ☐ Core tasks work on real Android and iOS devices.
• ☐ Key widths between 320 and 430 CSS pixels are checked.
• ☐ Major desktop and mobile browser engines are tested.
• ☐ Orientation, zoom and text resizing are checked.
• ☐ There is no accidental page-level horizontal scrolling.
• ☐ Touch targets and fixed elements do not obstruct use.

Accessibility

• ☐ The site can be navigated by keyboard.
• ☐ Focus is visible and moves logically.
• ☐ Headings and landmarks are meaningful.
• ☐ Images have appropriate alternatives or are marked decorative.
• ☐ Forms have labels, instructions and accessible errors.
• ☐ Colour is not the only way information is conveyed.
• ☐ Dialogues and menus can be opened and closed accessibly.
• ☐ Automated findings are followed by manual testing.

Performance and resilience

• ☐ Representative pages are tested on mobile conditions.
• ☐ Main images are appropriately sized and responsive.
• ☐ Layout space is reserved for images, embeds and advertising.
• ☐ Unnecessary third-party scripts are removed.
• ☐ Error handling works when an external service is unavailable.
• ☐ Backups run and a restoration route has been tested.

Security and privacy

• ☐ HTTPS works on every public page without mixed content.
• ☐ Administrator accounts use least privilege and strong authentication.
• ☐ Default, test and former-user accounts are removed or disabled.
• ☐ Supported software and dependencies are used.
• ☐ Non-exempt tracking follows the intended consent choice.
• ☐ Consent can be refused or withdrawn.
• ☐ Error pages do not reveal server paths or secrets.
• ☐ Forms and uploads validate on the server.

Search and analytics

• ☐ Production pages are not accidentally noindexed or blocked.
• ☐ Canonical URLs are correct.
• ☐ Titles and descriptions are editable and reviewed.
• ☐ Redirects are tested without chains or loops.
• ☐ The XML sitemap contains intended canonical URLs.
• ☐ Search Console ownership is available to the business.
• ☐ Analytics and conversion events record the intended actions.
• ☐ Internal and test traffic can be understood during verification.

Launch approval

• ☐ All blocking defects are closed and retested.
• ☐ Accepted limitations are documented with owners and follow-up dates.
• ☐ The final backup is complete.
• ☐ Monitoring and support contacts are active.
• ☐ The business has administrator access and handover documentation.
• ☐ A named person authorises launch.

The next practical step is to run the checklist against one final release candidate and store evidence for every business-critical test.