WordPress Recast: What you don't know about your site will drive your decisions for you. Plan an audit.
Published on
by
You're preparing a redesign. The perimeter is framed, the teams aligned, the provider identified. You have a direction.
What you see from the site, you control it. But what works below is another story – implicit dependencies, undocumented business logics, technical decisions that no one remembers anymore...
These shadow zones do not remain abstract for long. They occur during the course of the project, when arbitration is forced and every correction costs twice as much. This is not a theoretical risk: it is the most frequent scenario we observe on the recasts we resume.
An upstream audit does not slow down the project. He gives you control before someone – or something – makes the decisions for you.
In this article, we explain why the existing one is systematically underestimated, and what it costs in practice.
We also share a comprehensive diagnostic guide: +50 points of vigilance to map your site before transforming it.
A WordPress site is not a site. It's a system.
It articulates a business logic (forms, automations, interactions with other tools), a technical layer (plugins, specific developments, scripts), an infrastructure (hosting, cache, server configuration), an editorial model (contribution tools, content structuring), and an operating mode (deployment, maintenance, supervision).
In most cases we see when we resume maintenance projects, these layers are not fully aligned. Technical decisions that force content. Contribution habits that circumvent the rules. Host-inherited features that play a real role in balance – without anyone really knowing.
A living site is accumulating. Each intervention added a layer, functionality, correction, integration. Gradually, part of the logic moved out of the visible field.
As long as the site holds, it's not a problem. It's at the moment when you're trying to transform it.
The recast does not exist. She reveals it.
This is the point that most directorates underestimate when launching the project. And it's not a matter of negligence – it's a well-documented mechanism.
A site that works gives an illusion of mastery. We see the result, not the functioning. And the redesign is mentally experienced as a blank page – which makes it psychologically difficult to invest time in documenting what you are supposed to leave. Why dig what we're gonna replace?
It is precisely this reasoning that sets out the project.
The recast is seen as an opportunity to get back on sound bases. In reality, she acts first as a teller.
Because we're not going back from scratch. We modify several layers at the same time – structure, content, technique, sometimes infrastructure. And at that time, everything that was implicit becomes visible. A misunderstood functionality is poorly reproduced. Unidentified addiction breaks away. An anomaly tolerated for months has become blocker overnight.
What you don't know will decide for you.
When analysing an existing site upstream of a redesign, it is not so much the visible problems that emerge. This is the extent of what no one really knows: features that no one knows the exact perimeter, active but undocumented automations, technical choices that have lost logic.
And above all, a tolerance for anomalies. Errors can exist continuously without blocking the site – and therefore without being processed. As long as « It works. », they remain invisible. Until the day they are no longer, often in production, often at the wrong time.
The problem is not that these areas exist. All sites have them. The problem is that they continue to exist during the redesign, and that they guide your decisions without you knowing it.
You think you're arbitrating on the basis of a clear reading, but in reality you're arbitrating on assumptions.
And in practice, it translates into devoting the first weeks of the project to understanding what we have – not building what we want. It is the cost of the absence of audit, which is paid at the wrong time.
The audit is not a status report. That's what puts you in charge.
A redesign involves much more than a new site. It commits:
📍 Your acquisition – SEO, tracking, route
📍 Your actual performance
📍 Your Business Features
📍 Your ability to maintain and evolve the site
It also commits a budget, planning and teams. Without a clear reading of the existing, you do not secure these subjects: you bet.
What an audit actually produces is a mapping of the decisions to be taken. What you keep, what you correct, what you rebuild. With visibility on the real risks.
Without audit, these decisions still exist! But they are taken later, under pressure, with less visibility. It is not only more risky: it is structurally more expensive.
Useful clarification: what a pre-recast audit is, and what it is not.
This is a point that often comes back and deserves to be put clearly.
A pre-recast audit is not a security audit. This is not an SEO audit. It's not an UX audit. These are related, legitimate subjects with their own scope and deliverables.
A pre-recast audit is a systemic reading of the existing in the service of future decisions. He answers a specific question: what do I need to know about this site before transforming it – and why.
This clarity of perimeter is not insignificant. It is often the confusion between these different types of audit that delays the decision to initiate the process.
Who wears it internally?
In the organizations we accompany, the sponsor's question almost always comes up. Who's in charge? Who reads it? Who's responsible?
Clearly, it is the one who will carry the recast that must carry the audit. Not for reasons of abstract governance, but because the audit gives it something concrete: the arguments to align all other stakeholders.
A redesign is not the only way. It involves technical teams that have sometimes not chosen the tool, business directions that have their own priorities, validations that take time. The audit provides a common basis. A shared reading of the existing, on which arbitrations can be based.
Before you start your redesign
It is necessary to emerge from the tenacious idea that a recast can start from scratch. New site, new base, new white page.
Actually, we never start from scratch. We transform an existing system, with everything in it. Constraints do not disappear, they change form, and dependencies do not disappear, they move.
What changes is your level of reading when making decisions. And that's precisely what makes the difference between a project that is being piloted and a project that is going through.
Recover your diagnostic guide
+50 alert points listed, to see if your project is based on a controlled basis or on blind angles.
« * » indicates the required fields
If the checklist reveals many shadow areas, this is usually the sign that a structured audit is required before starting production. It is precisely this type of situation that we are accompanying.
