The first audit I ever sent a client was enormous, and I was proud of it. The client read the summary, asked which of the items actually mattered, and then went quiet for weeks. Nothing got fixed.
That taught me something I tell every new account manager: nobody approves an audit. They approve a plan. Turning the audit into ninety days of work a busy person can say yes to in one meeting is the part they're really paying for.
Sort before you sequence
Put every finding on one sheet and give each two rough ratings: how much it matters, and how much work it takes. High, medium and low is enough. You'll end up with four piles:
| Pile | What to do with it |
|---|---|
| High impact, low effort | Month one. These pay for the engagement. |
| High impact, high effort | Scope them properly and schedule them for months two and three. |
| Low impact, low effort | Batch them into a single tidy-up task. |
| Low impact, high effort | Leave them out, and say so. |
One rule overrides the matrix: anything that stops pages being crawled or indexed goes first, whatever it costs. A stray noindex, a robots.txt rule blocking a whole folder, canonicals pointing at the wrong pages. Polishing titles on a page Google can't index is wasted work.
Three sprints, one theme each
Ninety days splits naturally into three monthly sprints. A theme for each makes the plan easy to remember and to report on.
- Month one: get found. Indexing blockers, broken redirects, the quick wins from the first pile. The goal is visible progress within weeks.
- Month two: get chosen. Titles, descriptions, thin pages and internal links on the pages that already get impressions but not clicks.
- Month three: get faster and sturdier. The bigger technical work, like render-blocking resources or image delivery, which usually needs the client's developers and their release schedule.
Check the client's release calendar first. Developer work scheduled for the month of their big launch will slip.
Write tasks in the client's language
"Implement self-referencing canonicals on paginated category URLs" is accurate and means nothing to a marketing director. Compare it with: "Tell Google which version of each shoe category page is the real one, so the duplicates stop competing with it." Same task, and now it can be approved.
Each task gets four things: what changes, why it matters in one sentence, who does it, and when. The owner matters most. Plenty of SEO tasks are done by the client's own people, and a task with no named person on their side won't happen.
Say what you won't do
This is the section most plans skip and the one clients thank me for. List the findings you've deliberately left out, with a short reason: "The product images on korner.space without a WebP version: real, but small, and it's a two-week job for your developers. We'll revisit it in the next quarter."
It shows you read everything, it stops a developer raising the same item in every meeting, and it protects you when someone runs a free tool and finds an issue that's "not in the plan".
Show the starting line
End the plan with the baseline: current scores for the pages in scope, the indexing status, and the handful of numbers you'll report every month. A plan without a baseline can't show progress, however good the work is. Mohit's post on measuring whether a change worked covers how to record one.
Where the tooling helps
Every WebRankPage report ends with a What to fix first list, ranked by impact against effort and labeled as a quick fix, moderate or involved. It isn't a client plan, but it's a fast first pass at the sorting above. Tracking the pages in scope then gives you the before and after for each one when the ninety days are up.
For what comes before the plan, there's the first-week checklist.
