Website Launch Checklist: The 27-Point QA Pass to Run Before You Go Live

Picture a business owner who launches their new site on a Friday afternoon. The design is sharp. The copy is polished. Everyone's excited. By Monday morning, the calls start: Google Analytics isn't firing, the contact form has been swallowing every submission without a trace, and every old URL is returning a 404. The site looks exactly right. Almost nothing actually works. A proper website launch checklist is the difference between a site that performs from day one and one that quietly fails while looking great.

This post walks through every critical step, in order, including the exact Sproutbox 27-Point Pre-Launch QA Pass our web team runs before any site goes live. It covers content, technical SEO, performance, cross-browser testing, conversion tracking, and everything that needs to happen in the first 30 days after launch. If you run this checklist top to bottom, the most common silent failure modes — broken forms, missing analytics, crawl blocks left over from staging — don't make it to your visitors.

Most website launch failures aren't dramatic. There's no error screen, no alarm, no obvious sign that anything went wrong. That's exactly what makes them expensive. The goal of a website go-live checklist isn't just to catch bugs. It's to make sure the site you spent months building actually works the way it's supposed to, from the first session to the first lead.

Step 1: Audit Your Content and Copy Before Anything Else

This step gets skipped because it feels obvious. Which is exactly why it bites people. Before you touch a single technical setting, every visible element on the site needs a human eye on it, not a preview window on staging, but a real pass through the live-ready build.

Title Tags and Meta Descriptions

• Unique, descriptive title tags on every page. No 'Home | Home' duplicates. Every page title should reflect what that specific page is about.
• Meta descriptions under 160 characters, with the page's target keyword. These show up in search results. Write them like ad copy, not afterthoughts.

Placeholder Text and Image Alt Text

• Zero placeholder text. 'Lorem ipsum,' 'TBD,' and 'DRAFT' have no business being on a live site. Check every page, every section, every modal.
• Descriptive alt text on every image. Both for accessibility and for search engines that can't see images the way humans do.

CTAs and Legal Pages

• A CTA audit on every key page. Are the calls-to-action present? Do they point to the right destination? A CTA that links to a 404 is worse than no CTA at all.
• Legal pages live and linked in the footer. Privacy policy, terms of service, cookie notice if your site collects data. These aren't optional.

Step 2: Lock Down Your Technical SEO Foundation

This is the step most business owners hand to their developer and assume is handled. Sometimes it is. Often, it isn't, because staging environments have different settings than production, and flipping a site live without a technical walkthrough is how critical configuration errors survive into launch day. If you want a deeper look at how technical SEO decisions made at the build stage affect long-term rankings, our Portland SEO team covers that work in detail.

SSL and HTTPS Verification

The SSL certificate must be active before you flip the DNS switch. The URL should show https://, not http://. If your browser shows a 'Not Secure' warning, your visitors will leave before they read a single word. This is non-negotiable for both user trust and search ranking.

Robots.txt and Crawlability

The robots.txt file blocking search engines is the single most common staging-to-live error we see. Developers set robots.txt to block crawlers on staging so Google doesn't index half-built pages, then forget to flip it before launch. One missed setting, and you've cost yourself weeks of indexing time. We've audited sites that were live for three weeks with crawlers completely blocked. The owners had no idea why their pages weren't appearing in Google. Check it before you launch. Then check it again.

XML Sitemap and Redirect Mapping

• An XML sitemap exists and is accessible at /sitemap.xml. Confirm it loads and lists your actual pages, not staging URLs.
• 301 redirects are mapped for every old URL. If this is a redesign, every old page needs to forward to its new equivalent. Not to the homepage. Not to a 404. To the right page.

Canonical Tags and Schema Markup

• Canonical tags are set correctly. No duplicate content between www and non-www versions of your domain. Pick one and canonicalize everything to it.
• Schema markup is present on key pages. LocalBusiness, Service, and FAQ schema all help search engines understand who you are and what you do. They're not glamorous, but they matter for both traditional search and AI-generated answers.

Step 3: Website Testing Before Launch — Performance and Cross-Browser

Speed and cross-browser compatibility are where sites that look perfect in one environment quietly fall apart in another. Run every test before launch, not after.

Google PageSpeed Insights Targets

