Website Launch Checklist 2026: 63 Things to QA Before You Push Live

A website launch is one of those moments that looks clean from the outside and feels messy from the inside.

Design is approved. The build is almost done. Everyone wants to hit publish. Then the real problems show up after launch: forms stop sending, pages get indexed with the wrong titles, analytics miss half your leads, mobile performance tanks, or a staging noindex tag quietly blocks the whole site.

That stuff is expensive.

Portent analyzed more than 27,000 landing pages and found that for B2B lead generation sites, a page that loads in 1 second converts 3x better than a page that loads in 5 seconds, and 5x better than a page that loads in 10 seconds. Meanwhile, WebAIM’s 2026 Million report found 56,114,377 distinct accessibility errors across the top one million homepages, an average of 56.1 errors per page. And according to Google’s SEO Starter Guide, following Search Essentials makes a site more likely to show up in search, even if there’s never a guarantee.

So no, launch QA is not a ceremonial checkbox.

It’s revenue protection.

Below is the website launch checklist we recommend when a business site, lead generation site, or service company website is getting ready to go live. It’s written for business owners who want fewer surprises, and for developers and marketers who don’t want a 10:30 p.m. rollback.

How to use this checklist

Don’t treat this like a giant to-do list you skim five minutes before launch.

Use it in three passes:

1. One week before launch: catch structural issues like SEO rules, analytics, redirects, and template bugs.
2. One day before launch: test forms, mobile layouts, metadata, and page speed on production-like URLs.
3. Right after launch: verify crawling, indexing, events, and uptime on the live domain.

If you’re a business owner, assign an owner to each section. If you’re an agency or internal team, put this into your QA process and make sign-off explicit.

Part 1: Strategy and page-level basics

Before you worry about scripts and headers, make sure the site is clear about what it is supposed to do.

1) Confirm the primary conversion goal on every important page

A services page should not ask people to “learn more” if the real goal is to book a call. A landing page should not send traffic back to the homepage. Every high-value page needs one obvious next step.

2) Match the headline to search intent and ad intent

If someone clicks an ad for “commercial roofing company” and lands on a vague hero that says “Building Better Digital Experiences,” you’ve already lost them.

3) Make sure every core page has a unique title tag

This is basic, but it’s still missed all the time on template-driven builds. Service pages, city pages, blog posts, and case studies all need unique titles.

4) Make sure every core page has a unique meta description

Meta descriptions don’t guarantee rankings, but they shape click behavior. Use them to clarify the offer and set expectations.

5) Confirm there is one clear H1 per page

You can get away with all kinds of technical weirdness on the web, but a page with competing headline structures is still harder for users and search engines to understand.

6) Check that navigation labels are plain English

Visitors don’t want to decode clever labels. “Services,” “Pricing,” “About,” and “Contact” beat mystery-meat navigation almost every time. If your menu still feels crowded or vague, our guide to website navigation fixes that help small businesses get more leads gives you practical before-you-launch cleanup steps.

7) Verify the call to action appears above the fold on mobile

The majority of your users are likely seeing your site on a phone first. If your primary CTA is buried under a giant image stack or slider, fix it.

8) Remove filler copy and fake claims

If you wrote “trusted by hundreds of clients” and the business has served 37 clients, cut it. Trust gets destroyed faster than it gets built.

9) Check location, service, and industry pages for duplicate copy

This matters a lot on local SEO builds and programmatic service pages. If multiple pages say the same thing with a city name swapped in, expect weak performance.

10) Make sure every important page answers the next obvious question

A homepage should lead to services. A services page should show proof. A case study should offer a contact path. Good UX is often just good sequencing.

Part 2: Technical SEO before launch

This is the section that prevents the classic “we launched and disappeared from Google” nightmare.

11) Remove every staging noindex rule

Check the page source, CMS settings, and any SEO plugin settings. This is one of the most common launch mistakes because staging protections are easy to forget.

12) Confirm robots.txt is not blocking important sections

You’d be surprised how often /blog/, /services/, or asset folders are blocked during development and never reopened.

13) Generate a valid XML sitemap

Google’s sitemap documentation notes that XML sitemaps are the most versatile format and can include extra data for images, videos, and localized pages.

14) Make sure the sitemap only includes canonical, indexable URLs

Don’t send Google paginated junk, filtered URLs, staging URLs, or redirected pages.

15) Submit the sitemap in Google Search Console

Google Search Console explicitly supports submitting sitemaps and individual URLs for crawling. Don’t assume discovery alone is enough on launch day.

