Website Launch Checklist: Technical, SEO, Email and Security

Most launch-day disasters come from a short list of mistakes: the staging noindex that went live, old URLs that 404 instead of redirecting, a DNS switch that dropped the email records, a contact form whose messages land in spam. None of them are hard to prevent, but they're easy to forget at 6 p.m. on launch day. This checklist walks through what to verify before, during and after going live, with configs you can copy.

Before launch: one to two weeks out

Inventory DNS and email

• Export the current DNS zone from your DNS provider. You'll need it if anything goes missing.
• List every record you rely on: MX, SPF, DKIM selectors, DMARC, verification TXT records, subdomains for other services (help desk, store, email marketing tracking).
• Lower the TTL on records you'll change (usually the A/AAAA or CNAME for the site) to 300 seconds, at least one full old-TTL period ahead. Our DNS propagation guide explains why.
• Check for DNSSEC if you're changing DNS providers. A stale DS record can take the whole domain offline; see What is DNSSEC.

Map old URLs to new ones

If this is a redesign or a platform change, URL structures usually change. Google's site-move guidance recommends server-side permanent redirects (301 or 308), pointing each old URL straight to its final destination, and keeping them for as long as possible, generally at least a year.

• Export all old URLs: from the old sitemap, Search Console's indexed pages, and analytics' top landing pages.
• Map each to its closest new equivalent. Send genuinely removed pages to a relevant category, not all to the homepage.
• Write the redirects and test them on staging.

# Nginx: individual redirects
location = /services/web-design.html { return 301 /web-design/; }
location = /about-us.php            { return 301 /about/; }

# Apache .htaccess
Redirect 301 /services/web-design.html /web-design/
Redirect 301 /about-us.php /about/

Prepare the certificate

• Make sure the new host can issue a certificate for every hostname: the apex, www, and any subdomains.
• If you have CAA records, confirm they allow the CA the new host or CDN uses. See CAA records explained.

Pre-launch checks on staging

SEO basics

• Every important page has a unique, descriptive <title> and meta description. See title tags and meta descriptions.
• One clear H1 per page.
• Canonical tags point to the production URL, not staging:

<link rel="canonical" href="https://www.example.com/web-design/">

• Structured data (if used) validates and uses production URLs.
• An XML sitemap is generated and lists only canonical, indexable, production URLs. Google ignores <priority> and <changefreq>, so don't spend time on them.
• Images have meaningful alt text and are compressed (WebP or AVIF where possible).

Performance

• Run PageSpeed Insights or Lighthouse on key templates: home, a service page, a blog post, a product page. Aim for the Core Web Vitals "good" thresholds: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less.
• Caching and compression are enabled on the production server, not just staging.
• Third-party scripts (chat, analytics, ads) are only the ones you actually need.

Functionality

• Every form submits and the message actually arrives, including at a Gmail and an Outlook address.
• Checkout, booking and login flows work end to end.
• 404 page exists, returns a real 404 status code, and helps people find their way.
• Analytics and conversion tracking fire on the production domain.

Launch day

1. Remove the staging blocks

This is the single most common launch mistake. Check all three places:

• robots.txt doesn't contain Disallow: / for all user agents.
• No noindex in meta tags or X-Robots-Tag headers.
• WordPress: under Settings, Reading, untick "Discourage search engines from indexing this site." Since WordPress 5.3, that box adds a noindex, nofollow robots meta tag to every page.

A safe production robots.txt for most small sites:

User-agent: *
Disallow:

Sitemap: https://www.example.com/sitemap.xml

See our robots.txt guide for more.

2. Switch DNS

• Update the A/AAAA or CNAME records to the new host.
• Don't touch MX, SPF, DKIM or DMARC unless email is moving too. If you're changing DNS providers, confirm every email record exists at the new provider before switching nameservers.
• Keep the old server running for at least a few days.

3. Force HTTPS and one canonical hostname

