How to build the SEO business case
How to build an SEO business case that survives a finance review: the numbers to lead with, how to model the timeline, and a worked hypothetical example.
An SEO business case is a short document that states the cost, the expected return, the timeline and the risk of an SEO investment, in that order, so finance can evaluate it the way it evaluates any other spend. It works by starting from revenue you already make, not from a hoped-for number, and by naming what could go wrong.
That is the pitch version of a bigger topic: enterprise SEO sets out the whole programme this case is meant to fund, from team shape to technical scope.
On this page
What is an SEO business case, and who actually reads it?
It is the document that turns "we should invest in SEO" into a decision someone with a budget can say yes to. The reader is usually a CFO, a VP of marketing or a steering committee, none of whom need to understand search mechanics. They need to understand cost, return, timeline and risk, because that is the language every other budget request in the building is written in.
Write it to that reader, not to another SEO person. A business case full of ranking factors and technical jargon reads as a specialist justifying their own job. A business case full of revenue ranges, milestones and named risks reads as a manager who understands the business funding them.
Keep it short enough to read in one sitting. Two to four pages, with the numbers and the ask on the first page and everything else as backup, forces the writer to decide what actually matters. A forty-slide deck signals that the author has not yet decided what the strongest argument is, and a busy reviewer will not do that work for you.
What numbers does finance want to see first?
Current performance, then a modest, defensible projection. Start with organic sessions, conversions and revenue by the page types that carry your business, over the last twelve months. That baseline is the one number in the whole document nobody can argue with, because it is already happening.
From there, project conservatively. A modest number with visible assumptions beats a large one with none, because a reviewer who can see how you got a figure can also defend it to someone above them. State the assumption behind every number: current conversion rate held flat, a stated percentage lift in qualifying traffic, a stated timeline to reach it.
| Line | What it shows | Common mistake |
|---|---|---|
| Baseline | Organic revenue today, by page type | Skipping straight to the projection |
| Cost | People, platforms and engineering time, named separately | Folding engineering time into a services fee |
| Projected return | A conservative range with stated assumptions | One large round number with no visible working |
| Risk case | What a bad migration or lost ranking could cost | Leaving risk out entirely |
How do you build the revenue model, step by step?
Build it from the templates that carry the business, the same way a strategy is built, because a business case is really a strategy with a price tag attached.
Pull twelve months of baseline data
Organic sessions, conversions and revenue by page type, straight from analytics and Search Console, with no adjustment.
Identify the two or three templates worth fixing first
Rank them by current revenue and by how far each sits from a realistic best case.
Estimate a conservative lift per template
State the assumption in plain words: what has to be true for this number to happen, and by when.
Price the work against the return
Use real budget bands, not a placeholder, so the ratio of cost to return is honest from the first draft.
Write the downside case next to the upside case
What the projection looks like if adoption is slower, or if a planned redesign ships late.
Keep every number traceable to a source a reviewer could check themselves. A projection nobody can trace is a projection nobody defends once a hard quarter puts it under pressure.
Run the model past someone outside the SEO team before it goes to finance. A colleague in analytics or finance will ask the same questions a CFO will, and it is far cheaper to fix a shaky assumption in a working session than to have it surface for the first time in the meeting that decides the budget.
How do you handle the timeline honestly?
Promise milestones by quarter, never a single finish date. Template fixes on a large site can show up in crawl and indexing data within weeks of shipping, because one approved change reaches every page built from that template. Revenue a finance team will actually defend in a review usually takes two to four quarters, mostly because engineering releases, approvals and search engine re-indexing all add delay that has nothing to do with the quality of the work [1].
Say that delay out loud in the document. A business case that promises fast revenue and then produces a slow first quarter loses credibility for every quarter that follows it, even once the numbers do arrive.
What risks should the case name up front?
Two kinds: the risk of doing nothing, and the risk of doing the work badly. The risk of doing nothing is usually a competitor's pages taking the queries yours could have won, plus a slower but real risk from how answer engines now source what they cite, which draws on many of the same trust signals classic SEO builds [3]. The risk of doing the work badly is a migration, redesign or content push that damages what already ranks.
Naming the second risk is the part most cases skip, and it is often the stronger argument. A steering committee that already understands what a bad migration could cost will fund governance and review work faster than they will fund a growth pitch, because protecting revenue they already report is an easier "yes" than promising revenue they do not have yet.
Where does engineering cost fit into the ask?
As its own line, sized in sprints or story points, not folded into a general services fee. Most enterprise SEO wins ship as code, template or CMS changes, and a budget that pays for strategy and audits but not the hours to build the fixes produces a very good backlog and no shipped work.
Size it the way engineering already sizes its own work: name the ticket, the team, and a rough estimate before you ask for the time. SEO requirements for developers has the ticket format that makes this line credible to an engineering lead reading the case, rather than a vague request for "dev support."
What does a worked example look like?
Take a hypothetical mid-size retailer with 40,000 product pages and $18 million in annual organic revenue, entirely invented for illustration. Their baseline shows category pages driving 60% of that revenue but converting below the site average, with Search Console showing thousands of category variants marked "discovered, currently not indexed."
The case asks for $180,000 over the year: a $15,000-a-month retainer covering audit, content and reporting, plus 40 engineering story points a quarter for template and canonicalization fixes. It projects a conservative 8% lift in category-page conversion by month nine, worth roughly $860,000 in incremental annual revenue if the assumption holds, against a stated downside of half that if engineering capacity slips. That is the shape: one clear ask, one traceable model, one honest downside.
How do you present it to leadership and get a yes?
Present it as an investment decision, not a search update. Open with the baseline and the ask, put the model and its assumptions in an appendix, and spend the meeting on the risk case and the first milestone, because those are the two things a sceptical reviewer actually probes.
Bring the governance and pricing detail as backup, not as the pitch itself. Enterprise SEO pricing and SEO governance both hold the supporting detail a good question in the room will ask for, so you can answer it without promising a number you have not modelled.
After approval, keep the case alive rather than filing it away. Report against the first milestone on the date you promised, whether it lands well or not, because a sponsor who hears nothing until the quarterly review assumes the worst. The business case that gets a second round of funding is usually the one that kept its own promises visible the whole way through, not the one with the biggest opening number.
Questions people also ask
What is an SEO business case, exactly?
A short document that asks for money by naming its cost, its expected return, its timeline and its risk, in the order finance already uses for any other investment. It is not a keyword list, a ranking report or a pitch deck of tactics.
What is the single most common reason an SEO business case gets rejected?
A number nobody trusts. Cases that lead with a big, round revenue projection and no visible working are read as marketing, not modelling, and a sceptical reviewer stops trusting the rest of the document at the same point.
How far out should the timeline promise results?
In quarters, not in one end date. Template fixes can show in crawl and indexing data within weeks; revenue a finance team will defend usually takes two to four quarters once release cycles and re-indexing are accounted for.
Should the business case include engineering cost?
Yes, as a named line with a story-point or sprint estimate, not folded into a vague services fee. A case that leaves out engineering time gets approved and then stalls, because nobody budgeted the hours to actually ship the fixes.
Does the business case need a competitor comparison?
Only briefly, and only as context. A slide of competitor rankings supports urgency, but it is not a return estimate, and leaning on it too hard invites the question of why their growth should predict yours.
Sources
- SEO starter guide — Google Search Central (checked 23 September 2026)
- Do I need an SEO? — Google Search Central (checked 23 September 2026)
- AI features and your website — Google Search Central (checked 23 September 2026)
Get help building a business case finance will actually approve
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Enterprise SEO: the buyer's guide for 2026Enterprise SEO is search work for large sites and large teams: what it covers, what it costs, who owns it, and how to prove it pays back.
- Enterprise SEO pricing: what it actually costsWhat enterprise SEO costs per month, what pushes the price up or down, and how a large-site budget should split across people, platforms and engineering time.
- SEO governance: what it is and how to run itSEO governance is the rules, reviews and owners that stop a large site from undoing its own search work. What to write down, who owns it, and how to enforce it.
- SEO requirements for developersHow to write SEO requirements developers will build: ticket format, acceptance criteria, and the technical detail behind redirects, rendering and schema.