The website launch checklist: 40 things to check before you go live

Most launch problems are not hard to fix. They are hard to notice. A contact form that sends to an old inbox, a staging noindex tag that ships to production, a certificate that covers example.com but not www.example.com: none of these break the page you are looking at, so they slip through.

This checklist is the one we use at GelFuzion before every client launch. It is grouped by area so you can hand sections to different people, and every item is something you can verify, not a vague goal. Where a free tool makes the check faster, we have linked it.

Run it twice: on staging the day before, and on the live domain within an hour of launch.

Domain and DNS

DNS mistakes are the slowest to fix because changes take time to spread. Do these first, ideally two days before launch.

1. Registrar lock is on and auto-renew is enabled. The transfer lock (shown as clientTransferProhibited in a WHOIS lookup) stops the domain being moved without your approval. Auto-renew prevents the far more common disaster: a domain expiring because the renewal email went to a former employee.
2. A, AAAA and CNAME records point to the new host. Check the apex (@) A record, any AAAA record (an old IPv6 address left behind will send some visitors to the old server), and the www record.
3. You have chosen www or the bare domain, and only one. Decide which version is canonical, then make sure the other resolves and redirects to it. Both versions need DNS records for the redirect to work.
4. TTL was lowered before the migration. If you are moving from an old host, drop the TTL on the records you will change to around 300 seconds at least 24 to 48 hours ahead. When you switch, visitors pick up the new address within minutes instead of hours.
5. Email records were not disturbed. Moving web hosting should not touch MX, SPF or DKIM records. If your new host imported a fresh zone, compare it with the old one line by line.

Our DNS lookup tool queries Google and Cloudflare resolvers side by side, which is a quick way to see whether a change has propagated or whether one resolver still has the old answer cached.

Security and HTTPS

6. The SSL certificate is valid for every hostname. That means the apex and www, plus any subdomain you link to. Check the expiry date and that the full chain, including the intermediate certificate, is served.
7. Every HTTP and alternate-host URL redirects to the canonical HTTPS URL in one hop. http://example.com, http://www.example.com and https://www.example.com should all land on the canonical version with a single 301.
8. HSTS is set, conservatively. The Strict-Transport-Security header tells browsers to use HTTPS only. Start with a max-age of a few months or a year and leave out includeSubDomains until you know every subdomain serves HTTPS.
9. No mixed content. Images, scripts, fonts or iframes loaded over http:// on an HTTPS page will either be blocked or drop the padlock.
10. Basic security headers are present. At minimum: X-Content-Type-Options: nosniff, a Referrer-Policy such as strict-origin-when-cross-origin, and clickjacking protection via X-Frame-Options: SAMEORIGIN or a frame-ancestors directive in a Content Security Policy.
11. Admin logins are locked down. Default usernames like admin are gone, every account has a unique strong password, two-factor authentication is enabled for anyone with admin rights and contractor accounts are removed.
12. Backups run automatically and you have tested a restore. A backup you have never restored is a hope, not a plan. Store them somewhere other than the same server.

On Apache or LiteSpeed hosting (which includes most shared hosts), a short block in .htaccess handles the redirect and HSTS items together. This version forces HTTPS and the bare domain:

# Force HTTPS and the bare domain in a single 301
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

# HSTS for one year (add includeSubDomains later, once every subdomain is HTTPS)
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Behind some proxies and CDNs, %{HTTPS} is always off at the origin and this rule loops. If that happens, use the forwarded protocol header your host documents instead. The .htaccess generator builds these rules for you, including the www and non-www variants.

SEO basics

None of these will make a site rank on their own. All of them can stop a site ranking.

13. Every page has a unique title and meta description. Titles should lead with what the page is about and stay roughly within 50 to 60 characters so they are less likely to be cut off. Descriptions are not a ranking factor, but they are your pitch in the results.
14. Each page has exactly one h1. It should describe the page, not the logo.
15. Canonical tags point to the right URL. Each page should reference its own preferred HTTPS URL. A very common launch bug is every page carrying a canonical pointing at the home page, or at the staging domain.
16. Staging blocks are gone. Check robots.txt for a leftover Disallow: /, check the page source for <meta name="robots" content="noindex">, and in WordPress make sure "Discourage search engines" is unticked. Then password protect the staging site itself.
17. robots.txt does not block CSS, JavaScript or images. Search engines render pages the way browsers do. Blocking asset folders can make a page look broken to them.
18. An XML sitemap exists and is referenced. It should list only canonical, indexable, 200-status URLs, and robots.txt should include a Sitemap: line pointing to it.
19. Google Search Console is verified and the sitemap submitted. Use a Domain property if you can, since it covers every protocol and subdomain.
20. Old URLs 301 to their closest new equivalent. If this is a redesign, export the old site's URLs (from the old sitemap, Search Console or your analytics) and map each one. Redirecting everything to the home page is treated much like a 404 and throws away the value those pages had built up.

If your platform does not generate a sitemap, the sitemap generator will create a valid XML file from a list of URLs.

Social and brand

The first time many people see a new site is as a link preview in a message or social post. Make that preview look intentional.

