Secure Website Launch Checklist: Everything to Verify Before Going Live

Secure Website Launch Checklist: Everything to Verify Before Going Live

A website launch checklist that skips security is only half a checklist. The most common post-launch emergencies — expired certificates, unprotected admin panels, spoofable email domains, and missing security headers — are all preventable with a 30-minute pre-launch review. This guide walks through every layer, from DNS configuration to post-launch monitoring, with specific items to verify before go-live.

Scan your site in 60 seconds — it's free: ZeriFlow →

Layer 1: Domain and DNS Configuration

DNS is the foundation everything else sits on. Errors here affect deliverability, security, and even SEO.

### Domain Settings - [ ] Domain registered with a reputable registrar (Cloudflare, Namecheap, Google Domains) - [ ] Registrar account secured with a strong password and 2FA - [ ] WHOIS privacy enabled (prevents your personal contact information from being publicly listed) - [ ] Domain auto-renewal enabled with a valid payment method - [ ] Domain expiry date checked — at least 12 months remaining at launch

### DNS Records - [ ] A record (or AAAA for IPv6) pointing to correct server IP - [ ] CNAME for www (or A record if apex domain is not supported by your CDN) - [ ] MX records configured correctly for your mail provider - [ ] TTL values appropriate — 300–3600 seconds for records likely to change; 86400 for stable records

### DNSSEC - [ ] DNSSEC enabled at the registrar level if supported - [ ] DS record published and validated (use MXToolbox DNSSEC lookup to verify) - [ ] DNSSEC prevents DNS spoofing attacks where an attacker intercepts DNS resolution to redirect visitors to a fake site

### Email Security (SPF, DKIM, DMARC) - [ ] SPF record: v=spf1 include:[your-mail-provider] ~all — authorizes your mail provider to send on your behalf - [ ] DKIM: public key published in DNS, signing configured in your mail provider - [ ] DMARC: at minimum v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com - [ ] Verify all three with MXToolbox before launch — a misconfigured SPF record can silently cause your transactional emails to be rejected

Email security is one of the most commonly skipped items on a website launch checklist. A domain without DMARC can be impersonated trivially by spammers and phishers — your new brand domain becomes a spam vector within days of registration if not configured.

Layer 2: HTTPS and TLS