16) Check canonicals on every template type

Home, services, blog posts, category pages, case studies, and landing pages should all self-canonicalize unless there’s a specific reason not to.

17) Validate redirects from old URLs to new URLs

This is not just an SEO task. Redirects protect bookmarks, backlinks, sales pages, and paid traffic destinations.

18) Test both slash and non-slash URL behavior

Whatever your canonical URL format is, enforce it consistently. Same idea for HTTP to HTTPS and www to non-www, or the reverse.

19) Verify the preferred domain resolves cleanly

Pick one canonical hostname and redirect everything else to it. Split signals create messy reporting and avoidable SEO drift.

20) Check for orphan pages

If a page matters, it should be linked from somewhere sensible. Search engines and humans both rely on internal links.

21) Review internal anchor text on key pages

Use real descriptive text. “Our web design services” tells people more than “click here.”

22) Add schema where it genuinely fits

Organization, LocalBusiness, FAQ, Article, Breadcrumb, and Review markup can help search engines interpret the page, but only if the structured data matches visible content.

23) Test schema with Google’s Rich Results Test

Google’s Rich Results Test exists for a reason. Use it before launch, not after an SEO manager spots warnings three weeks later.

24) Check image filenames, alt text, and compression

Bad filenames and missing alt text make the site harder to understand. Huge images make it slower.

25) Verify 404 and 410 pages behave correctly

Your error page should be branded, useful, and easy to navigate from. A dead end is wasted traffic.

Part 3: Performance and stability

Performance problems are conversion problems. They are also trust problems.

26) Run PageSpeed Insights on the homepage, top services pages, and contact page

Don’t test one page and declare victory. Templates behave differently, and so do content-heavy pages.

27) Test on mobile first, not desktop first

HTTP Archive’s 2025 Web Almanac reports that only 48% of mobile websites achieved good Core Web Vitals, versus 56% on desktop. Mobile is where more sites fail.

28) Compress hero images and remove oversized media

A launch is the wrong time to ship a 4 MB hero video just because it looked nice in Figma.

29) Lazy-load below-the-fold images

This is usually an easy win if your implementation is sane. It reduces initial payload and helps the page feel faster.

30) Audit third-party scripts

Chat widgets, A/B testing tools, heatmaps, cookie banners, ad scripts, and social embeds add up fast. If a script doesn’t support the launch goal, it probably shouldn’t be there.

31) Check font loading behavior

Too many weights, too many families, or bad loading strategy can make a polished design feel slow and unstable.

32) Make sure buttons and forms feel responsive

People notice delay immediately, even if they can’t explain it. If a form submit button hangs with no feedback, they’ll assume it failed and click twice.

33) Verify layout stability on mobile

Unexpected jumps from banner injections, font swaps, or image placeholders create a cheap, unreliable feel.

34) Test uptime monitoring before launch

If monitoring starts after launch, you’ve already created a blind spot.

35) Confirm backups and rollback options exist

Launches go better when rollback is boring.

Part 4: Accessibility and usable forms

Accessibility work is not separate from quality work. It is quality work.

36) Check color contrast on buttons, links, and small text

WebAIM’s 2026 report found low-contrast text remained one of the most common accessibility issues on homepages. If people can’t read it, it doesn’t matter how nice it looks.

37) Make sure every form field has a real label

Placeholders are not labels. If the placeholder disappears when someone types, you’ve removed the instruction they needed.

38) Verify accessible names for icon-only controls

MDN’s documentation on aria-label explains that when a visible label is not available or not appropriate, aria-label can define an accessible name for interactive elements.

39) Test keyboard navigation on menus, forms, modals, and popups

If you can’t use the site without a mouse, the site is not ready.

40) Make sure focus states are visible

Too many polished designs remove focus outlines for aesthetics. That’s a bad trade.

41) Verify error messages are specific

“Something went wrong” is lazy. Tell people which field needs attention and how to fix it.

42) Test every form with valid and invalid inputs

Try empty required fields, malformed emails, very long names, and mobile autofill. QA the way real users behave, not the way you wish they behaved.

43) Confirm form submissions actually arrive where they should

This sounds obvious until you realize the CRM mapping broke, the notifications go to an old inbox, or spam filtering ate the lead.

44) Check thank-you pages and post-submit tracking

Google Analytics documents how to measure lead generation form submissions as key events. If a form matters to the business, its completion should be tracked cleanly.

