A site that ranked badly on the audit didn't get there by accident. Something — a habit, a missing process, a tool that was never finished, a developer who moved on — caused each leak. The rebuild has to fix that, not just the symptom.
What you'll be able to do by the end
- Diagnose the root cause behind each of your top 3 audit issues.
- Distinguish symptoms (slow page) from causes (uncompressed hero image).
- Produce a 3-item rebuild punch list with the cause named for each.
Plain language version — the fast read
Your top three problems each have a cause. The page is slow because the photo is too big. The phone link doesn't work because it's not clickable. For each top problem, write down WHY. The fix is in the why.
Why this lesson exists
The most common rebuild mistake is this: an operator hires a designer, the designer fixes everything visible, the new site launches, and within six months it looks like the old one. Hours are stale again. The menu is a PDF again. The photos haven't been refreshed.
The reason isn't the designer. It's that nothing changed about why things went stale the first time. If hours go stale because nobody in your shop owns updating them, a new site doesn't change that — it just gives you a prettier place for the same thing to happen.
The exercise in this lesson is short: take your top three leaks from Lesson 5b and write the cause behind each, in one or two sentences. The discipline takes 10 minutes. The payoff is years.
Symptom thinking vs cause thinking
Read these two ways of describing the same three common leaks. The difference between them is the difference between a rebuild that lasts and a rebuild that doesn't.
Both ways of describing the leak are accurate. Only one of them is actionable past the next launch.
Write the causes for your top three
Open your Lesson 5b ranking in another tab if you need to. For each of your top three leaks, write one or two sentences that name the cause behind the symptom. Use the same shape as the "Cause thinking" examples above: "X is broken because Y."
Be specific about who, what, when. "Nobody owns updating them" is OK; "Pat used to update them on Tuesdays and Pat left in March" is much better. The more concrete the cause, the more obvious the fix.
Read what you wrote. For each cause, ask yourself: if we rebuild the site without changing this, will the same leak come back? If yes — and it almost always is yes — you now know that the rebuild has to include a process change, not just a design change.
What this changes for the rest of the bootcamp
Module 3 builds the replacement piece by piece. Each lesson there has a small "and the process behind it" sidebar — Lesson 8 (menu) asks who owns the menu file and how often it gets updated; Lesson 10 (hours) asks who owns the hours; Lesson 11b (GBP repair) asks who owns review responses. The process answers come from this lesson's writing.
If you're feeling like this lesson handed you more work than you wanted ("I came here to fix a website, not redesign my management"), that's the right reaction. It's also the difference between a rebuild that fixes the symptoms for a season and a rebuild that fixes them for years.
You named what to actually fix.
Three causes — the real reasons behind your three top audit leaks — saved in your browser. Module 3 reads these and builds the process answers into the replacement, not just the design.
This is the half of rebuilding most operators skip because it's uncomfortable. You didn't.