Website Launch Checklist: 22 Things That Break Day One

A website launch does not fail loudly. Nobody calls to tell you the new site is broken. It looks great, the owner is happy, and then thirty days later the lead count is down and nobody can say why.

That is the shape of a launch failure on a service-business site: the site works, the plumbing behind it does not. The form posts and shows a thank-you page — and emails nobody. The tag fires — and records nothing Google Ads can bid on. The phone number sits in the header as plain text on a phone.

This is the launch checklist we'd hand a contractor before we let a service-business site go live, and the specific test that proves each item — not "check your forms work," but "submit a real form from a personal email and confirm the CRM record exists." If you are also changing URLs in this launch, read how to redesign a website without losing rankings first; redirect mapping is a separate job and this post does not cover it.

What breaks in the first 48 hours after a website goes live?

Six systems break, and 22 checks cover all of them: indexation flags, form delivery, analytics events, click-to-call, call-tracking number swap, and stale legacy details. None of them are visible from the homepage, which is exactly why they survive launch day.

We're ordering these by what they cost you, not by how often they happen — we don't have a launch-failure frequency dataset and we're not going to invent one. Every item has a verification step you can perform in under two minutes.

Is your staging noindex still on the live site?

This is the single most expensive two-line mistake in web design: a noindex meta tag that was correct on staging, shipped to production, and never removed. The site is live, beautiful, and invisible to Google — sometimes for months, because nothing on the page tells you.

Verify it by viewing the page source (not the rendered inspector) on five different template types — homepage, a service page, a location page, a blog post, and the contact page. Search the source for "noindex" and for "X-Robots-Tag" in the response headers. One template can carry it while the others are clean.

The second failure mode is the opposite one, and it is subtler. Google's documentation on blocking indexing is explicit: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file." If the crawler is blocked, "the crawler will never see the noindex rule, and the page can still appear in search results." So a staging site that is both disallowed in robots.txt and tagged noindex can still get indexed — Google can never read the tag that would have removed it.

Google says the same thing about robots.txt itself: it "is not a mechanism for keeping a web page out of Google," and "a page that's disallowed in robots.txt can still be indexed if linked to from other sites." Password-protect staging. Do not rely on a disallow line.

If a staging site is already indexed, the fix has two halves. Use the Removals tool in Google Search Console for the emergency, then make it permanent — because Google's Removals documentation states a removal request "lasts only about six months," and that "blocking a URL does not prevent Google from crawling your page, only from showing it in Search results." Permanent means a 404/410, a password, or a crawlable noindex. Google's own instruction on that page: "Do not use robots.txt as a blocking mechanism."

Does your contact form actually deliver, and how do you prove it?

You prove it by submitting a real form from an email address that is not on your team, and then confirming the message exists in three places: the destination inbox, the spam folder if it is not in the inbox, and the CRM. A form that shows a thank-you page has proven nothing except that JavaScript ran.

The usual cause is authentication, not code. The form plugin sends mail as you@yourdomain.com from a server your SPF and DMARC records have never heard of, so Google Workspace quietly bins it. Nothing errors. The submission counter goes up. The inbox stays empty.

Run this test properly. Use a distinctive fake name — "Launch Test 3" — so you can search for it. Submit from a personal Gmail. Then check: did the notification arrive; did it land in spam; did the CRM create a record with the right owner and source; did the lead get the autoresponder; and did the thank-you state fire the conversion event.

This matters more than it looks. In a 2011 Harvard Business Review study, firms that contacted an online lead within an hour were nearly seven times as likely to qualify that lead — defined as having a meaningful conversation with a key decision maker — as firms that waited just one hour longer. A form that emails nobody is not a slow response. It is an infinite one. While you are in there, make sure the same form is not letting bots through: see how to kill contact form spam without killing real leads.

Is your GA4 conversion event configured, or just firing pageviews?

In GA4, an event that fires is not a conversion until you explicitly mark it as a key event. Google's documentation on key events says it plainly: "Any event you collect can become a key event. To measure a key event, create or identify an event that measures the action and then mark the event as a key event." Until you flip that toggle, your form submissions are just traffic.

This is the failure that makes month one unmeasurable. Everything looks installed. The tag is on every page, Realtime shows users, the reports fill up — and the Key events column reads zero, so you cannot tell whether the new site is beating the old one.

Verify it in four steps. Open DebugView and submit a form on the live site; confirm your form event appears with the right name. In Admin, confirm that event is toggled as a key event. Wait 24 hours and confirm the Key events column in the Landing pages report is non-zero. Then, if you run ads, confirm the Google Ads conversion built from that key event shows a status of Recording — otherwise Smart Bidding is optimizing against nothing.

