Case studies / Constraint to rebuild
Case study · Constraint to rebuild

A studio nobody could find.

The reel was excellent. National brands, real budgets, work that wins the job in the room. The site scored 36 out of 100 on everything that decides whether a buyer ever reaches the room.

Published anonymously at the client’s request. No business name, no domain, no client list. Every figure below comes from the two audits on file.

36 → 87health score, same instrument
6findings, none cosmetic
4.5s → 0.9sload, heaviest pages
63%less page weight
23 → 48indexable pages
2audits, one of our own work
The brief

Nothing was wrong with the work. That was the problem.

When the product is good and the enquiries are thin, the constraint is almost never the product. It is the stage before anyone gets to see it.

This studio shoots for national brands. The films are genuinely good, and in a room with a buyer the reel usually closes it. Every part of the business depended on that reel reaching someone, and every mechanism that was supposed to deliver it was quietly broken.

The six-stage read put the constraint at the front of the chain, not the back. Not conversion, not retention. Being found, and being believed. Everything downstream was capped by it, which is why lifting anything downstream first would have been wasted effort.

Earliest, not lowest. A red at an early stage outranks a worse red further along, because an early choke caps everything after it. That is the whole discipline of the read, and it is what stopped this becoming a conversion project.
The evidence

Six findings. Not one of them visible from the front page.

The owner could not have found any of these by looking at his own site, and neither could a designer. They only surface when the site is walked the way a search engine walks it, and checked against what a buyer can actually verify in five minutes.

Google was describing a different company

Search the business name and the AI summary confidently described another firm, in another state, with a similar name and someone else’s founder. It sat directly beneath their own organic result. A buyer checking them out was reading about strangers, at the exact moment they were deciding.

Entity collisionBrand dilutionNothing first-party to disambiguate

Four location pages, near enough to identical

Over 97% the same text as one another, sharing a single page title, with copy that contradicted itself: the page for one city stated the business was based in another. That is the doorway pattern, and a search engine treats it accordingly.

97.8% similaritySelf-contradicting copy

One page title, across the entire site

Homepage, every location page, every service page, contact. All carrying the same title. That title is the line a buyer clicks in the results. Every page was making an identical promise, so no page stood for anything in particular.

No per-page disambiguation

The portfolio was orphaned

The individual project pages, the actual proof of the work and the whole reason a buyer picks one studio over another, were absent from the sitemap. The strongest asset on the site was the least findable thing on it.

UncrawlableProof invisible

No address, no founder, no about page

Nowhere on the site did it say who ran the business or where they were, while the verified address sat public on their business listing the whole time. For a company whose product is creative trust, there was nothing on the site to trust.

Zero E-E-A-TCredibility gap

About eight seconds to load on a phone

Most of it spent loading video player code for videos nobody had pressed play on. The buyer standing in a car park deciding whether to enquire was watching a blank screen.

~8s mobile312KB of player JS before interaction

Read one at a time, each looks survivable. Read together, they describe a business paying to produce beautiful films that a buyer either never finds, or finds and cannot verify.

"You cannot write a brief for a problem nobody has shown you yet."
Why the audit comes before the build, not after it
The decision

They had already hired a developer.

By the time the audit ran, the owner had engaged someone to rebuild the site. That is normally where a conversation like this ends, and reasonably so. Nobody wants to hear that the thing they have just commissioned is pointed at the wrong problem.

They changed course anyway. Not because anyone sold harder, but because the audit put six specific, checkable faults in front of them and a redesign would not have touched a single one. New look, same six faults, same silence.

None of which is a criticism of the developer. He was hired to build a better looking website and by every indication would have built one. He was hired for the wrong job. That is not his failure, and it is not really the owner’s either.

That is what the read is for. Not to find someone to blame, but to work out which job needs doing before anyone is paid to do a different one.

Rebuild, not patch

We do not often land here. Most sites are worth saving, and a rebuild nobody needed is an expensive way to arrive back where you started. This one was not worth saving: every fault traced to the platform and template underneath, so fixing them individually meant fighting that template on every future change.

It came apart and went back together as hand-authored, semantic HTML: a real structure, a page for every project, an interactive cost estimator so a buyer can reach a number without a phone call, and a build fast enough to render in under a second.

Then we audited our own rebuild

It scored 77. Not the number anyone wanted. It is in the documents, because a score you only take once is marketing. The second audit found what the rebuild had missed, including one item that had regressed against the old platform. Those were remediated, and it finished at 87.

Closed out

Every finding, and what happened to it.

Each line was verified on the deployed build rather than ticked off a plan: schema parsed, facades confirmed to load no player bytes, the 404 confirmed returning a 404, canonicals confirmed resolving without a redirect.

Eight seconds on mobile
Under one second on the heaviest pages, 63% lighter
Portfolio absent from the sitemap
Every project page listed, linked and crawlable
Four near-identical location pages
A real architecture: services, work, studio, estimator, a page per project
One broken schema block sitewide
Full structured data, including video markup on every project page
No address, founder or about page
All three published, and consistent everywhere they appear
Bare previews when shared
Open Graph and Twitter cards on all 23 pages
Missing pages returned a success code
A real, branded 404
Images hot-linked from third-party CDNs
101 stills self-hosted as right-sized WebP, no platform dependency

The largest single win was the least glamorous idea on the list: stop loading the video player until somebody presses play. That one change removed 312KB from every project page.

What it produced

A site that can be found, verified, and extended without us.

The visible output is a studio site that loads in under a second and puts the work where a buyer can reach it. The durable output is the structure underneath: every project declares which industry and which format it belongs to, so the vertical pages, format pages, work grid and sitemap all update themselves when project number sixteen is added. The cross-linking maintains itself instead of being hand-kept.

36 → 87Health score, before and after
48Indexable pages, from 23
98 – 100Lighthouse mobile, sitewide
0Invented client results

That last number matters as much as the first. No metric on the rebuilt site was invented to fill a gap. Where a result was not yet confirmed, the page says so plainly and waits, which is the same standard this case study is held to.

What we cannot claim yet. There are no enquiry figures here. The rebuilt site has not taken over the live domain, so any number quoted would be fiction. The 36 and the 87 are audit scores: they measure whether a buyer can find and verify the business, not whether the phone rings more. When there is a real trading number, it goes on this page, and not before.
Common questions

Constraint to rebuild, answered

Why rebuild instead of fixing the existing site?

Because every fault traced back to the platform and the template underneath it. Fixing them individually meant fighting that template on every future change, and losing ground on each update. That is the exception, not the rule. Most sites are worth saving, and a rebuild nobody needed is an expensive way to end up where you started.

You audited your own rebuild and published a 77. Why?

Because a score you only measure once is marketing. The first audit scored the live site 36. The rebuild was then audited on the same instrument and came back 77, which was not the number we wanted. That number is in the documents. We remediated what the second audit found and it finished at 87. A before-and-after that changes the test between readings is not a before-and-after.

The client had already hired a developer. What changed their mind?

Six specific, checkable faults, none of which a redesign would have touched. That is not a criticism of the developer. He was hired to build a better looking website and would have built one. He was hired for the wrong job, and nobody had shown the owner the right one yet. Naming the job is what the audit is for.

Do the scores mean the phone rings more?

No, and we will not imply otherwise. They measure whether a buyer can find the business and verify it before deciding. That was the stage capping this business. The rebuilt site has not yet taken over the live domain, so there is no enquiry figure we can honestly publish. When there is one, it goes on this page.

← The research case studies: regulatory and voice-of-customer Run the Constraint Audit on your own business →