• [ ] SSL/TLS certificate installed for both the apex domain and www (or a wildcard certificate)
• [ ] Certificate is from a trusted CA (Let's Encrypt, DigiCert, Sectigo) — self-signed certs will show browser security warnings
• [ ] Certificate auto-renewal configured and tested — if using Let's Encrypt, verify the renewal cron job works before launch
• [ ] Certificate expiry date: minimum 60 days remaining at launch, ideally auto-renewed at 30 days
• [ ] TLS 1.2 minimum, TLS 1.3 enabled — disable TLS 1.0, TLS 1.1, SSL 3.0
• [ ] HTTP redirects to HTTPS: 301 (permanent), not 302 (temporary) — 302 does not pass SEO value
• [ ] www redirects to apex (or vice versa) — pick one canonical version and redirect consistently
• [ ] No mixed content — all resources (images, scripts, fonts, API calls) served over HTTPS. Browser DevTools → Console shows mixed content warnings

Layer 3: HSTS — HTTP Strict Transport Security

HSTS is the instruction that tells browsers "always use HTTPS for this domain, even if the user types http://." Without it, an attacker on the same network can strip HTTPS on a user's first visit.

• [ ] HSTS header present: Strict-Transport-Security: max-age=31536000; includeSubDomains
• [ ] max-age of at least 1 year (31536000 seconds) — shorter values provide weaker protection
• [ ] includeSubDomains included if all subdomains support HTTPS
• [ ] Consider HSTS preload for maximum protection: add preload directive and submit to hstspreload.org

Verify HSTS is set on the HTTPS response, not the HTTP response. A common mistake is setting HSTS before the redirect — browsers ignore HSTS headers received over HTTP.

Layer 4: Security Headers

• [ ] Content-Security-Policy — configured and tested (use Report-Only mode during development to catch violations before enforcing)
• [ ] X-Frame-Options: DENY — prevents your site from being embedded in an iframe on another domain (clickjacking protection)
• [ ] X-Content-Type-Options: nosniff — prevents MIME-sniffing attacks
• [ ] Referrer-Policy: strict-origin-when-cross-origin — controls what URL is sent in the Referer header
• [ ] Permissions-Policy — restrict browser features to what the site actually uses: camera=(), microphone=(), geolocation=()
• [ ] No server version disclosure: verify the Server header does not reveal exact version numbers (Apache/2.4.52 is unnecessary and helpful to attackers)

Run a ZeriFlow scan at this point to verify all headers are actually being served. Configuration in your framework or server config does not always translate correctly to what the browser receives — a scan gives you the ground truth.

Layer 5: Cookie Security

For any site that sets cookies (analytics, session management, consent):

• [ ] Session cookies: Secure + HttpOnly + SameSite=Strict
• [ ] Analytics cookies: verify third-party analytics (Google Analytics, Plausible) is setting cookies with appropriate flags
• [ ] Cookie consent banner implemented if required (EU visitors, GDPR) — no non-essential cookies set before consent
• [ ] Cookie expiry values are appropriate to their purpose — session cookies should expire at session end or within a reasonable period
• [ ] No sensitive data stored in cookies beyond session identifiers

Layer 6: Application Security

• [ ] Admin panel URL is not yourdomain.com/admin — use a non-obvious path or restrict by IP
• [ ] Admin panel requires strong authentication — no default credentials, MFA enabled
• [ ] User registration does not allow username enumeration (identical error messages for "user not found" and "wrong password")
• [ ] Password reset flow uses single-use, expiring tokens (not security questions)
• [ ] Rate limiting on authentication, registration, and password reset endpoints
• [ ] No sensitive data in URLs (session tokens, API keys in query parameters end up in logs and browser history)
• [ ] robots.txt does not inadvertently reveal sensitive path structure
• [ ] sitemap.xml does not include admin, staging, or private pages

Layer 7: Performance and Infrastructure

Performance is included in a security checklist because performance failures can be security incidents: a site brought down by load is indistinguishable from a DDoS attack if you cannot handle baseline traffic.

• [ ] CDN configured (Cloudflare, CloudFront, Fastly) — provides DDoS mitigation as a side effect of caching
• [ ] Image optimization: modern formats (WebP, AVIF), appropriate dimensions, lazy loading
• [ ] Core Web Vitals measured: LCP < 2.5s, FID < 100ms, CLS < 0.1 — failing these affects SEO rankings
• [ ] Server response time < 200ms for first byte (TTFB)
• [ ] Gzip or Brotli compression enabled
• [ ] Caching headers set for static assets (Cache-Control: public, max-age=31536000, immutable for fingerprinted assets)

Layer 8: Monitoring Setup Before Launch

Monitoring should be in place before launch, not after the first incident.

• [ ] Uptime monitoring configured (UptimeRobot free tier, Better Stack, or Pingdom) — alert within 1–5 minutes of downtime
• [ ] Certificate expiry monitoring — alert at 30 days before expiry
• [ ] Error tracking (Sentry, Datadog, Rollbar) — catch application errors in production
• [ ] Real User Monitoring or synthetic monitoring — track performance from user perspective
• [ ] Log aggregation — application logs going to a persistent destination, not local disk
• [ ] Scheduled security scans — run ZeriFlow weekly or post-deployment to catch configuration drift

The Final Check: Automated Scan Before Go-Live

The last step before launching is an automated scan that verifies the infrastructure layer — TLS, security headers, cookies, DNS, and email security — in one pass.

Running ZeriFlow on your staging environment (if it mirrors production configuration) or on the production URL immediately before launch gives you:

• A documented record of security configuration at launch
• Instant identification of any missed items from this checklist
• A baseline to compare against in future scans

This takes 60 seconds and produces a shareable report. For client projects, this report is part of your professional deliverable.

Quick Reference: Pre-Launch Security Score Card

FAQ

Q: In what order should I fix items if I find issues on launch day?

A: Prioritize in this order: (1) broken HTTPS / certificate issues — these block all users and all security; (2) missing HSTS — direct risk of SSL stripping; (3) no HTTP→HTTPS redirect — leaks traffic and credentials; (4) missing security headers — high impact for low effort; (5) email security (SPF/DKIM/DMARC) — high-visibility spam risk; (6) cookie flags — important for authenticated applications specifically.

Q: Should I run the security checks on staging or production?

A: Both, but they serve different purposes. Staging catches issues before they go live. Production confirms nothing was lost in the deployment pipeline. CDN configurations, environment-specific headers, and certificate installation only appear on production.

Q: Does a perfect security header setup guarantee I won't be hacked?

A: No. Security headers are browser-enforced protections against specific client-side attacks (XSS, clickjacking, MIME sniffing). They do not protect against server-side vulnerabilities (SQL injection, authentication bypass, RCE), insecure dependencies, or social engineering. They are one layer of defense, not the only layer.

Q: My site uses a website builder (Squarespace, Webflow, Wix) — how much of this applies?

A: DNS, DMARC, and uptime monitoring fully apply. HTTPS and basic headers are handled by the platform (verify they are configured correctly — platforms vary). You cannot customize security headers in most website builders, which is a real limitation. For professional or commercial sites handling user data, this is a reason to prefer a platform that allows header customization (Cloudflare Pages, Netlify, Vercel — all support custom headers).

Q: Is DNSSEC worth the added complexity?

A: For most sites, yes. Modern registrars (Cloudflare, Google Domains) handle DNSSEC with a single toggle and no manual key management. The protection it provides — preventing DNS cache poisoning and DNS spoofing — is meaningful, especially for e-commerce, SaaS, and any site handling authentication.

Conclusion

A secure website launch is the same as any other professional launch: it follows a checklist rather than relying on memory or intuition. The items in this guide take less than a day to implement for a typical project and represent the baseline that any site handling user data should have before going live.

The last step before you flip the switch: run a scan and document the configuration state.

Start your free ZeriFlow scan → — no credit card, instant results.