Website Pre-Launch Checklist: What B2B Teams Miss Before Going Live

Most Pre-Launch Checklists Are Useless

Search "website launch checklist" and you get the same recycled list: check your spelling, test your forms, make sure your logo loads. That's table stakes. That's not a checklist. That's common sense.

The stuff that actually determines whether your site performs after launch? Nobody talks about it. AEO readiness. Schema validation. CRO baselines. Core Web Vitals thresholds that changed in 2024 and most teams still haven't caught up with.

This checklist is different. It's built for B2B teams shipping sites that need to drive revenue, rank in both traditional search and AI answer engines, and not fall apart three months after launch.

Use it before every launch. Print it. Share it with your dev team. Skip a section at your own risk.

Performance and Core Web Vitals

Google uses three Core Web Vitals to evaluate page experience. If you fail these at the 75th percentile, you're hurting rankings before your site even gets indexed properly.

LCP (Largest Contentful Paint): under 2.5 seconds. This measures how fast your main content becomes visible. Common killers: unoptimized hero images, render-blocking scripts, slow server response. Fix it by serving images in WebP or AVIF, lazy loading below-fold content, and preloading critical assets.

INP (Interaction to Next Paint): under 200ms. INP replaced FID in 2024 and it's harder to pass. It measures responsiveness across every interaction on the page, not just the first one. If your page feels sluggish when clicking buttons or opening menus, INP will catch it. Fix it by breaking up long JavaScript tasks, reducing main-thread work, and auditing third-party scripts (chat widgets and tag managers are the usual suspects).

CLS (Cumulative Layout Shift): under 0.1. Layout shift happens when elements move around while the page loads. The most common cause: images without defined dimensions, late-loading fonts, and ad/embed containers that resize. Set explicit width and height on all media. Use font-display: swap. Reserve space for dynamic content.

Test with Google PageSpeed Insights and check real-user data in Search Console. Lab scores are useful, but field data is what Google actually uses for ranking.

SEO Foundation

This is the layer most teams think they've covered but haven't actually verified.

Meta titles and descriptions on every page. Not just your homepage. Every CMS template page, every landing page, every utility page. In Webflow, CMS template pages pull meta from collection fields. Make sure those fields aren't empty or still showing placeholder text.

XML sitemap generated and submitted. Webflow auto-generates sitemaps, but verify the output. Check that your sitemap doesn't include staging URLs, password-protected pages, or utility pages you don't want indexed. Submit it in Google Search Console before launch.

Robots.txt configured correctly. The number of sites we've audited where robots.txt accidentally blocks /blog/ or entire CMS paths is alarming. Check it. Read it line by line.

Canonical URLs set. Especially on paginated pages, filtered views, and any page accessible through multiple URL paths. Duplicate content issues don't show up until weeks after launch when Google has crawled everything.

301 redirects mapped and tested. If you're migrating from an existing site, every old URL needs a redirect. No exceptions. Use a spreadsheet. Test each one. A single broken redirect can tank traffic to your highest-performing page. In Webflow, set these up in Project Settings > Hosting > 301 Redirects.

Image alt text on every image. Not "IMG_4392.jpg." Not "image." Descriptive, relevant alt text that serves both accessibility and SEO. This includes CMS images, which most teams forget.

Internal linking structure mapped. Your most important pages should have the most internal links pointing to them. Map this before launch, not after. Link from blog posts to service pages. Link from case studies to relevant capability pages.

AEO Readiness: The Layer Nobody Else Covers

60% of Google searches are now zero-click. AI answer engines like ChatGPT, Perplexity, and Gemini pull content directly and synthesize answers without sending users to your site. If your content isn't structured for these systems, you're invisible in the fastest-growing search channel.

Schema markup on every page type. At minimum: Organization schema on your homepage, BreadcrumbList on every page, Article or BlogPosting on content pages, FAQPage on any page with Q&A content. Use JSON-LD format. Validate with Google's Rich Results Test before launch.

Entity connections via @id referencing. This is where most teams stop. Individual schema blocks are fine, but connecting them through @id references creates an entity graph that AI systems and search engines can traverse. Your Organization schema should reference your FAQ schemas. Your Article schemas should reference your author and organization entities. This is what makes your structured data a system, not just scattered markup. We wrote a full technical breakdown of @id referencing here.