Run the site through Google PageSpeed Insights before launch and aim for a mobile score above 70 and a desktop score above 85. The most common culprits pulling scores down are uncompressed images, render-blocking scripts, and unoptimized fonts. Fix these first. They have the biggest impact and the clearest solutions.

Mobile Responsiveness Testing

View every page on an actual phone. Not a browser emulator. An actual device in your hand. Check that forms are tappable without zooming, nav menus open and close correctly, and no content is clipped or overflowing at the edges. Mobile responsiveness isn't just about the layout shrinking down. It's about whether the experience actually works for a human thumb.

Cross-Browser Testing

Cross-browser testing means Chrome, Safari, Firefox, and Edge at minimum. Safari on iOS trips up more sites than any other browser, especially with CSS animations and video autoplay. Use BrowserStack or a real Apple device for this. DevTools in Chrome does not accurately replicate Safari behavior, and that gap has burned more than a few launches.

Core Web Vitals and Console Errors

• Images compressed and served in WebP where supported.
• Fonts optimized, no excessive render-blocking resources.
• No console errors on any page.
• Video files are not self-hosted on the server.

Step 4: Verify All Tracking, Forms, and Conversion Paths

This is the step where launches fail silently. The site looks fine. Traffic is coming in. But you have no data, no leads, and no idea why. These errors are the most costly precisely because there's no alarm. Nothing breaks visibly.

Google Analytics 4 and Search Console

• GA4 is installed and firing. Open the site in a browser, then check GA4 Realtime. A session should appear within 30 seconds. If it doesn't, something is wrong with the installation.
• Google Search Console is connected to the live domain, not the staging domain. Submit the XML sitemap from within GSC so Google knows where to start crawling.

Form Testing

Every form has been tested end-to-end. Fill it out. Submit it. Confirm the notification email arrives at the right address, with the right content. Do this for every form on the site: contact, quote request, newsletter signup, all of them. What we've learned after building hundreds of sites is that tracking errors are almost always discovered too late. A client comes to us two weeks post-launch asking why leads have been quiet. We check the form. It's been erroring silently since day one. A ten-minute verification pass before launch would have caught it.

Conversion Events and Ad Pixels

• Conversion events are triggering correctly. If you have a 'Thank You' page or event-based conversion set up, verify it fires in GA4 or your ads platform before the site goes live.
• Ad pixels are installed and verified. Meta Pixel, Google Ads tag — use the relevant browser extension (Meta Pixel Helper, Google Tag Assistant) to confirm they're firing on the right pages.
• Email notifications are routing to the correct inbox. This sounds obvious. It gets missed constantly.

Step 5: The Sproutbox 27-Point Pre-Launch QA Pass

The Sproutbox 27-Point Pre-Launch QA Pass covers seven content checks, six technical items, five performance benchmarks, and four tracking verifications. Running all 27 in order, before DNS flips, eliminates the most common silent failure modes: broken forms, missing analytics, and crawl blocks left over from staging. This is the internal checklist our Portland web design and development team runs on every site before handing it to a client.

Content Checks (7 Items)

1. Unique title tags on every page
2. Meta descriptions on every page, under 160 characters
3. No placeholder text anywhere on the site
4. All images have descriptive alt text
5. All CTAs point to correct URLs
6. Legal pages are live and linked in the footer
7. 404 page is custom-designed and on-brand

Technical Checks (8 Items)

1. SSL certificate active, site loading on https://
2. robots.txt confirmed allowing search engine crawlers
3. XML sitemap accessible at /sitemap.xml and submitted to Google Search Console
4. 301 redirects mapped for all legacy URLs
5. Canonical tags set correctly, www vs. non-www resolved
6. No broken internal links (full crawl completed)
7. Schema markup present on key pages
8. DNS propagation confirmed on primary domain and any subdomains

Performance Checks (6 Items)

1. Mobile PageSpeed score at or above 70
2. Desktop PageSpeed score at or above 85
3. Images compressed and served in WebP where supported
4. Fonts optimized, no excessive render-blocking
5. No console errors on any page
6. Video files are not self-hosted on the server

Tracking and Conversion Checks (4 Items — Do Not Launch If Any Are Unchecked)

1. GA4 firing and confirmed in Realtime
2. Google Search Console connected to live domain
3. All forms tested end-to-end, notifications routing correctly
4. Conversion events verified in GA4 or ads platform, ad pixels confirmed via browser extension

