Website Launch Checklist: What to Check Before Go-Live and in the First 90 Days

A website launch checklist is the ordered list of checks a team runs before, during and after a new site goes live: content proofing, forms, analytics and consent, SEO and redirects, performance, accessibility, security, the DNS switch itself, and the first weeks of monitoring. It exists because most launch problems are cheap to catch on staging and expensive once Google has crawled the wrong version.

This checklist is written for teams launching a new or rebuilt business site, in-house or with an agency, and for anyone working out how to launch a website without losing the traffic the old one earned. It follows the three phases people actually work in: pre-launch, launch day, and the first 90 days after. Each item says what to check and, where it matters, which tool tells you whether it passed.

If the new site replaces an old one, read the redirect section twice. That step decides whether the old site's search traffic carries over.

A useful website go live checklist covers three phases. Pre-launch checks happen on staging and decide whether the site is ready. Launch-day steps are the switch itself: DNS, caches and indexing signals. Post-launch checks run for roughly 90 days and confirm that what worked on staging also works with real traffic, real browsers and real search crawlers. Many published checklists stop at the publish button, which is why the third phase gets its own part here.

The table below is the short version and works as a website launch checklist template you can copy into a project tracker. Give every row a named owner. An item that belongs to "the team" usually belongs to nobody, and it is the one still open on launch morning.

Content checks are the least technical part of a new website checklist and the part visitors notice first. Read every page on staging, not in the CMS editor, because templates change how text wraps and how images crop. Check prices, phone numbers, addresses, opening hours and legal company details against the source, and replace every placeholder, lorem ipsum paragraph and test image. Broken internal links and buttons that lead nowhere belong on the same pass.

Content and Proofing

• Every page has its own title tag, meta description and a single H1
• Images have alt text that describes them and are compressed (WebP or AVIF)
• The copyright year, social links and the logo link to the home page all work
• The Open Graph image and title look right when a link is shared in Slack, LinkedIn or WhatsApp
• A custom 404 page sends people back to the main sections

Forms and Email Deliverability

A form that submits is only half tested. The other half is whether the notification email reaches the person who has to answer it. Submit every form with realistic data, then check the inbox, the spam folder, and the CRM or spreadsheet where the lead is supposed to land.

Send form notifications through an authenticated domain or a transactional email service, not the web server's default mail function. Since February 2024, Gmail's email sender guidelines require every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to use both and publish a DMARC record. A contact form will never hit that volume, but unauthenticated mail from a fresh domain is far more likely to end up in spam, and nobody notices until a customer calls to ask why no one replied.

Analytics has to be live and verified on launch day, because data you did not collect in the first week cannot be recovered later. Pasting a tag is not enough. Decide which actions count as success (form submissions, quote requests, calls, purchases), mark them as key events in GA4, and test each one in DebugView or Tag Assistant before the DNS switch, while you can still fix it quietly.

If the site has visitors from the EU, the cookie banner and analytics have to work together. Google requires sites that measure EEA users with its tags to collect consent and pass it on through consent mode, which added two parameters, ad_user_data and ad_personalization, to the original storage signals. In practice, tags should not set analytics or advertising cookies before the visitor agrees, and declining should take no more effort than accepting. Test both paths in a private window and confirm that declining really stops the cookies.

Tracking Checklist

• GA4 property created, with your own office traffic filtered out
• Key events defined for every conversion the business cares about
• Search Console property verified before launch, ideally as a domain property
• Heatmap or session recording tools listed in the cookie banner and the privacy policy
• UTM naming agreed for the launch announcement and any campaigns

Most launch-day SEO problems come from staging settings that travel to production. A staging site is usually hidden from search engines, and that has to be undone the moment the site goes live. According to Google's documentation on blocking indexing, a page blocked in robots.txt cannot have its noindex rule read at all, so check the two settings together rather than one at a time.

Indexing Signals

• Remove noindex meta tags and X-Robots-Tag headers that were set for staging
• robots.txt on the live domain must not contain Disallow: /, and it can point to the sitemap with a Sitemap: line
• Every page has a self-referencing canonical tag on the live domain, not the staging URL
• One version of the domain (HTTPS, with or without www) is the main one, and the others redirect to it
• Structured data passes Google's Rich Results Test

