The Website Launch Checklist: What to Verify Before You Go Live

A client once asked us to push a redesigned site live on a Friday afternoon because the CEO wanted to announce it at a Monday conference. We ran through the checklist we use for every launch and found three things in twenty minutes: the contact form was still pointing to a developer's test inbox, the robots.txt file from the staging server had come along for the ride and was blocking the entire site from search engines, and the old blog URLs (which had years of backlinks and rankings) had no redirects set up. None of that would have shown up in a quick click-through of the homepage. All of it would have quietly cost the client leads, traffic, and rankings starting the moment the site went live.

This is the pattern with website launches: the things that break are rarely the things you'd notice by browsing the site casually. They're the things nobody checks unless there's a checklist forcing them to. Below is the one we actually use, organized by category, written so you can work through it item by item rather than trying to remember everything at once.

Technical and functional checks

Start here, because a broken function is the most visible kind of failure: visitors hit it immediately, and it undermines trust in everything else on the site.

• Every link on every page works: no dead internal links, no broken anchor links, no links pointing to staging or localhost URLs left over from development
• Every form submits successfully and the submission actually arrives where it's supposed to (test with a real submission, not just a visual check of the form)
• Autoresponder or confirmation emails triggered by forms are sending correctly and not landing in spam
• A custom 404 page exists, is styled to match the site, and offers a way back (search box, links to key pages, navigation) rather than a bare server error
• Favicon is set and displays correctly in browser tabs and bookmarks
• SSL certificate is active, valid, and the site loads on https:// without browser warnings (check this on the actual live domain, not just the staging environment)
• HTTP automatically redirects to HTTPS, and www/non-www versions resolve to a single consistent version rather than both working as separate URLs
• Mobile responsiveness checked on real devices, not just by resizing a desktop browser window: a browser resize doesn't reveal touch target sizing, real mobile keyboard behavior, or how forms render on an actual phone
• Site tested in the browsers your actual audience uses, not just the one your team develops in
• Contact details, phone numbers, and addresses on the site are current and correct
• Cross-browser and cross-device testing includes tablets if your traffic data shows meaningful tablet usage

The security side of a launch deserves its own attention beyond what fits here, things like backup schedules, firewall rules, and the specific attack vectors that target freshly launched sites. We cover that in more depth in our guide to website security essentials; treat the items above as the minimum launch-day subset of a fuller security setup, not the whole picture.

SEO basics

SEO mistakes at launch are some of the most expensive to fix after the fact, because search engines have already indexed, or failed to index, whatever version of the site they found first.

• Every page has a unique, descriptive meta title and meta description: no pages left with default CMS placeholders or duplicated titles across the site
• XML sitemap is generated, accurate, and submitted to Google Search Console (and Bing Webmaster Tools, if that traffic matters to you)
• robots.txt is configured correctly and does not block the site. This is one of the most common and most costly launch mistakes there is: a "Disallow: /" line left over from the staging environment silently tells search engines not to crawl anything, and a site can sit invisible to Google for weeks before anyone notices traffic isn't coming in. Check this file directly on the live domain before and after launch.
• No stray "noindex" meta tags left on pages that should be indexed: these often get added during development to keep staging pages out of search results and forgotten when the site goes live
• If this is a redesign or migration, 301 redirects are set up from every old URL that had traffic, rankings, or backlinks to its new equivalent: a mapped list of old-to-new URLs, not just a blanket redirect to the homepage
• Canonical tags are set correctly, especially if there's any risk of duplicate content (parameterized URLs, filtered category pages, etc.)
• Structured data (schema markup), where used, validates without errors
• Analytics and conversion tracking are installed and verified working before launch, not checked for the first time after: send a real test form submission or test purchase and confirm it shows up in your analytics and ad platforms before you consider the site live. Tracking gaps discovered after launch mean permanently lost data for that period; there's no way to retroactively capture it.

Legal and compliance

These items are easy to deprioritize under launch pressure, but they carry real legal and reputational risk, especially for sites serving European visitors.

• Privacy policy is live, accurate, and reflects what the site actually does with visitor data, not a generic template that references tools or data practices the site doesn't use
• Cookie consent banner is functioning correctly: it blocks non-essential cookies and tracking scripts until consent is given, not just displaying a banner while everything loads regardless
• Terms of service are live if the site involves transactions, user accounts, or user-generated content
• Basic accessibility checks are done: sufficient color contrast, keyboard navigation works for interactive elements, form fields have proper labels, and images have appropriate alt text (more on that below)
• If the business operates in a regulated industry, any required disclosures or licensing information are present and current

Content quality

Content problems are the ones most likely to be caught by an actual visitor, which makes them particularly damaging to credibility even when they're minor.

• A dedicated proofreading pass across every page, not just the pages the team looks at most, since it's often the "boring" pages like the footer, legal pages, and older blog posts where typos survive unnoticed
• All placeholder and lorem ipsum text is fully removed: check less-visited pages, form confirmation messages, and error states, which are the most common places placeholder copy gets left behind
• Every image has real, descriptive alt text, not left blank and not just the raw filename (like "IMG_4821.jpg"). Blank or filename-based alt text fails both accessibility and SEO at once, since it gives screen reader users nothing useful and gives search engines no signal about the image content.
• Headings are used in logical order (H1, then H2s, then H3s within them) rather than styled visually but structured incorrectly underneath
• Any pricing, dates, or availability information on the site is current as of launch day
• Author names, dates, and bylines on blog content are correct and not left as placeholder values

Performance

A slow site undermines everything else you've fixed on this list: visitors bounce before they ever see the polished content or working forms.

• Page speed tested on both desktop and mobile using a tool like Google PageSpeed Insights or GTmetrix, on the live domain rather than staging
• Images are properly compressed and served in modern formats (WebP where supported) rather than uploaded at full camera or design-file resolution
• Unused scripts, plugins, or tracking tags from development are removed rather than carried into production
• Caching and a CDN are configured where appropriate for the site's traffic and audience geography
• Core Web Vitals (loading, interactivity, visual stability) are within acceptable ranges, since these affect both user experience and search ranking

Pre-launch and the first 48 hours

The checklist above reduces risk, but it doesn't eliminate it. No amount of pre-launch QA catches everything, because real-world traffic behaves differently than test traffic. A few practices make the actual go-live moment safer:

• Where practical, use a soft launch or staged rollout: point a small percentage of traffic or a specific audience segment to the new site first, rather than switching everyone over simultaneously
• Have a rollback plan defined and tested before launch: know exactly how you'd revert DNS or restore the previous version if something critical breaks, and know who is responsible for making that call
• Monitor closely for the first 24–48 hours: watch server error rates, form submission volume, analytics traffic patterns, and any monitoring or uptime alerts rather than assuming silence means success
• Keep the person or team who built the site reachable during this window: problems found on hour three of a launch are far cheaper to fix than problems found a week later once traffic and search engines have already reacted to a broken state
• Do a final live-site pass after DNS has fully propagated, since some issues (mixed content warnings, cached old versions, redirect loops) only appear once the domain is actually pointing at the new site

Most of these items take minutes to check individually. What makes launches go wrong isn't that any single check is hard. It's that under deadline pressure, teams skip the checklist entirely and trust that things look fine. They usually do look fine. The problems on this list are, almost by definition, the ones that don't.

If you're preparing to launch or relaunch a site and want an outside team to run this process end to end, our custom web design service includes exactly this kind of pre-launch verification as a standard part of the build. Feel free to get in touch if you'd like a second set of eyes before you go live.