Skip to content

Knowledge · Website Redesign

Staging, QA, and Launch: How to Avoid a Friday Disaster

14 days kickoff → live $3K–$15K+ scope-tiered WCAG 2.1 AA baseline

Most redesign disasters happen at launch, not during build. Wrong robots.txt, broken 301s, unset canonical tags, forgotten analytics — small mistakes that cost weeks of recovery. Here’s the staging-and-launch protocol that’s let us launch 200+ builds without a Friday-night emergency.

№ 01Why staging matters more than most agencies admit

Staging is a production-equivalent environment where the new site lives before launch. The QA pass runs there. Same hosting tier, same plugin stack, same content, same SSL setup — just at a different URL (typically staging.yoursite.com or yoursite.stagingsite.com with the staging environment’s subdomain).

The reason this matters: localhost QA doesn’t catch caching issues, CDN issues, SSL configuration mistakes, or plugin conflicts that surface only in production-like environments. A localhost-only QA pass misses ~30% of launch-day issues.

№ 02The 22-item pre-launch checklist

Run every item. Sign off on each. No exceptions.

  1. Lighthouse 90+ Performance on top 20 pages.
  2. Lighthouse 100 Accessibility on top 20 pages.
  3. Lighthouse 100 SEO on top 20 pages.
  4. WCAG 2.1 AA audit clean (axe DevTools or equivalent).
  5. Cross-browser smoke test (Chrome, Safari, Firefox, Edge).
  6. Cross-device smoke test (iPhone Safari, Pixel Chrome).
  7. Every form submits successfully and routes to the correct inbox/CRM.
  8. GA4 fires on every page (verify in real-time view).
  9. GTM container loaded and tags firing.
  10. Search Console verified for the new site.
  11. XML sitemap accessible at /sitemap.xml.
  12. robots.txt allows crawling (NOT Disallow: /).
  13. Every page has self-canonical or correct cross-canonical.
  14. 301 redirects spot-checked (20 random URLs via curl).
  15. Schema markup validates (Google Rich Results Test on 10 pages).
  16. Open Graph tags + Twitter Card tags on every page.
  17. Favicon + Apple Touch Icon set.
  18. 404 page exists and is on-brand.
  19. SSL certificate valid for at least 60 days.
  20. Daily backup running on the production host.
  21. Security plugin active (Wordfence or equivalent).
  22. Caching plugin configured (WP Rocket or LiteSpeed).

№ 03Why Tuesday and Wednesday launches win

Friday launches sound smart (‘weekend to fix issues’) and are the worst choice. Google’s recrawl cycle accelerates Mon-Wed and slows Thu-Sun. The 301-recovery clock starts later on a Friday launch because Google waits until Monday to seriously recrawl.

Tuesday or Wednesday launches: Google recrawls the new site within 24-48 hours. You’re back to baseline rankings by Friday. The week is yours to monitor and fix; the weekend is recovery, not crisis management.

№ 04The launch-day timeline, hour by hour

9:00 AM Tuesday: Final staging sign-off. All 22 checklist items green.

10:00 AM: Database export from staging, import to production. DNS swap or hosting cutover initiated.

11:00 AM: DNS propagation begins. Spot-check the live site from 3 geographies (use BrowserStack or a VPN). Verify SSL.

12:00 PM: Submit sitemap to GSC. Request indexing on top 50 URLs. Verify GA4 firing on live traffic.

1:00 PM-5:00 PM: Active monitoring. Watch GA4 real-time, GSC URL Inspection, server logs for 404s and 500s. Fix surface-level issues as they appear.

Day 2-7: Daily check-in. GSC for indexing status. GA4 for traffic anomalies. Plugin updates deferred for 14 days post-launch (locked stack).

№ 05The post-launch lockdown window

For 14 days post-launch: no plugin updates, no theme updates, no content additions, no design tweaks. The site is locked. The reason: if rankings or traffic drop, you need to know whether the launch was the cause or whether a Day-5 plugin update broke something.

Day 15-onward: normal operations resume. Pent-up changes ship in a controlled batch. Rankings have stabilized by then on 90%+ of projects, so the change-cause attribution is clean.

What to avoid

  • Launching the redesign over a weekend so ‘fewer people will notice if something breaks.’ Wrong instinct. Launches need to be monitored. Pick the day with the most coverage, not the least.
  • Skipping the staging environment because ‘it’s a small site.’ Small sites have the same launch-day risks. The staging-mirror discipline costs $20-$50 in hosting for two weeks. Worth it every time.
  • Updating plugins on Day 3 post-launch because ‘there’s a Yoast security patch.’ Lock the stack for 14 days. The patch waits.