WEBFLOW EXPERTS ON IDENTIFYING WHICH WEBSITE EXPERIENCES SHOULD SURVIVE a REDESIGN

Redesigns are run as replacements. The old site is the problem, the new site is the answer, and anything carried across is treated as a compromise. That framing is how teams lose the three or four things their site was quietly doing well, discover it four months later in the traffic numbers, and have no record of what changed. The audit that prevents this takes a week and almost nobody does it.

TL;DR

• Ask the team running it to document what works before anything is redrawn.

• Three checks: what people use, what people arrive at, what people copy.

• Low-traffic pages can still be load-bearing for the sales process.

• Keep the URLs, or plan the redirects properly before launch.

• Write the keep list down, because institutional memory does not survive a rebuild.

Check One: What People Actually Use

Before anything is redrawn, list the pages and features by real usage over at least a quarter. The surprises tend to run both ways: a feature somebody fought hard for turns out to be untouched, and an unglamorous page somebody built in an afternoon turns out to carry the support load. A page nobody on the team mentions in meetings can still be the page half your customers open first. 

Pair the numbers with a conversation with support and sales, because the pages they send links to every week will not necessarily be the highest-traffic ones. Keep the window wide enough to cover a full quarter, since anything shorter reads campaign spikes as permanent behaviour. Webflow experts asked to review a site will usually start here, and if yours does not, ask why.

Check Two: What People Arrive At

Entry pages are different from popular pages. A page can have modest total traffic and still be the first thing a particular segment ever sees, which makes it worth more than the number suggests. These pages carry the burden of explaining who you are to somebody with no context, and a redesign that folds them into a general page removes that explanation without replacing it. 

An entry page is doing a job that the homepage will not do for it after the rebuild. The controls on those pages matter more than elsewhere too, since a first-time arrival has nothing to compare them against; the consistent identification criterion is Level AA and requires that components with the same functionality within a set of web pages are identified consistently, according to the W3C's understanding document. List every page with meaningful direct or organic arrivals and mark each one as keep, merge or drop, with a reason written next to it.

Check Three: What People Copy and Send

The third check does not show up in analytics at all. Ask internally which links get pasted into emails, proposals and chat threads. These are the pages doing work inside other people's workflows, and they are invisible to any traffic-based review because the person sending the link already knows where it is. A specification page, a comparison table, a status page: all typically low-traffic and high-consequence. The link your sales team pastes twice a week is a page the analytics will tell you to delete. 

A webflow agency will not find these by looking at your analytics, so the answer has to come from inside your own company. Ask the question in a channel rather than a meeting and give people a day; the answers arrive as people notice themselves doing it. Webflow experts running this audit properly will push for that list before they look at a single wireframe, because it is the only input that cannot be reconstructed later.

Keeping the Addresses Intact

Whatever survives in content needs to survive in address too, or the surviving pages start from zero. Google's change of address guidance covers moving a site to a new domain and describes using the Search Console change of address tool together with redirects from the old URLs to the new ones. Within a single domain, the same principle applies page by page: a redirect from every retired URL to its closest replacement, mapped before launch rather than after. A redesign that changes every URL without a redirect map is a new site wearing the old brand. Map it as a spreadsheet, one row per old URL, and check it on the staging build.

Three Ways to Run the Audit

• Analytics plus internal interviews: works for most sites and takes about a week, with the limit that it depends on a clean quarter of data to read.

• Full content inventory with decisions: works for large sites and leaves a usable record, though it costs several weeks and the decisions go stale if the rebuild slips.

• A short keep list only: works when time is short and protects the obvious things, with the limit that it catches nothing you did not already suspect.

Final Verdict

Run checks one and three before the design work starts. Between them they take a few days and they produce the list that the design brief should open with, rather than a list assembled defensively after launch. Webflow experts who skip straight to layout are starting the project without its most important input.

Treat the redirect map as a launch blocker rather than a post-launch task; it is the single cheapest thing on this list and the one most often skipped. If you are briefing a webflow agency or an in-house team, ask for the keep list as a written deliverable, and make sure the reason is recorded next to each item, because the reasons are what stop the same argument being had again next year.

FAQs

Q: How much data do we need before the audit is meaningful?

A: A full quarter at minimum, and a year if your business is seasonal. Shorter windows pick up campaign spikes and miss the steady pages that matter most. If you have less than a quarter, lean harder on the internal interviews, which do not depend on data volume.

Q: What if a page performs well but is badly written?

A: Keep what makes it work and fix the rest, which usually means keeping the URL, the title and the structure of the answer while rewriting the prose. The temptation is to rebuild it entirely because it is embarrassing, and that is how a page that was working stops working.

Q: Should we keep a feature that few people use but some rely on?

A: Usually yes if the people relying on it are customers, and usually no if they are internal. The question is not how many use it but what happens to the ones who do when it disappears. Where the answer is a support ticket, keeping it is cheaper than removing it.