The 15-Minute Pre-Launch Website QA That Saved Our Product Launch

Reading time: 16 minutes

TLDR

Our redesigned marketing site looked perfect in QA two days before launch. Scan caught seven critical issues standard QA missed: broken social sharing tags, missing schema markup, mobile viewport bugs, sitemap errors, accessibility failures, missing security headers, and slow performance under load. Fixed everything pre-launch and avoided day-one disasters. Standard QA checks if pages load. Scan checks if they convert, rank, and deliver results. Always audit staging sites with production-level tools before launching.

In This Article

The scenario: New marketing site redesign, launching in 48 hours

Our internal QA process: Design approved, Copy finalized, Pages render correctly, Forms submit

We felt ready to launch.

Then we ran Scan on the staging site.

Result: 7 critical issues that would have destroyed our conversion rate, SEO rankings, and credibility on day one.

Here’s what we caught 48 hours before launch. And why pre-launch audits are non-negotiable.

The Pre-Launch False Confidence Problem

Standard pre-launch QA checklist:

  • Does the site load?
  • Do pages look correct on desktop and mobile?
  • Do forms submit successfully?
  • Are there any obvious broken links?

What this checklist misses:

  • Social sharing previews (Open Graph tags)
  • Schema.org structured data for SEO
  • Mobile viewport edge cases
  • Accessibility for screen readers
  • Sitemap accuracy
  • Performance under load
  • Security headers

The result: Sites that look perfect in QA but fail in production when real users arrive from Google, Twitter, and LinkedIn.

KEY TAKEAWAY: Standard QA checks if pages load. Pre-launch audits check if they convert. The gap between “site works” and “site drives conversions” includes social previews, schema markup, mobile edge cases, accessibility, and performance under load. All invisible to standard QA but critical to launch success.

Our Pre-Launch Audit: What Scan Found

Context: Marketing site redesign for new product launch

  • Goal: Drive signups from Product Hunt launch (expecting 5,000+ visitors day one)
  • Timeline: 48 hours until public launch
  • Internal QA status: All green, design/dev teams confident

Scan audit results: 7 critical issues, 3 of them showstoppers

Issue #1: Broken Social Sharing Previews (SHOWSTOPPER)

What we tested internally: Clicked “Share on Twitter” button, saw it worked

What Scan caught: Open Graph image was 404ing

The problem:

<!-- Our code -->
<meta property="og:image" content="https://staging.example.com/og-image.png" />

<!-- The reality -->
<!-- /og-image.png returned 404 because we forgot to add it to the build output -->

Why this matters:

  • We planned to launch on Product Hunt
  • Product Hunt auto-generates preview cards from Open Graph tags
  • Our preview card would show broken image icon instead of compelling visual
  • Twitter shares would have no image preview
  • LinkedIn shares would use fallback (tiny logo, not full hero image)

Impact if we’d launched with this bug:

  • Product Hunt listing looks unprofessional (broken image in preview)
  • Social shares get 50-70% fewer clicks without image preview (industry benchmark)
  • Expected 5,000 visitors → would have been ~2,000 due to poor social CTR

The fix (5 minutes):

  1. Added og-image.png to /public folder
  2. Verified image loaded at https://staging.example.com/og-image.png
  3. Tested with OpenGraph.xyz preview tool

KEY TAKEAWAY: Broken social previews cost 50-70% fewer clicks on shares. For a Product Hunt launch expecting 5,000 visitors, broken Open Graph tags would have reduced that to 2,000. a 3,000 visitor loss from one missing image file. Five minutes to fix pre-launch vs thousands of lost visitors post-launch.

Issue #2: Missing Schema Markup (HIGH PRIORITY)

What we tested internally: Checked that pages rendered correctly in browser

What Scan caught: Zero structured data on any page

The problem: No Organization, WebSite, or Product schema.org markup

Why this matters:

  • Schema markup helps Google understand what your site is about
  • Competitors with schema get rich snippets (star ratings, prices, FAQs) in search results
  • We’d rank lower in search results without structured data

Example of what we were missing:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Our Product Name",
  "applicationCategory": "BusinessApplication",
  "offers": {
    "@type": "Offer",
    "price": "99",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "47"
  }
}

