A website launch is a handover from a controlled development environment to a public service. The pages may look complete while important details—forms, redirects, metadata, mobile navigation, environment variables or domain configuration—remain untested. A repeatable checklist helps teams catch these issues before visitors encounter them.
The checks below apply to portfolios, business websites and many web applications. Adjust the list to the actual product: a static portfolio has different risks from an account-based application or an online store, but both need working navigation, accurate content and a recovery plan.
Key takeaways
- Open every important route directly and check redirects.
- Verify real form delivery and integration failure states.
- Review metadata, canonicals, sitemap and robots rules.
Check routes and navigation
Visit every important route directly, not only by clicking from the homepage. Check trailing-slash behavior, legacy URLs, redirects, not-found pages and links to external services. A route that works through client navigation may still fail on a fresh request if the server configuration is incorrect. Confirm that navigation works at mobile widths and that focus indicators remain visible. Search for placeholder links, buttons without actions and links that point to staging domains or private repositories.
Test forms and integrations
Submit a real test contact form and confirm delivery at the intended destination. Verify authentication callbacks, booking actions, payment sandbox behavior or CRM integration where relevant. Check invalid input and service failures as well as the successful path. Ensure the user receives honest feedback and that private values do not appear in URLs or browser logs. Do not claim an integration is working merely because the interface is present; test the external service and its configured credentials.
Review content and metadata
Check titles, descriptions, headings, social preview images, image alternatives and publication dates on important routes. Confirm that each indexable page has a relevant canonical URL and that private pages are excluded from indexing. Look for spelling errors, outdated contact details, unsupported claims and missing legal information. Open social previews using available validators and inspect the rendered HTML where possible. Metadata should describe the real page rather than repeat a generic site-wide slogan.
Test mobile, keyboard and readability
Use real responsive viewport sizes and test the navigation, forms, project cards, tables, images and footer. Check for horizontal overflow, overlapping content, clipped headings and unexpectedly narrow paragraphs. Navigate the page with a keyboard, zoom in and confirm focus is visible. Verify text contrast in the actual color palette. If the site contains animation, test reduced motion and make sure important information is still available when effects are disabled.
Check technical SEO and performance
Validate the sitemap, robots rules, canonical host, redirects, internal links and intended indexability. Ensure that images have dimensions, large assets are appropriately compressed and important content is available in the rendered page. Run performance diagnostics on representative routes rather than just the homepage. Review JavaScript errors and missing network requests. A good lab score is useful, but it does not guarantee the same results for every real visitor or network condition.
Verify security and configuration
Check that production secrets are configured in the hosting provider and never committed to the repository. Confirm database migrations, access policies, rate limits, callback URLs and allowed origins. Review the public bundle for accidental private keys. Set up error reporting appropriate to the project and make sure the team can access the hosting and domain accounts. For applications with user data, confirm backup and restoration procedures before launch.
Prepare rollback and ownership
Record the deployment version, required environment variables, migration steps and the person responsible for launch. Know how to revert the application if a critical issue appears. Database changes need special care because restoring old application code may not reverse a destructive schema change. Confirm who owns the domain, hosting, source code, analytics and third-party accounts. After launch, run a short smoke test against the live domain and keep an eye on actual enquiry delivery and errors.
Test production-like journeys, not isolated pages
Open important routes directly as well as through navigation, then exercise the tasks visitors actually perform: submit an enquiry, sign in, use a filter, download a file or follow a project link. Confirm validation, waiting states, success states and failures. Test with realistic content because long titles, missing images, unusual names and empty lists can break layouts that look fine with demo text. Verify redirects and canonical URLs on the intended host, and ensure sensitive routes are not included in public sitemaps. Check mobile navigation, focus order, reduced motion and 404 handling. A green build is a useful gate, but it covers only part of the experience.
Verify search signals and sharing previews
Inspect the rendered HTML for a unique title, description, canonical, heading hierarchy and appropriate indexing directive on each important page. Confirm the sitemap contains valid canonical URLs and excludes authentication callbacks, admin pages and private routes. Check robots rules for accidental broad disallow directives. Test social previews using the correct Open Graph image and make sure the image can be fetched without authentication. Structured data must describe visible page content, not add invented ratings or properties. If analytics or Search Console verification is required, confirm ownership through the official process and do not assume indexing simply because the sitemap returns successfully.
Plan monitoring and rollback before the announcement
Keep a record of the deployed version, important environment variables, migrations and the steps for rolling back. Decide who watches enquiry delivery, error logs, uptime and third-party service quotas after release. Test the critical path on the live domain immediately after deployment, ideally from a separate browser session and a mobile device. A database migration may not be reversible just by deploying an old frontend, so document schema changes and recovery options separately. Remove temporary debug code and test data, rotate any credential that may have been shared inadvertently, and confirm that the team can access the domain and hosting accounts. A calm launch is planned before release day.
Organize release readiness by risk
Not every launch task has equal impact. Rank issues by whether they can block a customer task, expose private data, lose enquiries, mislead a visitor or prevent search engines from understanding the page. Broken authentication, incorrect pricing, failed forms, open admin access and destructive data changes should block release. A small decorative adjustment may be scheduled after launch if it does not reduce usability. Name one person responsible for the release and one person who can confirm that the critical user journeys work. Keep a written list of configuration values and the services they connect to, without copying secrets into the document. Verify redirects and canonical host behavior with the exact production domain. Confirm the backup and rollback procedure before a database or routing change. After deployment, run a small smoke test against the live service and check the error logs and form destination. Communicate any known limitation honestly to the team. This approach makes launch decisions less subjective because the team agrees on acceptable risk beforehand. It also prevents an arbitrary visual deadline from taking priority over customer data, security or revenue-critical workflows.
Practical checklist
- Open every important route directly and check redirects.
- Verify real form delivery and integration failure states.
- Review metadata, canonicals, sitemap and robots rules.
- Test mobile layout, keyboard use and reduced motion.
- Confirm secrets, backups, ownership and rollback steps.
Frequently asked questions
Should I launch if one noncritical visual issue remains?
Use impact and risk to decide. A minor cosmetic issue may be acceptable, but broken navigation, lost enquiries, security gaps or incorrect indexing should be fixed first. Test production environment variables and actual integrations separately from the local environment before announcing the launch.
Is a successful production build enough to launch?
No. A build confirms that the framework can compile the application. It does not prove that external integrations, forms, redirects or the live domain work correctly. Retain a rollback path and verify critical pages, forms and redirects again after deployment.
What should I test immediately after deployment?
Open key pages, submit a test enquiry, check the canonical host and redirects, inspect browser errors and verify that the expected production services respond. Test production environment variables and actual integrations separately from the local environment before announcing the launch.
Should staging and production use identical secret values?
No. Keep the expected variable names and configuration shape consistent, but use separate credentials and service instances where appropriate. Store secrets in the hosting environment, limit access, and verify the production configuration without copying sensitive values into source control.
Sources & references
Documentation and references used to check the technical and practical guidance in this article.
A launch checklist turns a risky final rush into a repeatable process. Test real user journeys, inspect the live domain, verify SEO and security configuration, and keep a rollback plan. A launch is successful when the important tasks work—not merely when the deployment command finishes.
Have a related project or need a second opinion? Share the context and start a conversation .