llms.txt file configured. This is a newer standard: a markdown file at /llms.txt that tells AI systems which pages on your site are most important and LLM-readable. Think of it as a sitemap specifically for AI crawlers. It complements robots.txt rather than replacing it. Robots.txt controls access. llms.txt guides AI systems toward your best content.

AI crawler directives in robots.txt. Decide whether you want AI training crawlers (GPTBot, ClaudeBot, Google-Extended) to access your content. If yes, make sure they're not accidentally blocked. If you want to allow citation but block training, you can selectively permit or deny specific bots.

Answer-ready content blocks. AI systems extract content that directly answers questions. Structure key sections of your pages as clear question-and-answer pairs. Use H2/H3 headings as questions. Lead with the direct answer in the first sentence. Then expand. Our guide to FAQ schema beyond the FAQ page covers how to implement this at scale.

CRO Pre-Launch: Will This Site Actually Convert?

A site that loads fast and ranks well but doesn't convert is an expensive content library. Before launch, validate that the site is built to drive business outcomes.

Primary CTA visible above the fold on every page. Not buried. Not subtle. Your visitor should know what action to take within 3 seconds of landing. Test this on mobile, where above-the-fold real estate is even more limited.

Form submissions tested end-to-end. Submit every form yourself. Check that the data arrives where it should (CRM, email, Slack notification, whatever your flow is). Test on mobile. Test with autofill. Test with edge cases like international phone numbers or company names with special characters.

Thank you pages and post-submission redirects configured. Every form should redirect to a confirmation page. This serves two purposes: it tells the visitor their submission went through, and it gives you a URL to use as a conversion event in analytics.

Social proof visible. Testimonials, client logos, case study references. These should be on every high-intent page (homepage, pricing, contact, service pages), not buried on a dedicated testimonials page nobody visits.

Mobile CTA placement tested. Thumb-zone friendly. Easy to tap. Not overlapping with other elements. Mobile visitors are often further down the funnel than desktop visitors. Don't make conversion harder for them.

Analytics conversion events defined before launch. Not after. Define what counts as a conversion: form submission, CTA click, demo booking, scroll depth on key pages. Set up these events in GA4 before you go live so you have baseline data from day one.

Heatmap tracking installed. Tools like Hotjar or Microsoft Clarity show you what visitors actually do on your pages. Install before launch so you start collecting behavioral data immediately. You'll need this for your first CRO sprint 30 days post-launch.

Security and Compliance

SSL/HTTPS enforced sitewide. In Webflow, toggle on SSL in the Hosting tab and enable Force HTTPS. Test that all pages, including CMS pages and asset URLs, load over HTTPS with no mixed content warnings.

Cookie consent banner in place. GDPR applies if you have any EU visitors. CCPA applies for California. Your banner needs to offer real choices (not just "accept all"), and your site needs to actually respect those choices. Dark patterns in cookie consent are becoming a legal liability.

Privacy policy and terms of service published. Linked from the footer. Written for your specific business (not a generic template). If you're collecting form data, your privacy policy needs to explain what you collect, how you store it, and who has access.

Form data handling documented. Where do form submissions go? Who on your team can see them? How long do you retain the data? These aren't just compliance questions. They're the questions a Series A+ company will ask during due diligence.

Accessibility: WCAG 2.2 Level AA

Accessibility isn't optional. It's a legal requirement under ADA Title III, and WCAG 2.2 Level AA is the standard courts reference in the US. Beyond compliance, accessible sites are better sites. They're more usable, more navigable, and they convert better.

Color contrast ratios passing. 4.5:1 minimum for normal text, 3:1 for large text. Test every text/background combination, including buttons, overlays, and CMS content where authors might not be thinking about contrast.

Keyboard navigation working. Tab through every page. Can you reach every interactive element? Can you activate every button, open every dropdown, submit every form? If anything requires a mouse, it's broken for keyboard and assistive technology users.

Focus states visible. When a user tabs to an element, they need a visible indicator showing where they are. Removing default focus outlines for aesthetics is one of the most common accessibility violations. Style them, don't remove them.

Alt text on all images. Decorative images get empty alt attributes (alt=""). Informative images get descriptive text. This overlaps with SEO, but the intent is different: alt text for accessibility describes what the image conveys, not what keywords you want to rank for.