Impact if we’d launched without this:

  • No rich snippets in Google (competitors would outshine us)
  • Slower indexing by search engines (schema helps crawlers understand context)
  • Missed opportunity for pricing/rating display in SERPs

The fix (30 minutes):

  1. Added Organization schema to homepage
  2. Added SoftwareApplication schema to product page
  3. Added FAQPage schema to help center
  4. Validated with Google Rich Results Test

Issue #3: Mobile Viewport Bug on iOS Safari (SHOWSTOPPER)

What we tested internally: Checked responsive design in Chrome DevTools mobile simulator

What Scan caught: Hero section cut off on iOS Safari (real device testing)

The problem:

/* Our CSS */
.hero {
  height: 100vh; /* This works in Chrome, breaks in iOS Safari */
}

Why this breaks on iOS:

  • iOS Safari’s bottom nav bar overlaps content
  • 100vh doesn’t account for Safari’s dynamic UI (address bar shrinks/grows on scroll)
  • Hero CTA button was hidden below the fold

Impact if we’d launched with this bug:

  • 40% of mobile visitors use iOS Safari (our analytics data)
  • Product Hunt traffic is 60% mobile (industry benchmark)
  • Expected 3,000 mobile visitors → 1,200 would see broken hero with hidden CTA
  • Estimated 30-50% conversion loss on iOS traffic

The fix (10 minutes):

/* Fixed CSS */
.hero {
  min-height: 100vh;
  min-height: -webkit-fill-available; /* iOS Safari fix */
}

Issue #4: 404 Errors in Sitemap (MEDIUM PRIORITY)

What we tested internally: Verified sitemap.xml generated correctly

What Scan caught: 3 URLs in sitemap returned 404

The problem: We renamed pages during redesign but forgot to update sitemap

Why this matters:

  • Google crawls URLs from your sitemap
  • 404s waste crawl budget and signal poor site quality
  • Google may deprioritize crawling if sitemap is inaccurate

Impact if we’d launched with this:

  • Google would crawl 3 broken pages on launch day
  • Credibility hit (search console would show sitemap errors)
  • Slower indexing of new pages (wasted crawl budget)

The fix (5 minutes):

  1. Removed old URLs from sitemap
  2. Verified all sitemap URLs returned 200 status
  3. Tested with XML Sitemap Validator

Issue #5: Accessibility Failures (HIGH PRIORITY)

What we tested internally: Clicked through pages, everything worked

What Scan caught (via pa11y): 11 WCAG 2.1 AA violations

The violations:

  1. Form labels not associated with inputs (WCAG 1.3.1)

    <!-- Broken -->
<label>Email</label>
<input type="email" />

<!-- Fixed -->
<label for="email">Email</label>
<input id="email" type="email" />

  2. Insufficient color contrast on CTA button (WCAG 1.4.3)

    • Button text: #6C63FF on white background
    • Contrast ratio: 3.2:1 (minimum: 4.5:1)
    • Fixed: Changed to #4C3FFF (4.6:1 ratio)

  3. Missing alt text on hero image (WCAG 1.1.1)

    • Screen readers announced “image” with no description
    • Fixed: Added descriptive alt text

  4. Keyboard navigation broken on custom dropdown (WCAG 2.1.1)

    • Tab key skipped dropdown menu (used div instead of button)
    • Fixed: Changed to semantic <button> element with proper ARIA

Why this matters:

  • 15-20% of web users have accessibility needs (screen readers, keyboard-only navigation, color blindness)
  • Inaccessible forms = lost conversions
  • Accessibility lawsuits are real (especially for B2B SaaS selling to enterprises)

Impact if we’d launched with these bugs:

  • Screen reader users couldn’t complete signup form (label/input mismatch)
  • Keyboard-only users couldn’t navigate dropdown menu
  • Color blind users couldn’t read CTA button text
  • Estimated 5-10% conversion loss from accessibility issues

The fix (45 minutes):

  • Fixed form label associations
  • Adjusted button color contrast
  • Added alt text to images
  • Made dropdowns keyboard-accessible

Issue #6: Missing Favicon (LOW PRIORITY, HIGH IMPACT)

