How Do I Test a Redesign Before Launching?

Test 1: Mobile and cross-device

Test on real devices, not just emulators:

• iPhone 13 or 14 (most common Tampa user device)
• Pixel 7 or Samsung Galaxy S22 (Android baseline)
• iPad portrait and landscape
• Desktop at 1280px, 1440px, 1920px widths

Click every nav item, scroll every section, tap every CTA on each device. Note any layout breaks, button positions, font sizing issues.

What to look for:

• Touch targets at least 44x44px (Apple’s minimum)
• Text readable at default zoom
• Hero CTA visible without scrolling on mobile
• Forms usable with mobile keyboard
• Phone number tappable (tel: link)

Test 2: Page speed

Run PageSpeed Insights (pagespeed.web.dev) on:

• Homepage
• Top 3 service pages
• Top 3 location pages (if applicable)
• Contact page
• One blog post

Targets:

• Mobile score above 60 (above 80 is excellent)
• LCP under 2.5 seconds
• CLS under 0.1
• INP under 200ms

If any page falls below these targets, fix before launching. Common culprits: oversized images, render-blocking JavaScript, slow hosting.

Test 3: Schema markup validation

Run Google’s Rich Results Test (search.google.com/test/rich-results) on:

• Homepage (LocalBusiness or Organization schema)
• Service pages (Service schema)
• FAQ pages (FAQPage schema)
• Blog posts (Article schema)
• Contact page (LocalBusiness with NAP)

Look for: zero critical errors, all expected schema types detected, structured data showing correct values (business name, hours, address, phone).

Test 4: 301 redirect map verification

This is the big one. Use Screaming Frog to:

• Crawl the old site, export all URLs
• Run that list through Screaming Frog’s “List” mode against the new redirect rules
• Confirm every old URL returns a 301 (not a 404 or 200)
• Confirm the destination of each 301 is a real page (not a redirect loop)

Manual spot checks on top 20 high-traffic URLs and top 20 backlink URLs.

If even one important URL is missing from the redirect map, fix before launch.

Test 5: Forms and conversion paths

Submit every form on the site as if you were a real customer:

• Contact form
• Quote request form
• Newsletter signup
• Scheduling links
• Phone-click events
• Email links

For each:

• Submission goes to the correct email address
• Confirmation message displays correctly
• Conversion event fires in GA4 (check Realtime view)
• Spam protection (reCAPTCHA, hCaptcha, honeypot) is working
• Form data shows up in CRM if integrated

Half of post-launch “the site is broken” complaints are forms quietly failing. Test thoroughly.

Test 6: Accessibility

Run automated checks:

• WAVE accessibility evaluator (wave.webaim.org)
• axe DevTools browser extension
• Lighthouse accessibility score (target 90+)

Manual checks:

• Tab through every page using only keyboard
• Confirm visible focus indicators
• Confirm all images have alt text (or empty alt for decorative)
• Confirm color contrast meets WCAG AA (4.5:1 for body text)
• Confirm form labels are present and associated

Full detail in should I add accessibility compliance during a redesign.

Test 7: Cross-browser

Test on:

• Chrome (latest)
• Safari (latest on macOS and iOS)
• Firefox (latest)
• Edge (latest)

Most Tampa users are on Chrome or Safari, but Firefox and Edge represent ~10% combined. A bug in Firefox that breaks the contact form is a real revenue leak.

Test 8: Content QA

The least technical, easiest to skip, and most embarrassing to miss. Read every page aloud:

• Typos and grammar
• Outdated information (old prices, old team, old phone numbers)
• Broken internal links
• Placeholder content (“Lorem ipsum,” “TBD,” “Add testimonial here”)
• Inconsistent terminology (some pages say “service area,” others “coverage zone”)
• Voice and tone consistency across pages

This pass usually catches 20-40 small fixes that would otherwise embarrass you the day after launch.

After your vendor finishes their internal QA, you (the owner) should do your own pass:

• Click through every page from the homepage navigation
• Submit at least one form yourself
• Check every phone number, email address, and physical address
• Verify pricing, service descriptions, and team bios are accurate
• Read the homepage and about page out loud
• Tap through on your own phone

Don’t sign off until you’ve actually used the staging site as a customer would. Surface-level reviews (“looks great!”) miss real bugs.

Before launch, every site should score:

| Test | Pass criteria | |—|—| | Mobile cross-device | Works on 4+ device sizes | | Page speed (mobile) | Score 60+, LCP <2.5s | | Schema markup | Zero critical errors | | 301 redirects | 100% of old URLs mapped | | Forms | All submit successfully | | Accessibility | Lighthouse 90+, manual keyboard test pass | | Cross-browser | Chrome, Safari, Firefox, Edge work | | Content QA | Owner sign-off complete |

If any row fails, launch is delayed until it passes. No exceptions for “we’ll fix it after launch” — post-launch fixes are public bugs.

Three questions for your vendor:

1. “Can I see your pre-launch QA checklist?” Real vendors have one. The 8 tests above are the minimum.
2. “How long will I have on the staging URL before launch?” Less than 48 hours is rushed. 5-7 days is healthy.
3. “What’s your bug-fix turnaround during owner review?” Same-day or next-day is standard. Anything slower means you’re not their priority.

Skipping pre-launch testing is the #1 cause of bad-looking post-launches. The day-after-launch “why is the form broken?” emergency is preventable with 8 hours of QA on the staging URL.

Every Tampa redesign we ship includes the 8 tests above as a required gate. The staging URL stays live for at least 5 business days before launch for owner review. We do bug fixes within 24 hours of any finding.

If a critical issue is found within 48 hours of planned launch, we delay launch until it’s fixed. The cost of a 2-day delay is much smaller than the cost of launching with a known bug.

The closest related topics are can I redesign my site without downtime and how do I roll back a bad redesign. Read all three before scoping any Tampa redesign.