Website launch checklist: every item to verify before you flip the switch

1. Content and copy

Read the staging site in a browser before launch. Tools won't catch wrong phone numbers, placeholders, or irrelevant service cities. Code editors and mockups aren't substitutes for checking the actual pages.

Verify business name, phone, address, and email everywhere, checking each location/area separately. Copied old/template details may be wrong. Tap every phone number on a phone and verify the dialed number; untappable service numbers lose leads immediately.

Find Lorem ipsum, unnamed testimonials, placeholder images/alt text, especially after late content additions. Remove unintended draft/test pages too; Google can expose them to customers.

Use concise descriptive alt text for screen readers and Google's image/context indexing. Avoid keyword stuffing, meaningful blanks, and redundant "image of." Mark purely decorative images to be skipped.

Data from forms, analytics, or cookies needs privacy policies; payments need terms/refund policies. Most jurisdictions require these, and Google/Meta require them for ads.

2. Technical: SSL, links, and cross-browser testing

The technical checklist covers everything determining whether your site works correctly for every visitor on every platform. Most checks take five minutes each; skip them and you discover problems after visitors have arrived.

SSL. Verify HTTPS/padlocks on home, interiors, contact, and input pages. HTTP images/fonts/scripts/styles on HTTPS pages trigger warnings or blocking. Check mixed content with WhyNoPadlock (opens in new tab).

Check links sitewide. Missing pages, mistyped slugs, or moved assets strand visitors/crawlers. External failures also matter. Screaming Frog SEO Spider (free through 500 URLs) or Ahrefs Site Audit finds both.

Custom 404. Missing URLs are inevitable. Replace blank "404 Not Found" dead ends with branded explanations and links to home/popular pages, helping visitors recover.

Test browsers/devices. Cover current Chrome, Firefox, Safari, especially iOS's differing CSS and substantial iPhone traffic. Use actual iOS/Android hardware or BrowserStack real-device environments; emulation misses rendering edge cases.

Allow search engines. Staging commonly blocks Google. Ensure migration removes that instruction from production; one leftover can exclude the entire live site.

Favicon. That's the tiny logo that shows up in the browser tab. Small detail, but visitors notice when it's missing. It should be a square image (minimum 32×32 pixels, ideally 512×512) and properly hooked up so browsers know to display it.

3. SEO: what to get right before Google looks at your site

Google's first visit establishes traction signals. Duplicate headlines, missing sitemaps, or wrong-address signals aren't permanently damaging, but correcting remembered errors after launch creates avoidable work.

Unique search titles/summaries. Each blue-link headline should describe its page, not repeat "Home | Business Name." Write 140–160-character summaries like ads: they affect clicks heavily, not ranking directly.

Sitemap. List all desired search pages, excluding tests, thank-you confirmations, and duplicates. Submit to Google Search Console after launch for immediate processing rather than awaiting discovery.

Prevent duplicates. www, trailing-slash, and HTTPS variants can split ranking strength. Declare each page's authoritative address and redirect alternatives there. The declaration backs up forwarding; it doesn't replace it.

Business labels can earn stars, hours, and FAQ search extras. Label name/address/phone/hours on home or every page; mark services and FAQs appropriately. Validate through Google's free Rich Results Test before launch.

Social previews. Set every page's headline, description, and 1200×630 image for Facebook, LinkedIn, iMessage, Slack, and others. Otherwise platforms guess, often showing blanks or stray text.

Redirect redesign URLs. Every changed address must forward to its equivalent by launch, preserving backlinks, bookmarks, social shares, and directory trust. Dead ends lose authority and frustrate visitors. SEO setup →

4. Forms and functionality

A contact form that doesn't send is arguably worse than no contact form. Visitors fill it out and assume you'll respond, then wonder why you don't. Meanwhile you have no idea the submissions aren't arriving. This category needs end-to-end testing under production conditions, not just a quick tap in the browser.