What we tested internally: Didn’t check favicon (assumed it worked from old site)

What Scan caught: Favicon 404ing, browser showed generic icon

Why this matters:

  • Favicon shows in browser tabs, bookmarks, and search results
  • Professional polish signal (missing favicon looks amateur)
  • Brand recognition (users with 20+ tabs open identify you by favicon)

Impact if we’d launched without this:

  • Generic browser icon in tabs (looks unfinished)
  • Lower perceived credibility on Product Hunt (details matter)
  • Missed branding opportunity in bookmarks

The fix (5 minutes):

  1. Generated favicon from logo using RealFaviconGenerator
  2. Added to /public folder
  3. Verified in browser

Issue #7: Performance Regression (MEDIUM PRIORITY)

What we tested internally: Site felt fast on our dev machines (MacBook Pros, fast internet)

What Scan caught: Lighthouse performance score 62/100 (down from 95/100 on old site)

The problem: Unoptimized images from design team

Why this matters:

  • Google uses Core Web Vitals as ranking factor
  • Slow sites have higher bounce rates (53% of mobile users leave if site takes >3 seconds)
  • Product Hunt traffic is impatient (they’re browsing 50+ products)

Impact if we’d launched with this:

  • Higher bounce rate (especially on mobile)
  • Lower SEO rankings due to poor Core Web Vitals
  • Bad first impression (slow site = low-quality product perception)

The fix (20 minutes):

  1. Converted hero image from PNG (2.4 MB) → WebP (240 KB) = 10x smaller
  2. Added loading="lazy" to below-the-fold images
  3. Enabled gzip compression on hosting
  4. Result: Lighthouse score 62 → 94

The Avoided Disaster: What Would Have Happened

If we’d launched without pre-launch Scan audit:

Day 1: Product Hunt Launch

Expected: 5,000 visitors, 150 signups (3% conversion rate)

Reality (without fixes):

  • Social sharing broken → 40% fewer clicks from Twitter/LinkedIn → 3,000 visitors instead of 5,000
  • iOS Safari bug → 40% of mobile visitors see broken hero → 30% conversion loss on mobile → 90 signups instead of 150
  • Accessibility failures → 5-10% conversion loss → 81 signups instead of 90
  • Performance regression → 10% bounce rate increase → 73 signups instead of 81

Actual result without fixes: 73 signups (vs expected 150)

Lost opportunity: 77 signups × $99/mo LTV (12 months) = $91,476 in lost ARR

Week 1: SEO Impact

Without schema markup:

  • Competitors rank higher with rich snippets
  • Our organic CTR: 2.1% (vs 3.5% with schema)
  • Lost organic traffic: 40% fewer clicks from Google

Month 1: Reputation Damage

Without accessibility fixes:

  • Negative Product Hunt comments: “Can’t even use the signup form with my screen reader”
  • Twitter complaints about iOS bug: “Hero section cut off on iPhone, CTA not visible”
  • Lost credibility during critical launch window

The Pre-Launch Audit ROI

Cost of Scan audit: $25

Time to review and fix issues: 2 hours (distributed across team)

Avoided losses:

  • $91K in lost ARR from conversion issues
  • 40% organic CTR loss from missing schema
  • Reputation damage during launch window

ROI: $25 → prevented $91K loss = 3,640x return

Bonus: Peace of mind. We launched confidently instead of scrambling to fix bugs post-launch.

KEY TAKEAWAY: A $25 pre-launch audit prevented $91,000 in lost revenue from conversion killers. The 7 issues caught (broken social sharing, iOS viewport bug, accessibility failures, missing schema, performance regression, sitemap errors, missing favicon) were invisible to standard QA but would have destroyed our Product Hunt launch. The ROI isn’t just financial. It’s the difference between confident launch and day-one scramble.

The Pre-Launch Audit Checklist (How to Do This Yourself)

When to run pre-launch audit: 24-48 hours before launch (enough time to fix issues, not so early that you make breaking changes after)

What to test:

1. Social Sharing (5 minutes)

  • Open Graph tags present and correct
  • og:image actually loads (paste URL in browser)
  • Twitter Card tags present
  • Test preview with OpenGraph.xyz