21. Open Graph and Twitter card tags are set on every page. At minimum og:title, og:description, og:url, og:image and twitter:card set to summary_large_image. Use an absolute URL for the image.
22. The share image is 1200 by 630 pixels. That 1.91:1 ratio displays well on most platforms. Keep text and logos away from the edges, because some apps crop to a square or a narrower frame.
23. Favicons and the Apple touch icon are in place. A modern minimal set is an SVG or 32 by 32 pixel icon, a 180 by 180 pixel apple-touch-icon.png, and a web manifest with 192 and 512 pixel icons so the site looks right when saved to a phone home screen.
24. Structured data describes the business. An Organization or LocalBusiness block in JSON-LD with the name, logo, address and contact details helps search engines connect the site to the business. Validate it with Google's Rich Results Test.

<meta property="og:title" content="Harbor Dental | Family Dentist in Portland">
<meta property="og:description" content="Gentle family dentistry with evening appointments.">
<meta property="og:url" content="https://example.com/">
<meta property="og:image" content="https://example.com/og-image.jpg">
<meta name="twitter:card" content="summary_large_image">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

The favicon generator outputs the full icon set and manifest from one image, and the schema generator writes the JSON-LD for item 24.

Content and UX

25. A real 404 page exists and returns a 404 status. It should be branded, offer navigation or search, and actually send a 404 code. A friendly page that returns 200 (a "soft 404") confuses search engines.
26. Every form works end to end. Submit each one from the live domain, on a phone and a desktop. Confirm the message arrives in the right inbox, the autoresponder (if any) reads correctly, spam protection does not block real people, and the thank-you state or page shows. If you track conversions, confirm the event fires too.
27. No broken links or leftover staging URLs. Crawl the site with a link checker and search the database or source for the staging domain.
28. Copy is proofread and placeholder text is gone. Search for "lorem", "TBC", "example.com" and the template's demo business name.
29. Legal pages are live and linked in the footer. A privacy policy that reflects what the site actually collects (forms, analytics, embedded maps, chat widgets), a cookie policy if you use non-essential cookies, and terms where you sell or take bookings. Legal requirements vary by country, so have the client confirm the wording.

Performance

Most slow small-business sites are slow for the same two reasons: oversized images and too many third-party scripts.

30. Images are compressed and in a modern format. WebP is supported by every current browser and AVIF by nearly all. A hero photo straight from a camera can be several megabytes; the same image at display size in WebP is usually a small fraction of that.
31. Images are sized and lazy loaded correctly. Serve images close to their displayed size (use srcset for responsive layouts), set width and height attributes so the browser reserves space, and add loading="lazy" to images below the fold. Do not lazy load the hero image: it is usually your Largest Contentful Paint element.
32. Caching and compression are on. Text assets should be served with Brotli or gzip, and static files such as images, fonts, CSS and JS should have long cache lifetimes.
33. Core Web Vitals are in the good range on mobile. Test your heaviest template, not just the home page.

These are the thresholds Google uses, assessed at the 75th percentile of real visits. A brand-new site will not have field data yet, so use a lab test such as PageSpeed Insights or Lighthouse as your launch benchmark.

Accessibility

These checks cover the most common failures, not a full audit.

34. Text contrast meets 4.5:1. That is the WCAG AA minimum for normal body text. Large text (roughly 24 pixels, or 19 pixels bold) and essential icons and form borders need at least 3:1. Pale grey text on white and white text on brand yellow are the usual failures.
35. Images have meaningful alt text. Describe what the image communicates, not "image of". Decorative images get an empty alt="" so screen readers skip them.
36. The site works with a keyboard and focus is visible. Unplug the mouse and Tab through the page. You should be able to reach and operate the menu, every link and every form control, always see where focus is, and close any modal or mobile menu with Escape.
37. Form fields have real labels and clear errors. Placeholder text is not a label: it disappears as soon as someone types. Each input needs a <label>, and error messages should say what went wrong in text, not just turn a border red.

Email

A new website often means new things sending email from your domain: contact forms, booking systems, shop receipts. Each one needs to be authorised.

38. SPF, DKIM and DMARC are set up, and form email passes them. Every service that sends as your domain should be in your single SPF record and sign with DKIM, and you should have at least a DMARC record at p=none with reporting. Send a test from the contact form, open the message headers in Gmail ("Show original") and confirm SPF, DKIM and DMARC all show PASS. A form plugin sending through the web server's PHP mail function will often fail all three; route it through an SMTP or transactional email service instead.

Our guide to SPF, DKIM and DMARC walks through the records in detail.

Analytics and tracking

39. Analytics is installed, consented and measuring what matters. Confirm the tag fires on every page (use the real-time view), that it respects your cookie consent setup where the law requires one, and that your own visits are filtered out. Then set up the conversions that matter to the business, such as form submissions, calls from tel: links and bookings, and test each one.

Post-launch

40. Monitoring is on, and you have a date in the diary to check Search Console. Set up a free uptime monitor that alerts by email or text, and add expiry reminders for the domain and certificate if they do not auto-renew. About a week after launch, open Search Console's Pages report: check how many pages are indexed, read the reasons for any that are not, and look for 404s from old URLs you missed in the redirect map.

Frequently asked questions