Sitewrightstudio
Back to blog
Article
29 May 2026by Sitewright Studio

Website launch checklist: complete guide

A solid website launch checklist keeps panic moments from becoming disasters. Learn what actually needs to happen before you go live, technical readiness, compliance, communication, and rollback plans.

Website launch checklist: complete guide

You're hours away from launch, and suddenly your email automation hasn't synced to your CRM, your SSL certificate won't renew, and your client is asking whether staging passwords are still live. A solid website launch checklist keeps those panic moments from becoming disasters.

What a real website launch checklist actually includes

Most launch checklists you'll find online are generic: "test your site," "set up SSL," "tell people it's live." That's the skeleton, but it misses the muscle. A practical website launch checklist needs to cover four layers: technical readiness, compliance, stakeholder communication, and rollback plans. Each layer has non-negotiable items, but the specifics vary wildly depending on whether you're launching a SaaS product, an e-commerce store, a law firm website, or a membership site.

The real risk isn't missing one item, it's not knowing why it matters or what "ready" actually looks like. A slow page load might be invisible in your office on fast Wi-Fi but catastrophic for a visitor on 4G. A missing WCAG accessibility fix isn't just nice-to-have; it's a legal exposure if your site targets customers in the EU or serves any regulated industry. And if you're migrating from Shopify to a custom WordPress build, data loss isn't a hypothetical, it's one bad API call away.

Pre-launch: technical readiness and performance

The most overlooked part of any go live checklist is when to stop building and start testing. Teams often keep adding features until 48 hours before launch, which leaves no buffer for actual verification.

Performance benchmarks that matter

"Test page speed" is useless advice. You need thresholds. Core Web Vitals for small business websites should target a Lighthouse score of 90+, but that's only meaningful if you're testing the right pages. Test:

  • Your homepage (first impression)
  • Your most-linked page from external sites (likely your busiest traffic route)
  • Any page with forms, payment flows, or conversions (slowness costs abandonment)
  • Your largest-media page (video embeds, image galleries, carousels)

Acceptable thresholds: Largest Contentful Paint (LCP) under 2.5 seconds, Cumulative Layout Shift under 0.1, First Input Delay under 100ms. If you're above those numbers, you'll lose visitors. Most DIY or budget-builder sites (Wix, Squarespace, GoDaddy) ship at 50 to 70 Lighthouse; bespoke builds target 90+, which matters most if you're competing on search visibility.

Database, integrations, and fallback routes

If your site uses a CMS, database, or third-party payment processor, test the unhappy path. What happens if Stripe goes down for 6 hours? Can customers still contact you? If you're using Resend or SendGrid for email, have you tested that contact-form replies actually land in your inbox? Run each integration test three times in your staging environment, not once on launch day.

If you're migrating from another platform (Shopify to WordPress, Webflow to a custom React build), data loss is the leading cause of launch day disasters. Before you point DNS to your new site, export your old database, import it to the new platform, and verify record counts match. Check that URLs haven't changed, broken URLs cost SEO authority and user trust. Set up 301 redirects from old paths to new ones for at least 12 months.

Staging, previewing, and stakeholder sign-off

Never launch to production without a staging version that's identical to production (same database, same integrations, same domain SSL). Have at least three people test it on different devices and browsers. On Firefox, Safari, Chrome, and on phone, tablet, and desktop. Collect sign-off in writing (a Slack message counts), this matters later when a client says they didn't approve the copy.

Compliance and legal: industry-specific requirements

This is where most checklists fail hardest, especially for regulated industries.

SSL certificate is table stakes, every site needs HTTPS. But SSL alone doesn't solve compliance. A healthcare site needs HIPAA compliance (encrypted data at rest and in transit, audit logging, business associate agreements with any tool you use). An e-commerce site processing payments needs PCI compliance (never store card data, use Stripe Checkout instead of custom forms). A law firm needs client confidentiality (encrypted client portals, clear privacy policies about data retention). A nonprofit handling donations might have donor privacy and gift-aid tax obligations.

