How to Write an SEO Case Study With Verifiable Evidence, Not Inflated Claims

Direct answer: Build an SEO case study from a permissioned evidence file: define the business problem, record a comparable baseline, explain what changed, show the measured outcome and disclose what you cannot attribute to SEO. Use absolute numbers beside percentages, preserve report filters and distinguish a real result from a hypothetical example. Do not invent a client, quote, screenshot or causal explanation.

A credible case study helps a prospective client judge your reasoning and fit. It is not merely an impressive chart with a “we ranked number one” headline. A modest, well-documented result can be more useful than a dramatic claim whose period, metric and source are missing.

Scope and research method

This guide proposes an original evidence-led writing framework for freelancers and small agencies. Google's current people-first content and Search Console reporting documentation was reviewed on 15 October 2026 for relevant principles and metric definitions. The numerical examples below are explicitly hypothetical, not ShazzSEO results or proof of a ranking technique.

Google's helpful-content guidance encourages original information, clear sourcing and trustworthy presentation. That does not mean a case study guarantees rankings. The purpose here is to make professional evidence understandable and defensible.

Choose a case that answers a buyer's question

Start with the decision a prospective client needs to make. Can you diagnose a technical access problem? Can you improve a neglected service section? Can you work within a small development budget? Choose a project that demonstrates a relevant capability rather than the largest percentage in your records.

Define the audience and scope in one sentence. “How a small service business improved discovery of its existing service pages” is more informative than “Our amazing SEO success.” It tells the reader what kind of problem and business the evidence concerns.

Do not imply a universal outcome from one engagement. A case involving an established brand, significant development resources or a seasonal market may not transfer to a new local company. Describe those conditions so the reader can judge relevance.

Step 1: obtain publication approval

Agree which client name, logo, screenshots, quotations and results may be shown. Record the approved wording and scope privately. This is a proposed editorial safeguard, not a substitute for reviewing the actual contract and confidentiality obligations.

If the client declines identification, an anonymised case may still be useful if permitted and honestly labelled. Remove identifying details consistently; do not leave the domain visible in a screenshot while calling the project confidential. Avoid anonymisation that makes verification impossible without acknowledging that limitation.

For a Pakistani freelancer working with international clients, confirm the approver rather than assuming a day-to-day contact can authorise publication. Do not publish private dashboard access, customer names, email addresses or account identifiers to make a case look more convincing.

Step 2: create an evidence ledger

Claim	Required evidence	Limitation to record
Organic clicks increased	Comparable Search Console exports	Period, scope and filters
A technical fault was corrected	Before-and-after response or output evidence	Sample size and test time
Leads increased	Consistently defined enquiry records	Tracking changes and qualification rules
Revenue increased	Authorised business records	Attribution and other marketing activity
The client said something	Approved quotation or interview record	Editing and publication permission

Give each evidence item a private reference, collection date, owner and access location. The published article can cite an appropriate source description without exposing the entire private file. Preserve raw exports separately from edited presentation graphics.

Write the proposed claim before making the chart. If the evidence cannot support the wording, change the wording or omit the claim. A graph should clarify the evidence, not determine what the story must say.

Step 3: make the baseline comparable

Record the website section, country, device, search type, date range and metric. Google's Performance report documentation distinguishes clicks, impressions, CTR and average position and explains report dimensions. They are not interchangeable measures of business growth.

Use like-for-like periods where possible. A seven-day launch window compared with a thirty-day mature period is not a meaningful percentage comparison. Consider seasonality, holidays, promotions and changes in the set of pages being measured.

Keep the report configuration with the evidence. A screenshot cropped so tightly that the period and filters disappear may look cleaner but removes information a reviewer needs. Include a readable source note near the chart or table.

If tracking was broken during the baseline, do not pretend the baseline is reliable. You may have a technical implementation case rather than a growth case. Explain the measurement repair and begin a new comparable observation window.

Step 4: document the intervention timeline

List the significant changes with dates: diagnosis, approval, deployment and verification. Separate recommendations from implemented work. “We recommended internal links” is not the same as “the links were deployed and tested.”

Record other important activity during the same period, such as paid campaigns, brand publicity, a redesign, pricing changes or a tracking migration. These do not invalidate every observation, but they affect attribution. Omitting them creates a simpler and less trustworthy story.

Use a timeline that a reader can follow without a long task diary. For each major action, state the problem it addressed, the evidence behind the decision and the expected mechanism. Avoid listing routine tasks as if each were independently proven to cause growth.

Step 5: calculate outcomes transparently

