Subscribe to interact — see the form below ↓
Checklist20 min read·May 28, 2026

Website Launch Checklist

47 points to verify before any website goes live — covering technical foundations, performance, SEO, design, content, accessibility, analytics, and post-launch essentials.

TK

Team Kairo

Strategy & Design

47

Checklist points

8

Audit categories

60 min

Avg audit time

Beginner

Difficulty level

A website launch is not a single moment — it is the culmination of dozens of decisions, each of which can quietly undermine everything else if left unchecked. This checklist is designed to catch every issue before it reaches a live audience. Run it on any website, any platform, any project size.

How to Use This Checklist

Work through these 47 points in order. The first two categories are hard blockers — do not launch with any of these unresolved. The remaining six categories are high-impact improvements: the site can go live, but each open item represents avoidable risk or left-behind performance.

Assign each item a status: Pass, Fail, or N/A. Anything marked Fail in Categories 1–2 must be resolved. For Categories 3–8, aim to resolve at least 80% before launch day. Items marked N/A are genuinely not applicable to your project — not items you are choosing to skip.

Before You Start

Run this checklist on the staging environment first, then again on the production environment immediately after go-live. Issues that appear only in production (cached assets, environment variables, DNS propagation) will not surface in staging.

Category 1 — Technical Foundations (Hard Blockers)

  • SSL certificate installed and active — all pages load over HTTPS with a padlock, no mixed-content warnings in the browser console
  • Domain pointing to the correct server — verify with a DNS lookup tool; www and non-www both resolve correctly or redirect cleanly to one canonical version
  • All pages return a 200 status code — scan the full site with a crawler; no 404s, no broken links, no redirect chains longer than one hop
  • robots.txt present and correctly configured — confirm it is not accidentally blocking pages you need indexed
  • XML sitemap generated and accessible at /sitemap.xml — will be submitted to Google Search Console immediately after launch
  • No sensitive data exposed — check that .env files, database credentials, admin routes, and staging URLs are not publicly accessible
  • All third-party API keys scoped to production domains — staging keys should not be active on the live environment

Category 2 — Forms and Critical Functionality (Hard Blockers)

  • Every form on the site tested end-to-end: submit, verify confirmation message, confirm data arrives in the destination (CRM, email inbox, database)
  • Contact and enquiry forms send a confirmation email to the submitter within 60 seconds — silent form submissions destroy trust
  • Payment flows (if applicable) tested with real card details in a test environment — confirm successful charge, refund, and decline handling
  • User authentication flows tested: sign up, log in, password reset, session expiry all function correctly
  • Search functionality returns accurate results — empty states handled gracefully with a useful message, not a blank page
  • Any interactive tools (calculators, configurators, quizzes) tested on mobile and desktop across Chrome, Safari, and Firefox

Category 3 — Performance

Performance is a conversion variable, not a technical afterthought. A one-second delay in page load reduces conversions by approximately 7% on desktop and up to 20% on mobile. Every point below directly impacts whether your audience stays or leaves.

  • Google Lighthouse score: 90+ on Performance for both desktop and mobile — run from an incognito window to exclude extensions
  • Largest Contentful Paint (LCP) under 2.5 seconds on a simulated 4G mobile connection — the single most important Core Web Vital
  • Cumulative Layout Shift (CLS) below 0.1 — check pages with images, embeds, and dynamically loaded content; layout jumps cost conversions
  • All images served in WebP or AVIF format with responsive srcset — PNG and unoptimised JPEGs are the most common source of performance issues
  • Hero images and above-the-fold images preloaded — use <link rel="preload"> for the primary visual on every key landing page
  • JavaScript bundle size under 200 kb gzipped — use the Coverage tab in Chrome DevTools to identify unused code loaded on every page
  • Font loading uses font-display: swap — prevents invisible text during load; verify fonts are subset to only the characters used
  • CDN active for static assets — hosting static files directly on a single-origin server without a CDN adds avoidable latency for every non-local visitor

Category 4 — SEO

  • Every page has a unique <title> tag between 50–60 characters that describes the page content clearly and includes the primary keyword
  • Every page has a unique meta description between 120–155 characters — written to earn the click, not just describe the page
  • Exactly one H1 tag per page — present on every page, unique to each, and aligned with the page title and primary keyword
  • Heading hierarchy logical throughout: H1 → H2 → H3 with no skipped levels or decorative headings out of sequence
  • OG tags (og:title, og:description, og:image) set on all pages likely to be shared — test with the Facebook Sharing Debugger or Twitter Card Validator
  • Canonical tags configured correctly — especially important if the site has pagination, filtered views, or duplicate content across www and non-www
  • All images have descriptive alt text — written to describe what is in the image, not keyword-stuffed, not empty on meaningful visuals
  • Google Search Console property verified with the correct domain variant — submit the sitemap immediately after go-live

SEO at Launch

SEO is a long-term compounding investment, but the decisions made at launch — canonicals, URL structure, heading hierarchy, sitemap — are the hardest to reverse without penalty. Get these right on day one; do not plan to fix them later.

Category 5 — Design and Content Review

  • Brand consistency: fonts, colours, icon styles, and spacing are consistent across every page — no leftover placeholder styles from the template
  • All placeholder content removed — no Lorem Ipsum, no "TBC" copy, no [CLIENT NAME] tokens, no sample images from the theme
  • All copy proofread by a second person — spellcheck misses homophone errors, missing words, and inconsistent capitalisation
  • All images are final, high-quality, and have correct licences — no watermarked stock images, no images sourced from a Google image search
  • Logo displays correctly at all viewport sizes — SVG format preferred; test on both light and dark backgrounds where the design uses both
  • Favicon visible in browser tab across Chrome, Safari, and Firefox — test at both 16×16 and 32×32 display sizes
  • Privacy policy, terms of service, and cookie policy pages exist, are current, and are linked from the footer
  • 404 page exists and is useful — it should offer navigation back to key areas of the site, not just display an error message

