Skip to content

Checklist · 9 min read

Website Launch ChecklistNothing left to luck

Diagrams
02
Tools
02
Sections
11

The short answer

A website launch checklist is a structured set of checks confirming that a site is complete, functional, measurable, findable and safe before and after go-live. The essentials are redirects and SEO settings, working forms and tracking, performance and accessibility, security and legal requirements, a rollback plan and a monitored first month.

Launches fail on the boring things

When website launches go wrong, the cause is rarely sophisticated. A staging setting that blocks search engines is carried into production. Old URLs are not redirected. A form sends enquiries to a mailbox nobody checks. The analytics tag is missing from the new templates, so the first month of data is lost and nobody can say whether the new site is better.

None of these is difficult to prevent. They happen because launches are hectic and responsibility is diffuse. A checklist with named owners turns a stressful event into a routine one. Use the lists below as a starting point and adapt them to your platform and organisation.

A launch is not the day the site goes live; it is the day you start finding out whether it works.

Prioritise by what would hurt most

Not all checks are equal. If time is short, protect the things that would cause lasting damage or lost revenue before polishing the rest.

Fig. 01 · Hierarchy

Launch priorities, most critical first

  1. 01 · Revenue and legal

    Checkout, forms, payments, consent, privacy, security

  2. 02 · Findability

    Indexing allowed, redirects live, sitemaps submitted

  3. 03 · Measurement

    Analytics, conversion events, tag firing verified

  4. 04 · Experience

    Performance, accessibility, devices, broken links

  5. 05 · Polish

    Microcopy, imagery, minor visual details

Fix the top levels before launch at any cost; lower levels can follow in the first weeks if necessary.

The timeline

Fig. 02 · Timeline

A launch timeline

Exact timing depends on the project; the sequence is what matters.

Avoid launching on a Friday or before a holiday unless the team will be available through the weekend. Avoid launching during peak trading periods, such as a festive sale, when any problem costs most and attention is elsewhere.

Content and functionality

Checklist

0/8

Content and functionality checks

SEO and redirects

If you are replacing an existing site, this is the area where mistakes cost most and last longest. Redirect mapping should have been done well before launch; launch day is for verifying it. See site migration SEO for the full process.

  • Indexing allowed. Remove staging 'noindex' tags and robots.txt blocks. This single check prevents one of the most damaging launch errors.
  • Redirects live and tested. Every old URL with traffic or links returns a permanent redirect to its closest new equivalent, without chains.
  • Canonical tags correct. Pointing to the live domain, not staging.
  • XML sitemap generated and submitted in Search Console and other webmaster tools.
  • Titles, meta descriptions and headings present on every template; structured data validated.
  • HTTPS everywhere, with HTTP and non-preferred hostnames redirecting to the canonical version.

Keep the old site's crawl and redirect map after launch. When 404 errors appear in the first weeks, they are the quickest way to find URLs that were missed. Check server logs and Search Console for old URLs still receiving visits or links, add redirects for any that matter, and record each addition so the map stays complete.

Analytics and tracking

A site launched without working measurement cannot prove it is better. Verify tracking on the live site, not just staging, and compare data against your baseline from the old site. Your measurement plan should list every event that matters.

  • Analytics tag present on every template and firing once per page.
  • Key conversion events tested end to end: forms, purchases, calls, downloads.
  • Consent management working, with tags respecting visitor choices. See consent mode.
  • Advertising conversion tags and audiences reconnected to the new pages.
  • Search Console verified for the domain; old property retained for comparison.
  • Annotations added in analytics marking the launch date.

Performance, accessibility and devices

  • Core Web Vitals and page weight checked on key templates; see website speed.
  • Images compressed and correctly sized; caching and CDN configured.
  • Keyboard navigation, focus states, alt text and contrast checked on key templates.
  • Tested on real devices: recent and older phones, tablets, main desktop browsers.
  • Forms and checkout tested on mobile networks, not only office Wi-Fi.
  • SSL certificate valid and auto-renewing; security headers configured.
  • Admin accounts reviewed: default credentials removed, strong authentication enabled, former staff removed.
  • Backups configured and a restore tested.
  • Privacy policy, cookie notice and terms updated for the new site and current law, including the DPDP Act where it applies.
  • Uptime and error monitoring active, with alerts going to someone who will respond.
  • Rollback plan documented: how to revert quickly if something critical breaks.

