Case Study Pages: Structure and Examples
Build a credible case study with sourced baselines, checkable methods, timed results, honest attribution, client approval, and a decision-stage next step.
A case study documents a real client’s context, baseline, completed work, sourced results over time, attribution limits, and lessons.
Purpose: help a skeptical reader decide whether the method is credible and relevant to an organization recognizably like theirs.
Reader question: “Did this work for someone with my constraints, what exactly did they do, and how much confidence should I place in the result?”
This evidence-and-authority format belongs in the SEO post types system. Its fixed spine is context → before → method → results → what we would do differently. The final section is mandatory because honest hindsight makes the evidence believable and useful.
Questions it answers
Late-stage readers are testing risk, fit, and proof:
- “Is this company similar to mine in size, market, resources, or starting condition?”
- “What was happening before the engagement, and what are the actual baseline numbers?”
- “What was changed, shipped, or stopped—not merely recommended?”
- “Who did the work, over what period, and what moved in sourced absolute terms?”
- “Could another campaign, product change, season, or measurement change explain it?”
- “What failed, underperformed, or took longer?”
- “What would the client and team do differently?”
A logo, quote, or rising chart cannot substitute for those answers.
When to use this post type
Claims become decision evidence only when the reader can connect a starting condition, an intervention, and a measured outcome. Choose this type after enough time has passed to observe results and the client has approved disclosure.
| Page type | Choose it when | Expected evidence | Decisive difference |
|---|---|---|---|
| Case study | A real, bounded engagement has a recorded baseline, checkable work, and results | Client context, source-owned numbers, timeframe, implementation record, attribution limits, lessons | Past tense and specific: it proves what happened in one named or responsibly anonymized case |
| Testimonial | A customer can credibly describe experience or satisfaction, but a complete evidence record is unavailable | Approved first-person opinion with speaker, role, and context | Opinion is the product; it is short and does not prove causal performance |
| use-case page | A recurring audience needs to understand how a capability solves a common problem | Generic workflow, relevant capabilities, constraints, and expected—not guaranteed—outcomes | Present tense and repeatable: it explains what someone can do, not what one client did |
| results framework | Readers need a portfolio-level view of measurement or several outcomes | Consistent metric definitions, links to underlying evidence, segmentation | It summarizes across cases; it does not contain one engagement’s full narrative spine |
Do not manufacture a case study from a quote and screenshot. If baselines, dates, or source access are missing, publish a testimonial or labeled customer story instead.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Best for these business types
The ranking reflects how much buyers must trust delivery and how strongly results vary by context.
- B2B services . Intangible delivery and collaborative outcomes make method, responsibilities, and constraints essential proof before an enquiry.
- SaaS . Buyers need evidence that implementation reached adoption and value. Segment by company size, use case, stack, and time to value.
- Ecommerce . Revenue and conversion are measurable, but inventory, promotions, seasonality, and channel mix confound them. Compare like periods and disclose context.
- Local service businesses . Geography, capacity, lead quality, and booking value matter more than national traffic. Distinguish enquiries from qualified and paid jobs.
- Marketplaces . Show which side changed, in which market, and whether liquidity or completed transactions improved—not registrations alone.
- Media publishers and affiliates . Use for a documented editorial, distribution, or monetization change; separate traffic, qualified referrals, and revenue.
Search intent
The dominant search intent is commercial investigation. Queries combine a method or vendor with an industry, outcome, or constraint: “B2B SaaS SEO case study” or “[provider] customer results.”
A current search engine results page commonly mixes libraries, individual stories, example collections, and vendor pages. AI answers compress cases into client → action → result summaries. Precise qualifiers must therefore travel with every extracted number.
Use this review to select the fit signals and evidence that survive extraction; do not copy competing claims.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Page structure
Word ranges are planning controls, not quotas.
| Section | Word range | Purpose | Status |
|---|---|---|---|
| Direct answer and outcome | 50–90 | Identify the client type, method, primary result, period, and important attribution qualifier | Required |
| Client profile | 80–150 | Establish business model, size band, market, audience, offering, team, and relevant constraints | Required |
| Situation before | 180–300 | Describe the decision pressure and report comparable baseline values with dates and sources | Required |
| Goals and measurement contract | 100–180 | State desired outcomes, metric definitions, observation windows, data owners, and exclusions agreed before work | Required |
| What was done | 400–700 | Name phases run, post types produced, elements retrofitted, technical changes, volume, owners, and dates | Required |
| Implementation timeline | 120–220 | Put decisions, releases, delays, and measurement points in chronological order | Required |
| Results | 300–500 | Report before and after absolutes, calculated change, timeframe, source, segments, and limitations | Required |
| Client quote | 40–100 | Add approved first-person experience or decision context that data cannot provide | Conditional: only with approval |
| Attribution and other changes | 120–220 | Separate directly measured effects, modeled contribution, correlation, and plausible confounders | Required |
| What we would do differently | 150–260 | Name one to three specific changes to sequencing, scope, instrumentation, or execution | Required |
| Related method | 80–140 | Route readers to the exact post types, elements, and process phases used | Required |
| FAQ | 220–420 | Resolve five or more residual questions about fit, evidence, privacy, timing, and transferability | Required |
| CTA | 30–80 | Offer one decision-stage action tied to the reader’s comparable situation | Required |
Required elements
The anatomy governs the profile, stat band, timeline, method summary, chart, quote, and results table. These reusable elements have canonical pages.
| Element | Always or conditional | Exact position | Why |
|---|---|---|---|
| Direct answer block | Always | Immediately after the H1 | It gives a skeptical reader the client, method, outcome, period, and qualifier before narrative detail |
| Quick overview and table of contents | Always | After the opening outcome and client profile | A long evidence page needs stable routes to method, results, limitations, and lessons |
| Annotated screenshot | Conditional | Beside the first claim that depends on a dashboard, interface, or visual implementation state | It turns a cropped image into inspectable evidence with source, date, unit, and relevant region identified |
| Sources block | Always | After attribution and before FAQ | Every number and material factual claim needs a source record a reviewer can trace |
| Related content block | Always | After lessons, before FAQ | It exposes the exact method behind the result and routes readers to the matching business model |
| FAQ structure | Always | After sources and related method, before CTA | It handles legitimate questions about relevance, transferability, privacy, and evidence without weakening the narrative |
| CTA block | Always | Final authored element | One decision-stage next step lets a qualified reader test their own starting position |
Frontmatter
Follow the frontmatter specification
. This page uses entity = "post-type-case-study"; a produced story uses a stable identifier such as case-study-hz-containers.
Schema.org has no general CaseStudy type. Use Article, with about identifying the approved client or engagement; templates may emit BreadcrumbList. Add FAQPage only when visible and structured answers match. A client quote does not make the page a Review.
| Field | Required value or rule |
|---|---|
title and seoTitle | Name the client or approved segment plus one verified outcome; do not lead with an unqualified percentage |
description | 150–160 characters containing the primary term, relevant client context, result, and period |
entity | Stable identifier in the form case-study-[client-or-approved-alias] |
type | Site case-study layout for produced stories; academy only for this specification |
schemaType | Article; optional matching FAQPage node and template-generated BreadcrumbList |
client, industry, domain | Required when approved; otherwise approved alias, specific industry, region, and size band |
date and lastmod | Initial publication and latest material evidence or approval review |
measurementStart, measurementEnd | ISO dates for the principal result window; add baseline dates in the evidence record |
sourceOwner | System or party owning the primary metric, such as Google Search Console, CRM, or client finance team |
approvalStatus and approvedAt | Publication permission state and latest approval date |
elements and businessTypes | Only components rendered and business models genuinely represented |
[[lnks]] | One record for every internal body link, with verbatim anchor text and valid canonical path |
[[faq]] | Five to eight visible residual questions with answers matching the rendered page exactly |
Full example
This copy-pasteable skeleton uses brackets as contracts for approved, sourced copy.
# How a European B2B supplier built measurable search and AI visibility in 12 months
[In 50–90 words, identify the approved client profile, starting state, exact program, primary before/after result, measurement dates, source, and attribution qualifier.]
## Client profile
- **Business:** [approved name or specific anonymized description]
- **Scale:** [employee/revenue/customer band approved for publication]
- **Market:** [countries, language, buyer, and sales model]
- **Team:** [people responsible for implementation and approval]
- **Constraint:** [the operational limitation that shaped the method]
## The situation before
[Explain what was failing and why it mattered. Report each baseline as: metric definition; absolute value; start and end dates; segment; source owner. State missing data plainly.]
## Goals and measurement contract
[List the outcomes agreed before implementation, the leading indicators, the business outcomes, observation window, data sources, attribution rule, and exclusions.]
## What we did
### Phase 1: establish the baseline and opportunity
[Name the process phases run, dates, participants, findings, and decisions.]
### Phase 2: build and retrofit the content system
[Name each post type, page count, element, language, owner, review standard, and release period.]
### Phase 3: measure and iterate
[Name the monitoring cadence, prompts or queries, changes made after release, and what was intentionally left unchanged.]
## Implementation timeline
| Date | Work shipped | Owner | Verification |
|---|---|---|---|
| [YYYY-MM-DD] | [specific deliverable] | [role] | [release record or source] |
| [YYYY-MM-DD] | [specific deliverable] | [role] | [release record or source] |
| [YYYY-MM-DD] | [measurement checkpoint] | [role] | [dashboard and export date] |
## Results after 12 months
| Metric | Baseline | Result | Change | Period | Source |
|---|---:|---:|---:|---|---|
| [metric and definition] | [absolute] | [absolute] | [absolute and %] | [dates] | [owner/system] |
| [metric and definition] | [absolute] | [absolute] | [absolute and %] | [dates] | [owner/system] |
[Explain segment differences, lag, seasonality, data gaps, and whether the observation window is complete.]
> “[Approved client wording about implementation, adoption, or decision value—not an unsupported result claim.]”
>
> — [Name or approved role], [organization or approved description]
## What the evidence can and cannot attribute
[Separate direct measurements, modeled contribution, and correlation. Name concurrent releases, campaigns, demand changes, tracking changes, and other plausible causes.]
## What we would do differently
[Name one to three changes, why each would improve the work, and when it would happen. Include a tradeoff rather than pretending hindsight is free.]
## The method behind the result
[Link to the exact process phases, post types, and elements used. Explain what the reader will learn at each destination.]
## FAQ
[Add five or more approved questions about fit, timing, method, data, privacy, and transferability.]
## Compare your starting point
[Offer one decision-stage action: audit a comparable baseline, review a relevant method, or request a scoped assessment.]
Numbers discipline for the example
Every number needs a definition, baseline absolute, result absolute, comparison period, source owner, and limitation. “Traffic increased 180%” fails. “Monthly organic clicks increased from 1,240 in January 2025 to 3,472 in January 2026, a gain of 2,232 or 180%, in Google Search Console; no adjustment was made for branded-demand changes” is reviewable. These figures illustrate syntax, not an AmICited client claim.
If absolutes cannot be approved, use indexed values or ranges with dates, source, and the restriction disclosed. Never imply withheld absolutes.
Design examples
The gallery makes evidence easier to inspect.
Use a line chart for time and bars for discrete comparisons. An adjacent table must carry exact values.
Quality checklist
- The opening names the client or approved segment, method, result, timeframe, source, and attribution qualifier.
- The client profile gives enough scale, market, team, and constraint detail for a reader to judge similarity.
- Every figure includes a definition, baseline absolute, result absolute, comparison period, source owner, and limitation.
- Percentage claims show the underlying absolutes; confidential cases use approved indexes or ranges with the restriction disclosed.
- Baseline and result periods are comparable, or the difference is disclosed.
- “What was done” names shipped post types, retrofitted elements, process phases, volume, dates, and owners.
- The timeline includes implementation and measurement checkpoints, delays, and scope changes.
- Charts label axes, units, periods, interventions, source, and table equivalents.
- Attribution distinguishes direct measurement, modeled contribution, correlation, and unknowns.
- Concurrent campaigns, product releases, tracking changes, seasonality, and demand shifts are disclosed where relevant.
- Written approval covers identity, logo, quote, numbers, screenshots, commercial details, links, and final copy.
- Anonymization preserves model, scale, market, constraint, method, period, and source while removing identifying combinations.
- The mandatory “what we would do differently” section contains specific changes and tradeoffs.
- The method summary links to the exact post types and process phases used.
- Five or more FAQs match frontmatter exactly, and one decision-stage CTA closes the page.
Client approval and anonymization workflow
Publication can expose confidential operations, performance, and testimony. Agree disclosure before drafting, then obtain written sign-off on the rendered page.
- Set scope. List every proposed identity, company, performance, image, quote, link, and distribution disclosure.
- Verify evidence. Have the source owner confirm definitions, exports, periods, filters, currency, timezone, and tracking changes.
- Review claims. Delivery, analytics, legal, and client reviewers check facts and attribution without dropping qualifiers.
- Approve the rendering. Sign off charts, crops, captions, alt text, quote formatting, schema fields, and mobile presentation.
- Record expiry and withdrawal. Name an owner, review date, and correction or withdrawal route.
When naming is impossible, ask what combination of industry, country, headcount, product, date, and result could reveal the client. Replace identifiers with approved bands while preserving relevance. “A company got better results” is useless; an approved “50–100-person European B2B SaaS provider” can remain useful. Remove recognizable accounts, quotes, URLs, and disguised logos.
Common mistakes
- Starting after the low point. Justify the baseline and show enough preceding data to expose volatility.
- Reporting percentages without absolutes. A 500% increase from one lead to six is materially different from 100 to 600.
- Mislabeling totals or metrics. Cumulative totals need periods; sessions, clicks, citations, leads, and revenue are not interchangeable.
- Hiding the segment. Regional, non-brand, mobile, or new-user results must stay labeled.
- Treating correlation as attribution. Product launches, PR, seasonality, algorithm changes, or corrected tracking may explain movement.
- Calling recommendations implementation. “We improved content” is not checkable. Name the pages, elements, quantities, releases, owners, and verification.
- Using a quote as proof. A customer can credibly describe experience; analytics and business systems establish performance.
- Removing every imperfection. Omitting delays and misses makes the page less credible.
- Over-anonymizing. Preserve the traits needed to judge fit, or use another format.
- Reusing a use-case page in past tense. A generic workflow with a customer logo is still not an evidence record.
Internal linking
Link every method component actually used. In “what we did,” connect discovery and goals , access, tracking, and data sources , baseline measurement , and keyword and prompt research only when records confirm them.
Link only formats built—for example, ultimate guides , how-to guides , glossary term pages , or category pages .
Each case study must receive a contextual link from the results framework and matching business-type page. Relevant product, solution, and method pages may link when it proves the same capability.
Use the HZ-Containers case study and TarmacView case study as concise production references. Future revisions should retain their narrative while adding this specification’s measurement, attribution, approval, method, and lessons controls.
Do not duplicate a testimonial’s opinion, a use-case page’s generic present-tense workflow, or a results hub’s portfolio summary. Each sibling should link to the case study when a reader needs the complete evidence chain.
How to measure results
Measure qualified discovery, evidence consumption, method exploration, and the chosen conversion. Baseline branded and industry-plus-outcome prompts, organic discovery, assisted journeys, and the CTA action.
Use AmICited prompt tracking for “[brand] results” and “[service] case study for [industry].” Use source and citation intelligence to check whether answers cite the URL, preserve qualifiers, and avoid turning one result into a guarantee.
In the AmICited Cockpit , compare visibility, mentions, and citations over a defined window. Pair them with on-page events, CRM-qualified enquiries, and the agreed attribution model . A citation proves discovery, not pipeline; a reader’s enquiry is an assisted touchpoint, not automatically a sourced sale.
If relevant visitors do not reach the results, strengthen the opening fit signal. If they inspect evidence but stop, test the CTA. If AI answers strip absolutes or dates, rewrite the opening and chart caption so qualifiers travel.
FAQ
How long should a case study be?
Use the shortest length that preserves context, baseline, method, timed results, limitations, and lessons. A focused engagement may need 1,500 words; a multi-market program may need 3,000 or more. Evidence completeness matters more than length.
Can a case study be anonymous?
Yes, when the description remains specific enough for a reader to judge relevance. State the business model, scale band, market, starting condition, period, method, and sourced results; remove combinations that could identify the client.
Does every case study need a customer quote?
No. A quote is conditional on informed client approval and should add experience or decision context that the data cannot. Never invent, paraphrase into quotation marks, or make a quote carry an unsupported performance claim.
How should percentages be reported?
Pair each percentage with starting and ending absolutes, the exact measurement periods, the source, and any definition change. If confidentiality prevents absolutes, use approved indexed values or ranges and explain that limitation.
How do you discuss attribution honestly?
Separate directly measured effects from correlated movement. Name concurrent changes, use the agreed attribution model, and say when the evidence supports contribution rather than sole causation. Timing alone does not prove that the work caused the result.
When should a case study be updated?
Review it when its measurement window closes, a material result changes, the client withdraws approval, a product or method is renamed, or a source becomes unavailable. Keep the original baseline and dated observation windows visible.
Turn your evidence into a credible next step
Use the AmICited Cockpit to establish your visibility baseline, compare the prompts and sources that matter to your market, and identify the first result a future case study would need to prove.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card