From Zero to 50 Indexed Blog Posts in 90 Days (an SMB Sprint)

Most "X posts in 90 days" content lies about results. The numbers come from clients with established authority, the timelines hide the strategy phase, and the unflattering middle months get edited out. This post does the opposite. It walks through a modelled scenario for a representative SMB website (B2B SaaS, DR 12, no existing blog content) executing a structured 90-day sprint, with every assumption named.

The numbers in this post come from public benchmarks, not invented client data. Two outcomes are modelled side by side: the realistic one (what most SMBs see if they execute the plan competently) and the under-performance one (what happens when the cluster strategy is wrong or briefs slip). The point is to give you a defensible plan to take to a budget conversation, not a fairy tale to inspire you.

Why a 90-day content sprint is the right unit of planning

Ninety days is long enough to build cluster depth and short enough to fit inside a single quarterly budget cycle. Anything shorter ships posts that have not had time to index, and anything longer pushes the first measurement window past the renewal conversation that paid for the work.

The 90-day frame also matches how search engines now read new content. A sprint that ships 50 thematically related posts inside a quarter sends a stronger topical authority signal than the same 50 posts published over 18 months, because the topical authority signals search engines now use to evaluate cluster depth reward depth concentrated in time over slow drip-feed publishing.

The reason most SMBs do not run sprints is operational, not strategic. Producing 50 posts in 90 days requires a publishing rhythm of 4 to 5 articles per week, brief approval inside three working days, and zero rework loops on the strategy. The plan in this post is built around the strategy and approval workflow SMB teams of 1 to 5 use to ship content without an agency, because the model breaks at the operational layer first.

The starting assumptions of this modelled SMB scenario

• Domain profile. B2B SaaS website, 18 to 36 months old, Domain Rating around 12 (per Ahrefs). Existing site content is product, pricing, about, and a stub blog with under 5 posts. No prior topical authority.
• Audience and offering. A defined target persona, a priced product or service, and at least one priority commercial keyword set the company already cares about ranking for.
• Resource available. One marketing owner with 8 to 12 hours per week for content, an AI writing budget of £100 to £300 per month, and a single approver on the business side who can sign off briefs in under three working days.
• Technical baseline. A working CMS with sitemap submission to Google Search Console, schema markup for Article and BreadcrumbList, page speed in the green for desktop, and no major crawl issues.
• Out of scope. Paid promotion, link building outreach, technical SEO migrations, and rebrand work. The sprint is a content production exercise on a working baseline, not a recovery project.

If your situation differs from these assumptions, the model still applies but the numbers shift. Lower starting domain rating slows indexing. Weak technical baseline produces lower indexed-share rates regardless of content quality. No defined approver pushes the publishing rhythm out of the four-per-week range that makes the 50-post target achievable.

Days 1 to 14 are the strategy and infrastructure you cannot skip

The strategy and infrastructure phase is where most sprints fail, not the writing phase. Skipping cluster mapping at the start produces a publishing rhythm that ships posts but cannot rank them, and that pattern is invisible until day 60 when the indexed posts have no traffic.

In the first two weeks the work is: identify three to five topical clusters from the priority commercial keyword set, map 10 to 14 article slots per cluster (one pillar plus 9 to 13 cluster posts), draft an 8-field brief template the team will use for every post, wire up Google Search Console and Google Analytics 4 with conversion event tracking, and produce the first 4 briefs ready to enter the writing rhythm at day 15. No posts publish in this phase. The temptation to skip ahead and start writing on day 3 is the single biggest predictor of under-performance at day 90.

Cluster mapping is the load-bearing piece. A pillar-cluster architecture mapped before writing starts cuts the rework that kills sprint timelines, because every post written before the architecture exists has to be re-evaluated when the architecture is added later. The model assumes the cluster work happens in days 3 to 9 of phase one, with brief production filling days 10 to 14.

Days 15 to 60 are the publishing rhythm that produces 50 indexed posts

