title: "I Published 24 Articles in 5 Days. Here's What Actually Moved — and What Took 3 Days to Show Up."
published: true
tags: seo, contentstrategy, webdev, indiehackers
description: "A solo dev's content sprint on a 172-tool site: 24 posts in 5 days across two languages, a 38-position jump in Google rankings, a traffic record — and the honest numbers on what lagged (GSC's 2-3 day delay, Baidu's 10-URL daily quota, and the silent MDX build failure that ate a post)."
Two months ago my side project — ToolVault, 172 browser-local developer tools — had the classic tool-site problem: utility traffic, no depth. People came, used the formatter, left. Google had noticed the same thing: our average position was 52.7. Page three of the search results, which is the same as not existing.
So I ran a content sprint. Not the "write every day" kind — the engineering kind, with a backlog, a bilingual pairing constraint, a per-day URL quota on the biggest search engine in my market, and a build pipeline that fights back. This post is the honest numbers: what moved immediately, what took three days to register, and what quietly broke.
The shape of the sprint
Five days, 24 articles, two languages each — 48 files. Three clusters:
- Post-quantum cryptography (14 posts): migration checklists, ML-KEM internals, passkeys, Ed25519, HKDF — a deliberate bet on a topic where 2026-2028 regulatory timelines are creating search demand faster than supply
- China compliance (6 posts): MLPS 2.0, PIPL impact assessments, generative-AI filing checklists — dense, checklist-heavy, almost no competition from real tool sites
- GEO (6 posts): making sites legible to AI search, robots.txt decisions for AI crawlers, llms.txt
Every post follows the same template: a real problem, a working checklist or table, an implementer's note with details only the person who built the thing knows, and cross-links into the tool pages.
What moved immediately
Direct traffic to fresh content. The PIPL impact-assessment post hit the site's top-10 pages the day it shipped — 18 visits from nowhere, which told me the search demand was real and the internal linking was doing its job before Google even noticed.
The spider economy. Baidu's crawler went from ~215 to ~280 hits/day across the sprint — new content doesn't just wait for organic discovery when you're pushing URLs through their API. Speaking of which:
The quota war nobody warns you about
Baidu's URL submission API allows 10 URLs per day for a site our size. Ten. We had 20 new posts' worth of Chinese URLs on day one of the sprint. That constraint reshaped the whole distribution plan: explicit URL lists over sitemap-driven auto-push (which had previously burned entire days' quotas on alphabetically-first tool pages), a next-morning ritual of pushing the highest-value ten, and English URLs excluded entirely (they go to IndexNow/Bing instead — different ecosystem).
If your market includes China, budget the quota into your content calendar. It's a strange but real rate limit on your distribution.
What took three days to show up
Google Search Console operates on a 2-3 day lag. The sprint started on a Friday; the first GSC evidence of the 146 deepened pages (an earlier content pass, same sprint family) arrived Monday. And it arrived spectacularly: average position 52.7 → 14.1 in a week, with the page-level impressions list composed entirely of deepened posts.
The lesson that took me an embarrassing amount of time to internalize: you cannot evaluate a content batch on day one. Not on traffic (internal links only carry you so far), not on GSC (the lag). The earliest honest read is day three, and the real read is day seven. Plan your metrics review cadence around that, or you'll either panic or celebrate early, both wrongly.
What quietly broke
The scariest part of the sprint wasn't the writing. It was this: one post silently vanished from the production build.
The cause: MDX parses < followed by a letter or digit as JSX. A perfectly innocent sentence — "lifetimes under 10 years are mostly fine" written with a literal <10 — threw a compile error that the build logged without failing the build, and the post simply didn't exist at its URL. A 404 where content should be.
We caught it only because the deployment checklist requires per-post curl checks: HTTP status plus a feature phrase grep for every new URL, every deploy. The fix was rewriting the sentence in prose ("under 10 years"). But the meta-lesson stands: static-site content pipelines fail silently, and "the build passed" is not "the content shipped." Verify per artifact, not per build.
(That same week the build also rejected a post title because the OG-image font subset lacked one Chinese character. Content pipelines are pipelines.)
The scoreboard
| Signal | Before | After 5 days |
|---|---|---|
| Published posts | 147 | 171 |
| GSC average position (7-day) | 52.7 | 14.1 |
| Human UV (server logs, daily, bot-filtered) | ~550 | 1,104 (record) |
| Baidu spider hits/day | ~215 | ~280 |
| PQC post traffic | 0 | top-5 page within 3 days |
The honest caveats: correlation isn't attribution — the sprint rode a holiday traffic peak, some of the position jump is the older deepening batch landing, and one day's record UV proves nothing by itself. But the composition of the traffic changed in a way raw numbers don't show: search-sourced visits to deep content instead of drive-by tool usage.
What I'd do differently
- Write the distribution plan with the content plan. The Baidu quota and the bilingual pairing constraint (our sitemap generator refuses unpaired zh/en posts — a 404-prevention rule that also once blocked a deploy for an hour) should shape the batch sizes from day one, not be discovered mid-sprint
- Automate the per-post verification harder. Every deploy should assert N new URLs × 200 × feature phrase, mechanically. We do it by script now; it should have been that way before the 404
- Trust the three-day rhythm. Publish, verify rendering, wait 72 hours, then look at data. Anything else is vibes
Try it
The sprint posts are live on ToolVault — the PQC cluster starts with a migration checklist, and the compliance series is deeper than anything I've found from a tool site. The series covers how the 100%-local architecture makes all of this a one-person operation.
And if you're running a tool site with thin content: the deepening math is unglamorous and it works. Position 52 to 14 in a week is not a growth hack. It's table stakes arriving late.
Top comments (0)