45) Review phone links, email links, and tap targets on mobile

Buttons that are too small or links that are hard to tap create friction right where people are trying to convert.

Part 5: Analytics, attribution, and consent

A site that launches without clean measurement is a site that starts its life half-blind.

46) Confirm GA4 or your analytics stack is installed on every template

Not just the homepage. Not just the blog. Every page template.

47) Verify your primary conversions are marked correctly

Calls, form submissions, booked demos, quote requests, purchases, and chat leads all need clear definitions.

48) Test source and campaign attribution paths

Submit a test lead from paid traffic, organic search, direct traffic, and email if those channels matter to the business.

49) Check Search Console property setup

Connect the domain property, confirm ownership, and make sure the right people can access it.

50) Link GA4 with Google Ads if paid search is part of the mix

Don’t wait until after launch to realize conversions aren’t eligible for import.

51) Confirm cookie consent behavior matches your implementation

If tags fire before consent is granted where consent is required, you have a compliance and data-quality problem.

52) Review consent mode requirements for EEA traffic if relevant

Google’s guidance for EEA traffic states that to keep using applicable tags for measurement, ad personalization, and remarketing, you must collect consent for the use of personal data from end users based in the EEA and share those consent signals with Google.

53) Exclude internal traffic and development referrals

Otherwise your launch-day testing muddies the first clean baseline you should have.

54) Verify call tracking, CRM sync, and webhook events

A lead that hits the form but never reaches sales is still a lost lead.

Part 6: Security, operations, and post-launch checks

This is the stuff people skip because it isn’t visible in the mockup. It still matters.

55) Force HTTPS everywhere

Mixed content warnings make a site feel broken and can block assets from loading correctly.

56) Check security headers and basic hardening

At minimum, review HSTS, content security policy where appropriate, referrer policy, and permissions policy. Exact implementation varies, but launching with no review here is sloppy.

57) Remove unused plugins, themes, packages, and admin accounts

If the site runs on WordPress, this matters even more. Patchstack’s 2025 State of WordPress Security report details how plugin and theme vulnerabilities continue to dominate the ecosystem.

58) Rotate default credentials and confirm MFA where possible

Especially for hosting, CMS, DNS, and form or CRM integrations.

59) Review legal pages and footer links

Privacy policy, terms, and any required disclosures should be reachable and current.

60) Verify favicon, social share image, and browser tab title

These are small details until a client sends you a screenshot with the default starter icon still showing.

61) Run a live-domain crawl after launch

Crawl the actual site, not the staging version. That’s how you catch redirect chains, missing metadata, orphan pages, and broken canonicals in the environment users actually hit.

62) Manually test the live homepage, top 5 pages, and all lead paths

Human QA still catches things automated crawlers miss, especially copy bugs and weird device-specific behavior.

63) Document what changed, what was tested, and who approved launch

A clean launch log makes post-launch debugging faster and future redesigns much less painful.

How to Prioritize a Website Launch Checklist

If you don’t have time to do all 63 items before launch, do not guess. Prioritize in this order:

1. Revenue blockers: forms, calls, checkout, booking flows, CRM delivery.
2. Indexing blockers: noindex, robots.txt, canonicals, redirects, sitemap submission.
3. Performance blockers: mobile speed, huge media, script bloat, broken layouts.
4. Trust blockers: accessibility issues, broken links, security warnings, sloppy copy.
5. Measurement blockers: analytics events, Search Console, attribution, consent.

That’s the order that protects the business first.

Most Common Website Launch Mistakes on Launch Day

Not the flashy stuff. The boring stuff.

They forget to test the thank-you page on mobile. They forget to change the notification email on a contact form. They forget the canonical tag still points to staging. They launch a giant new video background and wonder why conversions dip. They assume analytics is working because the pageview count looks normal.

Launch problems usually aren’t caused by one catastrophic error. They’re caused by five small misses that stack together.

A slow site plus a weak CTA plus broken event tracking plus one form delivery bug is enough to make a good website look like it “just isn’t performing.”

Website Launch Checklist Final Takeaway

A website launch should not feel like a coin flip.

If you have a real checklist, clear ownership, and one person accountable for final QA, most launch disasters are avoidable. That’s true whether you’re launching a five-page local service site or a 5,000-page content-heavy property.

The goal is simple: when the site goes live, it should be fast, trackable, indexable, usable, and ready to convert.

If you want help pressure-testing your next redesign, rebuild, or migration before it goes live, talk to us here.