Most teams that reach out to us already know something is off. Pages load slowly. The CMS fights them on every update. Their agency disappeared after launch and nobody knows how half the integrations work. The instinct is to skip straight to the solution: rebuild it, migrate it, throw it out and start over.
That instinct is usually right about the direction. But it is almost always wrong about the details.
A rebuild without a clear picture of the current system is how you end up six months into a project that was supposed to take three, discovering integrations nobody documented and content structures nobody understood. We have seen this pattern enough times to know that the most expensive mistake in a website project is not choosing the wrong CMS. It is starting before you understand what you already have.
The gap between “something is wrong” and “here is what to do about it”
When a marketing team says their website is slow, that can mean ten different things. The homepage might take four seconds to load because of unoptimized images. Or the CMS might take 45 seconds to save a draft because the content model has 200 fields per entry. Or the hosting is undersized. Or a third-party script is blocking the render. Each of these problems has a different solution, a different cost, and a different timeline.
The same applies to “we need a new CMS.” Sometimes the CMS genuinely cannot do what the team needs. Sometimes the CMS is fine but was configured badly by the previous agency. Sometimes a migration would fix the editorial workflow but destroy three years of SEO equity because nobody planned the redirect strategy.
Without a structured look at the current setup, every conversation about next steps is guesswork. And guesswork at the scoping stage is where project budgets go to die.
What a structured audit actually covers
A useful audit is not a sales pitch disguised as a report. It is an honest inventory of what works, what does not, and what it would take to fix it. Here is what we look at when we run one.
Technical stack and CMS evaluation
What is running under the hood? What version? What plugins, what custom code, what dependencies? How is it hosted, and who has access?
This sounds basic, but the answer is often “nobody knows.” The agency that built the site is gone. The developer who set it up left the company. The documentation, if it existed, is two years out of date. One client discovered during an audit that their WordPress site was running 34 plugins, 11 of which were deactivated but still installed, and three of which had known security vulnerabilities. Nobody on their team had the access or knowledge to check.
The point is not to judge the current setup. The point is to see it clearly so the next decision is based on facts.
Performance and Core Web Vitals
We run the site through Lighthouse, WebPageTest, and Chrome DevTools to get real performance data. Not just the homepage, but the pages that actually matter for the business: product pages, landing pages, the blog, the contact form.
The results often surprise teams. A site can feel fast to the people who built it (they are on a fast office connection, browsing on a MacBook) and feel slow to every visitor on a mobile connection in a different country. Core Web Vitals are not vanity metrics. Google uses them as a ranking factor, and they directly correlate with bounce rates and conversion rates.
What matters is not just the numbers but the root cause. A poor Largest Contentful Paint score might be a hosting problem, an image optimization problem, or a CMS architecture problem. Each one leads to a different fix.
Content structure and editorial workflows
This is where most audits get interesting, because this is where the real pain lives for marketing teams.
How is content organized in the CMS? Are there reusable content blocks, or is every page a one-off? Can editors preview their changes before publishing? Can they schedule content? Can they manage multiple languages without duplicating entire pages?
Teams that are held back by their CMS often do not realize how much time they lose to workarounds. They copy-paste content between pages because there are no shared components. They ask a developer to make changes that should be self-service. They maintain separate spreadsheets to track what has been translated and what has not. These are not technical problems in the traditional sense. They are workflow problems that a better content architecture would solve.
An audit maps these workflows and identifies where the friction is. Sometimes the answer is a new CMS. Sometimes it is restructuring the existing one. Sometimes it is both: migrating to a new system that supports structured content from the ground up.
SEO risks and redirect requirements
This is the part most teams skip, and it is the part that costs the most when it goes wrong.
If you are considering a migration, every URL on your current site that receives traffic or has backlinks needs a plan. How many URLs are there? What is the current URL structure? Which pages carry the most SEO value? What happens to those URLs in the new system?
A failed redirect strategy is responsible for the majority of post-migration traffic drops. We have seen sites lose 40% of their organic traffic because nobody mapped the old URLs to the new structure before launch. Recovery from that kind of loss takes months, sometimes over a year. Sometimes sites never recover at all.
An audit quantifies this risk upfront. It tells you exactly how many redirects you need, which pages are critical, and what the realistic scope of a migration would look like before you commit to one.
Integrations and third-party dependencies
What does your website talk to? CRM, email marketing, analytics, search, e-commerce, ERP, booking systems, payment processors? How are those connections built? Are they documented? Does anyone on your team know what happens if one of them breaks?
Integration dependencies are the number one source of scope creep in website projects. A migration that looks straightforward in the CMS layer turns into a six-month project when you discover that the site has 15 API connections, half of which were built by a freelancer who is no longer available, and none of which have documentation.
An audit maps every integration, documents how it works (or how we think it works, because documentation is often missing), and flags the ones that will require significant work in a rebuild.
What an audit does not do
An audit is not a redesign. It does not produce mockups, wireframes, or a new visual direction. It does not write your content or fix your problems.
It also does not guarantee that you need us. We have run audits where the honest recommendation was “your current setup is fine, spend the money on content instead of a migration.” That is a valid outcome. A good audit tells you the truth about your situation, not what the auditor wants to sell you next.
When you need one
An audit makes sense in a few specific situations.
You suspect your setup is holding your team back, but you cannot prove it. You need a clear picture to make a business case for investment. An audit gives you data, not opinions.
You are comparing options and every vendor is telling you something different. One agency says you need a full rebuild. Another says a CMS migration is enough. A third says you should just optimize what you have. An independent audit cuts through the sales pitches because the auditor has no stake in which direction you go.
You have been burned before. A previous project went over budget, took twice as long as promised, or delivered something that did not solve the actual problem. You want someone to look at the situation before you commit again.
You are planning a migration and want to understand the real scope. The Essential Launch Framework that we use for every migration starts with a complete audit. If you are evaluating whether a migration is even the right move, the audit is the place to start.
What a good audit delivers
The format matters less than the substance, but a useful audit should give you three things.
A clear picture of the current system. Not a vague summary, but specific findings you can act on. Performance numbers with root causes identified. A content architecture map that shows where editorial friction comes from. An integration inventory that documents what connects to what and how.
The raw data behind the conclusions. Lighthouse reports, crawl results, redirect inventories, dependency maps. You should be able to hand these to any developer or agency and they should understand what they are looking at. If an audit only gives you a slide deck with recommendations but no supporting evidence, the recommendations are opinions.
An honest assessment of your options. Not “you need to rebuild everything.” A straightforward look at what each path forward would cost, what it would risk, and what it would solve. Sometimes the right answer is a targeted fix. Sometimes it is a full migration. Sometimes it is doing nothing yet and investing in content instead. A good audit does not have a predetermined conclusion.
The output should be something you can share with your team, your management, or any future service provider. It should be useful regardless of who you hire next or whether you hire anyone at all.
The cost of not knowing
A website migration typically costs somewhere between € 25.000 and € 55.000. A migration that goes wrong because nobody understood the current system costs that amount in rework, plus months of lost time, plus potentially years of lost organic traffic.
Most of the disasters we have seen in this space started the same way. A team committed to a rebuild based on a gut feeling about what was wrong. They scoped the project based on assumptions. They discovered the real complexity three months in, when the budget was half spent and the timeline was already slipping.
An audit that takes two weeks and produces a clear picture of reality is the cheapest insurance a team can buy before committing to a five-figure project. The question is not whether you can afford to do one. It is whether you can afford to skip it.