The 15-Point Checklist Before Your Business Website Goes Live

What gets missed and why

The website is designed, developed, approved, and ready to go live. The client is excited. The agency wants to ship. And in the rush to launch, a list of critical infrastructure elements gets skipped, not because anyone was lazy, but because no one’s checklist included them.

These aren’t design problems. They’re operational gaps that silently cost the business traffic, trust, and conversions for weeks or months until someone accidentally discovers them. The site “works”. it loads, the pages are there, the contact form submits. But it’s invisible to Google, looks broken when shared on LinkedIn, sends form submissions into a void with no confirmation, and has no way to measure whether it’s actually generating leads.

Here’s the pre-launch checklist that every business website should pass before the DNS is switched.

The 15-point checklist

1. DNS and domain ownership verification

The domain is registered in the business owners’s account, not the agency’s. The DNS is configured correctly, A records, CNAME records, and any MX records for email. If you’re using Cloudflare, the nameservers are updated at the registrar. If you can’t log into your domain registrar right now, you have a problem that needs to be fixed before anything else.

2. SSL / HTTPS everywhere

Every page loads over HTTPS with a valid SSL certificate. No mixed content warnings. HTTP requests redirect to HTTPS automatically. Cloudflare provides free SSL on every domain. There is zero reason for any business website to show “Not Secure” in the browser bar in 2026.

3. Google Search Console verification

Google Search Console is connected and verified using DNS or meta tag verification. The XML sitemap is submitted. This is how Google discovers and indexes your pages. Without it, you’re launching blind, no data on what Google sees, no visibility into crawl errors, no search performance data.

4. XML sitemap

A valid sitemap.xml exists at yourdomain.com/sitemap.xml. It lists every public page with correct <lastmod> dates. The sitemap is referenced in robots.txt and submitted to Search Console. Most modern frameworks (Astro, Next.js) generate this automatically, but verify it exists and contains the right pages.

5. Robots.txt

A robots.txt file exists at the domain root. It allows crawling of all public pages and blocks access to admin, staging, or private directories. It references the sitemap URL. A missing or misconfigured robots.txt can accidentally block Google from indexing the entire site.

6. Meta tags on every page

Every page has a unique <title> tag (50-60 characters) and a unique <meta name="description"> tag (120-160 characters). No two pages share the same title or description. The homepage title includes the business name and primary service.

7. Open Graph and social sharing tags

Every page has Open Graph tags (og:title, og:description, og:image, og:url) and Twitter Card tags. When someone shares a link on LinkedIn, WhatsApp, Facebook, or Slack, it should show a branded image, a clean title, and a compelling description. Test with LinkedIn’s Post Inspector and Facebook’s Sharing Debugger before launch.

8. Favicon and web app manifest

A favicon is configured in multiple sizes (16x16, 32x32, 180x180 for Apple Touch Icon). A site.webmanifest file exists for mobile browsers. The browser tab should show the business’s icon, not a blank square or the default framework icon.

9. Performance validation on mobile

Run PageSpeed Insights on mobile for every key page: homepage, services, contact. The Largest Contentful Paint (LCP) should be under 2.5 seconds. Total Blocking Time (TBT) under 200ms. Cumulative Layout Shift (CLS) under 0.1. These aren’t vanity metrics, they’re Google ranking factors.

10. Contact form confirmation

When someone submits the contact form, two things should happen instantly: (1) the business receives a notification email with the lead’s details, and (2) the submitter receives a confirmation email acknowledging their message and setting expectations for response time. A form that submits silently into a database with no confirmation loses leads, the person doesn’t know if it worked and may submit again or leave.

11. Analytics setup

Either Plausible (privacy-first, no cookie banner needed in most jurisdictions) or GA4 (if Google Ads integration is required) is installed and verified. Events are configured for form submissions, phone clicks, and any conversion action. Without analytics, you cannot measure whether the website is doing its job.

12. Cookie consent (if applicable)

If using GA4 or any tracking that places cookies, a GDPR-compliant cookie consent banner is implemented. The banner must block tracking scripts until consent is given, not just show a decorative notification. If using Plausible or Umami (cookieless analytics), no consent banner is needed for analytics.

13. Schema markup

Schema.org structured data is implemented: Organization schema on the homepage (business name, logo, contact info, social profiles), LocalBusiness schema if the business has a physical location, FAQPage schema on FAQ sections, and Article schema on blog posts. This is what enables rich results in Google, star ratings, FAQ dropdowns, business information panels.

14. Backup and recovery plan

A full backup exists before launch. A rollback plan is documented, if something goes wrong in the first 48 hours, you can revert to the previous site within minutes. For static sites on Cloudflare or Vercel, this means having the previous deployment available. For WordPress or CMS-based sites, this means a full database + files backup.

15. Ownership documentation

A handover document lists every account and credential the business owners needs: domain registrar login, hosting dashboard, CMS admin access, analytics dashboard, Search Console access, email configuration, and any third-party service credentials. If the agency disappears tomorrow, the business owners should be able to hand these credentials to any other developer and continue operating.

The testing pipeline

For teams that manage multiple client websites, this checklist should be automated. A pre-deployment pipeline (using tools like Playwright or Lighthouse CI) can verify performance thresholds, check for broken links, validate structured data, and ensure critical pages return 200 status codes. This is the approach Webxtek Studio uses: every deployment runs through automated quality gates before going live. Not because things always break, but because the one time they do, the automated check catches it before the client or their customers do.

The goal isn’t perfection, it’s preventing the avoidable. Every item on this list is fixable in minutes. Every item left unchecked costs the business real money, real traffic, or real credibility for every day it stays unfixed.