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 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.
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: Tools map cleanly onto search intent (compress image to 200kb, pdf to jpg, heic to webp) Long-tail tool queries are fragmented enough that a new site can slip into the gaps 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.
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.
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.
| 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.
I had a comfortable theory: my tool pages were thin (~300 words), Google declines thin pages, so I should make them longer.
| 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