Check your industry's specific rules. WCAG 2.1 AA accessibility isn't just ethical, it's legally required in the UK for public websites, and many B2B buyers now audit for it in their vendor procurement. If your site handles any EU customer data, GDPR applies: you need a privacy policy that explains data collection, a legal basis for storage, and a way for users to request data deletion.

An easy win: add a footer privacy-policy link, a clearly-labeled contact email, and a "last updated" date on legal pages. If you're unsure, your business insurance broker or legal advisor can review your privacy policy and terms for under £200, which beats the cost of a complaint or a fine.

Managing launch timelines and stakeholder expectations

Launch delays happen. Common causes: client approval cycles (waiting for copy review takes longer than expected), integration bugs that only surface in production, or third-party API changes that break existing features. A realistic timeline buffer is 25 to 40% longer than your best-case estimate.

If you're working with an agency or freelancer, clarify the timeline upfront. Some build sites in a week; others take eight weeks. Budget ranges vary too. A DIY Wix site costs £0, £500 and takes 2 to 8 weeks (your time). A freelancer or small agency build (like Sitewright) typically costs £500, £3,000 setup and ships within 1 to 3 weeks. A larger agency build runs £5,000, £25,000+ and takes 6 to 12 weeks. E-commerce or SaaS builds can easily run £10,000, £50,000+. The more pages, integrations, and custom design, the longer and more expensive.

Setting realistic dates with clients

