Most redesigns start from a good intention. The site is old, the offer has evolved, the image no longer fits, the CMS is tiring, the teams want a simpler tool, or leadership senses something is off. The danger begins when the redesign becomes the answer before the question has been properly asked.
Rebuilding a site without mapping existing digital assets means risking the displacement of structural problems into a newer container. A strategic digital readability diagnostic helps avoid this error by identifying the canonical surfaces to preserve. You can emerge from the project with a cleaner design, a more modern CMS and an even more fragile readability than before.
Why mapping arrives too late in most projects
In many organizations, mapping is not seen as a prerequisite. Teams start with apparent needs:
- redo the homepage;
- simplify the navigation;
- rewrite service pages;
- migrate platforms. The challenge of a machine-first redesign explains why this surface-level approach often fails;
- modernize the image.
All of that is legitimate. But if you do not know exactly which assets exist, what role they play, what must be kept, what must be merged, what must be redirected and what is polluting the reading, the redesign becomes a blind operation.
The problem is not only technical. An organization often owns more assets than it realizes:
- main site;
- old pages still indexed;
- microsites;
- documentation;
- support pages;
- blog articles;
- historical domains;
- expert pages;
- product assets;
- highly visible public profiles.
Without mapping, some of these elements drop off the project radar. Yet they continue to weigh on comprehension.
What mapping actually changes
Mapping assets is not a bureaucratic inventory exercise. It is about understanding:
- which assets are central;
- which are peripheral;
- which play a proof role;
- which create confusion;
- which must become canonical surfaces;
- which must be redirected, consolidated or de-emphasized.
This reading changes the project from the start. It prevents treating every page as equally important. It also prevents migrating content simply because it exists. An old asset can still be useful. A recent asset can be strategically weak. A support page can be more structuring for comprehension than a marketing page. Documentation can play a proof role that no commercial page assumes.
The four most common mistakes before a redesign
1. Treating the main site as the sole asset
The team thinks it is working “on the site,” while external reading and systems are actually reading an ecosystem. If documentation, products, legacy domains or satellite pages are not factored into the thinking, the redesign may improve the central facade while leaving contradictions around it intact.
2. Migrating by inertia
When content has existed for a long time, it gets kept “just in case.” Weak pages, empty categories, offer duplicates, posts with no clear function and historical routes are moved from the old environment to the new one. The future site is born already burdened with an unsorted legacy.
3. Confusing visibility with role
A page can generate traffic without being a good comprehension surface. Conversely, a less visible page can be essential for stabilizing a reading. Mapping forces you to distinguish an asset’s raw performance from its function in the system.
4. Redoing the container without revisiting the logic
A new site structure, a new design and a better CMS do not automatically resolve a vague offer, an ambiguous brand or a poorly governed corpus. Without a diagnostic, the redesign can even reinforce the wrong shortcuts. Good initial ideas are compressed into a prettier navigation that is not more readable.
Which assets need to be mapped
Before any serious redesign, at least five families of assets should be mapped.
Conversion surfaces
Homepages, service pages, industry pages, forms, diagnostics, “about” pages, FAQ.
Proof surfaces
Case studies, inspectable proof, screenshots, diagrams, documentation, demonstrations, trajectory pages, results pages.
Context surfaces
Blog articles, expert content, glossary, educational pages, position statements, structuring texts.
Technical or satellite surfaces
Documentation, help centre, products, sub-domains, legacy sites still active, generated assets, governance files, machine routes.
Legacy items
Former brands, former slugs, heavily indexed content, historical domains, properties more visible than you imagine.
This mapping does not need to be monumental. It needs to be accurate. The goal is not to fill a perfect spreadsheet. The goal is to enable a clean decision.
What mapping often reveals
In practice, three types of surprises come up frequently.
The first: the real problem is not on the pages the team had placed at the centre of the project. The reading weakness sometimes comes from peripheral assets that are much more visible than you think.
The second: pages thought to be secondary turn out to be essential. A well-structured proof page, clear documentation or a highly readable industry page can become a system pivot.
The third: the redesign needed to be smaller or more strategic than imagined. Sometimes, less rebuilding and more reordering is needed. Sometimes the scope must be widened because the historical assets weigh too heavily to be ignored.
Who this step is vital for
Pre-redesign mapping becomes particularly important for:
- multi-domain organizations;
- firms and practices that have accumulated similar offer pages;
- software vendors with rich documentation;
- personal brands with multiple properties;
- specialized B2B SMEs that have published a lot without governing the whole.
Before rebuilding, you must decide
A redesign is a good project when it translates an already-clarified decision. It becomes a bad project when it replaces that decision.
Before rebuilding the site, you need to know:
- what must become central;
- what must be relegated;
- what must be merged;
- what must be redirected;
- what must be rewritten;
- what must be shown as proof.
Without this step, the risk is not only wasted time. The risk is building a cleaner new version of a system that remains poorly understood.
This is exactly why we place the diagnostic before the redesign. Not to slow the project down, but to prevent it from rebuilding the problem instead of solving it.