XML Sitemap

Generate a sitemap that lists only live, indexable, canonical URLs. Google's sitemap guidelines cap a single file at 50,000 URLs or 50 MB uncompressed and state that Google ignores the priority and changefreq values, so there is no point tuning them. lastmod is used only when it is consistently accurate.

Redirects From the Old Site

If the new site replaces an old one, the redirect map is the most important document in the project. Crawl the old site, export its URLs along with the pages that have backlinks or search traffic, and map each one to its closest new equivalent. Google's site move guide asks for server-side permanent redirects (301 or 308), no redirect chains, no mass redirects to the home page, and keeping the redirects in place for at least a year. Our website migration guide and the article on protecting SEO during a redesign walk through the mapping step by step.

Multilingual Sites

On sites with more than one language, every page needs hreflang annotations that list all its language versions, itself included, and each version has to link back. Google's documentation on localized versions says annotations that only point one way are ignored. Add an x-default entry for the language picker or fallback page.

Speed is easiest to fix before launch, while the templates are still open. Google's Core Web Vitals give clear targets. Web.dev defines a good experience at the 75th percentile of page loads, on mobile and desktop, as Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. INP replaced First Input Delay as a Core Web Vital in 2024.

Before launch you only have lab data. Run PageSpeed Insights and Lighthouse on the home page and on one page of each template type (service page, article, contact page, product page) using the mobile profile. Fix the heavy items first: uncompressed hero images, fonts loaded from several sources, and chat or tracking scripts that block the main thread. Our guide to building a high-performance website covers the fixes in more depth.

Accessibility errors are common and mostly easy to catch. The WebAIM Million 2026 report found detectable WCAG 2 failures on 95.9% of the top one million home pages: low-contrast text on 83.9% of them, missing image alt text on 53.1% and missing form labels on 51%. Automated tools such as axe or WAVE flag most of these on staging in a few minutes per template.

Automated scans miss a lot, so add a manual pass. Tab through each template with the keyboard, check that the focus outline is visible, and make sure the cookie banner, menus and pop-ups can be closed without a mouse. WCAG 2.2 level AA is the usual target, and in the EU the European Accessibility Act has applied to many consumer-facing digital services since June 2025. Our accessible website design guide lists the checks per component.

