The Website Launch Checklist: 45 Checks Before You Go Live (2026)

Key takeaways

• Launch-day disasters are never mysterious — they're the same dozen forgotten items: placeholder text, forms that never send, a staging site still blocking Google.
• Split the list into launch blockers and week-one fixes, or the list paralyzes you and nothing launches.
• The ownership handoff is the most-skipped step — logins, domain, hosting, and licenses in your name, done before you pay the final invoice. It's the hardest thing to fix after launch.
• Test forms, payments, and tracking with real submissions. Demos lie.
• Launch Tuesday to Thursday morning, keep one named human on call for 48 hours, and announce on day three — not minute one.

Your developer says the site is done. It looks done. You pay the final invoice, announce the launch, and go to bed feeling accomplished.

Then the emails start. The contact form submissions never arrived. Your old domain still shows the old site. Google can't find you. And the developer is "a bit busy this week."

None of this is bad luck. Launch-day problems are never mysterious — they're the same dozen items, forgotten under deadline pressure, on nearly every launch. This is the checklist we run before every site we ship: what to verify with your own eyes before you approve the launch and release the final payment.

First: split the list into blockers and week-one fixes

Most launch checklists fail as one flat list of fifty items where nobody can tell what actually stops the launch. Use this split:

The rule: if it touches money, legal liability, ownership, or data you can't reconstruct, it's a blocker. A missing favicon is embarrassing. A form that silently drops enquiries for a week is expensive.

1. Content and copy — the six checks

1. Hunt the placeholders. Search the whole site for "lorem", "TODO", and "coming soon" — including footer widgets, error messages, and email notification templates. Placeholder text in a transactional email is the classic one nobody checks.
2. Get a fresh pair of eyes on the copy. Not you, not the developer — someone who didn't write it. You'll both read what you meant to write, not what's on the page.
3. Verify every contact detail like a customer would. Call the phone number from your mobile — is it tappable, and does it ring the right place? Send an email to the listed address. Check hours and prices against reality, not the three-month-old brief. Wrong phone numbers on launched sites are shockingly common.
4. Give every meaningful image alt text. Describe what the image shows and why it's there — accessibility and SEO in one move. (WebAIM's 2024 scan of the top million home pages found detectable accessibility failures on 95.9% of them; missing alt text is the most common single cause.)
5. Check the favicon. Open the site in a fresh tab and look at the tab icon. A missing or default-CMS favicon makes a new site look unfinished in the one place every visitor stares at.
6. Visit a page that doesn't exist. Type a gibberish URL. You should land on a branded 404 page that helps — search box, links to key pages. A raw server error, or a redirect to the homepage, tells visitors the site isn't finished.

2. The ownership handoff — do this before you pay the final invoice

Most launch checklists skip this section, and it causes the most expensive problems: owners who can't log in to their own site, don't own their domain, or pay for hosting through their ex-developer's account. Every one of those was preventable in a single afternoon before launch.

Your final invoice is the only leverage you will ever have. Once it's paid, you're a support ticket. Get the handoff done first.

1. Admin credentials are in your hands — tested by you. Log in yourself, on your own device, before launch day. If you can't log in to your own site, you don't own it yet.
2. The domain is registered in your name, on your account. Check the registrar yourself. A domain in your developer's account can take your whole business offline over a forgotten renewal or a dispute. Transfer it now, while everyone's cooperating.
3. Hosting is in your name with billing going to you. You should be able to log in, see the plan, and update the payment method. Hosting under the developer's account "for convenience" is a dependency you will regret.
4. Premium plugin and theme licenses are in your name. Many WordPress builds run on the developer's agency license. The day it lapses, your premium theme stops updating — and unmaintained themes are how sites get hacked.
5. You hold a full backup and a restore has been tested. A complete backup file stored somewhere you control — not just on the developer's laptop. An untested backup is a hope, not a backup.
6. Source files and repository access, if any custom code exists. If the site was custom-built, you should have access to the code repository. "The developer has it" is not a backup strategy.
7. A written handoff document. One page: where everything lives, how to publish, how to add a user, who to call when it breaks. If only one person knows how your site works, you don't have a website — you have a hostage situation.

We wrote a full 15-minute ownership audit for exactly this — run through who actually owns your website before you sign off. If your developer pushes back on any item above, treat that as information.

3. The money checks

1. Run a real payment, then refund it. Not test mode — a live transaction for a small amount, refunded immediately. Test mode hides real-world failures: mismatched currency, webhooks pointing at staging, tax rules that only trigger on live keys.
2. Prices, tax, and shipping match reality. Walk the checkout as a customer in your actual location. Staging checkouts usually carry sample data nobody updated.
3. The refund and return policy page exists and matches what you actually do. Write your real policy, not a downloaded template. If the page says "30-day returns" and you do store-credit-only, that's a dispute waiting to happen.
4. Tie the final invoice to the blockers, not the calendar. Final payment releases when the blocker list passes, verified by you. Reasonable developers expect this; the ones who pressure you to pay "because we're basically done" are telling you something.

4. Technical basics, in plain English

Verify each of these in about two minutes:

The robots.txt row deserves emphasis: staging sites are routinely set to block search engines, and that setting migrates to production more often than anyone admits. A site launching with Disallow: / is invisible to Google until someone notices — sometimes months later.

5. SEO before Google ever sees it

Get the basics right now and you skip months of "why isn't my site showing up" pain later.

1. Unique title and meta description on every page. Each page gets a title saying what that page is about, in words a customer would search. Highest-leverage SEO task at launch.
2. One H1 per page, in a sensible heading order. The H1 is the page's headline — there should be exactly one, and it should match what the page is actually about. Subheadings cascade H2, H3 in order. It matters for both Google and screen readers.
3. Set social share images and test the actual preview. Paste your homepage URL into a private message and look at what appears. The auto-generated crop of your hero section is almost never what you want representing your business.
4. Map redirects from old URLs if this replaces an existing site. Every old page with traffic or links needs a redirect to its replacement. Skip this and you donate months of search equity to 404 pages — the number-one cause of post-redesign traffic drops we've seen.
5. Make sure no page is orphaned. Every page should be reachable by clicking links from somewhere else on the site — ideally within three clicks of the homepage. Pages with no internal links are pages Google may never find.

If Google ignores you after launch anyway, work through our 10-minute diagnosis for sites not showing up on Google — it covers the usual suspects in order.

6. Speed and mobile — tested on a real phone

Your developer tested on a $2,000 laptop with fiber internet. Your customers are on three-year-old Androids with one bar of signal. Test like a customer.

1. Load the site on a real mid-range phone, on mobile data — the oldest phone in the office, wifi off. If you're embarrassed by how long it takes, your customers feel the same; they just leave instead of telling you.
2. Know Google's thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. That's how fast the main content appears, how fast the page responds to taps, and how much the layout jumps while loading. Run PageSpeed Insights on your key pages; anything in the red is a blocker.
3. Images are the usual culprit. Every image should be compressed, in a modern format (WebP or AVIF), sized to its display dimensions — not a 4MB photo shrunk by CSS — and lazy-loaded below the fold. On image-heavy sites this one fix routinely cuts load time in half.
4. Check tap targets and text size. Buttons must be comfortably tappable with a thumb, and body text readable without pinching. If you're mis-tapping on your own site, so is everyone else.
5. Confirm the big four browsers. Chrome, Safari, Firefox, and Edge cover roughly 95% of traffic. Pay special attention to Safari on iPhone — it's where the weird rendering bugs live.

More on the issues the score hides: why your website is too slow even if PageSpeed says it isn't.

7. Forms, tracking, and the numbers you'll wish you had

1. Submit every form for real. Every contact, quote, newsletter, and checkout form — filled out as a customer and confirmed received, inbox and spam folder. Forms that "worked in testing" fail in production constantly: wrong recipient, staging-only SMTP credentials, a success message that shows while the email silently dies.
2. Verify analytics in the real-time view. Open the site on your phone and watch yourself appear in the real-time report. If you can't see your own visit, your tracking is broken — and every future marketing decision will rest on bad data.
3. Test conversion events in debug mode. Form submissions, purchases, phone taps — each should fire a named event you can see in your analytics debugger. Sites routinely launch with analytics "installed" but zero events configured: months of traffic, no idea what converted.
4. Wire consent mode to your cookie banner. Your analytics must respect the banner — otherwise you're tracking visitors who declined (a legal problem) or silently losing everyone's data (a measurement problem). Test both paths: accept and decline.
5. Point uptime and error alerts at a phone somebody carries. A free uptime monitor that texts you when the site goes down is the cheapest insurance in this entire checklist.

For the analytics setup itself, our 40-minute GA4 guide walks through tracking only what matters.

8. Legal pages — the boring three

Not exciting, not optional. At minimum, before you take a single enquiry or sale:

• Privacy policy — required the moment you collect anything: names, emails, analytics, cookies. It must describe what you actually collect, not what a template assumes.
• Terms of service — especially if you sell anything.
• Cookie notice — if you set non-essential cookies, you need consent infrastructure, not just a policy page.

Our honest guide to privacy policies covers what small businesses actually need.

9. Launch-day protocol

1. Lower your DNS TTL the day before. Dropping it to 300 seconds a day early means a bad cutover rolls back in minutes, not hours.
2. Launch Tuesday through Thursday morning. Never Friday, never the night before a holiday. Two full working days with everyone available beats a weekend firefight.
3. Write the rollback plan down before you need it — what gets reverted, in what order, by whom. Deciding calmly at 10am beats inventing it at midnight.
4. Name one human on call for 48 hours. Not "the team" — a person, with a phone number, who agreed to it.
5. Announce after the watch period, not at minute one. Go live quietly, run your checks, and let the first visitors be a trickle. Announce on day three, when the forms work and payments clear.

10. The first 48 hours

1. Watch your alerts and error logs. Check uptime and error tracking twice a day. Customers who hit errors mostly leave silently — the ones who email you are the minority.
2. Complete a purchase or enquiry as a customer. Do it again on the live site, on your phone, on day one. Staging tests don't count anymore.
3. Check Search Console coverage. Confirm Google is crawling the new pages without errors, and submit the sitemap if it wasn't submitted at launch.
4. Fix the first thing a real user reports. They will find something your QA never imagined. Fix it fast — early visitors who get a quick fix become loyal ones.
5. Schedule the week-one fixes. Put dates and owners on everything from the "week-one" column. Unscheduled fixes become permanent technical debt.

Launch day is not the finish line — it's the day your site starts being judged by people who owe you nothing. Run the list, hold the final invoice until the blockers pass, and your launch will be boring. Boring launches are the good ones.

Want a second pair of eyes before you go live? Run your staging link through our free website roast. Or book a call and we'll walk the checklist with you before launch day.