Tools: OpenGraph.xyz, Twitter Card Validator, LinkedIn Post Inspector

2. Schema Markup (5 minutes)

  • Organization schema on homepage
  • Product/Service schema on product pages
  • Breadcrumb schema on deep pages
  • FAQPage schema on help/FAQ pages

Tools: Google Rich Results Test, Schema.org Validator

3. Mobile Testing (10 minutes)

  • Test on real iPhone (iOS Safari)
  • Test on real Android (Chrome)
  • Check viewport height issues (100vh bugs)
  • Verify forms work on mobile keyboards
  • Test horizontal scroll (shouldn’t exist)

Tools: Real devices (not just Chrome DevTools simulator), BrowserStack

4. Accessibility (10 minutes)

  • All images have alt text
  • Form labels associated with inputs (for attribute)
  • Color contrast meets WCAG AA (4.5:1 minimum)
  • Keyboard navigation works (Tab through entire page)
  • Screen reader test (turn on VoiceOver on Mac)

Tools: pa11y, axe DevTools, WAVE browser extension

5. Technical SEO (10 minutes)

  • Sitemap.xml generated and all URLs return 200
  • Robots.txt allows crawling (not blocking production accidentally)
  • Meta descriptions unique and under 160 characters
  • Title tags unique and under 60 characters
  • Canonical tags pointing to correct URLs

Tools: Screaming Frog (free for <500 URLs), Scan

6. Performance (5 minutes)

  • Images optimized (use WebP, compress JPGs)
  • Lighthouse score >90 on mobile
  • No render-blocking resources
  • Lazy loading on below-the-fold images

Tools: Lighthouse, WebPageTest, Scan

7. Forms & Conversions (5 minutes)

  • All forms submit successfully
  • Email validation works correctly
  • Thank you page loads after submission
  • Form submissions tracked in analytics
  • Error messages display correctly

Manual testing: Fill out every form on staging site

How Scan Streamlines This (The $25 Shortcut)

DIY pre-launch audit: 50 minutes across 7 categories, multiple tools

Scan pre-launch audit: 5 minutes, one report

What Scan checks automatically:

  • Social sharing tags (Open Graph, Twitter Cards)
  • Schema markup (validates presence and correctness)
  • Mobile viewport issues (real iOS/Android testing)
  • Accessibility (pa11y integration, 150+ WCAG checks)
  • Technical SEO (sitemap, robots.txt, meta tags, canonicals)
  • Performance (Lighthouse audit, Core Web Vitals)
  • Broken links and 404s

The output: Prioritized checklist of issues to fix before launch

Our pre-launch audit:

  • Scan report generated: 5 minutes
  • Review and triage: 10 minutes
  • Fix issues: 2 hours (distributed across team)
  • Retest: 5 minutes

Total time: 2.5 hours from audit to ship-ready

Compare to post-launch scramble:

  • Discover issues: 1-3 days (as users report bugs)
  • Emergency fixes: 8+ hours (high-stress, reactive)
  • Reputation damage: Already done (can’t undo bad launch day)

Pre-Launch Audit vs Post-Launch Firefighting

Pre-Launch Audit Approach

Timeline: Run Scan 48 hours before launch

Mindset: Proactive, calm, “let’s catch issues before users see them”

Process:

  1. Run Scan on staging site
  2. Review issues with team (10 minutes)
  3. Prioritize fixes (SHOWSTOPPER → HIGH → MEDIUM → LOW)
  4. Assign tasks (split across dev/design/content teams)
  5. Fix issues over 24-48 hours
  6. Re-run Scan to verify fixes
  7. Launch confidently

Cost: $25 Scan + 2-3 hours team time

Outcome: Clean launch, no surprises

Post-Launch Firefighting Approach

Timeline: Launch → discover issues → scramble to fix

Mindset: Reactive, stressed, “why didn’t we catch this?!”

Process:

  1. Launch site publicly
  2. Users start reporting issues:
    • “Your site is broken on iPhone”
    • “I can’t submit the signup form with my screen reader”
    • “Social share preview shows broken image”
  3. Drop everything to investigate
  4. Emergency fixes in production (high-stress, high-risk)
  5. Deploy hotfixes throughout launch day
  6. Reputation damage already done (bad Product Hunt comments, social media complaints)

