Define release readiness as evidence

A business website launch checklist should verify the visitor journey, content accuracy, accessibility, search setup and operational ownership before public release. A successful build proves that code can be packaged; it does not prove that a customer can submit a request on the production domain. Separate those checks and record what was actually tested.

Start with the journeys that matter: finding a service, understanding eligibility or coverage, contacting the business and receiving a useful confirmation. For each one, name the expected result and the person responsible for checking it. Unverified dependencies should appear in the release notes.

Check content, links and branding

Review service descriptions, contact information, operating hours and images. Remove template text and placeholder buttons. Make sure claims are supported and that any case study or testimonial has permission for publication. Check the favicon, logo, page titles and footer links on the actual published site.

Follow internal links from the homepage to important pages. A page that exists but is never linked may be hard for both visitors and crawlers to discover. Avoid making a customer guess whether two navigation labels describe the same destination.

Test the complete form journey

Submit a non-sensitive test inquiry. Verify receipt at the backend, not just the browser’s success message. Test invalid input, oversized requests, a slow connection, duplicate retries and the error state when storage is unavailable. If notification delivery is separate, check it separately instead of treating storage as proof an email was sent.

OWASP’s REST security guidance covers HTTPS endpoints and server-side input validation. For a public form, also agree on abuse controls and administrative access. Do not expose submissions through an anonymous read endpoint simply to make debugging convenient.

Review mobile and accessibility behavior

Use narrow screens, keyboard navigation and zoom. Confirm that navigation opens and closes, focus remains visible, text is readable and the form does not force horizontal scrolling. Labels should explain fields without relying solely on placeholders. Error messages should identify what needs attention.

W3C’s preliminary review covers checks such as page titles, headings, alternative text and keyboard interaction. These are useful early checks, not a complete accessibility audit. Record the scope of evaluation instead of claiming compliance from a few automated results.

Assign an owner for the day after launch

Identify who watches errors, reviews requests, updates content and handles access changes. Agree what is backed up, how often and how a restore will be tested. If data collection is new, make the privacy disclosures match the implementation and avoid promising deletion automation that does not exist.

A release record should state the deployed version, checks passed, known limitations and rollback path. If a critical form or domain check fails, resolve it before inviting traffic. For lower-priority issues, assign an owner and a follow-up date so they do not disappear behind the launch announcement.

Common questions

Is a successful deployment enough to launch?

It verifies publication, but core journeys still need checks on the deployed domain. Form storage, notifications and visual behavior are separate results.

Can a sitemap guarantee Google indexing?

No. A sitemap supports URL discovery; it does not guarantee crawling, indexing or rankings.

Sources & further reading

Consult the original documentation for current behavior and implementation details.

Make it useful for your business.

Explore our services, or tell us about the problem you want to solve.

Share your project Explore services