The Challenge
At an agency running 50+ simultaneous client accounts, every site launch was a potential SEO incident. Not because the team was careless — but because pre-launch SEO validation was entirely manual, undocumented, and person-dependent. If the SEO lead on a given account was on leave during launch week, critical checks didn't happen. Robots.txt blocking production, GA4 tags firing in duplicate, canonical tags pointing to staging environments — these were recurring post-launch hotfixes, not hypothetical risks.
The cost was significant: not just in recovery time, but in client trust. A site that launches and immediately drops in search visibility is a reputational problem, regardless of whether it's technically recoverable in three weeks.
The QA System Design
The solution was to make SEO launch validation a system, not a person. I designed a Go-Live QA Protocol as a three-layer framework:
Layer 1: Pre-launch staging validation (T-72h)
A staging environment checklist run 72 hours before go-live. Items validated at this stage don't require the live domain and can be tested in staging: robots.txt confirms Disallow: / is present (staging should be blocked), canonical tags across page types are templated correctly (not hardcoded), noindex is applied to admin/utility pages, and GA4 + GTM containers are installed but not firing in production mode.
Layer 2: Launch-day live checks (T+2h)
Within two hours of DNS propagation, a defined checklist of live-environment checks: robots.txt no longer blocks all crawlers, canonical tags now point to the live domain (not staging), HTTPS redirect is functioning correctly, XML sitemap is accessible and returns valid XML, and GA4 is receiving live events (verified via GA4 DebugView and GTM Preview). Pagespeed / Core Web Vitals baseline is captured using PageSpeed Insights API.
Layer 3: 72h post-launch monitoring
GSC Coverage report monitored for unexpected 404 spikes or canonicalisation errors. GA4 traffic compared to pre-launch baseline (bounce rate anomalies can indicate tracking misconfiguration). Any issues flagged in this window are escalated to the technical team with a documented fix protocol.
Standardisation and Automation
The protocol was built as a Google Sheets template — one tab per layer, with dropdown status fields (Pass/Fail/N/A) and notes columns. Account managers could run it independently for straightforward launches; complex launches required SEO sign-off on Layer 2.
For recurring checks (robots.txt status, sitemap validation, canonical consistency), I wrote Python scripts that could be pointed at any domain and output a structured report in under two minutes. These became the basis for Layer 1 and Layer 2 automated checks, reducing manual time per launch from approximately 90 minutes to 25 minutes.
The Outcome
Across 50+ site launches post-implementation: zero launch-day ranking drops attributable to SEO configuration errors (the previous 12-month baseline had four such incidents). Post-launch hotfixes reduced by 70%. The protocol was adopted as a company-wide standard, with the Google Sheets template adapted for different site types (eCommerce, lead gen, content). Junior team members could execute Layer 1 and Layer 3 independently, freeing senior SEO time for strategy.
Tools & Stack
Google Sheets (QA template) · Python (automated validation scripts) · PageSpeed Insights API · Google Search Console · GTM Preview / GA4 DebugView · Screaming Frog (post-launch crawl) · GitHub (protocol versioning)