The strategy planner turns search demand, what competitors cover and the state of a site into an ordered plan: what to build, what to fix, what to merge and what to leave alone. The ordering is the point, because most SEO plans fail from being too long rather than from being wrong.
Built in-house. It is my own tooling rather than a reseller’s dashboard, which is why it checks the things I act on rather than everything a generic tool can measure.
What it does
It takes the inputs that already exist, keyword demand, Search Console performance, a crawl, competitor coverage and the site’s own structure, and produces a plan that says what happens first and what explicitly waits.
The second half of that matters as much as the first. A plan that lists forty things in priority order still reads like forty things to do. Saying plainly that twenty-eight of them can wait is what makes the first twelve happen.
What goes into it
| Input | What it contributes |
|---|---|
| Keyword demand | Where the volume actually is, by topic rather than by single term |
| Search Console | What already earns impressions, and what ranks just off the first page |
| Crawl data | What’s broken, duplicated or unreachable |
| Competitor coverage | What the ranking sites have that this one doesn’t |
| Site structure | Whether there’s a sensible home for new content, or whether that needs building first |
| Commercial value | Which topics connect to what the business actually sells |
How things get ordered
By what’s likely to produce a result soonest for the least work, weighted by commercial value. In practice that usually means pages sitting just off page one before anything new gets written, because improving something that already has impressions is faster than starting from nothing.
Structural fixes come before content in one specific case: when there’s nowhere sensible for the content to live. Publishing twenty pages into a section with no hub and no menu link is work that partly wastes itself.
Complexity rather than timeframes
Plans here carry a complexity rating rather than a date. A timeframe depends on approvals, developer availability and how much of the client’s own time is free, none of which I control, so a date on my plan is a guess presented as a commitment.
Complexity is something I can actually assess, and it lets a client sequence the work against their own capacity.
Example output
FIRST: Rebuild the main service page. 38,465 impressions at position 10.7, no sitewide menu link. Complexity: medium. FIRST: Consolidate 11 duplicate page sets to one URL per topic. Complexity: medium, needs developer time for redirects. NEXT: Build the hub for the largest uncovered topic cluster, then three supporting pages. LATER: The remaining 28 content gaps, in demand order. NOT NOW: Blog image alt text. Real, and not worth doing before the above.
What I review
Nothing goes in a plan without being checked against the live site. A content gap is checked against the client’s own content tracker first, because on any client running a content programme a “missing” page is often already written and sitting in an approval queue.
Demand figures come from keyword tools rather than from live results alone, and they’re treated as a guide to relative size rather than as a forecast.
Limitations
- A plan is a hypothesis. It’s ordered on what’s likely, and it should change as results come in.
- No timescales or guarantees. Search doesn’t work that way.
- It depends on access. Without Search Console, the plan is built on external estimates rather than on what the site actually earns.
Services it powers
The strategy planner powers SEO strategy and roadmap work, and feeds content pipelines and editorial briefs. See the rest of the tools on the tech stack page.
FAQ
Why don’t your plans have timescales?
Because the timing depends on approvals, developer availability and your own team’s capacity, none of which I control. A date from me would be a guess presented as a commitment. Each item carries a complexity rating instead, so you can sequence it against your own capacity.
What usually comes first in a plan?
Improving pages that already earn impressions but sit just off the first page, because lifting something with history is usually faster than starting from nothing. The exception is structural work, which comes first whenever there’s nowhere sensible for the new content to actually live.
Does the plan say what not to do?
Yes, and that’s deliberate. Every plan names the things that are real but can wait. A list of forty prioritised items still reads as forty jobs, and saying explicitly that most of them aren’t happening yet is what makes the first few get done.
See the whole toolkit
The tech stack page lists every tool, and the free assessment is where most plans start.