Web Development

Website Launch Checklist

A practical website launch checklist covering content, SEO, forms, analytics, redirects, security, backups and post-launch monitoring so go-live day is calm and reversible.

Quick answer: A website launch checklist is an ordered list of checks you run before flipping DNS or publishing a new site, so content, forms, tracking, redirects, security and backups are ready. Work through content and design sign-off, technical SEO, integrations, performance, access control and a rollback plan. After launch, watch uptime, forms and analytics for the first few days. Skipping the list is how “we went live” turns into “nobody can submit the contact form.”

Why launches fail without a list

Launches fail for boring reasons: a form still points at staging email, HTTPS is half-configured, old URLs 404, Analytics is missing, or someone left “noindex” on. A checklist turns tribal knowledge into a repeatable process. Use the same list for redesigns, migrations and brand-new builds.

Write ownership next to each item (developer, designer, client, marketer). A checklist with no owner is a wish list. Keep the master list in a shared doc so the next launch starts from the last one’s lessons, not from memory.

One week before launch

Content and design

  • Final copy approved for every template and key page
  • Legal pages present: privacy, terms, cookie notice if required
  • Images compressed, with useful alt text where needed
  • Broken links fixed on staging
  • 404 page designed and helpful
  • Favicon and social share images set
  • Contact details match the real company NAP used elsewhere

If the brief was vague, problems show up here. A clear website brief earlier in the project prevents last-minute rewrites. Print a page inventory and tick each URL; “we think everything is done” is not a sign-off.

Staging hygiene

  • Remove test accounts, lorem ipsum and dummy products
  • Confirm staging is password-protected or otherwise blocked from indexing
  • Confirm production will not inherit “Discourage search engines” or basic auth
  • Separate staging and production databases and keys for payment and email tools

Access and credentials

  • Client owns domain registrar, hosting, CMS admin, email and Analytics
  • Shared passwords moved to a password manager
  • Deploy accounts documented
  • Emergency contacts listed for host, DNS and developer

Website documentation should list who has what before go-live, not after.

Technical SEO checks

  • Unique title tags and meta descriptions on key templates
  • One clear H1 per page
  • XML sitemap generated and linked from robots.txt
  • robots.txt allows important paths
  • Canonical tags correct for the production host
  • Structured data validated where you use it
  • Open Graph tags checked with a preview tool
  • Language and region settings correct if you serve more than one market
  • Pagination and facet URLs reviewed so they do not flood the index

Run an on-page SEO checklist pass on homepage, service pages and top landing pages. For larger sites, sample category and product templates rather than every URL.

Redirects and URLs

For redesigns and migrations this is the highest-risk item.

  • Inventory of old URLs from Analytics, Search Console and the current sitemap
  • 301 map from old paths to new ones
  • Special cases: removed pages, merged posts, changed blog structure
  • Trailing slash and www vs non-www rules decided and consistent
  • HTTP to HTTPS redirect working on a temporary host or hosts file test
  • Query parameter rules documented if marketing uses tracked links

Test a sample of old URLs after launch, not only the homepage. Include PDF and image URLs if sales teams share them. A single missed product URL can cost more than a day of launch prep.

Forms, email and integrations

  • Every form submits to the right endpoint
  • Confirmation messages and thank-you pages work
  • Notification emails arrive (and are not in spam)
  • CRM or email tool receives leads if connected
  • Ecommerce checkout tested with a real small transaction where possible
  • Payment gateway is in live mode on purpose, not stuck in test mode
  • Webhooks and Zapier-style automations pointed at production endpoints

Send at least one test lead from a phone and one from a desktop browser. Ask a person outside the project team to try the main conversion path without coaching.

Analytics and tags

  • Google Analytics property receiving hits on production (filter out staging if needed)
  • Goals or events for forms, calls and key clicks
  • Google Tag Manager container published to the live environment if you use it
  • Search Console property verified for the exact production host
  • Conversion tracking for ads verified with a test conversion if campaigns will run
  • Cross-domain tracking checked if checkout lives on another host

Without measurement you cannot tell whether launch helped. Our Google Tag Manager for WordPress guide covers a common CMS setup.

Performance and devices

  • Homepage and key templates tested on a mid-range phone
  • Core pages load in an acceptable time on a throttled connection
  • Large hero images resized
  • Third-party scripts reviewed (chat, heatmaps, pixels)
  • Browser smoke test: current Chrome, Firefox, Safari, Edge
  • Fonts loading without long invisible text where you can avoid it

You do not need perfection on day one, but you do need usable speed on mobile. Note known issues in the launch log so they do not get forgotten after the celebration email.

Security and backups

  • HTTPS certificate valid and auto-renewing
  • Admin URLs and login protection hardened for your stack
  • Unnecessary plugins or sample apps removed
  • Latest CMS, theme and dependency updates applied on staging first, then production
  • Backup taken immediately before DNS cutover
  • Restore tested at least once on a throwaway environment during the project
  • File permissions and environment secrets reviewed

A launch without a restore path is a bet you do not need to make. Pair backups with a simple website maintenance plan so the new site does not rot in month two.

DNS and go-live steps

  1. Lower TTL on the domain a day or two ahead if you can
  2. Final content freeze time agreed with the client
  3. Deploy production build
  4. Point DNS or flip host mapping
  5. Purge CDN cache if you use one
  6. Recheck HTTPS, homepage, a blog post, a form and checkout
  7. Submit sitemap in Search Console
  8. Remove staging blockers only on production, never the reverse
  9. Tell the team the site is live and where to report issues

Follow a calm website deployment process so everyone knows the order of operations. One person should be “launch lead” with authority to pause if a blocker appears.

First 48 hours after launch

  • Uptime monitoring on
  • Form notifications watched by a named person
  • Search Console coverage checked for sudden spikes of 404s
  • Analytics real-time checked during the first traffic window
  • Hotfix list for copy typos and broken images
  • Redirect misses logged and fixed the same day when possible
  • Ad campaigns or email sends only after forms and tracking pass

Schedule a short post-launch review one week later: what broke, what to automate next time, what to add to the checklist. Capture screenshots of critical flows for the documentation pack.

Roles on launch day

A small RACI-style split keeps chaos down:

  • Developer: deploy, DNS, redirects, HTTPS, rollbacks
  • Designer or front-end: visual QA on key templates
  • Marketer: Analytics, tags, Search Console, campaigns
  • Client contact: content freezes, final copy calls, stakeholder updates

If one person wears every hat, shrink the launch window and cut scope rather than hoping energy will cover missing checks.

FAQ

Should we launch on a Friday?

Prefer mid-week when your team is available to fix issues. Friday afternoon launches strand problems over the weekend.

Do we need a soft launch?

For bigger sites, yes. Limit traffic with ads off, or launch to staff first, then open marketing once forms and tracking are proven.

What if we find a major bug after DNS change?

Revert using the pre-launch backup or roll DNS back if the old site is still intact. That is why the backup and TTL steps matter.

How long should content freeze last?

Long enough to deploy and verify, short enough that the business can still update offers. Many teams freeze non-essential edits for 24 to 48 hours.

Launch with a plan, not a hope

A website launch checklist turns go-live into a controlled cutover. Cover content, SEO, redirects, forms, analytics, security and monitoring, then watch closely for two days. If you want a launch process built into your next build, see how we help businesses turn visitors into customers.

About the author

Imran M

Leave a Reply

Your email address will not be published. Required fields are marked *

Ready to improve your website?

Let's build a faster, higher performing website.