Show the starting and ending values beside the percentage. For a non-zero baseline, percentage change is the difference divided by the baseline, multiplied by one hundred. Do not use an undefined percentage when the baseline is zero.

Hypothetical metric	Before	After	Interpretation
Organic clicks	200	300	100 more clicks; 50% increase
Confirmed enquiries	10	12	2 more enquiries; 20% increase
CTR	2%	3%	1 percentage-point increase; 50% relative increase

All figures in this table are invented for explanation and must never be presented as a client result. The example also shows why percentage points and relative percentages need different labels.

Do not average averages without understanding their weighting. If a combined metric requires clicks and impressions, calculate it from the appropriate underlying totals. Keep units and definitions consistent between the source export and the published table.

Step 6: separate observation from attribution

“Clicks increased after the release” describes timing. “The release caused every additional click” is a stronger claim. A typical client project is not a controlled experiment, so explain plausible contributions and competing explanations instead of claiming certainty.

Use calibrated wording: “The improvement followed these changes,” “the affected section showed this pattern,” or “we cannot isolate the effect of each intervention.” This is not weakness; it gives the buyer a more accurate picture of your analytical judgement.

If the case includes a genuine controlled test, describe its design, sample, exclusions and limitations. Do not relabel an ordinary before-and-after screenshot as an experiment. Never invent a control group or pretend that all external conditions stayed constant.

A reusable case-study structure

1. Context: business type, audience and relevant constraints.
2. Problem: the specific decision or failure being addressed.
3. Baseline: metric definitions, period and scope.
4. Diagnosis: evidence and rejected alternatives.
5. Actions: what was actually implemented and when.
6. Verification: tests showing the implementation worked.
7. Outcome: comparable absolute and relative figures.
8. Limitations: confounders, missing data and transferability.
9. Lesson: what a similar business can reasonably learn.

Do not fill this structure with generic paragraphs. If the case has no reliable revenue data, leave out a revenue claim. If the client permits no quote, do not manufacture one. The format should adapt to the evidence.

Worked example: a technical recovery case

Imagine a service section that accidentally served an indexing restriction after a release. The evidence file contains the affected URLs, observed output, deployment record and later checks. This is a hypothetical case outline, not an account of a ShazzSEO engagement.

A defensible headline could describe correcting the restriction and restoring the intended public configuration. The body would show what failed, how the cause was identified and which pages passed after the correction. Search visibility would be reported later with the available dates and limitations.

An indefensible version would claim a guaranteed traffic multiplier immediately after changing a setting. The technical test proves the restriction was corrected; it does not prove future demand, indexing speed or revenue. Keep those outcomes separate.

This example can still demonstrate valuable expertise without a spectacular growth chart. It shows diagnosis, implementation control and verification—capabilities a prospective client may genuinely need.

Use images as evidence, not decoration disguised as proof

Use approved screenshots with legible date ranges and source notes, and redact confidential details properly. Do not generate a fake Analytics interface, modify the underlying values or use a stock chart labelled as a client result.

An editorial illustration can explain the process, but label it by its role. The cartoon in this guide is a conceptual illustration, not performance evidence. Keep that distinction when building your own portfolio.

For the author and business context surrounding a case, see WordPress author proof and profile guidance. A byline supports accountability; it does not validate unsupported numbers.

Editorial review before publication

Have a second reviewer trace every material number to its evidence reference. Check calculations, periods, filters, permission and the difference between implemented and proposed work. Read the headline last to confirm it does not promise more than the body supports.

Record the publication date and a correction route. If the client withdraws permission or you discover a calculation error, review and correct the page promptly through the agreed process. Keep a version history rather than silently rewriting the story to preserve an impressive claim.

Frequently asked questions

Can I write a case study without a client name?

Yes, when permitted and honestly explained. State the anonymisation and the resulting verification limits. Do not invent identifying details to make the account feel concrete.

What if I only have a small result?

Show the absolute figures and the learning. A small, relevant result can demonstrate a useful method. Avoid making a tiny baseline look dramatic with a percentage-only headline.

Can AI help write the case?

It can help organise approved evidence and improve clarity. It must not invent results, quotations, tests or experience. The responsible author still needs to verify the final claims.

Should every case end with a sales pitch?

A relevant next step is fine, but keep the lesson and limitations intact. Do not turn one case into a promise that every buyer will receive the same result.

Conclusion

A trustworthy SEO case study is a traceable argument: problem, evidence, action, verification and measured outcome. Preserve permission, make comparisons fair and acknowledge attribution limits. Let the quality of the record carry the credibility.