• Cadence. Four to five articles per week, published Monday and Thursday, with a buffer slot for catch-up or overflow. The cadence is the unit of measurement. Weeks that drop below four posts compound into shortfall the sprint cannot recover from after day 60.
• Brief enforcement. Every post enters writing only after a signed-off 8-field brief. Briefs slipping past 24 hours of approval delay are the second-largest source of sprint failure. A minimum viable content brief with 8 fields keeps the publishing rhythm sustainable past week three, where most internally-run sprints stall.
• Internal linking on publication, not later. Every new post links to two earlier posts in the same cluster on the day it publishes. Retroactive linking gets done at day 60 to 90 in phase three, but the on-publication links cost almost nothing to add and matter disproportionately for indexing.
• Indexing submission. Submit each new URL to Google Search Console within 24 hours of publication. Use IndexNow for Bing. Indexing latency for a new domain is 7 to 21 days per post in this model, and submission cuts the upper bound on that range.

The publishing rhythm is the part the team underestimates. Producing one article per week is psychologically and operationally different from producing five. Most SMB teams hit week three at a 3-per-week cadence, fall behind the brief queue, and spend week four catching up rather than producing. A rolling 7-day calendar with auto-generated briefs handles the planning load that breaks most sprints in week three by keeping the brief pipeline ahead of the writing pipeline.

Days 61 to 90 produce indexing, internal linking, and the first ranking signals

The final phase is where the cluster work compounds into measurable signal. Indexing latency for a new domain on a fresh blog runs 7 to 21 days per post in this model, which means posts published in days 60 to 80 will not have indexed in time to show ranking signals by day 90. The phase-three work focuses on consolidating the posts that did publish early enough.

Three workstreams run in parallel. First, ship the final 15 to 20 articles of the sprint, prioritising posts that complete cluster coverage rather than posts that target the most competitive keywords. Second, audit indexing across all 50 published posts in Google Search Console and resubmit any URL Google has crawled but not yet placed in the index, and any URL Google has found but not yet crawled. Third, retroactively add internal links across the entire cluster, so every cluster post links to its pillar and to two to three sibling posts. The internal link architecture that turns 50 disconnected posts into a clustered authority signal is the work most SMB sprints defer to "later" and never come back to.

The realistic vs under-performance outcomes (and what causes each)

• Realistic outcome at day 90 (modelled). 45 to 55 indexed pages. Single-digit ranking positions on long-tail variations of cluster keywords. No top-10 rankings on competitive head terms. Domain Rating up by 1 to 3 points. Organic traffic at 100 to 400 monthly visitors, mostly from long-tail informational queries. Demo or signup conversions in single digits.
• Under-performance outcome at day 90 (modelled). 10 to 20 indexed pages. No top-50 rankings on cluster keywords. Domain Rating change of 0 to 1. Organic traffic effectively flat. The team blames "content marketing takes longer," and the budget gets cut at the next review.
• The three failures behind under-performance. Cluster strategy was wrong (the cluster does not match search intent or has no commercial value). Briefs were not enforced (writers freelanced the angle on each post, and the cluster does not read as a coherent body of work). Internal linking was deferred to a later that never came (50 isolated posts do not signal cluster authority).
• The leading indicator at day 30. If fewer than 8 articles have published by day 30, the under-performance scenario is already baked in. The fix is not "write faster" — the fix is to inspect the brief queue, not the writing capacity, because the bottleneck at day 30 is almost always brief approval delay.

The model is calibrated to the SMB profile in the assumptions section. A team with stronger starting domain rating sees indexing happen earlier and ranking signals show up by day 60 rather than day 90. A team with weaker brief enforcement collapses into the under-performance scenario regardless of how many writers are on the project. The Growth plan at £99 per month covers 3 sites and 30 articles, which fits a 50-post sprint with overage on a single site.

What to do at day 91 (and what to ignore until then)

At day 91 the work shifts from production to compounding. The next 90 days should publish 15 to 20 new posts (a third of the sprint pace), refresh the underperforming posts from the first sprint, and run the first cluster expansion based on the keyword data Google Search Console produced in days 60 to 90.

The temptation at day 91 is to look at outcome metrics and act on them. Resist that. Ranking volatility on new content is high in months 4 to 6, and acting on day-91 data will produce wasted optimisation work that gets undone by month 6 ranking shifts. The compounding effect of the sprint arrives in months 4 to 9, not at day 90, and the work at day 91 is to keep the publishing rhythm at a sustainable pace rather than chase early signals. If you want to model what your own cluster plan would look like before committing, analyse your site free and see the cluster plan you would publish from. The cluster generation step takes longer to read about than to run.