Submit using another address, preferably personal Gmail. Verify correct business inbox delivery, no spam filtering, and received auto-reply. Check reply appearance, business/contact details, and inbox placement on the receiving end.

Blank required fields must reject submission. Verify honeypot/CAPTCHA protection. Newly indexed forms attract spam within days; database flooding or mail-service limits create operational problems beyond inbox annoyance.

Test bookings, payments, scheduling, and intake end to end: click Book Now, complete, confirm email/dashboard/calendar. Run payment sandbox transactions before live mode. Independently verify production credentials, webhooks, and API keys; staging success isn't sufficient.

Mailtrap-style staging sandboxes intercept outgoing messages. Live failures often mean production email still points to the test catch-all. Verify live delivery-account configuration when staging worked but production doesn't.

5. Speed and Google's page-health checks

Performance is worth checking before launch rather than after. A slow site doesn't fail visibly. It quietly drives higher bounce rates and lower conversion rates, and the fixes (image compression, script deferral, server tuning) are significantly easier to make before visitors are hitting the page.

Run Google PageSpeed Insights at pagespeed.web.dev on both devices. Google ranks mobile: 95 desktop/42 mobile isn't acceptable. Target 90+ desktop and 75+ mobile before launch.

Google's three ranking checks target main content under 2.5 seconds, tap/click response under a fifth of a second, and stable layouts avoiding mistaps. Failing any disadvantages you against passing competitors.

Common fixes: compress/modernize images without visible loss and reserve dimensions; defer blocking chat/tracking widgets; address cheap-host response delays. Other polishing cannot fully offset a server slow to start.

For a full guide to what moves the needle on speed and in what order: How to speed up your website →. For a plain-English breakdown of Google's page-health checks and why website-builder platforms often struggle to pass them: Google's page-health checks explained →

6. Security and privacy

Security isn't just about keeping bad actors out. It's also about protecting your visitors' data and your site's availability. A few baseline checks before launch significantly reduce your exposure.

Configure SSL. Cover www/non-www, redirect all visitors to one preferred HTTPS address, and verify expiry/automatic renewal. Hosts commonly use Let's Encrypt, but test renewal: expired certificates cause browser-blocked outages.

Security headers prevent file-type misreading, deceptive embedding, and excessive outgoing referral information. Developers configure them; verify post-launch at securityheaders.com (opens in new tab).

Protect internal files. Passwords, keys, and business logic must resist direct browser access. Have the developer verify error/not-found responses instead of exposed source.

Privacy/cookies. Most jurisdictions require personal-data disclosure, including forms/analytics; GDPR, CCPA, and growing US state laws specify rules. Provide privacy policies and nonessential-cookie consent. Google/Meta also require compliant policies for ads; omissions block future marketing.

7. Analytics and search console

Install analytics before traffic arrives to establish day-one baselines. Later setup permanently loses launch-period data, often a new site's busiest window as announcements draw attention.

Google Search Console. Before launch, verify through a registrar DNS TXT record, the most reliable method. Submit sitemap afterward. Monitor indexed pages, queries, errors, and visitor-based health checks at least weekly during month one.

Verify tracking. Google Analytics, Plausible, or Fathom real-time reports should show your session and each page visit before announcement. Missing events often reveal omitted template snippets or failed header includes.

Exclude your traffic. Google Analytics 4 Admin supports IP filters; changing IPs/multiple locations may suit Block Yourself from Analytics. Early low-traffic periods are particularly distorted by owner review visits.

Monitor 404s. Search Console Coverage misses 404s outside sitemaps. Configure analytics custom events or error-page reports to identify missing old redirects and broken internal links.

8. Post-launch: the first two weeks

Launch day isn't the finish line. It's when the real-world test begins. The first two weeks are the highest-density period for discovering issues because live traffic creates conditions that testing environments don't replicate: production email servers, actual DNS propagation, mobile devices on cellular networks, and users navigating in unexpected ways.

Announce launch through email, relevant social channels, and personal contacts whose opinions matter. Real-user analytics/Search Console data informs Google engagement understanding; two weeks without traffic supplies no signal.