Category 6 — Accessibility

Accessibility is both a legal requirement in many jurisdictions and a significant usability improvement for all users. The items below cover the most common failure points — resolving them typically increases overall task completion rates, not just compliance scores.

  • Colour contrast meets WCAG AA minimum: 4.5:1 for body text, 3:1 for large text (18pt or 14pt bold) and UI components — test with a browser extension or Lighthouse
  • All interactive elements (buttons, links, form fields, navigation) operable by keyboard alone, in a logical tab order
  • Focus states visible on all interactive elements — do not suppress the default outline without providing an alternative that is equally visible
  • All form fields have associated <label> elements — placeholder text alone is not a label; it disappears on focus and is invisible to many screen readers
  • Images with meaningful content have descriptive alt text; decorative images have empty alt="" so screen readers skip them
  • No content depends solely on colour to convey meaning — icons, patterns, or text should accompany any colour-coded information
  • Video content has captions or a written transcript available

Category 7 — Analytics and Tracking

  • Analytics installed and verified — confirm it is firing on all pages by watching the Realtime report while navigating the live site
  • Conversion events configured: contact form submissions, purchases, sign-ups, and any other high-value actions tracked as Goal Completions or Events
  • Session recording tool (Hotjar, FullStory, or equivalent) installed on key conversion pages — recording begins on launch day
  • Cookie consent mechanism deployed — analytics and marketing scripts should not fire until consent is given; verify this actually works by checking the Network tab before accepting cookies
  • Google Search Console property verified and sitemap submitted within the first hour of launch
  • UTM parameters tested for all planned launch campaigns — confirm that source, medium, and campaign values appear correctly in the analytics dashboard

Category 8 — Cross-Device and Cross-Browser QA

  • Tested on real iOS Safari — not emulated. Safari on iPhone handles flex, grid, and certain CSS properties differently to Chrome; emulators will not catch these differences
  • Tested on Android Chrome on a mid-range device — flagship phones hide performance issues that real users experience on slower hardware
  • Tested at 375px, 768px, 1280px, and 1440px viewport widths — check for layout breaks at each breakpoint, not just the extremes
  • Navigation tested on touch: mobile menu opens and closes correctly, dropdowns accessible via tap, no hover-only interactions
  • All animations and transitions tested with the Reduce Motion preference enabled in OS accessibility settings — motion-sensitive users should have a usable experience
  • Footer links all resolve: privacy policy, terms, and any external links open correctly
  • Printed layout checked if the site has content users may reasonably want to print (articles, guides, receipts)

Issues caught vs ad-hoc QA

Before

Ad hoc

After

This checklist

+2.1× more

Post-launch critical fixes

Before

Without audit

After

With audit

−87%

Time to complete audit

Before

Ad hoc (avg)

After

Structured

−3 hrs

Mobile Lighthouse score (typical)

Before

64

After

93

+45%

Post-Launch: The First 48 Hours

Going live is not the end of the launch — it is the beginning. The 48 hours after go-live are the highest-risk window: DNS propagation can expose configuration issues, real traffic can surface edge cases that staging missed, and crawlers begin indexing immediately. Stay close to the following.

  • Monitor your analytics Realtime view for the first two hours — a flat line when traffic is expected means tracking is broken, not that no one arrived
  • Check your server error logs for any 5xx errors — these indicate server-side failures that staging likely never triggered
  • Submit the sitemap to Google Search Console and request indexing for your highest-priority pages
  • Test all forms again from a different device and network — production email deliverability can differ from staging
  • Share the live URL with a small group before wider announcement — fresh eyes catch things the build team has become blind to

We used to treat the launch checklist as optional — something to do if we had time. After two incidents where broken forms cost us leads on day one, it became non-negotiable. We run it on every project, every time, without exception.

Project Lead, Digital Agency

Launch Readiness

If every item in Categories 1 and 2 passes, and at least 80% of items in Categories 3–8 pass, the site is ready to launch. Below that threshold, consider a soft launch to a limited audience — it is significantly easier to fix issues with 200 visitors than with 20,000.

TK

Team Kairo

Strategy & Design · Kairo Creations

Every article on KairoHub is written from first-hand project experience — strategies, frameworks, and data we've applied across 60+ client engagements.

3 comments
Share:

Discussion3

R
Rohan Verma30 May 2026

The 'test forms again from a different device in production' point saved us once already. Our staging environment used a test SMTP server that accepted everything — the production environment had stricter SPF records and confirmation emails were going to spam. Caught it on launch day before the announcement went out.

L
Lena Hoffmann2 Jun 2026

The robots.txt point is underrated. I've seen a site go live with Disallow: / in the robots.txt — a copy-paste from the staging config. Six weeks before anyone noticed why organic traffic wasn't building. First item I check on every handoff now.

J
Jake Sutton6 Jun 2026

The cookie consent verification step — checking the Network tab before accepting cookies — is something almost nobody actually does. Most teams assume the consent banner works. In my experience, about one in four has a misconfiguration where analytics fires regardless of consent choice.

Leave a comment

Subscribe to our newsletter below to post a comment.