Pick your analytics stack before launch, not after. We compare the realistic options in GA4 vs Plausible vs Fathom for service businesses.

Does your click-to-call link work on a real phone?

Test it on an actual iPhone and an actual Android, not in a desktop mobile emulator — an emulator will happily render a phone number that does nothing when a thumb hits it. The number must be a tel: link, and the digits that appear in the dialer must be the digits you want ringing.

Three things go wrong. The number is typed as plain text in the header, so tapping it does nothing. It is a tel: link, but the href carries the old number while the visible text shows the new one. Or the tel: string contains characters the dialer chokes on, so the call drops a digit.

Mobile is where this bill comes due. Zuko's form benchmarking database, covering over 93 million tracked sessions, puts desktop form completion at 54.48% versus 47.53% on mobile — mobile visitors are measurably less willing to fill in a form, which is exactly why an HVAC or plumbing site leans on the phone. If the tap does not dial, that visitor is not filling out your form instead. They are calling the next result.

Check the header, the footer, the sticky mobile call bar, every service page, and the thank-you page. They are frequently hardcoded in different components, and only one of them gets updated.

Is your call tracking swapping numbers on the live site?

Verify dynamic number insertion by clicking one of your own live ads on a phone and watching the number on the page actually change — not by trusting the tracking vendor's dashboard, which reports what it thinks it did, not what your production site rendered.

DNI is JavaScript. It runs after the page paints, it needs the right pool assigned to the right source, and it breaks the moment a developer changes the class or ID the script targets. A launch is exactly when that happens. When it fails, every paid call gets attributed to organic — and you cut the ad budget that was actually working.

There is one number the swap must never touch: the NAP number in your footer, your LocalBusiness schema, and your Google Business Profile. Those three must match each other and stay static. Google's guidance for AI features is blunt on the underlying principle — "make sure your structured data matches the visible text on the page." A swapped tracking number in schema is a self-inflicted consistency problem. How dynamic number insertion works without breaking local SEO covers the setup in detail.

Which old details are still hiding in your footer and schema?

Grep the codebase for the old phone number, the old address, the old email domain, and the staging hostname — all four survive launches, and all four hide in components nobody reads. A visual review of the homepage will not find any of them.

The usual suspects: the old suite number in the footer, an info@ address that forwards to a person who left, a copyright year that is two years stale, a LocalBusiness schema block copied from the previous site with the previous hours, and OG image URLs still pointing at staging.

Verification is mechanical. Search your repository for the old number in every format it might appear — with dashes, with dots, with parentheses, and as raw digits in a tel: href. Then run one page through Google's Rich Results Test and read the parsed schema fields against what is visible on the page. If the schema says one thing and the page says another, fix the schema.

If your site was built on a template you inherited, the odds of a stale schema block are high. A technical SEO audit of a service-business site catches these in an afternoon, and our technical SEO service exists mostly because this class of bug is invisible until it costs you.

What do you check on day 7 and day 30?

On day 7, confirm indexation is happening: Search Console shows the sitemap as Success, key pages return "URL is on Google" in the URL Inspection tool, and the Pages report is not filling up with "Excluded by noindex tag." On day 30, confirm the money is moving: key events counted, calls answered, forms in the CRM.

Submit the sitemap and then be patient about it. Google's sitemap documentation caps a single sitemap at "50MB (uncompressed) or 50,000 URLs," and is careful to note that "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site." A sitemap speeds discovery. It does not buy indexation.

Day 30 is also the first honest read on speed. Google's Core Web Vitals thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less — each measured at the 75th percentile of real-user page loads, split by mobile and desktop. Lab scores from launch week are a guess; the field data at day 30 is the truth.

• Day 1: all 22 checks above, done on a real phone and a real desktop, by someone who is not the developer who built it
• Day 7: sitemap Success, key URLs indexed, no unexpected noindex exclusions, GA4 key events counting, call tracking swapping
• Day 30: field Core Web Vitals at the 75th percentile, key events versus the pre-launch baseline, lead volume versus the old site, every form-to-CRM path retested

The whole point of the protocol is that it is falsifiable. "The forms work" is an opinion. "I submitted as Launch Test 3 from a Gmail account at 9:14am and the record exists in the CRM with source = Organic" is a fact. Launch on facts.

If you have already launched and you are not sure which of these 22 checks passed, that is what an audit is for. We build conversion-focused websites with this protocol baked in, and if you just want to know what is currently broken on a site you already own, Get my free audit and we will tell you which items are failing right now.