A website launch has exactly one moment where everything has to work at once. The DNS cutover happens, traffic arrives, and every mistake your team made in the last three months becomes public simultaneously.
I spent five years in digital content operations at Samsung, running pre-publish QA and launch support for Samsung.com. I've been the person staring at a staging environment at 11 PM the night before a launch, working through a checklist, knowing that whatever I missed would be live by morning.
Here's the process I used. It works on any CMS, any site, any team size — including a team of one.
Why launches break
In my experience, launches don't break because of one catastrophic bug. They break because of twenty small things nobody checked:
- A hero image that looks perfect on desktop but crops someone's face out on mobile
- A product page linking to a PDF that 404s
- Meta descriptions that are still "Lorem ipsum" from the template
- An analytics tag that fires on staging but was never added to production
- A "Buy now" button that works in Chrome and does nothing in Safari
Each one is trivial. Together, they're a launch-day disaster. A process beats heroics.
The process, step by step
1. Freeze the content
Before you QA anything, get a content freeze. No new pages, no edits, no "just one quick change." Every change after the freeze invalidates the checks you already ran. In Jira, I marked the freeze as a hard status change so the whole team could see it. If your team won't agree to a freeze, scope your audit to a snapshot and note the timestamp — at least you'll know what you actually checked.
2. Crawl the staging site
Run a crawler (Screaming Frog's free tier covers 500 URLs) and export everything. You're looking for:
- Broken links — internal and external. External links rot constantly; check every one.
- Redirect chains — especially after a migration. A chain of three redirects is a page that loads slowly for no reason.
- Missing or duplicate titles and meta descriptions — template leftovers are among the most common findings I've seen.
- Images over 500KB — page speed killers. Flag them for compression.
- Orphan pages — pages with no internal links pointing to them. If nothing links to it, users can't find it, and neither can search engines.
This one step surfaces more issues than any other single check. It's also the step most teams skip because "we'll check manually." You won't. Crawl it.
3. Walk the money paths
Identify the 3–5 pages that matter most — homepage, top product pages, checkout or contact flow — and test them by hand, end to end, like a user would:
- Fill out every form. Submit it. Confirm the confirmation page loads and the email actually arrives.
- Click every CTA. On every browser you support.
- Test on a real phone, not just responsive mode in dev tools. Real phones have real rendering quirks.
I call these the money paths because if they're broken, nothing else matters. A perfect blog archive doesn't save a broken checkout.
4. The device and browser matrix
You don't need 40 devices. You need the ones your analytics say your users have. At minimum:
- Chrome and Safari on desktop
- Safari on iPhone, Chrome on Android
- One tablet view
Check layout, navigation, and forms on each. Take screenshots. An outsized share of the issues I found lived in exactly one place: Safari on iOS, usually a flexbox or video autoplay issue.
5. SEO and analytics spot-check
- Is there a robots.txt? Does it block staging but allow production? (Getting this backwards is one of the most expensive mistakes you can make on launch day.)
- Are canonical tags present and correct?
- Is the analytics/GTM container on every template, including the new ones?
- Are 404 and 500 pages branded, or are they server defaults?
6. Accessibility basics
You don't need a full WCAG audit before launch, but check the cheap wins: alt text on images (especially linked images), keyboard navigation on the main menu, color contrast on body text, and form labels. These take an hour and prevent the most embarrassing findings.
7. The go-live checklist
The night before, verify the boring infrastructure stuff:
- DNS cutover plan and who owns it
- SSL certificate installed and forced (http → https redirect working)
- Staging environment locked or de-indexed so it doesn't compete in search
- Rollback plan — who decides, how fast, and what's the trigger
- Who's on call for the first 24 hours
How long does this take?
For a site under 100 pages: about two days, solo. Day one is the crawl and the money paths. Day two is browsers, SEO, accessibility, and writing up the findings. For a 1,000-page site, add a day for triage and prioritization.
The deliverable is a prioritized list: blockers (fix before launch), should-fix (fix this week), and nice-to-have (backlog). No launch I've ever worked had zero findings. The goal isn't perfection — it's knowing what's broken before your users do.
The part nobody wants to hear
The process only works if someone actually runs it. On most teams, launch QA is everyone's responsibility, which means it's nobody's. The single highest-value thing I did on launches wasn't finding bugs — it was being the person whose job it was to look.
If you're launching a site and you don't have that person: that's the gap.
I do pre-launch website audits for agencies and site owners — the full process above, delivered as a prioritized findings report in 5–7 days. If your launch is coming up, drop a comment and I'll walk you through what an audit would cover for your site.
Top comments (0)