3 min read
Website launch checklist: what to test before going live
A launch review checks content, journeys, forms, metadata, security and recovery under the production configuration. It should produce named evidence and owners, not a vague statement that the website looks ready.
Verify content and navigation
Every public route needs final copy, working navigation and a deliberate response for missing or retired pages. A valid homepage does not prove that campaign links, language variants or footer destinations are correct.
Crawl the release candidate, check redirects and review titles, descriptions, canonicals and language alternates on representative pages.
Content review covers more than spelling. Confirm the current brand name, contact details, prices, service boundaries, legal links and image rights on every public template. Crawl internal links and decide how retired URLs redirect. Check titles, descriptions, canonical URLs and language alternates from rendered production HTML. Search staging markers and placeholder text across the build so they do not appear in pages that were missed during manual review.
Test complete user journeys
Buttons and forms need testing from the first click through the final confirmation and operational handoff. A contact form that stores a record but fails to notify the team is not a successful enquiry path.
Submit real test cases for contact, quote and purchase flows; confirm email delivery, reply routing, errors and duplicate protection.
Test complete journeys with production-like data. Submit each contact and quote form, verify the delivered email, reply address, saved record, failure message and duplicate handling. For stores, place test orders through supported payment and delivery states. Include validation, slow connections and provider failure. A success screen is evidence only when the operational destination also received the information needed to continue the task.
Use the production configuration
Local success does not verify domains, HTTPS, environment variables, external services or reverse-proxy behaviour. A missing secret or incorrect host rule can break only after deployment.
Run smoke checks against the intended domain, verify secure redirects and confirm that private configuration is absent from client bundles.
Production configuration needs its own checklist. Verify DNS, HTTPS, host redirects, environment variables, email credentials, reverse-proxy headers, scheduled workers and backup locations. Confirm that secrets remain server-side and the application port is not exposed unnecessarily. Test anonymous access in a clean browser, because an authenticated administrator session can hide cache, permission or redirect problems that public visitors will encounter.
Prepare rollback and ownership
A release needs a known previous version, backup scope and a person who can respond to a failed check. Without a rollback path, a small defect can become a long outage while the team rebuilds under pressure.
Practical checks
- Record the deployed revision, health endpoint, logs, backup location and the condition that triggers rollback.
Record the deployed revision and a rollback path before release. Name the person who watches application and proxy logs, the checks that trigger rollback and the previous image or package that can be restored. Recheck the main routes after deployment from outside the server. A short written release record makes incident response faster and prevents the team from guessing which version, migration or environment value reached production.
Related service