If even one item in the Tracking and Conversion group is unchecked, do not launch. The rest of the site can be perfect, and those four items can make the entire launch effectively invisible. A CMS walkthrough is also recorded and delivered for client handoff so your team can make content updates without calling us.

Step 6: Your Go-Live Day and First 30-Day Plan

Most website launch checklists end at go-live. This one doesn't, because the first 30 days are when you actually learn whether the site works, not just whether it loads.

Launch Day Best Practices

Don't launch on a Friday afternoon. We know this sounds simple, but it's the scenario from the opening of this post, and it happens constantly. Launch mid-week when your team is available to catch issues within hours, not days. Immediately after DNS propagates, run a full crawl with Screaming Frog or Ahrefs to catch redirect errors or missing pages before Google does.

First 7 Days After Launch

• Check GA4 daily. You're looking for traffic anomalies, 404 spikes, and unexpected form drop-offs.
• Check the Coverage report in Google Search Console three to four days after launch for any crawl errors that surfaced during initial indexing.
• Set up a GSC email alert for any spike in 404 errors. It takes two minutes and has saved us from more than a few quiet disasters on sites we've supported post-launch.

First 30 Days: Core Web Vitals and User Behavior

• Monitor Core Web Vitals in GSC. Watch for ranking shifts on your key pages, especially if this is a redesign. Some volatility is normal, but a sharp drop on a previously strong page needs attention.
• Run a heatmap tool like Hotjar or Microsoft Clarity to see where real users are clicking, scrolling, and dropping off. What you see will surprise you.
• Watch AI referral traffic in GA4 as a secondary signal. If your content is well-structured and schema is in place, you may start seeing sessions from generative search tools. Our GEO team can help you build on that visibility intentionally.

Protecting Your Forms Post-Launch

Before or immediately after launch, make sure your forms are protected against spam submissions. Setting up Google reCAPTCHA is a five-minute task that prevents your lead data from being contaminated by bots from day one.

Frequently Asked Questions

How long does it take to go through a website launch checklist?

For a small business site under 15 pages, a thorough pre-launch QA pass takes 3 to 5 hours when done carefully. For larger sites with complex 301 redirects or custom functionality, budget a full day. Rushing this process is the single most common reason sites go live with broken tracking or missing redirects, and those problems rarely announce themselves right away. The Sproutbox 27-Point Pre-Launch QA Pass is designed to make that time structured and repeatable, not improvised under deadline pressure.

What happens if I skip the pre-launch checklist and launch anyway?

The most common outcomes are invisible. GA4 isn't set up so you have no traffic data. Forms error silently so leads disappear without a trace. Old URLs return 404s so any SEO equity from your previous site evaporates. Most of these issues are fixable, but they cost time, rankings, and in some cases real revenue while you're tracking them down. A pre-launch website checklist exists specifically to make these problems impossible to miss before they reach your visitors.

What should I check after a website launch?

In the first seven days, check GA4 daily for anomalies and review the GSC Coverage report for crawl errors three to four days post-launch. In the first 30 days, monitor Core Web Vitals in Google Search Console, run heatmaps with Hotjar or Microsoft Clarity to understand real user behavior, and set up a GSC email alert for 404 spikes. If rankings shift sharply on previously strong pages, investigate immediately. Some volatility after a redesign is normal; a sustained drop is a signal.

How do I know if my website is indexed by Google after launch?

Connect your live domain to Google Search Console and submit your XML sitemap from within the GSC interface. You can then check the Coverage report and use the URL Inspection tool to see whether individual pages have been crawled and indexed. For a brand new domain, initial indexing can take anywhere from a few days to a few weeks. The most important thing to confirm first is that your robots.txt file is not blocking crawlers, since that is the most common reason pages fail to appear in Google after a site goes live.

A Checklist Doesn't Replace a Team Who's Done This Before

A website launch checklist works when someone actually runs it, line by line, on a real device, with real data flowing through real forms. Most launches fail not because the site is bad but because the last 10% of QA gets skipped under deadline pressure. Without a dedicated QA owner, the most important items are the first to fall through the cracks.

The Sproutbox 27-Point Pre-Launch QA Pass exists because we've seen too many great-looking sites go live broken. If you're planning a redesign or building something new, we're happy to talk through what a launch-ready process looks like for your business. We build sites that are fast, clear, and designed to get people to take action from the moment they land.