Security work before launch is mostly configuration. The SSL certificate has to cover every hostname you serve, with and without www, and renew automatically, and every HTTP request should redirect to HTTPS. Security headers take an hour to set up and close common gaps: Strict-Transport-Security, a Content-Security-Policy (see MDN's CSP guide), X-Content-Type-Options and a Referrer-Policy. Check them with an external scanner rather than trusting the hosting panel.

• Admin accounts use unique passwords and two-factor authentication, and default accounts are removed
• The CMS, plugins and dependencies are on current versions
• Automatic backups run, are stored off the server, and one restore has been tested
• Forms have spam protection, such as a honeypot field, rate limiting or a CAPTCHA
• Uptime monitoring alerts a named person, not a shared inbox nobody reads

Legal Pages

Link a privacy policy, a cookie policy and, where required (Germany and Austria, for example), an imprint with company details from the footer of every page. The privacy policy has to name the tools that actually run on the site, so write it after the analytics, chat and embed choices are final, not before.

Launch day should be boring. Pick a weekday morning when the developer and the content owner are both available for the rest of the day, and avoid Friday afternoons. Freeze content changes on the old site a day before, so nothing gets published there that the new site does not have. Then work through the steps in this order and tick each one off as it is done.

1. One or two days ahead, lower the TTL on the DNS records you will change (300 seconds is a common value). Resolvers keep a record for the TTL they were given, so this only helps if it happens in advance.
2. Take a final backup of both the old site and the new one.
3. Deploy, then switch DNS or the hosting configuration.
4. Purge every cache layer (CDN, server, CMS) so nobody is served a stale or staging version.
5. Check robots.txt and the noindex state on the live domain.
6. Crawl the old URL list to confirm the redirects, and open the top 20 pages by traffic by hand.
7. Submit the XML sitemap in Search Console and run URL Inspection on the home page and the main service pages. If the domain itself changed, use the Change of Address tool, which Google reserves for moves between domains or subdomains.
8. Submit a real test form and confirm that both the email and the GA4 key event arrive.
9. Switch on uptime monitoring, and raise the TTL again once the new setup is stable.

Expect a delay before search catches up. Google says crawling can take anywhere from a few days to a few weeks, and requesting the same URL again does not speed it up. After a site move, rankings can fluctuate for a while as Google processes the redirects.

The first month is about catching what the staging review missed. Real visitors arrive on browsers, devices and paths nobody tested, and search crawlers find old URLs nobody mapped. Check Search Console every few days for the first two weeks, then weekly. Problems fixed in this window cost little, while the same problems found in month four have already cost traffic and leads.

Search Console and 404s

• In the Page indexing report, watch for rising counts of "Not found (404)", "Excluded by noindex tag" and "Page with redirect"
• Redirect 404 URLs that have backlinks or traffic to the right new pages
• Confirm the sitemap shows as processed without errors
• Compare impressions for your main queries with the old site's baseline

Analytics and Conversions

• Compare conversion counts in GA4 with what actually arrived in the CRM or inbox, and find out why they differ before anyone uses the numbers
• Look for landing pages with unusually high exit rates on mobile
• Check the consent rate. Exactly 0% or exactly 100% acceptance means something is misconfigured

Field Performance Data

Lab scores from before launch are a forecast. Field data comes from real Chrome users through the Chrome UX Report, which aggregates a rolling 28-day window. The first meaningful Core Web Vitals report therefore arrives about a month after launch, and a low-traffic site may never have enough data for page-level results. In that case, origin-level data or your own real-user monitoring fills the gap.

By the second month there is enough data to stop fixing and start improving. The question changes from "is anything broken?" to "where do visitors drop off, and why?" Use the conversion path and landing page reports to pick the two or three pages that matter most for leads, then watch how people use them with heatmaps or session recordings before you change anything.

Change one thing at a time and measure it against the baseline, because changes made in a batch cannot be attributed to anything. If traffic is high enough, run a proper A/B test following the cycle in Nielsen Norman Group's A/B testing guide: a hypothesis, one variable, a defined metric and enough time to reach a result. On low-traffic B2B sites, a clean before-and-after comparison over several weeks is often the honest alternative. Our guide to conversion optimization goes further.

Typical improvements in this window:

• Shorter forms, with the fields sales never uses removed
• Clearer calls to action in the first screen on mobile
• Page sections reordered based on scroll depth
• Internal links from blog posts to the service pages they support
• Thin pages expanded or merged into stronger ones

Where AI Tools Help

AI tools are good at the analysis half of this loop: summarizing session recordings, grouping search queries, flagging anomalies in analytics and drafting test variants. The deciding half still needs someone who knows the business, its margins and its customers. Use AI to shorten the time from data to a hypothesis, and keep a person responsible for what ships.

Most failed launches fail on process rather than technology. Nearly every problem traces back to something that was true on staging and stopped being true in production, or to a task everyone assumed someone else had done. Each of the mistakes below is cheap to prevent with a named owner and a test, and expensive to discover from a drop in leads a month later.

• A staging noindex tag or robots.txt block shipped to production
• No redirect map, or redirects that all point to the home page
• Analytics installed but key events never tested, so the first month of conversion data is missing
• A cookie banner that loads trackers before the visitor has agreed
• Form notifications landing in spam, unnoticed for weeks
• Launching late on a Friday with nobody available until Monday
• Treating launch as the end of the project, with no review booked for day 30 or day 90

A website audit around three months after launch catches what slipped through, and our website maintenance guide covers the routine work after that.

A website launch checklist works when it is ordered, owned and finished. Pre-launch checks decide whether the site is ready. Launch day is a short sequence of switches that should be rehearsed on staging first. The 90 days after are when you find out whether the site does its job with real visitors. Write the baseline down, give every line an owner, and put the day-30 and day-90 reviews in the calendar before go-live.

When Vezert builds a corporate website or a landing page, a checklist like this one is part of the handover. After launch, our website maintenance plans cover performance monitoring, security updates and content support, and SEO services handle indexing, redirects, content and internal links. Current prices are on the pricing page.