Who owns what

Checklists fail when items have no owner. Before launch week, assign every area to a named person who confirms it is complete. The same person is the first call if something in that area breaks after launch.

AreaTypical ownerConfirms
ContentContent or marketing leadAll copy final, approved and proofread
FunctionalityLead developerForms, checkout, integrations, error handling
SEO and redirectsSEO leadIndexing, redirects, sitemaps, metadata
AnalyticsAnalytics leadTags, events, consent, advertising conversions
Security and hostingTechnical lead or hostCertificates, backups, monitoring, access
Legal and privacyLegal or compliancePolicies, consent, accessibility statement
Go/no-goProject ownerFinal decision based on the confirmations above

Telling people it has launched

Internal communication is part of the launch. Sales, customer service and anyone who shares links should know the date, what has changed, how to report problems and where old pages have moved. Customer-facing teams will hear about issues before your monitoring does, so give them a simple route to report them. Externally, update email signatures, social profiles, directory listings and ad destinations that point to changed URLs.

Launch day and the first 30 days

Self-diagnostic

0/5

Go/no-go questions

Ask these before deploying. Any 'no' on the first three should delay launch.

  1. 01Have forms, checkout and payments been tested end to end on the production environment?

    If yes: Revenue paths are protected. If no: Do not launch until they have been.
  2. 02Are redirects in place and indexing allowed?

    If yes: Search visibility is protected. If no: Fix before launch; these errors cause lasting damage.
  3. 03Is analytics verified, with conversion events firing?

    If yes: You can measure the new site from day one. If no: Fix now, or you lose the ability to compare.
  4. 04Is there a tested rollback plan?

    If yes: You can recover quickly if needed. If no: Document one before launching.
  5. 05Is the team available for the next 48 hours?

    If yes: Problems can be fixed quickly. If no: Move the launch to a time when they are.

In the first week, review crawl errors, 404 reports, Search Console coverage, conversion volumes and site errors daily. In the first month, compare performance with the pre-launch baseline, fix issues in order of commercial impact and start an optimisation backlog. The CRO process is how a new site gets better rather than slowly worse.

Key takeaways

  1. 01Most launch failures are omissions, so a checklist with named owners prevents most of them.
  2. 02Protect revenue paths, legal compliance, findability and measurement first.
  3. 03Verify indexing, redirects and analytics on the live site, not just on staging.
  4. 04Never launch without a tested rollback plan and a team available to respond.
  5. 05Treat the first 30 days as part of the launch: monitor daily and compare against the baseline.

Frequently asked

What should be on a website launch checklist?
At minimum: content proofed and complete, forms and payments tested end to end, indexing allowed and redirects in place, sitemaps submitted, analytics and conversion tracking verified, performance and accessibility checked, security and backups configured, legal pages updated, monitoring active and a rollback plan ready. Each item should have a named owner.
How do I avoid losing SEO when launching a new website?
Map every old URL with traffic or links to a relevant new URL and implement permanent redirects. Remove staging noindex settings, keep or improve high-performing content and metadata, submit new sitemaps and monitor Search Console closely after launch. Most SEO losses at launch come from missing redirects or accidental indexing blocks.
What is the best day to launch a website?
Early in the working week, when the team is available for several days afterwards and traffic is not at its peak. Avoid Fridays, holidays and major sales periods. The aim is to have people ready to fix problems quickly, during a period when any disruption costs least.
What should I do after launching a website?
Monitor errors, broken links, search coverage, conversions and performance daily for the first week. Fix issues in order of commercial impact. After a few weeks, compare results against your pre-launch baseline, gather user feedback and begin a structured optimisation programme rather than treating the project as finished.
Who should sign off a website launch?
A single accountable owner should make the go or no-go decision, based on confirmations from those responsible for each area: content, development, SEO, analytics, security, legal and customer-facing operations. Clear sign-off avoids both last-minute surprises and launches delayed by diffuse approval.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.

Read next

Prefer a specialist to do this with you? The network has a house for every discipline in this library.

Request an Introduction