Form labels and error messages. Every input needs an associated label (not just a placeholder). Error messages need to be specific ("Email address is required" not "Error in field 3") and announced to screen readers.

Touch targets at least 44px. WCAG 2.2 added this requirement. Buttons, links, and interactive elements need to be large enough to tap without accidentally hitting something else. Check mobile especially.

Remember the 30/70 rule: automated tools catch about 30% of accessibility issues. A proper audit requires manual testing with assistive technology to catch the rest.

Cross-Browser and Device Testing

Test on real devices, not just browser resize. Chrome DevTools responsive mode is useful for layout checks, but it doesn't catch touch behavior, actual rendering differences, or mobile browser quirks.

Priority browsers: Chrome (desktop and Android), Safari (desktop and iOS), Firefox, Edge. Safari on iOS is the one that breaks things most often. Test it.

Webflow interactions and animations. Custom animations that work perfectly on Chrome desktop can behave differently on Safari or stutter on mid-range Android devices. Test every interaction on at least three different devices.

Forms on mobile. Dropdowns, date pickers, and file upload fields are notorious for breaking on mobile browsers. Test every form variation on iOS and Android.

Tablet breakpoint. The forgotten middle child. Most teams test desktop and mobile, then wonder why their site looks broken on iPads. Webflow lets you set a tablet breakpoint. Use it.

Webflow-Specific Launch Settings

These are the settings that are unique to Webflow and easy to miss if you're used to other platforms.

DNS records updated to new Cloudflare infrastructure. As of January 2026, Webflow requires updated DNS records for all sites. If your site was created before April 2025, you need to migrate to the new records: A record pointing to 198.202.211.1 and CNAME pointing to cdn.webflow.com. Sites on legacy records can't publish updates.

SSL enabled and HTTPS forced. Site Settings > Hosting tab. Toggle both on. Verify that your domain's CAA records (if any) allow Webflow's certificate providers, otherwise SSL provisioning will fail silently.

Sitemap and robots.txt reviewed. Webflow auto-generates both. Go to yourdomain.com/sitemap.xml and yourdomain.com/robots.txt after publishing. Verify the output matches your expectations.

301 redirects configured. Project Settings > Hosting > 301 Redirects. If migrating, import your full redirect map before switching DNS. Test every redirect after the domain is live.

Custom code in place. Head code (analytics, schema, tracking pixels) and footer code (chat widgets, conversion scripts). Verify in Site Settings > Custom Code. Remember that custom code only appears on the published site, not in the designer preview.

CMS content published. New CMS items in Webflow start as drafts. Make sure every CMS item you want live is published. Check both the collection list and individual item status.

Form notifications configured. By default, Webflow sends form submissions to the site owner's email. If you need submissions going to a different address, Zapier, or a CRM, set that up and test it before launch.

Staging vs. production URLs. Make sure no internal links point to your webflow.io staging URL. Search your codebase and CMS content for any references to the staging domain.

Launch Day Operations

Lower DNS TTL 24-48 hours before launch. Set it to the minimum your registrar allows (usually 60-300 seconds). This ensures DNS changes propagate faster when you flip the switch.

Backup the old site. If you're replacing an existing site, take a full backup. Screenshots, Wayback Machine capture, database export, whatever applies. You can't undo a DNS switch.

Test redirects one final time. After DNS propagates, test your full redirect map. Use a tool or script that checks every URL. Don't rely on spot-checking three URLs manually.

Submit sitemap to Search Console. If this is a new domain or a migration, submit your sitemap immediately after launch. Request indexing on your highest-priority pages.

Monitor for 48 hours. Watch for: 404 errors in Search Console, broken form submissions, SSL certificate issues, analytics tracking gaps, crawl errors. The first 48 hours after launch tell you everything you need to know about whether your pre-launch prep was thorough.

Re-crawl in Search Console after 7 days. Give Google a week to process your new site, then check for indexing issues, coverage errors, and any unexpected drops in impressions.

The Checklist Behind the Checklist

Most pre-launch checklists tell you to check your spelling. This one tells you to validate your schema graph, baseline your conversion events, and configure your AI crawler directives. The difference is the difference between launching a website and launching a revenue engine.

If your current launch process doesn't include AEO readiness, CRO baselines, and structured data validation, you're shipping a site that's already behind.

Talk to us about building a launch process that doesn't leave revenue on the table.