Tell stakeholders: the site is "ready" when testing passes, not when building finishes. Building takes 40% of the project time; testing, revisions, and rollout take 60%. If your agency says "we'll launch on the 15th," confirm whether that means "design is done" (which it doesn't) or "live for customers" (which does). Get that in writing.

Delays often come from change requests mid-build. Define a "freeze date", after that point, any new feature request gets quoted separately and pushes the launch back. Communicate this to your team or agency upfront; it saves friction later.

Launch day: the actual go live checklist

On launch day itself, follow this order:

  1. DNS cutover: If switching from an old site, update DNS records to point to your new host. Give DNS 15 to 30 minutes to propagate globally, but some users may see the old site for up to 24 hours. Have the old site online as a fallback.

  2. SSL verification: Visit your site and confirm the padlock icon appears. Open browser developer tools and check that no resources (images, stylesheets, scripts) are loading over insecure HTTP. One insecure resource will trigger a warning.

  3. Forms and integrations live: Send a test contact-form message to yourself and confirm it lands in your inbox. Process a test payment (use Stripe's test-card numbers) and confirm the receipt email arrives. Test email notifications for admin and customer.

  4. Indexing and search: Submit your sitemap to Google Search Console. This doesn't speed up indexing but confirms Google can see your site. Check Search Console for any crawl errors.

  5. Redirects working: If you migrated from an old site, test 10 random old URLs and confirm they redirect to the new ones. Use a tool like Redirect Checker (free online) to verify.

  6. Analytics tracking: Confirm Google Analytics 4 (or your chosen analytics tool) is recording page views. Visit your site and check that a session appears in GA4 within 30 seconds.

  7. Social preview: Share your homepage link on Slack or Twitter and check that the preview image, title, and description appear correctly. If they're wrong, your open-graph meta tags need tweaking.

Rollback strategy and disaster recovery

The moment you go live, you need a rollback plan. If something breaks critically after launch, can you revert to the old site in under 30 minutes?

If you control your domain DNS, the easiest rollback is to point DNS back to your old hosting. This takes 5 minutes but may take 15 to 30 minutes to propagate. If you don't control DNS, you can't rollback quickly, that's a risk to raise before launch.

Keep your old site running on its old hosting for at least 48 hours after the new launch. If critical bugs emerge (payment processing broken, contact forms not working), you can flip DNS back and fix the new site offline. After 48 hours of stable operation, you can decommission the old site.

Bigger teams use blue-green deployments: run two identical environments (blue and green) and switch traffic between them. That's complex and not worth it for small-business sites, but if you're launching a SaaS or e-commerce store, ask your development partner how they handle it.

Document your rollback steps in writing. Include:

  • Who has DNS access and their contact number
  • Which hosting provider holds your current live site
  • The URL of your staging/rollback environment
  • The exact DNS change needed to flip back (e.g., "change A record from 1.2.3.4 to 5.6.7.8")

Give a copy to your team and your developer. This is worthless if it's only in someone's email.

Post-launch: your first 30 days

Your website launch checklist doesn't end when the site goes live. The first 30 days are the most critical for catching bugs and understanding real user behaviour.

Monitor your error logs daily. Most hosting platforms (Vercel, Netlify, Cloudflare Pages) offer built-in error tracking. Check for 404s, 500s, or timeouts. A few are normal; hundreds suggest something's broken.

Run Lighthouse again on day one, day seven, and day 30. Sites often slow down after launch when real traffic hits and image CDNs need to cache new assets. If Lighthouse drops below 80, identify the culprit (usually images, third-party scripts, or analytics tags) and fix it.

Check your analytics for broken user journeys. If 50% of visitors land on your homepage but only 5% visit the next page, that's a sign your call-to-action is weak or confusing. If contact-form submissions drop off half-way through, a form field is probably broken (test it on mobile, many forms fail there).

A final note: almost all hosting platforms, including those used by Sitewright, Webflow, and Squarespace, offer a 30-day post-launch guarantee where critical bugs are fixed free. Use that window aggressively. After 30 days, fixes become paid work.

A solid website launch checklist is less about the number of items and more about testing the right things, knowing your industry's legal requirements, and building in rollback time before you go live, because a launch isn't success until it's stable.

Frequently asked questions

what should be on a website launch checklist

A website launch checklist covers four essential layers: technical readiness, compliance, stakeholder communication, and rollback plans. Each layer prevents different types of launch-day failures.

  • Technical readiness includes performance testing, database verification, and integration checks
  • Compliance covers SSL certificates, WCAG accessibility, and legal requirements
  • Communication ensures stakeholders know timelines and their sign-off responsibilities
  • Rollback plans let you revert quickly if critical issues appear post-launch
how do I test page speed before website launch

Test Core Web Vitals on your three busiest pages: homepage, most-linked page, and any conversion-focused page with forms or payments. Aim for Lighthouse scores of 90+, LCP under 2.5 seconds, and CLS under 0.1.

  • Use Google PageSpeed Insights or WebPageTest to measure real conditions
  • Test on mobile 4G networks, not just office Wi-Fi
  • Retest after each major change within 48 hours of launch
why do databases fail during website migration

Database failures during migration happen when record counts don't match between old and new platforms or when URLs change without proper redirects set up beforehand. Export, import, and verify before switching DNS.

  • Compare record counts between old database and new platform
  • Set up 301 redirects from old URLs to new ones for 12+ months
  • Test the import process three times in staging before going live
what integrations should I test before going live

Test every third-party integration your site depends on, including payment processors, email services, CRM syncing, and analytics tools, to ensure they work in production conditions. Run unhappy-path tests too.

  • Verify contact form submissions actually arrive in your inbox
  • Test payment flows end-to-end with test transactions
  • Confirm analytics pixels fire correctly and data appears in dashboards
  • Plan fallbacks if external services go down during launch
when should you stop building and start testing before launch

Stop adding new features at least one week before your launch date to allow time for thorough testing, verification, and stakeholder sign-off. Launching with incomplete testing is the leading cause of preventable disasters.

  • Freeze the codebase 7 days before launch at minimum
  • Use the final week only for testing, bug fixes, and verification
  • Never add features during the final 48 hours before going live
how do I set up a staging environment for website launch testing

A staging environment is an exact copy of your production site where you test all changes, integrations, and migrations before the actual launch without affecting live users. Staging prevents launch-day surprises.

  • Make staging identical to production in database, plugins, and configuration
  • Test password resets, payment flows, and email notifications in staging
  • Ensure staging is password-protected so it doesn't get indexed by search engines