Check Search Console daily in week one. Review Coverage errors/indexing, visitor-based speed/stability health, and indexed Pages. Previously indexed pages missing after a week warrant checking redirects or Coverage explanations for removal.

Review forms daily during week one. Real traffic exposes unexpected character-set failures, spam waves, and notification filtering missed by single tests. Catch these before they persist for months.

Test actual phones. Submit forms, tap every number, and scroll long pages. Physical devices reveal small touch targets, fonts differing from emulation, and tiny-screen layout breaks outside your test matrix.

Check logs daily in week one. cPanel, Plesk, or CLI access reveals PHP, 500-level, and exception failures under real traffic. One-in-50 errors evade manual tests; prioritize silently lost forms/API calls.

9. Launch day: the exact sequence

The next section sequences launch-day domain cutover, specifying each check before proceeding. Launch requires ordered deployment, beyond merely repointing the domain.

1. Point your domain at the new site

   Record the old server address for rollback within the next two hours, then repoint the domain. At least 24 hours beforehand, lower lookup timing from an hour-plus to minutes, preventing visitors lingering on the old site for an hour.

2. Confirm the secure padlock is working on the live site

   Before announcements, check the public domain's padlock and correct certificate. Automatic issuance commonly completes only after domain propagation; premature setup is the common launch failure. Don't test only the private URL.

3. Test the contact form from your phone

   Use an actual phone on cellular, not WiFi, with an infrequently monitored email. Test production mail/mobile layout; verify business-inbox delivery and submitter auto-reply before proceeding.

4. Submit the sitemap to Search Console

   After domain propagation, submit the sitemap in Search Console; earlier requests may fetch the old server and fail. Then request indexing via URL Inspection for five priorities: home, main service, contact, and two other target pages.

5. Verify analytics is live

   Browse pages while watching analytics real-time sessions/page counts. Missing increments expose tracking gaps now, before a week's launch traffic goes unmeasured.

6. Spot-check redirects

   Open ten to fifteen important old URLs directly. Each should reach its proper replacement in one hop, avoiding dead ends. Chains cost authority and visitor time; straighten them now.

7. Announce

   Only after the above steps are confirmed. Send the email, post on social, message the contacts. Now you're driving traffic to a verified environment, not a gamble.

Key takeaways

• Read every page before launch. Placeholder text, wrong phone numbers, and missing legal pages require human review, no tool catches them automatically. Block time to read the site as a visitor would.
• The secure padlock is non-negotiable. Every page should load securely, with nothing on the page sneaking in over an insecure connection. Use a free padlock checker to catch any insecure pieces before visitors see the browser warnings they trigger.
• Get SEO right before Google first looks at your site. A unique clickable headline on every page, a valid page list submitted to Search Console, a clear signal of which web address is the authoritative one, behind-the-scenes labels tested against Google's Rich Results Test, and (for redesigns) old web addresses forwarding to their new equivalents. These are pre-launch tasks, not post-launch cleanups.
• Test forms end-to-end under production conditions. Use a different email address. Verify delivery, auto-reply, and spam filter behavior on both ends. Staging email sandboxes and production mail configs are different, and they break in different ways.
• Run PageSpeed Insights on mobile before launch. Your mobile score is what matters for Google's ranking. An unoptimized site can be addressed before launch; it's harder after you've already announced and driven traffic to it.
• Verify analytics before you drive any traffic. Open the real-time report and navigate through the site. If a page doesn't register, find out why before you start measuring your launch results against broken data.
• Plan to be available on launch day. Launch during business hours mid-week. Have server access, your host's support contact, and two to three hours blocked to monitor before you step away.

Related guides

• SEO setup for new websites: what's included and why it matters at launch
• Google's page-health checks explained: what they measure and how to pass them
• How to speed up your website: every lever, in order of impact
• Website maintenance: what needs attention after launch and how often

Common questions

See all FAQs →