DEV Community

Cover image for 302 pages in 7 days, 29 impressions: an honest programmatic-SEO postmortem
shenghua wu
shenghua wu

Posted on

302 pages in 7 days, 29 impressions: an honest programmatic-SEO postmortem

Disclosure: I built this site with AI coding agents, and this article was drafted with AI assistance from my own Search Console exports, crawl logs, and GitHub API queries. The numbers are copied from those sources, not estimated.

Search Console, first data window after launch

Clicks        0
Impressions  29
Avg position 29.86

That is the entire search performance of a 302-page site.

This is a postmortem of a programmatic SEO play. Not the "we 10x'd our traffic" genre — the other one. The data is real and the conclusions cost me a week.


The bet

I built Tool Pantry: 208 free browser tools for PDFs, images, video, audio, and text, where everything processes client-side and nothing uploads. Zero backend, zero accounts.

The distribution plan was pSEO, and the reasoning was standard:

  1. Tools map cleanly onto search intent (compress image to 200kb, pdf to jpg, heic to webp)
  2. Long-tail tool queries are fragmented enough that a new site can slip into the gaps
  3. Volume wins — more indexed pages means more surface area for impressions

So I optimized for shipping rate. In seven days: 208 tools, 302 URLs, 25 long-form guides, 47 Spanish pages.

Then I waited for Google.


Week one, raw

Clicks:                    0
Impressions:              29
Average position:      29.86
Pages ever shown:          7  (of 302)
Indexed:              ~12–30  (of 302)
Enter fullscreen mode Exit fullscreen mode

Twenty-nine impressions. For three hundred and two pages.

Meanwhile the crawl logs were busy: 1,176 Googlebot requests in 48 hours, plus several thousand from AI crawlers. Google was absolutely reading the site. It just wasn't ranking it.

Here is the part that reframed everything for me.


Finding 1: The bottleneck is indexation, not ranking

I had been thinking about this as a ranking problem — "how do I get to page one?" But the pages weren't on page four either. Most weren't in the index at all.

Search Console puts every URL in one of three states:

State Meaning
URL is unknown to Google Never discovered
Discovered – currently not indexed Known, queued, not crawled yet
Crawled – currently not indexed Crawled, read, and declined

Out of 302 URLs, the overwhelming majority sat in the first bucket. Google knew about the homepage and a scattering of tool pages. The rest — 25 guides, 47 Spanish pages, most of the tool library — it had never looked at.

You cannot rank for a query if you are not in the index. And I had spent the entire week doing the thing that does not fix that.


Finding 2: Word count did not predict indexation. At all.

I had a comfortable theory: my tool pages were thin (~300 words), Google declines thin pages, so I should make them longer.

Then I actually checked word count against indexation status:

Page Words Status Position
/subnet-calculator 309 ✅ Indexed 7
/inventory-spreadsheet-generator 311 ✅ Indexed 7
/meme-generator 410 ✅ Indexed 6
/tool-pantry-vs-smallpdf 413 ✅ Indexed —
/tool-pantry-vs-tinypng 443 ✅ Indexed —
/tool-pantry-vs-pdf24 506 ❌ Crawled, not indexed —
/tool-pantry-vs-adobe-acrobat-online 547 ❌ Crawled, not indexed —
/compress-video 723 ❌ Crawled, not indexed —

The correlation is backwards. The shortest pages got indexed and ranked; the longest got declined.

The cleanest control is the vs-* pages: eight pages built from an identical template on the same day, with near-identical length. vs-smallpdf (413 words) and vs-tinypng (443 words) indexed. vs-pdf24 (506 words) and vs-adobe-acrobat-online (547 words) did not.

Same structure, same length, same day, same site. Split roughly down the middle.

My "thin content" theory was dead. If content depth were the gate, this table would look like the opposite of what it looks like.


Finding 3: Crawled – currently not indexed is a trust verdict, not a quality verdict

That label means Google fetched the page, parsed it, and decided not to spend index space on it. It reads like "your page isn't good enough." For a new domain, it usually means something else: "I don't yet have enough reason to trust this site."

The evidence is in the progression. Watching the same URLs over three days:

/compress-pdf        unknown → indexed → indexed
/video-to-mp3        unknown → indexed → indexed
/tool-pantry-vs-smallpdf   unknown → unknown → indexed
/tool-pantry-vs-tinypng    unknown → unknown → indexed
/tool-pantry-vs-pdf24      unknown → unknown → crawled, declined
Enter fullscreen mode Exit fullscreen mode

