Why most audits don't change anything.

Here's the pattern I've watched play out at three agencies over twelve years.

A company decides their site is underperforming. They have a gut feeling, or a board slide, or a quarter where conversions dipped and nobody could explain it. So they hire someone to audit it and tell them why.

Six weeks later, a PDF arrives. It's two hundred pages of color-coded severity ratings and a long executive summary. It talks about links and content and mentions Core Web Vitals in a fancy font. The most commonly used word is “opportunities.”

Leadership gets on a call where they'll go through a 60-slide deck of charts, with five slides highlighting the most important next steps. The executives forward the deck and the PDF to their dev teams.

If the dev team opens it, they only make that mistake once. Those severity ratings don't tell them what to do first, so they put it in a shared drive and add “seo” to their roadmap.

Three quarters later, someone in planning goes “wait, didn't we do an audit last year? what happened with that?”

And the answer is nothing happened with that, because that's how most audits go in the industry. It's not because anyone was lazy, it's because the shape of the deliverable was wrong.

The three failure modes

“Doing an audit” isn't a silver bullet — the findings have to be implemented and acted on. This doesn't happen for three structural reasons, and they're almost always happening together. Even if one team fixes something in isolation, you still end up with a PDF that nobody opens.

1. Symptoms instead of root causes.

Most audits list two hundred findings. A real site doesn't have two hundred problems, it has a few dozen root causes that create those two hundred downstream symptoms.

Most technical issues start at the platform level, forcing every page to inherit unminified CSS, render-blocking JavaScript, and a host of other issues that all trace back to the same cause — the site was built to look good first, function second. A handful of design decisions create an avalanche of findings.

When the audit lists the symptoms instead of the cluster, the engineering team must find root causes themselves. That was the job of the people doing the audit. So the job doesn't get done.

2. Advisory instead of implementation-ready.

“Consider optimizing your images” is not an instruction. It's a writing prompt for the person who actually has to do the work.

The same goes for “implement structured data,” “improve your internal linking,” and the perennial favorite, “ensure your site is mobile-friendly.”

An audit finding that doesn't give the file path, specific snippet, or config change isn't a finding, it's homework.

It transfers responsibility from the auditor, who was paid to figure out how to improve the site, to the engineer, and that's not their job.

Most engineers look at a PDF full of homework and, very reasonably, choose something actionable to work on.

3. Best-practice anchored instead of revenue-anchored.

“This is best practice” are the four most useless words in the industry, because they don't tell you what meeting best practice gets you.

What is your alternative costing you? Why is that practice best? It's homework.

A finding that doesn't connect to things that drive your bottom line won't survive contact with a quarterly planning meeting.

Planning meetings are about revenue, not best practice. Anything that doesn't make something more profitable, more efficient, or (ideally) both doesn't get a seat at that table.

A real finding anchors to the question “if we fix this, how does it help us hit our goals?” If you can't answer that, you don't know if the fix is worth doing, you just know it's “Best Practice.”

An audit that highlights impact competes against every other priority in the boardroom. An audit that lists best practices? It sits in Drive.

The synthesis problem

Even when an audit doesn't fail in the three ways above, there's a fourth failure mode waiting to kill the engagement. Synthesis.

Modern digital properties have three independent failure surfaces:

• The infrastructure (server, platform, frontend)
• The content (what questions you answer and how authoritatively)
• The measurement (whether your analytics is telling the truth at all)

All of these surfaces leak revenue, and they are all interconnected, but most audits only focus on one of them.

What ends up happening is the technical agency says “your LCP is bad,” the content agency says “you need more topic-cluster pages,” and the analytics consultant says “your GA4 is undercounting by 14%.”

All three are right. None of them know about the others. The client gets three roadmaps and now has to decide which one to actually execute, because time and budget are finite and no one has the time to take three audits from three teams and make them work together.

Synthesis is the answer. A unified roadmap that says “fix this server config first because it unblocks these four content improvements, which won't show up in analytics until you fix this tracking gap, and the total revenue impact across the chain is $X per month over six months” is the deliverable that actually ships. Three separate reports are three separate deliverables that don't get acted on.

What to demand instead

If you're commissioning an audit — any audit, from anyone — here's the four-line spec to hand them before you sign:

1. Every finding has a root cause, not a symptom. If you list two hundred items, I'm going to ask you which thirty of them are the actual underlying problems.
2. Every finding is implementation-ready. Config snippets, file paths, the specific change. If my engineer has to do the diagnostic work to ship the fix, you gave me homework, not an audit.
3. Every finding is impact-anchored. Show your math. I'm fine with ranges and conservative estimates, but I want my money back if the reason I'm told to spend my budget is that it's best practice.
4. The output is one ranked plan, not a folder of separate documents. If you can't synthesize across infrastructure, content, and measurement, you're missing two of the three places revenue actually leaks.

That's the audit shape your engineers can act on. It's the audit shape that delivers, and it's the audit shape that most of our industry refuses to deliver because it's a lot harder to produce than a handful of flashy PDFs.

Agencies and tools that can produce synthesis are rare and worth what they charge, because you can measure their impact. A Drive full of unopened reports is too expensive at any price, because all you did was pay for paper.

Why we care about this

We built WKTW because we see audits get commissioned and then quietly die because they're not acted on.

Every cofounder at this company has shipped audits like this in their career. Hundreds of pages full of prismatic graphs that don't go anywhere because they can't explain the why.

We're not above critique. We've contributed to the pile, but we wanted to make something better.

The Get Right is what you get when you let people with decades of industry experience build the tools they wished they had every time they shipped a PDF in the past.

The Get Right:

• Gives dev teams the root cause, not a tally.
• Provides an implementation path to every recommendation.
• Anchors each finding in WHY it matters to what you care about — your bottom line.
• Pulls everything into a single roadmap, so you don't need to figure out where to go, just when to start.

If a finding can't clear all four requirements, we don't tell you to do it. Even if it's best practice.

That's the whole product. That's why we built We Know The Why. Everything else is marketing.