Pick www or non-www and redirect everything else to it in one hop:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate lines here
    return 301 https://www.example.com$request_uri;
}

• http://example.com, http://www.example.com and https://example.com all reach https://www.example.com in a single redirect.

4. Add security headers

A sensible starting set:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Only use includeSubDomains if every subdomain works over HTTPS. Don't add preload on launch day: the HSTS preload list requires a max-age of at least one year with includeSubDomains and preload, and the list itself warns that removal is slow and hard to undo. Build up to it. The HTTP security headers guide covers each header, including a full Content Security Policy.

5. Make sure nothing sensitive is exposed

• /.env, /.git/config, database dumps, phpinfo.php and backup archives return 403 or 404.
• Debug mode is off (WP_DEBUG, APP_DEBUG, framework error pages).
• Staging credentials and test admin accounts are removed.

# Block dotfiles except the ACME challenge directory
location ~ /\.(?!well-known) { deny all; }

Email: check it even if "nothing changed"

New sites often add a new sender: the contact form plugin, a booking system, a newsletter tool. Each one needs to be authorized.

• SPF includes every service that sends as your domain, in a single v=spf1 record, within the 10 DNS lookup limit. See SPF too many DNS lookups.
• DKIM is enabled for each sending service, with its selector published.
• DMARC exists, at least p=none with a reporting address, moving toward quarantine or reject.
• Forms send from your own authenticated domain, or through an SMTP/API service that's in your SPF and signs with DKIM, rather than PHP mail() from the web server.

Gmail has required SPF or DKIM from all senders since February 2024, and SPF, DKIM and DMARC from senders of more than 5,000 messages a day. The email authentication checklist walks through each step.

After launch: the first week

• Run a full audit on the live domain. Run a free audit to check performance, SEO tags, robots.txt, sitemap, broken internal links, DNS, email authentication, security headers, certificate and exposed files in one pass.
• Submit the sitemap in Search Console and watch the Pages report for unexpected exclusions.
• For a domain change, use Search Console's Change of Address tool. Google says it's for domain or subdomain moves only, not HTTP-to-HTTPS or path changes.
• Spot-check redirects for your top old URLs (the bulk redirect checker tests up to 100 at once) and watch Search Console for new 404s.
• Raise DNS TTLs back to 3600 or higher once everything is stable.
• Set up monitoring: an uptime service for availability, plus scheduled audits to catch configuration regressions. See the website monitoring guide.

Frequently asked questions

When should I submit my sitemap to Google?

Right after launch, once robots.txt and noindex blocks are removed and the sitemap lists production URLs. You can submit it in Search Console's Sitemaps report and reference it in robots.txt. Google treats a sitemap as a hint, so it still needs crawlable internal links.

Should I launch on a Friday?

Avoid it if you can. Problems with DNS, email and redirects often surface over the following 24 to 48 hours as caches expire and traffic arrives, and you want people available to fix them. Early in the week gives you room.

Do I need to redirect every old URL?

Redirect every old URL that has traffic, backlinks or rankings, and anything listed in your old sitemap. For pages with no equivalent, redirect to the closest relevant page, or return a 404 or 410 if there's genuinely nothing related. Redirecting everything to the homepage is unhelpful for users.

How long should I keep the old server running?

At least until DNS caches have expired and traffic on the old server has dropped to zero, which for a normal record change is often a day or two. If you changed nameservers, give it longer. Keep the old site's files and database backed up for weeks after that.

What to do next

Copy this checklist into your project tool and assign each item an owner. On launch day, work through the "remove the staging blocks" section first, then run an audit on the live domain as soon as DNS has switched, and again a week later to catch anything that slipped through.

Sources

• Google Search Central: Site moves with URL changes
• Google Search Central: Build and submit a sitemap
• WordPress Documentation: Settings Reading screen
• HSTS Preload List Submission
• web.dev: Web Vitals
• Google Workspace Admin Help: Email sender guidelines