Website Launch Impact Report

A before/after report anchored on a launch date: did the new site help or hurt? You compare a pre-launch window against an equal-length post-launch window across three lenses — SEO (Search Console), conversions (analytics + call tracking), and UX — and you split every lens by page type (money/service pages vs. blog), because a relaunch almost always moves those two groups in opposite directions.

A capable agent already knows the obvious moves: match window lengths, split branded vs. non-branded queries, confirm old URLs 301 to new ones and new ones are indexed, isolate organic from other channels, lead with a verdict and keep tables in an appendix, and recommend a 60/90-day re-check. Do all that. This skill exists for what a capable agent still gets wrong by default: which comparison to headline (next), and five data-integrity traps that quietly wreck the numbers.

Headline the comparison that isn't seasonal

For anything with seasonal demand — home services, retail, travel, tax — a plain before/after around the launch conflates the launch with the season. Launch in spring, measure into summer, and a pest-control site shows a big "lift" that is mostly rising demand, not the new site.

Lead with year-over-year, per page-group: this year's post-launch window vs. the same calendar window last year. That cancels the season out and is the truest measure of the launch's effect on the pages that matter — the commercial/"money" pages. Keep the before/after too (the daily chart shows launch timing), but label it seasonally-influenced and never let it headline a seasonal group.

Real case: a service-area group showed +78% impressions before/after; year-over-year it was +9% — most of the "launch lift" was just the season. Clicks held up YoY (+37%), so the honest headline was "up year-over-year," with the before/after flagged as mostly seasonal.

Corollary — when you can't run year-over-year, check which season the post-launch window lands in; off-season cuts the other way. With no year-ago data you must lead with before/after, so look at where the post window sits on the demand calendar. A launch heading into the off-season (a fall launch measured through winter, against a spring/summer "before") puts the launch's numbers on the low side of the season — the before/after now understates the launch, the mirror image of the spring-launch inflation above. The signature is impressions and average position climbing while clicks barely move: that is a seasonal headwind, not a weak launch. Say plainly that clicks are seasonally suppressed and will follow when demand returns, and treat the before/after as a floor. Don't default to "rankings just need time to mature" when the calendar is the simpler explanation — check the season first.

Corollary — YoY totals must compare equal-coverage spans; the retention horizon silently truncates the last-year side. Search Console keeps ~16 months. Request "this full measured span vs. the same span last year" and the last-year daily series can silently start months late — then summing both sides compares unequal windows and overstates growth. This flipped a real shipped headline from "+38% YoY" to −3.8% (last year covered 134 days of a requested 241), and overstated two more reports by 40–90 points. The same truncation corrupts anything derived from the series: a per-day legend rate divided by len(daily) inflates last year, and a chart plotted by day-index draws the last-year line across only part of the x-axis. The tell is len(last_daily) << len(this_daily) — check the row counts of the two daily series, never trust the requested date range. Fix by restricting both years to the calendar span both actually cover, stating that span in the copy, and deriving the chart and per-day rates from the matched arrays: