A baseline is not a screenshot of total users from last month. It is a dated, reproducible record of how the current site attracts people, helps them act, and passes outcomes into the business. Without it, a post-launch discussion turns into memory: one person recalls more calls, another remembers weak leads, and the agency points to engagement. A useful benchmark connects website behavior to the decisions the redesign is supposed to improve.

Define one primary outcome and several guardrails

The primary outcome should be close to business value: qualified consultation requests, booked appointments, completed purchases, started applications, or another accepted action. Guardrails prevent a narrow win from hiding damage. A new short form may produce more submissions while the sales team receives more spam. A navigation change may improve clicks to one service while burying another. Record volume, quality, completion, and operational impact together.

A buyer-focused measurement stack

QuestionMetric or evidenceWhere to get it
Are the right people arriving?Qualified sessions, source or medium, geography, new versus returning contextGA4 acquisition and user reports, with consent and configuration understood
Which pages earn search demand?Clicks, impressions, query themes, pages, countries, devicesGoogle Search Console Performance report
Do visitors complete the intended path?Key events, form starts, form completions, calls, bookings, checkout stepsGA4 events plus the form, call, booking, or commerce system
Are leads useful?Accepted lead rate, sales stage, revenue or case outcome where appropriateCRM or operating system, not analytics alone
Does the site work well on real devices?Core Web Vitals field data when available; support tickets and device-specific failuresCrUX, Search Console, real-user monitoring, testing records
What must not get worse?Top landing-page traffic, critical form success, returning-customer tasksCombined benchmark workbook

Audit the tracking before trusting the numbers

Prove the measurement chain

01

Map each important action

List the exact user action, the analytics event, the destination system, and the person who owns the follow-up. A form submission event is not proof that the CRM created a lead.

02

Run controlled tests

Submit each form, book a test slot where safe, use tracked phone numbers according to policy, and complete a test purchase in an approved environment. Record timestamps so the event can be traced across systems.

03

Check duplication and missing events

A tag firing on both button click and thank-you-page load can count one inquiry twice. A single-page form may never load a thank-you page. Match analytics counts to receiving-system records for a sample period.

04

Document consent and exclusions

Note the consent setup, internal-traffic filters, referral exclusions, cross-domain settings, and known blind spots. Do not treat analytics as a complete census when collection depends on browsers and user choices.

05

Freeze the event dictionary

Save event names, parameters, definitions, and who maintains them. The redesigned site should either preserve these definitions or document the date and impact of each change.

If the current tracking is unreliable, do not manufacture a precise baseline. Mark the gap and use the strongest independent evidence available: CRM records, appointment logs, order data, call-platform reports, or server logs. You may also run a short validation period before the redesign. The purpose is an honest reference point, not a dashboard that looks complete.

Export the dimensions a redesign can disturb

Totals hide the pages and audiences most exposed to a redesign. Export performance by landing page, channel, device category, country or service area, and conversion type. In Search Console, save pages and query themes that currently earn impressions and clicks. In GA4, look at acquisition and landing-page behavior, not only the default overview. In the CRM, separate qualified opportunities from raw submissions. This makes it possible to detect a specific loss, such as mobile organic inquiries falling on two renamed service pages, instead of saying 'traffic is down.'

  • Export the current URL inventory with page title, canonical destination, status, organic clicks, entrances, important events, and redirect decision.
  • Save the highest-value organic queries by intent rather than treating every query as equally important.
  • Record paid campaign landing pages and tracking parameters so a redesign does not break active ads.
  • Break out mobile, desktop, and tablet where the volume is large enough to interpret responsibly.
  • Capture location or market segments only when privacy, consent, and sample size make the comparison appropriate.
  • Record form error reports, abandonment clues, and sales-team feedback that a numeric dashboard may miss.
VISUAL CHECKPOINT · RedesignWrite the redesign claim before choosing metrics

Examples: 'Help more mobile visitors request an estimate,' 'make qualified organic landing pages easier to find,' or 'reduce support calls caused by missing service information.' Each claim needs its own baseline and guardrails.

