Website Launch Checklist: The 2026 Guide for Going Live

You are days, maybe weeks, away from going live. The build is mostly done, the team is making final tweaks, and you have a quiet, nagging feeling that something is going to break the moment you flip the switch. That feeling is reasonable. Launch day is the most stressful point in any website design project, and a step-by-step website launch checklist you can actually work through is worth more than another generic pep talk.

Bad launches quietly cost real money. A redirect map you skipped can erase years of organic traffic, a staging Disallow: / rule left in place at cutover keeps Google out of the new site for weeks, and a broken contact form drops leads on the floor before you even notice. The launches that go well are the ones where the prep work was treated as table stakes, not as something to get to "if there is time."

This website launch checklist covers the three phases that decide how your launch performs: the pre-launch work that hardens the site, the cutover itself, and the 30 days of monitoring and follow-through that determine whether your traffic survives. It applies equally to a site built on a custom stack and to one assembled with a website builder, and it works for first-time launches as well as relaunches, with extra emphasis on the redirect and SEO work that protect existing rankings during a migration.

Plan the Launch Before You Touch Anything Technical

Most launch problems are actually planning problems, not web design problems. Teams treat the launch as a single moment, when it is closer to a 30-day arc with a cutover in the middle. The work before is meant to harden the site. The work after is meant to catch what hardening missed.

Before any of the technical pre-launch tasks below, sit with your team and answer four questions. They are simple, but most launches that go sideways skipped them.

• What does success look like in numbers? Pick concrete metrics: no rank drop greater than 15 percent in week one, 300 organic visits in month one, zero broken form submissions in week one. Without numbers, post-launch monitoring turns into vibes.
• Who owns what? Name one person for technical and dev, one for SEO, one for content and QA, and one for the announcement. One person per role, even on a small team. If two people own the same thing, nobody owns it.
• What is the launch window, not the launch moment? Plan for a 30-day arc: pre-launch hardening, cutover day, and the post-launch monitoring window. Communicate that arc to stakeholders so the team is not expected to disappear on day two.
• What gets announced where, and when? Decide which audiences hear about the new site, on which channels, and in what order. The customer email list, LinkedIn, and any specific industry venue where the audience already pays attention are usually the three that matter.

This is the section the original article version of this checklist was missing entirely, and it is the section that determines whether the rest of the checklist actually gets used. A website launch plan that lives only in someone's head will not survive contact with the calendar.

Most migration failures trace back to broken redirects, missed canonicals, or staging directives that survived cutover. (Source: Numen Technology analysis citing Search Engine Journal's review of 892 migrations.)

For more on planning a redesign properly:

• Website Revamp Guide
• Must-Ask Questions for Each Phase of a Website Redesign

Pre-Launch Checklist

This is the biggest section of the article for a reason. The work that happens before cutover is what protects your traffic, your conversions, and your sanity once the site goes live. The categories below are not optional, but the depth you go into in each one will depend on the size of your site and the stakes of the launch.

Technical SEO Foundations

This is the pre-launch search engine optimization (SEO) track that decides whether search engines can crawl, render, and rank your new site on day one. It is also the area where the most expensive launch mistakes happen. None of these tasks are hard. They are easy to forget.

• Robots.txt review. Remove any staging-era Disallow: / rule. Confirm the live file serves at /robots.txt with a 200 status and references your sitemap. This single rule, left in place at cutover, has invisibly de-indexed entire sites for weeks.
• Noindex sweep. Audit every page for noindex meta tags left over from staging. Templates often inherit these without anyone noticing.
• Canonical tags. Every page should have a self-referencing canonical pointing to the production URL. No canonicals pointing to staging. No canonicals pointing to a different domain.
• XML sitemap. Generate it, validate it, include only canonical and indexable web pages, and submit it to Google Search Console and Bing Webmaster Tools on launch day. Reference the sitemap from robots.txt.
• Page titles and meta descriptions. Every page has a unique, descriptive title with the primary keyword near the front, and a meta description that gives someone a reason to click. Default titles like "Home" or "Untitled" are easy to miss in a templated build.
• Redirect map (for relaunches). Every old URL maps to its new counterpart. The catastrophe to avoid: redirecting all old pages to the new homepage. Search engines read that as "the new site is not relevant," and rankings collapse.
• Schema and structured data validation. Run any pages that use schema (Article, Organization, FAQ, Product) through Google's Rich Results Test. Validate on staging, then re-validate on the live URL after cutover.
• Internal linking sanity check. Crawl staging with Screaming Frog or SiteBulb. Look for 404s, broken links, redirect chains, and orphan pages. Fix them before launch, not after.
• Heading hierarchy. Each page has one H1 and a logical H2 and H3 nesting. This catches templating errors before they ship.

The redirect map is the single most important item on this list for relaunches. If you do nothing else from this section, build a row-by-row mapping of every old URL to a new URL, and audit the live site against it within the first hour after cutover.

For more on the broader SEO picture:

• B2B Website SEO: A Technical and Content Strategy Guide

Core Web Vitals and Performance

Speed and stability are not a tiebreaker anymore. Slow load times hurt user experience, and pages that miss Core Web Vitals thresholds lose eligibility for top rankings on competitive queries. Website performance is a ranking floor now, not a polish item. Your job before launch is to make sure the live site meets the thresholds on the pages that matter.

• LCP (Largest Contentful Paint) under 2.5 seconds. Measures how fast the main content of a page becomes visible.
• INP (Interaction to Next Paint) under 200 milliseconds. Replaced FID in March 2024. Measures how responsive the page feels when a user actually clicks, taps, or types.
• CLS (Cumulative Layout Shift) under 0.1. Measures how much things jump around as the page loads.

Aim for "Good" on all three metrics, not just one or two. Measurement is on 75th-percentile field data, not lab tests. (Source: Google's web.dev Core Web Vitals documentation.)

All three are measured on 75th-percentile field data, not lab data. That distinction matters. Lab tools like PageSpeed Insights give you a clean test in a controlled environment. Field data tells you what your real users actually experience.

Run your top 10 pages through PageSpeed Insights before launch and look at both the lab score and the field data, if the site has enough traffic to show field data. The most common pre-launch optimization wins are unsurprising: modern image formats like AVIF and WebP, lazy-loading anything below the fold, splitting up oversized JavaScript bundles, putting a CDN in front of the site, and setting sane caching headers.

Web fonts deserve a specific call-out because they cause more launch performance regressions than almost anything else. Set font-display: swap or font-display: optional so text never sits invisible while a font loads. Subset your fonts to only the glyphs and weights you actually use. Self-host where possible to remove a third-party DNS lookup from the critical render path.

Accessibility

Accessibility is a default expectation now, not a polish item. WCAG 2.2 AA is the standard most commercial sites in the US and the EU are now held to, and Americans with Disabilities Act lawsuits over inaccessible websites are increasing every year. Skipping this section is a mistake whether you care about the legal exposure or only about the people who will use your site. A user-friendly site is one that works for every visitor, not just the easy ones.

The good news is the technical fundamentals are well-documented and most of them are simple. Pre-launch accessibility work breaks down into automated and manual checks.

• Run an automated scan. Tools like axe DevTools and Lighthouse catch roughly 30 to 40 percent of accessibility issues. They will not catch everything, but they catch the obvious things in seconds.
• Verify color contrast. Body text needs a contrast ratio of at least 4.5 to 1 against its background. Large text needs at least 3 to 1. Brand colors that look great on a slide can fail badly on a real page.
• Test keyboard navigation. Tab through every form and every menu without using a mouse. If you cannot reach something with the keyboard, your users with motor or visual impairments cannot either.
• Check focus states. Every interactive element needs a visible focus outline. Many CSS resets remove these. Put them back.
• Verify alt text on every meaningful image. Decorative images can be empty alt attributes. Functional images need descriptive alt text. Background images that carry information are a common miss.
• Spot-check with a screen reader. Run VoiceOver on macOS or NVDA on Windows through the homepage and at least one conversion path. You do not have to be an expert. You only have to listen for whether the page is intelligible.

The legal context is worth a sentence. Federal court website accessibility lawsuit filings have grown steadily, with mid-2025 filings up 37 percent year over year according to industry trackers. That number does not tell you anything personally, but it tells you that this is no longer an emerging risk. It is a current one.

Content and Functional QA

This is the old "test everything" category, with the items that actually break launches called out specifically. Most teams test the homepage and a few obvious pages. The launches that fail are the ones where nobody touched the contact form or noticed that the favicon broke.

• Proofread every page. Watch the places authors usually skip: H2 and H3 headings, button copy, image alt text, the footer, and any boilerplate template areas. Typos in heading copy are remarkably common because authors edit body text and skip back.
• Test every form. Submit each form with a real address on the live site after cutover. Confirm the autoresponder fires, the analytics event fires, and the lead arrives in the CRM or email tool. Test the failure cases too: required fields, invalid email formats, oversized inputs.
• Verify every call-to-action. Click every primary and secondary CTA on every key page. Check that the destination is correct, the URL query parameters are intact, and the conversion tracking fires.
• Test landing pages and top conversion paths. The homepage and the four or five highest-priority pages are the ones that actually convert. Test those thoroughly, not the obscure footer pages.
• Cross-browser and cross-device. Run the top five pages through Chrome, Safari, Firefox, and Edge. Then iOS Safari and Android Chrome on real mobile devices. Confirm mobile responsiveness and mobile-friendly rendering across desktop, tablet, and phone resolutions. Catch the regressions before users do.
• Customize the 404 page. Default 404s are missed opportunities. A custom 404 with clear navigation back to the homepage and a search bar where relevant turns a dead end into a recovery path.
• Verify the favicon. The small browser-tab icon is genuinely the most-forgotten asset on most launches. Confirm it serves at every required resolution, including the 32×32, the Apple touch icon, and any SVG variants if you use them.
• Final link sweep. Crawl the site one last time before cutover. Fix every 404. External links break quietly all the time.
• For ecommerce sites. Test the full checkout flow with a real card. Verify tax and shipping calculations. Confirm the order confirmation email and the CRM sync fire correctly.

Analytics, Tag Management, and Baseline Capture

You cannot prove your launch went well, or diagnose what went wrong, without a baseline. The teams that skip this step are the ones that argue for six months about whether the new site is performing.

• Set up Google Analytics 4 with conversion events. Map form submissions, key page views, and important outbound clicks to GA4 conversion events. Verify each one fires on a real submission, not just in preview mode.
• Verify Google Search Console. Both the old and new properties for a migration. Submit the new sitemap immediately after cutover.
• Audit Google Tag Manager. If you use GTM, walk through every tag, every trigger, and every variable. Remove anything that was staging-only or test-only. Confirm all production tags fire.
• Confirm CRM, email tool, and chat integrations. Form submissions should land in the CRM. Newsletter signups should sync to the email tool. Chat widgets should load and respond. Test each one with a real submission.
• Capture a baseline. Pull your current keyword rankings from Ahrefs, Semrush, or whichever SEO tool you use. Export your current Search Console data and the latest snapshot from your analytics tool. Note current organic traffic, conversion rates, and any other metrics you intend to compare against. Without this, you have no anchor.
• Have a rollback plan. Know how to roll the site back. Keep a backup of the old site and its database. Identify who calls whom if something breaks at 9 a.m. on launch day.

The baseline is the most-skipped item on this list and the one that costs the most when it is missing. It takes 30 minutes to capture and is impossible to reconstruct after the fact.

Security and Hosting

A short section, but the items here are the kind that go from "fine" to "fire drill" the moment something breaks. Treat them as launch-blocking.

• SSL certificate and HTTPS verified on the production domain. Every page, every asset, no mixed content warnings. Test a few interior pages, not just the homepage.
• Security headers in place. HSTS, X-Content-Type-Options, X-Frame-Options, and a Content-Security-Policy at minimum. There are good defaults for most stacks.
• Plugin and CMS updates current. For WordPress, Webflow, or any website builder or content management system, every plugin and the CMS core should be on the latest stable version at cutover. Outdated plugins are one of the most common breach vectors on launched sites.
• Hosting environment confirmed. Production web hosting is live, not staging. The server location matches your primary audience geography. You have a documented uptime SLA from your hosting provider.
• Admin and login surfaces secured. Two-factor authentication enabled on every admin account. Remove any leftover test or temporary accounts before launch. Strong passwords on everyone still left.

Launch Day Checklist

The cutover itself is shorter and more procedural than most teams realize. The work in the 24 hours before, in the cutover window itself, and in the first hour after the site is live falls into three crisp groups.

The 24 Hours Before Cutover

The day before launch is for staging the operational pieces, not for making changes to the site. Save anything that touches the live build for the cutover window itself.

• Reduce DNS TTL. Drop the time-to-live on your domain name's DNS records to roughly 5 minutes, 24 to 48 hours in advance. This makes the actual DNS swap propagate quickly and gives you a fast rollback if you need one.
• Take a final backup of the old site. Full database, full file system. Store it somewhere outside the production environment.
• Send the go-live notice internally. Stakeholders should know the cutover time, who is on point, and who to call if they see something odd. Quiet expectations beat surprise scrambles.
• Run one final staging crawl. Last sanity check for 404s, redirect chains, and template errors.
• Run one final accessibility scan. Last automated pass before live.

The Cutover Window

Cutover is procedural. Have the checklist in front of the person doing it.

• DNS swap. Point your custom domain to the new server or hosting platform.
• Verify SSL on the live domain name. As soon as DNS propagates, confirm HTTPS works on your custom domain across the homepage and a few interior pages. No mixed content warnings.
• Confirm robots.txt and the sitemap serve correctly. Pull both URLs directly. Verify they return 200 with the expected content.
• Submit the sitemap to Google Search Console. Request indexing on the homepage and the top 10 priority pages individually.

Within the First Hour

This is the window where small problems are still small. Look for them.

• Submit one real form on the live site. Not a test on staging. A real submission. Confirm the autoresponder, the analytics event, and the CRM record.
• Spot-check the top 5 pages. Homepage and the four or five highest-traffic pages from your old site analytics. Look for layout, links, images.
• Run PageSpeed Insights on the live homepage. Catch any performance regressions that did not appear on staging.
• 404 sweep on the live site. Crawl the live site immediately after cutover. Major pages returning 404 indicate a redirect mistake.

The cutover itself is short and procedural. Most launch-day risk lives in the 24 hours before and the hour after.

Post-Launch Checklist

The launch is not the end. It is the start of the window in which most launch problems become obvious. The first 24 hours, the first week, and the first 30 days each call for different attention.

First 24 Hours

Active monitoring is the goal for the rest of launch day. The people who launched the site should stay at their desks for a few more hours, watching for anything that looks off.

• Watch GA4, Search Console, and any uptime monitoring you have. Real-time data is the point.
• Spot-check the live site every few hours. Things that worked at noon sometimes break by 4 p.m. because someone changed something.
• Watch the form submission inbox. Real submissions confirm that real users are completing the conversion path.
• Watch for unusual 404 spikes. A sudden cluster of 404s is the earliest sign of a redirect that did not work.

For more on what active monitoring looks like longer-term:

• B2B Website Maintenance Checklist: Monthly Tasks That Matter

First Week

The first week is for catching what active monitoring missed and for making sure the launch reaches its audience. Both halves matter, and most teams overweight one and underweight the other.

• Watch Search Console for new crawl errors. Most surface within three to five days.
• Run a redirect audit. Crawl your old URLs against your redirect map. Confirm every one returns a 301 to the correct new URL. Fix any that did not.
• Reconcile backlinks (for relaunches). Pull your top 50 backlinks pointing to the old site. Confirm they resolve to the new URL. If they do not, you are leaking link equity.
• Communicate the launch externally. Three channels are usually enough: your email marketing list, social media where your audience already pays attention (often LinkedIn for B2B), and any specific industry venue that matters to your market. Skip the buffet of "post on every platform." Pick the channels where attention actually compounds.
• Be measured in announcements. Your audience does not care that there is a new website. They care what is now possible because the new website exists. Lead with what changed for them, not what changed for you.

First 30 Days

The 30-day window is for confirming the launch performed and for setting up the content and SEO cadence that will carry the site forward. It is also when the team can finally start to exhale, as long as the early signals are pointing the right way.

• Compare actual metrics to the baseline. Rank, organic traffic, conversion rate. Sustained drops greater than 15 percent on important keywords warrant investigation. Smaller wobbles in the first 2 to 4 weeks are normal.
• Watch INP and LCP on real-user data. CrUX or GA4 web vitals if you have them integrated. Lab data lies. Field data tells the truth about what users actually experience.
• Start a content cadence and an optimization rhythm. One substantive post in the first month signals to search engines that the new site is alive and being maintained. It also gives your team something to talk about during the launch communication window.
• Run a follow-up accessibility scan. Some issues do not appear on staging because they depend on real content interactions. Re-scan a week or two after launch.

What to Expect After Launch

A short, honest section, because expectations are where most post-launch stress comes from. Knowing what is normal saves real time and real arguments in the weeks after a launch.

For a relaunch on the same domain, expect a temporary rank dip in the first 2 to 4 weeks even when everything was done right. Search engines take time to re-crawl, re-evaluate, and re-rank a meaningfully changed site. Panic-edits during this window usually make things worse, not better.

For a first-time launch on a new domain, organic traffic builds over months, not days. Direct, email, and referral traffic are the early channels that matter. Patience with SEO is part of the plan, not an apology for missing numbers.

Knowing when a dip is normal versus when to escalate is the skill that keeps small problems small. A 10 to 20 percent rank wobble on important keywords that recovers by week 6 is normal. A sustained 30 percent or greater drop past week 4, a sudden mass de-indexing event, or a precipitous traffic cliff that lasts more than a week is escalation-worthy and usually points back to a specific cause: a redirect that did not work, a robots.txt rule that survived staging, or a canonical tag pointing to the wrong place.

For more on the broader redesign picture:

• 11 Benefits of Website Redesign
• How Long Does It Take to Redesign a Website?

Where to Start Tomorrow

Two items, in this order, will protect more launch outcomes than any other pair on the website checklist. Both are unglamorous, and both pay back the time investment many times over.

The first is the redirect map. For any relaunch, build a row-by-row spreadsheet of every old URL and the new URL it should point to. Audit the live site against that spreadsheet within the first hour after cutover. This single artifact prevents the largest, most common, and most expensive launch failure.

The second is the baseline capture. Take 30 minutes before cutover to export your current rankings, your current Search Console data, and your current organic traffic and conversion numbers. After the launch, this is the only way you will know whether anything is wrong. Without it, the first month is guesswork.

Treat the launch as a one-day event and you will miss the 30 days that decide whether the site performs. Treat it as a window and you will catch the small problems while they are still small.

For ongoing maintenance after launch:

• B2B Website Maintenance Checklist: Monthly Tasks That Matter