Client relationships in SEO can go wrong for reasons that have nothing to do with the technical work. Often it comes down to information: the client saw a comment that was never meant for them, a strategy document changed after it was approved, or nobody could say who signed off a piece of work and on what basis. These are process problems, and they have SEO consequences because SEO depends on long, ongoing collaboration with people who need to trust the direction.
Keep working notes and client-facing notes apart
Every engagement produces two kinds of writing. One is the working layer: hypotheses, half-formed ideas, observations about how the client’s team operates, notes on what might not work. The other is the client-facing layer: findings, decisions, recommendations and status. Mixing them produces two predictable problems. Either everything is written defensively, because the client might read it, and the quality of the thinking suffers, or something candid reaches the client and the relationship pays for it.
The fix is to make the distinction explicit when something is written, not at the moment someone decides to share it. A comment is either internal or visible to the client, and it says so.
Tiered visibility is already normal in the tools SEOs use daily. Search Console, for example, distinguishes owners, full users, restricted users and associates, with different rights to view data and take actions. A project record deserves the same care.
Show the agreed version, not the working draft
A strategy is a living document inside an agency and a commitment outside it. If the client sees whatever the draft says today, every edit changes what they think they signed up for. Publishing the strategy as dated versions solves this. The client sees the version that was agreed, a change creates a new version, and the history shows what changed and when. It also makes it much easier to measure results against the plan that was actually in force at the time.
Record approvals as decisions
SEO work often needs the client’s approval: a change to templates, a migration plan, a set of redirects, a content brief. When approval is a thread of emails, the question “did we agree to that?” six months later is answered by whoever searches best. A recorded decision names what was approved, which version, who approved it and when, and it cannot be quietly edited afterwards. That protects the client as much as the agency, because it also proves what was not approved.
Attach the evidence
A recommendation is stronger with its evidence beside it: the crawl export, the screenshot, the report. Clients who can see why something is recommended argue less about whether it should be done. Evidence also makes a handover to another consultant or an in-house team much less painful.
Agree what the client will see before the work starts
Most of the friction described above is avoidable with a conversation in the first week. Agree three things:
- What the client will see, and when. A published strategy, a regular report and a place to see current priorities. Say what they will not see, such as internal discussion, so that its absence is not a surprise.
- Who approves what. Name the people and the kinds of change. A client’s marketing lead may be able to approve a content brief but not a change to templates or redirects.
- How decisions are recorded. If the answer is “in the system”, say where the client can look them up.
It also helps to agree the language. SEO is full of terms that mean something specific to a practitioner and nothing to a finance director. A report that is understood is more useful than a more detailed one that is not.
Other people on the project
Clients usually have more than one stakeholder: developers who implement changes, a content team who write pages, an agency that handles paid media. Each needs a different slice of the work. Developers need precise tickets with evidence and acceptance criteria. Content teams need briefs. Executives need outcomes. Giving everyone the same view serves none of them well, and it is another reason to separate what is internal, what is shared with the project team and what is for the client’s decision-makers.
What goes in the client report
A client report is not a log of everything done. It earns its place by answering the questions the client actually has. A useful structure is:
- What changed: the work completed since the last report, in plain language.
- What it did: the measured effect, with the period and source stated, and any figure that is not available labelled as such.
- What we found: new issues or opportunities, each with its evidence.
- What happens next: the priorities for the coming period, in order.
- What we need from you: decisions, approvals or access that are blocking progress.
Common ways this goes wrong
- A comment meant for the team is visible to the client, or the reverse.
- A strategy is edited after it was approved, and nobody can say what the approved version was.
- An approval was given in a meeting or a chat, and a year later nobody can find it.
- The evidence for a recommendation lives in one person’s inbox and leaves with them.
- A handover to another consultant loses the reasoning behind decisions, so they are made again.
- Different people at the client see different amounts of the work, and the gaps cause friction.
When an engagement ends
The way an engagement closes says a lot about how it was run. A client who can take away the published strategy versions, the decision record and the evidence can hand the work to anyone. Making that possible from the start changes how the work is documented while it is under way.
Where we put this into practice
These are the habits SEO Ops is organised around: a clear line between internal and client-visible comments, a client portal that shows the published version of a strategy, and approvals that are recorded as decisions. It runs inside WordPress, so a consultancy can keep client work in a system it already controls.