A website is not ready for production simply because its home page looks finished. Visitors arrive through deep links, use different devices, follow old URLs, and try to complete tasks with keyboards or assistive technology. The launch needs to account for those journeys as well as the deployment itself.
Use a release checklist to make responsibilities visible. Each item should have an owner, an observable result, and a response if it fails. The following sequence suits a small business website and can be extended for an application with accounts, payments, or a backend.
The key ideas
- Test visitor journeys on the actual release artifact.
- Verify direct URLs and real HTTP responses.
- Retain a recoverable release and name the person who can restore it.
Review what the website promises
Read the service descriptions, contact details, claims, and calls to action as a prospective customer would. Remove placeholder content and distinguish published material from planned work. Confirm that any client names, testimonials, or results have an appropriate basis and permission to appear.
Follow each important action to its outcome. A form that prepares an email draft should say so; it should not display a message-sent confirmation. A booking request should explain whether a reservation is confirmed. Make failure and fallback states as clear as the primary action so visitors know what to do next.
Check real reading and navigation conditions
Review page titles, heading structure, alternative text, visible keyboard focus, form labels, contrast, and zoom. W3C's Easy Checks is a useful first review, but passing a short checklist does not establish comprehensive accessibility. Include more detailed assessment when the site's requirements or risks call for it.
Try the site's important journeys on a narrow screen and with a keyboard. Open and close navigation, follow article links, and reach form feedback. Check long headings and browser text enlargement. Turn on reduced motion and verify that content remains visible. These checks can reveal issues that an attractive desktop screenshot will not show.
Reference: W3C WAI: a first review of web accessibility
Verify URLs, metadata, and missing pages
Load important pages directly in a fresh tab and refresh them. Confirm that the preferred hostname redirects consistently, canonical metadata points to the intended public URL, and a nonexistent page returns an actual 404 response. A home-page fallback with status 200 can conceal broken routing.
Keep the sitemap aligned with published canonical pages and link to those pages within the site. Google describes a sitemap as a way to help search engines discover content; submission does not guarantee crawling or indexing. Review robots directives and accidental noindex settings before launch, then inspect the published site through the relevant search tools.
Reference: Google Search Central: sitemap overview
Test the artifact that will be deployed
Build from the committed dependency lockfile and run checks against the generated output. Preview that output rather than relying only on a development server. Record the source revision and keep an inventory or checksum so the team can identify the artifact it intends to publish.
Check asset paths, content types, and caching behavior in the real hosting environment. Long-lived caching works well for content-addressed assets when old files remain available to open browser pages. HTML needs a deliberate freshness policy. If a CDN sits in front of the origin, account for both layers when verifying a new release and planning recovery.
Assign access, data, and operational ownership
Document who owns the domain, certificate, hosting account, deployment process, and support inbox. Prefer individual or appropriately managed access over a password shared informally across the team. Keep credentials out of source, public bundles, and release archives.
Inventory what the site actually stores or sends, including forms, analytics, embeds, and browser preferences. Match the published explanations and controls to that behavior. If a third-party tool is optional, decide how it is gated before loading and how a visitor withdraws a choice. Operational ownership includes keeping those descriptions current after launch.
Launch with a recovery plan
Retain the previous verified release before publishing. Write down the exact restore procedure and any limits: restoring website files does not necessarily reverse a database migration, DNS update, or permission change. For a runtime application, plan those recovery paths separately.
- Deploy through the agreed process and wait for its completion.
- Check the homepage, deep links, assets, critical interactions, redirect, and missing-page status on production.
- Record the release revision and verification outcome.
- Monitor the first operating period and give problems a named owner.
- If a critical check fails, use the documented recovery path and verify the restored experience.
Sources & further reading
The guidance above combines our engineering recommendations with the official references below. Service features and platform requirements can change; check the current documentation when implementing.