Cost: 8+ hours team time + opportunity cost + reputation damage

Outcome: Stressful launch, missed conversions, credibility hit

KEY TAKEAWAY: Pre-launch audits are proactive, calm, and prevent disasters. Post-launch firefighting is reactive, stressful, and repairs damage after it’s done. The cost difference: $25 + 2 hours pre-launch vs 8+ hours of emergency fixes + lost conversions + reputation damage post-launch. Technical audits should happen before users arrive, not after.

Real-World Pre-Launch Audit Examples

Example 1: SaaS Startup Redesign

Caught 48 hours pre-launch:

  • Pricing page 404ing (main conversion page!)
  • Signup form missing required CSRF token (security vulnerability)
  • Blog images not loading (broken CDN configuration)

Avoided: Launch day scramble, zero signups due to broken form, security exposure

Example 2: E-Commerce Product Launch

Caught 24 hours pre-launch:

  • Product images not optimized (4-5 MB each)
  • Mobile checkout flow broken on iOS Safari
  • Missing product schema markup (no rich snippets)

Avoided: Slow site → high bounce rate, lost mobile sales, poor SEO visibility

Example 3: Content Marketing Site

Caught 72 hours pre-launch:

  • Social previews using placeholder image (“Replace with real image”)
  • Blog post URLs not in sitemap
  • Newsletter signup form not connected to email provider

Avoided: Embarrassing social shares, poor indexing, zero email captures

When to Run Pre-Launch Audits

Ideal Timing: 48 Hours Before Launch

Why 48 hours:

  • Enough time to fix showstopper issues
  • Not so early that you make breaking changes after audit
  • Team still has context on recent code changes
  • Low-stress timeline (not same-day panic)

Also Run Audits For:

Major redesigns - Regressions happen during visual overhauls

Platform migrations - Moving from WordPress → Webflow → custom, things break

New features - Checkout flow, pricing page, product launch

Before marketing campaigns - Don’t drive paid traffic to broken site

Post-deployment - Verify production matches staging

The Bottom Line

Our internal QA: Site loads, pages look correct, forms work

Scan pre-launch audit: 7 critical issues that would have killed our launch

The gap: Visual QA catches obvious bugs. Technical audits catch invisible conversion killers.

One $25 Scan audit caught issues that would have cost us $91K in lost ARR and damaged our reputation during launch.

Your staging site probably looks perfect. But is it technically ready?

What to Do Next

Option 1: DIY Pre-Launch Checklist (Free, 50+ Minutes)

Use the checklist above to manually test:

  • Social sharing tags
  • Schema markup
  • Mobile devices
  • Accessibility
  • Technical SEO
  • Performance
  • Forms

Time: 50+ minutes across multiple tools

Cost: Free (your time)

Option 2: Run Scan on Your Staging Site ($25, 5 Minutes)

What you get:

  • Automated checks across all 7 categories above
  • Real device testing (iOS Safari, Android Chrome)
  • Pa11y accessibility audit (150+ WCAG checks)
  • Lighthouse performance audit
  • Prioritized fix list

How it works:

  1. Enter your staging site URL
  2. Scan runs automated audit (~5 minutes)
  3. Get comprehensive report with prioritized issues
  4. Fix issues before launch
  5. Re-run to verify

Time: 5 minutes for audit, 2-3 hours for fixes

Cost: $25

Run a pre-launch Scan audit

Pre-Launch Checklist Summary

48 hours before launch:

  • Run Scan on staging site
  • Review issues with team
  • Prioritize: SHOWSTOPPER → HIGH → MEDIUM → LOW
  • Assign fixes across team

24 hours before launch:

  • Verify all SHOWSTOPPER issues fixed
  • Verify all HIGH priority issues fixed
  • Re-run Scan to confirm fixes

Launch day:

  • Final smoke test on production
  • Monitor analytics for unexpected issues
  • Launch confidently

Your site looks ready. But have you run the technical audit?

One $25 Scan report might be the difference between a smooth launch and a $91K disaster.

Ready to audit your staging site? Run a Scan audit ($25) and catch issues before your users do. Visual QA is not enough. Technical audits save launches.