Choose a fair comparison window

Weak comparisonMore defensible comparison
TimeSeven days before versus seven days afterRepresentative periods with day-of-week and seasonal context
MarketingIgnore a new paid campaignAnnotate campaign starts, stops, budget changes, and major publicity
DemandAssume all market demand stayed constantRecord holidays, weather events, product changes, outages, and known business cycles
TrackingCompare events after their definitions changedPreserve definitions or create a bridge explaining the measurement break
AttributionCredit every change to the redesignDescribe associations, investigate mechanisms, and use experiments when a causal claim matters

For a seasonal business, compare against the same business period in a prior year as well as the immediately preceding period, while noting changes in operations and marketing. For a rapidly growing company, a rolling trend may be more informative than a single historical month. The right window depends on traffic volume, buying cycle, seasonality, and how long it takes a qualified inquiry to become revenue. Decide the window before seeing post-launch results.

Keep speed data in context

Laboratory tests help diagnose a page under controlled conditions, while field data describes eligible real-user experiences in aggregate. The Chrome UX Report can provide Core Web Vitals data at origin or page level when enough eligible data exists, but smaller sites or individual pages may not have reportable data. Save the available field view, device dimension, observation date, and tool. Pair it with repeatable lab tests on a fixed set of key templates. Do not blend the two into one invented score.

Turn the baseline into launch acceptance criteria

Example acceptance record for a service company

AreaPre-launch recordPost-launch question
Lead deliveryTest submission reaches CRM and assigned inbox with required fieldsDoes every production form still create the expected record?
Organic entry pagesTop landing pages and mapped replacement URLs exportedAre they indexable, redirected correctly where needed, and receiving expected search exposure?
Mobile taskCall, quote, and booking paths tested on real devicesCan a visitor complete each path without hidden controls or keyboard obstruction?
Lead qualityCRM acceptance definition and historical rate documentedDid volume change with a corresponding change in accepted opportunities?
ReportingEvent dictionary, filters, and dashboard owners savedAre definitions unchanged, or is every break annotated?
PerformanceField availability and repeatable lab pages recordedDid key templates improve or regress under the same testing method?

Bring this package into the scope discussion with your website design team, not after the site has launched. It changes priorities: a high-value landing page needs a deliberate migration decision; a form with poor data quality needs more than visual polish; and a campaign URL cannot be renamed casually. The related redesign and migration guides cover those implementation choices.

After launch, use the schedule in how to monitor SEO after a website redesign and pair it with this broader business baseline. Search clicks can move while lead quality holds steady, or conversions can rise while an important page disappears. One disciplined package lets the team see both.

How far back should a pre-redesign benchmark go?

Use enough history to represent normal demand and the buying cycle, then include a comparable seasonal period when seasonality matters. There is no universal number of days. Record the chosen windows and why they are fair before evaluating the launch.

Should we use users, sessions, or pageviews as the main redesign KPI?

Usually none of those is a sufficient primary business outcome. They describe activity, not necessarily value. Choose a verified action such as a qualified inquiry, booking, or purchase, then use traffic and behavior metrics to explain how people reached it.

What if GA4 and the CRM disagree?

Expect different systems to have different collection rules, then investigate the size and direction of the difference. Test the full path, check duplicate or missing events, consent behavior, spam handling, and time zones. Treat the CRM or operating system as the stronger source for accepted business outcomes when its data is maintained.

Can a before-and-after comparison prove the redesign caused the result?

Not by itself. Marketing changes, seasonality, market demand, operations, tracking, and random variation can affect results. A comparison can reveal a change worth investigating; controlled experiments or stronger causal methods are needed for a firm causal claim.

Should low-traffic businesses skip benchmarking?

No. Use longer windows, avoid overinterpreting small movements, and add qualitative evidence such as call reasons, customer interviews, form errors, and sales feedback. The baseline can be honest about limited statistical power while still protecting key pages and workflows.