Rarely the design. Almost always the plumbing. Forms that go nowhere, redirects that were never mapped, images that were fine on a laptop and enormous on a phone, and analytics that quietly stopped recording. Launch failures are boring, repeatable, and completely preventable.
We have never seen a launch go wrong because a heading was the wrong size. We have seen plenty go wrong because nobody submitted the contact form on the live domain after the DNS change, and three weeks of enquiries went into a mailbox nobody owned.
This is the sequence we work through before a site goes live. It is deliberately written as a process rather than a checklist, because the order matters more than the individual items.
Because the cost of finding a problem multiplies the moment you go live. Before launch, a broken form is a ten minute fix. After launch, it is a ten minute fix plus lost leads you never knew you had, plus a conversation with a client who found it before you did.
The second reason is that launch day compresses everything. DNS propagates, caches clear at different times, and half a dozen things change at once. If you have not tested beforehand, you are debugging in the worst possible conditions with the largest possible audience.
Our rule is that nothing gets tested for the first time on launch day. Everything that can be checked on the staging domain gets checked there, so launch day is only for the handful of things that genuinely cannot be verified until the real domain is live.
Test the real pages on a throttled mobile connection, not the homepage on your office wifi. Run Lighthouse or PageSpeed Insights against your heaviest template, usually a blog post or a product page, because that is where the images and scripts pile up.
Know the targets you are aiming at. Google's Core Web Vitals guidance says Largest Contentful Paint should occur within 2.5 seconds of when the page first starts loading, Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should stay at 0.1 or less.
The detail people skip is the measurement basis. Google states that a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop. That means your fastest visits do not save you. You are being judged on the slower quarter of your real audience.
Before launch you only have lab data, which is a prediction rather than a measurement. Treat a good lab score as permission to launch, not as proof of success, and plan to check field data once real traffic arrives. Interaction problems in particular tend to show up only once real people are clicking things on real devices.
Automated scan first, keyboard test second, and neither one is optional. Run a tool like axe DevTools or WAVE across your main templates, then unplug your mouse and try to use the site with only the Tab key. That second test finds things no scanner catches.
The scale of the problem justifies the time. The WebAIM Million report for 2026 found that 95.9% of home pages had detected WCAG 2 failures, with an average of 56.1 errors per page, up 10.1% from 51 errors the year before. This is not a rare defect.
The good news is that the failures cluster. WebAIM found six issue types accounting for 96% of all detected errors, led by low contrast text on 83.9% of pages, missing alternative text on 53.1%, and missing form input labels on 51%. Fix those three categories and you have removed most of your exposure.
Contrast is the easiest to check against a fixed standard. WCAG 2.2 at AA level requires a contrast ratio of at least 4.5:1 for normal text and at least 3:1 for large-scale text, where large means at least 18 point or 14 point bold. Those are numbers, not opinions, so settle them in design rather than arguing at launch. There is more detail in our guide to making a website WCAG accessible.
Test on at least one real phone, not only the browser's device emulator. Emulators get layout roughly right and tell you nothing useful about touch targets, scroll behaviour, sticky headers, or how a video behaves on cellular data.
Cover the four rendering realities that matter: Chrome, Safari on iOS, Firefox, and Edge. Safari is the one that catches people out, because it is the browser your emulator is least likely to be simulating accurately, and it is on every iPhone your customers own.
Pay particular attention to the awkward sizes. A small phone in landscape, a tablet in portrait, and a laptop at a scaled resolution break more layouts than any of the standard breakpoints do. If a layout only works at exactly the widths you designed for, it does not work.
Services like BrowserStack help when you cannot hold every device, and we still keep a couple of real phones on the desk. Nothing replaces putting a thumb on a button and finding out it is too close to the edge of the screen.
Submit every form yourself, on the live domain, and confirm the message arrives in the inbox that a human actually reads. Then do it again from a different device on a different network. This is the single highest value test on this entire list.
Test the failure paths too, not just the happy one. Submit with a required field empty, with an invalid email address, and with a very long string in a text field. Confirm the error messages are visible, clear, and announced properly rather than communicated only by a red border.
Then follow the message downstream. If the form feeds a CRM, an email tool, or an automation, verify the record appears at the far end with the right fields mapped. A form that sends an email but silently fails to create the CRM record is the kind of bug that surfaces months later.
Finally, check what happens after submission. The confirmation state should be obvious, and any tracking that depends on a thank you page needs to fire on the real page, not just in a test environment.
Start with the one that ruins launches: confirm the staging site is not indexable and the live site is. A noindex tag left over from staging is the most common self-inflicted SEO wound we see, and it can go unnoticed for weeks while traffic never arrives.
Then verify that every page has a unique title tag and meta description, that heading levels run in a sensible order, and that images have real alternative text. Crawl the site with a tool like Screaming Frog to find these at scale rather than clicking through page by page.
Check the machine-readable layer as well. Your sitemap should list only final, indexable URLs, your robots.txt should point at it, and your canonical tags should point at the pages themselves. We wrote about the details in our guide to getting your XML sitemap right.
One more check that costs a minute and is worth far more: view the page source with JavaScript disabled and confirm your actual content is there. If your body text only appears after scripts run, crawlers that do not execute JavaScript see an empty page, and so do some AI systems.
Build the map before you build the site. Export every URL from the old site, decide where each one goes, and test the map against the new site before you switch DNS. Redirects added reactively after launch are always more expensive than redirects planned in advance.
Test the whole list mechanically rather than sampling it. You are checking that each old URL returns a 301 to a real page that returns a 200, in one hop. Chains of redirects and redirects to a generic homepage are both quiet ways to lose the value of a link.
Do not forget the URLs that are not pages. Old PDF files, image URLs used in emails, and links people bookmarked all deserve a destination. We covered the whole process in our guide to setting up redirects without losing traffic.
Only the things that could not be tested before. Confirm the domain resolves and serves HTTPS with a valid certificate, submit the contact form on the real URL, and check that analytics is recording your own visit.
Then verify the search engine side. Submit the sitemap in Google Search Console, run a live URL inspection on your homepage, and confirm the page is fetchable and shows the content you expect. Doing this in the first hour means an indexing problem gets caught in a day rather than a month.
Keep the old site reachable for a short while if you can. Being able to compare a live page against the previous version turns a confusing bug report into a five minute answer.
Automate the checks that are boring and repeatable, and keep the judgement calls human. Link checking, page weight, heading structure, alternative text presence, and basic accessibility scans all run perfectly well on every build without anyone remembering to do them.
What does not automate well is meaning. A tool can confirm an image has alternative text. It cannot tell you the text says "image1" instead of describing the image. It can confirm a button exists. It cannot tell you the label is confusing.
We use AI-assisted review in that gap, for tasks like reading through copy for inconsistencies or spotting pages where the heading and the content disagree. It is genuinely useful as a first pass, and it does not replace a person opening the site and using it like a customer would.
You are ready when someone who did not build the site can complete the main task on a phone without help, when every form has been submitted and received on the live domain, and when your redirect map has been tested end to end. Everything else is refinement.
The honest truth about launches is that you will still find something in the first week. The goal is not perfection, it is making sure the things you find are cosmetic rather than the sort that cost you customers while you sleep.
If you want a second pair of eyes on a site before you push it live, or a proper pre-launch audit on a migration, we are happy to walk through it with you. Let's talk. You can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.