Pages are moving through a queue. It's not a verdict on any individual page — it's Google metering how much index space a brand-new, zero-authority domain has earned, and releasing it in batches.

That reframes the fix entirely. Improving page quality doesn't make the queue move faster. Increasing the domain's trust does.


Finding 4: The backlink strategy was a graveyard

The one lever I did have was backlinks, and the plan was "awesome lists" — submit the project to curated GitHub lists, get dofollow links from READMEs, accumulate authority.

I filed 21 PRs across six repositories.

Merged: zero.

Then I checked whether they could merge. Open PR counts and last-merge dates:

Repository Stars Open PRs Last merged anything
ComposioHQ/awesome-claude-skills 76K 100+ 2026-05-22
BehiSecc/awesome-claude-skills 10K 100+ 2026-06-03
heilcheng/awesome-agent-skills 6K 100+ 2026-04-05
SecretiveShell/Awesome-llms-txt 107 81 2026-09-28
karanb192/awesome-claude-skills 544 100+ 2026-10-02
thedaviddias/llms-txt-hub — 100+ 2026-09-25

100+ is the API's page limit. The real numbers are higher.

The three biggest targets — the ones that would have been worth the most — haven't merged a single PR in four to six months. They were flooded with submissions (largely AI-generated, which is its own irony here) and the maintainers stopped showing up.

My PRs are sitting at position ~100 in a queue that isn't being processed. They will never merge. And I spent a week of effort producing them, because I never checked whether the channel was alive before I committed to it.

That's the most expensive lesson in this post: validate that a distribution channel is actually functioning before you spend a week in it. "This repo has 76K stars" says nothing about whether it accepts contributions in 2026.


Finding 5: What did rank — and the one pattern worth keeping

Seven pages got impressions. Of those, three landed on page one:

Page Position Impressions
/meme-generator 6 9
/inventory-spreadsheet-generator 7 2
/subnet-calculator 7 1

And by query, the standout:

validate json     →  position 1
ukuran tiktok pixel →  position 9
validar json      →  position 17
json validator    →  position 8
Enter fullscreen mode Exit fullscreen mode

Two observations:

A single page can rank fast — for a query the big sites didn't bother with. /json-validator hit position 1 for validate json. That's a page competing with established developer-tool sites, and it won on specificity. validar json at 17 suggests the Spanish pages have the same opening.

But impressions were single digits. Ranking #1 for a query that gets searched a few times a week produces three impressions and zero clicks. Low-difficulty and low-volume are the same property. A brand-new domain can only win the queries nobody else wants, and those queries are small.

Which is not an argument against the approach — it's an argument against expecting it to be fast. The compounding is real, it's just slow, and it starts from zero.


What I changed

Stopped shipping pages. The marginal page was worth approximately nothing — 302 pages produced 29 impressions. Page 303 would produce a fraction of an impression. Worse, an ever-growing backlog of unindexed URLs against a fixed crawl allowance means each page gets a smaller share.

Redirected the effort into links from channels that actually work. Not GitHub READMEs with 100-deep PR queues — directories, communities, and content platforms where submissions get processed. The metric is links that land, not links that are attempted.

Kept the pages that already ranked, and left them alone. Three pages at positions 6–7 are the only proven asset. The instinct is to go rewrite everything; the discipline is to not disturb what's working.


The honest timeline

Nothing about this is fast. A new domain with no backlink history:

  • Weeks 1–2: crawling, almost no indexing, single-digit impressions
  • Weeks 3–8: indexation accelerates if authority signals appear; first real impressions
  • Months 2–4: rankings begin to stabilize and traffic becomes measurable

Anyone promising faster on a fresh domain is selling something. The pSEO playbook works — but it's a compounding strategy, and compounding has a floor you have to survive first.

The floor is a week of building followed by several weeks of near-zero feedback. I was not prepared for how demoralizing that stretch is, which is exactly why I'm writing the numbers down instead of only publishing the eventual graph.


Raw data: Search Console, property created 2026-10-08. The site is toolpantry.app. Happy to share the specific queries or the PR list if anyone's planning a similar play and wants to skip a mistake.

Top comments (1)

Collapse
 
onlymoein profile image
Moein •

Thanks for sharing real numbers. With 302 new pages, the first split worth doing is probably which sitemap URLs Google has actually indexed. The open-source Search Console MCP I built rebuilds that indexing list from your sitemap, in case it helps: github.com/onlymoein/google-search...