Website redesign: what breaks in measurement and how to preserve it

A website redesign rarely breaks measurement in a visible way. The new version looks better, forms work, the phone rings—but the report stops showing where those inquiries came from. This is not a redesign guide. It is a list of what to safeguard before launch and verify afterward so the new site does not begin life without a history.

What exactly a redesign breaks

Website measurement is not one thing. It consists of several layers attached to different elements: template code, page URLs, names and identifiers in the code, and the visual layout. A redesign changes all these layers at once, but each breaks differently and at a different moment.

↔ Scroll the table sideways to see all columns.

These failures share one characteristic: none announces itself. The page works, the button responds, and the form submits. Only the record that something happened is missing—and in a report, a missing record looks exactly like lower interest.

Why before-and-after comparisons can be worthless

The first question after every redesign is whether the new website is better. The usual answer compares the month before launch with the month after. In most cases, that comparison says nothing reliable because both the site and the way it is counted have changed, along with the composition of traffic.

• The counter changedGoals rewritten from scratch have different trigger conditions, so they count a slightly different event.
• The denominator changedNew URLs split or merge pages, so the page-view base is no longer the same.
• Traffic changedSearch rankings settle for several weeks after a redesign, while the share of traffic sources shifts.
• The timing changedA launch rarely falls in a neutral week, so calendar rhythms become mixed with the effect of the change.

Narrow the comparison to make it meaningful. Instead of asking whether the entire site is better, choose several specific transitions that mean the same thing before and after launch: arriving on a service page and moving to contact, opening pricing and starting a conversation, or submitting a form from one named page. We explain how to choose such events in our article about website micro-conversions.

We do not specify how many weeks it takes for post-redesign data to become comparable. The period depends on traffic volume, reindexing speed, the scale of URL changes, and the season in which the launch occurs. A credible baseline begins when your own daily figures return to a stable range, not after a number of weeks copied from someone else's article.

Another trap is comparing figures from two different tools on either side of the launch. If you used one panel before the redesign and another afterward, part of the difference comes from definitions rather than the website. We explain these discrepancies in our article about why data does not match.

What to collect before the redesign to establish a baseline

You cannot reconstruct a baseline after the fact. When the old template disappears, so does the information about where measurement was attached and what the old layout's readings looked like. This list takes one day to complete and is the only thing that cannot be postponed.

1. Four weeks before launch: inventory your goals.List every measured business goal with the page, element, and label to which it is attached. Give this inventory to the contractor as part of the scope.
2. Four weeks before: inventory where measurement loads.Identify what lives in a plugin, what lives in a tag manager, and what someone once pasted directly into theme files. The third group is what will disappear.
3. Three weeks before: map the URLs.Create a complete list of current URLs mapped to their replacements. The same list will support redirects, widget visibility rules, and joined reports later.
4. Two weeks before: freeze the baseline reading.Record key metrics for one consistent, closed period, together with the date range and data-coverage information. No one will be able to reconstruct the sample later.
5. Two weeks before: describe maps and select recordings.Describe what click and scroll maps showed on key pages, and retain references to several recordings that illustrate known problems with the old layout.
6. One week before: list widget visibility rules.List the path prefixes where the widget should appear and where it should be hidden, then compare them with the new URL map.
7. On launch day: note the date and time.Record the exact switch-over time in one place. Three months later, this single line will settle half the arguments about when a decline began.

The final point looks trivial and is skipped most often. Without a recorded switch-over date, every later analysis begins by trying to establish when the website actually changed—and the team's memories diverge within a month.

The first week after launch: measurement before results

The most common post-launch mistake is to look at results immediately. The chart drops, a nervous discussion about the new layout begins, and two weeks later someone discovers that the goal stopped firing on switch-over day. Reverse the order: first make sure measurement works at all, then read the numbers.

1. Day one: a test visit through the full journey.Personally follow the path from arrival to contact and check whether the visit, conversation, or ticket appears in the panel. This one check resolves most doubts.
2. Day one: check the widget on every page type.Open one page from each URL group and confirm that the widget appears exactly where it should and remains hidden where it should not appear.
3. Day two: test every business goal separately.Trigger each measured goal manually and check its record. A goal you have not triggered yourself is untested—a zero in the report does not prove a lack of interest.
4. Day two: inspect URLs in reports.Check whether new URLs appear, whether old ones still collect page views, and whether redirects create a loop or an extra hop.
5. Day three: check data coverage.Compare the share of sessions with a recorded traffic source against the pre-launch value. A sudden increase in uncovered sessions usually means the consent banner or script-loading order changed.
6. Day five: check maps and recordings on the new layout.Confirm that data collection has begun on the new URLs. It is too early to assess results, but collection itself must be verified.
7. Only after a week: first read the results.Once every point above is closed, a drop or increase can finally be treated as information about the site rather than its measurement.

The same checking order works whenever you launch a new tool, not only during a redesign. We describe it in more detail in our article about the first month after implementation.

When tracking navigation without a full page reload, use the guide: SPA page tracking: does each screen change reach the visit history?.

Maps and recordings after the layout changes

Click and scroll maps are tied to a specific website layout more strongly than any other kind of data. A point on a map means ‘people clicked here,’ but it is meaningful only if you know what occupied that location at the time. After a redesign, that knowledge no longer applies, even when the page URL remains unchanged.

• Findings from the old layout were described in words before the template disappeared—a map screenshot without a description of the elements quickly becomes unreadable.
• Map data from before and after launch is not summed or averaged in one view.
• Fresh collection starts on switch-over day, not the day someone notices the layout changed.
• The first conclusions from new maps are drawn only after a comparable number of sessions has been collected on key pages.
• Pre-launch recordings were retained selectively as illustrations of known problems, not material for quantitative comparison.
• For pages whose URLs changed, the team clearly recorded that the map history belongs to the old URL.

The practical rule is this: maps collected on the old layout answer why a redesign was needed, while maps from the new layout answer whether it helped. These are two separate datasets; mixing them produces a chart that cannot be interpreted. We explain the readings themselves in our guide to reading heatmaps.

Recordings are less problematic because each one always shows a specific visit on a specific website version and does not pretend to be aggregate data. Just remember that a pre-launch recording documents a layout that no longer exists, so any conclusion must state which version it concerns.

What not to change at the same time as a redesign

A redesign creates the temptation to tidy up everything else at the same time. Since the website is changing anyway, why not replace the analytics tool, rewrite goals, improve the consent banner, and move the forms? The result is a change whose effects cannot be separated because everything shifted on the same day.

↔ Scroll the table sideways to see all columns.

The rule is simple: make one major change at a time, with enough space to collect data. If the schedule makes that impossible and some changes must launch together, record it explicitly in the launch note. Knowing that a given month cannot be assessed unambiguously is better than drawing conclusions from a comparison that mixes five causes. If the redesign lands just before your peak season, our guide to a holiday code freeze helps you set the order of work.

Remember that some things will remain beyond quantitative measurement after the redesign. We explain the limitations of analytics in our article about what Google Analytics cannot show you. After URL changes, Search Console also shows a transitional picture for several weeks and should not be the sole criterion for assessing the new version.