Most SEO case studies are written after the win, which makes them useless — the author already knows the ending and quietly edits out the wrong turns. This one is written as it happens. It is a dated log of building SarvKit from a blank domain to roughly 500 pages, and it includes the decisions that turned out badly.
Two things you should know before reading. First, I am deliberately not publishing absolute traffic figures, per-page keyword data, or revenue. What is here are ratios, rates and the reasoning — enough to be useful, not enough to be a competitor's roadmap. Second, this page is updated as the site ages rather than rewritten, so entries stay as they were written even when a later entry proves them wrong.
The timeline
Breadth-first, on purpose
The opening decision was to build wide rather than deep: thirteen unrelated suites covering finance, health, legal, developer, design, PDF and study tools. The reasoning was that I had no idea which category would work, and static client-side tools cost essentially nothing to keep online — no servers, no per-tool maintenance.
That reasoning still holds, with one correction I would not understand for another four months. Breadth is a fine way to find a winner. It is a bad way to keep spending once you have found one.
Roughly 500 pages published in a few weeks
Nearly the whole site went live in a short window. Every suite received a comparable number of guides — about twenty each — regardless of whether that suite had shown any sign of working, because at that point none of them had any data at all.
This is the single most expensive mistake in the log. The tools were cheap. The guides were not: they were the bulk of the actual work, and they were spread evenly across thirteen categories before a single piece of evidence existed about which category deserved them.
Bing arrived first. Google did not arrive at all.
Within weeks Bing was indexing pages and sending real clicks. Google, given the identical sitemap, the identical markup and the identical content, sent essentially nothing.
Nothing was wrong technically — no blocked resources, no canonical errors, no robots directives. The engines simply have very different tolerance for an unknown domain. Bing will index a new site liberally and let ranking sort it out. Google largely declines to spend crawl budget until it has a reason to.
AI citations started growing before clicks did
Bing Webmaster Tools reports how often an AI assistant cites your pages when composing an answer. That number began climbing steadily, across a widening set of distinct pages, well before those pages earned meaningful click traffic.
This is a genuinely new measurement problem. A page can be doing real work — being read, being used as a source, shaping an answer someone acted on — while its click count sits at zero. Judged on clicks alone, those pages look like failures.
The first per-page data: brutal concentration
The first proper per-URL export was the most informative thing that happened all year. Traffic was not spread thinly across 200 tools. The overwhelming majority of all clicks landed on one tool, and it was not one I would have predicted — nor one I had spent much time on.
The winner was a sample file generator: you specify a format and an exact size, and it hands you a valid file. Working out why that one won, when 200 others didn't, became the central question.
The answer turned out to be simple. It produces an artifact. An AI assistant can tell you an email attachment limit instantly and correctly — which is why our guide explaining that limit earns nothing. It cannot hand you a 25 MB file to test the limit with. The click survives only where the answer is a file rather than a fact.
Rejecting the obvious growth plan
The tempting next move was to build a landing page for every popular variant — one for each size, one for each format, a dozen or so near-identical pages. Search demand clearly existed for each.
I didn't, and I think that was right. Those pages would have been about ninety percent identical to a page that already ranked for the same queries. That is the textbook doorway pattern, and it is exactly the profile that gets a large templated site into trouble.
The alternative was depth: make the one winning page do more. Multi-page documents, more formats, real image dimensions, larger files, exact byte sizing. Same demand captured, one URL, no duplication risk.
Testing with strict parsers found bugs nothing else caught
Generating a file of an exact byte size that is also valid is much harder than it looks, and the failures are silent. Padding to hit a target size is where everything breaks. Real bugs found only by validating output with strict library parsers rather than by opening files in a viewer:
- PDF: a content stream declared a hardcoded
/Lengththat did not match its actual byte count. Lenient viewers rendered it fine; strict readers over-read past the stream and rejected the file. Byte offsets in the cross-reference table have to be computed, never assumed. - DOCX and XLSX: padding bytes were appended after the closing XML tag. Word opened them; proper XML parsers refused them outright with "extra content at end of document" — which broke the exact audience that needs generated test files. The fix was to place padding inside an XML comment.
- PNG: pad using a
tEXtchunk inserted beforeIEND, so the chunk structure stays valid. - JPEG: pad using comment markers placed after the start-of-image marker; padding near the end decodes unreliably.
- Structured text: JSON, XML and SVG each have a minimum size below which no valid document exists. Requests below that floor were silently returning whitespace.
Google finally showed up — as impressions, not clicks
Google impressions went from essentially nothing to a genuine, sustained presence. Clicks stayed near zero, because average positions were well outside the pages anyone actually looks at.
It is tempting to read that as failure. It isn't. Impressions arriving before clicks is the normal sequence: it means the pages are indexed and being considered. What was interesting is where it happened — on a handful of country-specific financial calculators, not on the tool that dominates elsewhere.
The mistake: noindexing almost the entire site
Acting on widely-repeated forum advice that search engines were penalising sites with large volumes of AI-assisted pages, I applied a noindex header to nearly every page, keeping only a couple of proven ones indexed. The theory was that a smaller, higher-quality indexed footprint would lift the rest.
It was reverted within days. Four reasons it was wrong:
- Most non-indexed pages had never been crawled in the first place. Removing something that was already absent changes nothing.
- It de-indexed the pages that were indexed — including the ones that had just started earning impressions.
- There is no documented mechanism by which fewer indexed pages improves how a site is assessed. It is folk wisdom.
- The header included
nofollow, which silently cancelled months of deliberate internal linking, and the directive applied equally to the engine that was actually sending traffic.
Comparing the same weekdays before and after showed no measurable damage, which was luck rather than judgement.
What actually predicts an AI citation (it isn't length)
With citation data for every guide on the site, I could finally test the assumption everyone repeats — that longer, more comprehensive content wins. I bucketed all ~240 articles by word count and measured what share of each bucket had ever been cited:
| Article length | Share of articles ever cited |
|---|---|
| Under 600 words | 46% |
| 600–799 words | 44% |
| 800–1,199 words | 50% |
| 1,200–1,799 words | 51% |
| 1,800+ words | 33% |
Flat — and the longest bucket performs worst. Two of the most-cited pages on the entire site are among the shortest things published, at just over 500 words each.
The real pattern showed up when comparing suites with identical median article length. One suite of unit-conversion references (median 637 words) and one suite of fitness guides (median 649 words) differ by roughly two orders of magnitude in citations. Same length, same site, same author, same template.
The difference is what the content is. Bounded reference material — viscosity units, paper size specifications, PDF format differences, refund-policy rules — gets cited constantly. General advice — intermittent fasting, resume tailoring, tone of voice — gets cited almost never, despite far higher search demand.
What I would tell someone starting today
- Build cheap and wide only until something moves. Then stop and concentrate. The expensive mistake is not breadth — it is continuing to invest evenly after the data has spoken.
- Prefer things that produce an artifact. If an AI assistant can answer the query in a sentence, you will not get the click, no matter how good the page is.
- Do not judge pages by clicks alone. Citations and impressions are real signals, and on a young site they arrive first.
- Write reference material, not advice. Bounded and checkable beats broad and helpful, by a factor that surprised me.
- Validate output with strict tooling. Everything that looked fine in a viewer was the thing that was broken.
- Be slow to restructure. Every "prune it, shrink it, noindex it" theory tested here has failed against actual data.
- Expect the timeline to be long. Six months in, one engine works well and the other is only beginning to notice. That appears to be normal.
Still open
Questions this log has not answered yet, which future entries should: whether Google impressions convert into positions that earn clicks; whether reference-style content can be produced deliberately rather than discovered by accident; and whether a second artifact tool can be made to work, or whether the first one was simply luck. I will add entries as those resolve — including if they resolve badly.