Launch-day mistakes follow remarkably consistent patterns — the same handful of missed items repeat across projects regardless of who built the site. A concrete checklist, run through methodically rather than from memory in the rush of going live, catches almost all of them before they become a visible problem.

Technical Checks

  1. SSL certificate installed and forcing HTTPS everywhere (no mixed-content warnings).
  2. All forms tested end-to-end — submit a real test entry and confirm it arrives.
  3. 404 page exists and is styled, not a raw server error.
  4. Site tested on actual mobile devices, not just browser dev-tools mobile view.
  5. Page speed tested (PageSpeed Insights or similar) and within acceptable range.
  6. All internal links checked for typos or broken destinations.
  7. Favicon displays correctly across browsers and devices.
  8. Browser back-button and navigation behavior tested, not just the happy path.

SEO and Analytics

  1. Google Analytics (or equivalent) installed and confirmed tracking real events.
  2. Google Search Console verified and sitemap submitted.
  3. Robots.txt reviewed — confirm it isn't accidentally blocking the whole site (a common leftover from staging).
  4. Every page has a unique title tag and meta description, not defaults or duplicates.
  5. Old URLs (if this is a redesign, not a new site) have 301 redirects to their new equivalents.
  6. Structured data (schema markup) validated with Google's Rich Results Test.

Content Checks

  1. No leftover lorem ipsum or placeholder text anywhere on the site.
  2. All images have proper alt text, not blank or filename-based defaults.
  3. Contact information (phone, email, address) is current and consistent across every page it appears.
  4. Legal pages exist — privacy policy, terms, any industry-specific disclosures required.
  5. Copyright year in the footer is current.
  6. Social media links (if present) point to the correct, live accounts, not placeholders.

Business and Operational Checks

  1. Email addresses on the new hosting/domain are working, tested by sending and receiving a real message.
  2. DNS fully propagated and confirmed from multiple locations before announcing the launch publicly.
  3. A backup of the freshly launched site taken immediately, as the first entry in the ongoing backup schedule.
  4. Staff who need CMS access have working logins with appropriately scoped permissions.
  5. A monitoring or uptime-check tool set up so a future outage is caught proactively, not reported by a confused customer first.

Who Should Own This Checklist

On most projects, ownership of the launch checklist defaults to whoever built the site, but that's a mistake for the business-and-operational section specifically — the developer can confirm SSL and redirects are correct, but only the business owner can confirm the phone number in the footer is current or that the email addresses about to go live are ones staff are actually monitoring. The cleanest approach splits the list: a technical owner runs items 1-20, and the business owner (or whoever manages day-to-day operations) signs off on items 21-25 specifically, so nothing falls into the gap between "the developer assumed the client checked" and "the client assumed the developer checked."

Why a Written Checklist Beats Memory

Even an experienced team misses items under the specific pressure of a launch deadline, which is exactly when a written checklist, worked through item by item rather than trusted to memory, earns its keep. WebsNP runs a version of this exact list on every site launch, because the cost of catching a missed SSL redirect or a broken contact form before announcing a launch is minutes; the cost of catching it after a client has already shared the link with their customers is real, visible embarrassment.