DEV Community: shenghua wu

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

shenghua wu — Thu, 15 Oct 2026 07:40:51 +0000

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:

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.

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)

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

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

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.

208 file tools that never upload your files — and the 7 bugs that taught us how

shenghua wu — Wed, 14 Oct 2026 13:21:37 +0000

Disclosure: I build Tool Pantry with AI coding agents, and this article was drafted with AI assistance from my own engineering notes and test logs. Every technical claim below — file sizes, byte counts, pixel diffs, MD5s — was verified against the source code or real test output, and I've marked the two places where I had to correct an earlier conclusion.

Every "free online PDF tool" works the same way: you pick a file, it uploads to their server, they process it, you download the result. That's fine until you're handling a passport scan, a signed contract, or a medical record.

We built Tool Pantry on the opposite premise: 208 tools, zero uploads. PDF, images, video, audio, text. Nothing ever leaves the device — not by policy, by architecture.

That constraint turned out to be a much better engineering problem than we expected. Here are the seven things that actually bit us.

1. The 25 MiB wall — why we abandoned ffmpeg.wasm

Video compression was the first "obviously we'll use the obvious library" decision. ffmpeg.wasm is the standard answer for browser video.

It died at deploy time.

ffmpeg-core.wasm is 30.7 MiB. Cloudflare Workers caps a single asset at 25 MiB. Not a soft limit — the deploy just fails. We could have moved off Workers to keep the library, but shipping a 30 MB download to every visitor is its own problem.

So we rebuilt the pipeline on native browser primitives:

Stage	Library	Size
Demux	MP4Box.js	~200 KB
Decode / scale / encode	WebCodecs (`VideoDecoder`, `VideoEncoder`)	built in
Mux	mp4-muxer	~50 KB

Total: ~390 KB instead of ~30 MB — a 77× reduction. And it's not just smaller, it's faster, because WebCodecs hits hardware encoders instead of compiling x264 to WASM.

Verified output: 1280×720 6s source → 854×480 H.264 Baseline + AAC, 1.81 MB, confirmed with ffprobe picking apart the actual container.

Lesson: the ecosystem's obvious library was written when the platform couldn't do the job. Check whether the platform caught up before you ship the workaround.

2. `pdf-lib`'s `removePage` doesn't delete anything

Deleting a page from a PDF should make the file smaller. Ours got bigger:

793 KB  →  remove one page  →  812 KB

removePage() unlinks the page from the page tree, but the page's content stream, images, and fonts stay in the file — reachable through the incremental-update structure. The bytes are still there. Forensically, the "deleted" page is still in your document.

The fix is a rebuild: create a fresh PDFDocument, copyPages() only the pages you're keeping, and save that.

812 KB  →  copyPages rebuild  →  510 KB

A 37% reduction — the data genuinely gone.

The side effect is worth disclosing to users: rebuilding a PDF drops its metadata (author, producer, creation dates). We say so on the page rather than letting people discover it.

Lesson: in PDF, "delete" almost always means "unlink." If a user's threat model includes recovering deleted content, unlinking is not enough.

3. `constructor.name` is a lie in minified builds

We shipped a PDF form-filler that detects AcroForm fields — text, checkbox, dropdown, radio — and renders the right input for each.

It worked perfectly in development and detected nothing in production.

Root cause: pdf-lib ships minified. In the minified build, every class's constructor.name is "n". Our type dispatch (field.constructor.name === 'PDFTextField') matched nothing.

The fix is instanceof against the exported classes, which survives minification because it compares actual prototype chains:

var isText     = field instanceof PDFLib.PDFTextField;
var isCheck    = field instanceof PDFLib.PDFCheckBox;
var isDropdown = field instanceof PDFLib.PDFDropdown;
var isOptionList = field instanceof PDFLib.PDFOptionList;
var isRadio    = field instanceof PDFLib.PDFRadioGroup;

Lesson: never dispatch on constructor.name for anything that ships minified — including your own code, if a bundler might rename it. instanceof or an explicit discriminant field, always.

4. MP4 rotation lives in the header, not the pixels

A phone video shot in portrait is usually stored landscape, with a rotation matrix in the tkhd box telling the player "turn this 90°." The pixels never change; the metadata does.

MP4Box.js exposes both, and they disagree:

track.track_width / track_height → the display size from tkhd
videoTrack.video.width / height → the encoded size from stsd

We used the first one everywhere. Every operation on a rotated video was wrong — crops landed in the wrong place, blends misaligned, output dimensions swapped.

Once we understood the split, a better option appeared for the operations that don't need pixel access. Rotating a video isn't decoding 30 million pixels and re-encoding them — it's rewriting one 3×3 matrix in a header.

We rewrite the tkhd matrix directly. Verified: byte-identical result to re-encoding with transpose=1, pixel difference 0.0. It finishes in 0.0 seconds on a 6-second clip, because nothing is decoded.

Same trick for muting: stream-copy the video track, drop the audio track. The output video bitstream's MD5 is identical to the source. Lossless, verifiable, instant.

Lesson: before you write the pixel loop, check whether the answer is already a number in a header.

5. The color bug that wasn't — verify your measurement tool first

This one nearly cost us a working pipeline.

We compared input and output video frames pixel by pixel and got a clean, damning result:

output ≈ 0.81 × source + 23

That formula is the signature of a YUV↔RGB range mismatch — the classic full-range (0–255) vs. limited-range (16–235) bug. Textbook. So we started hunting for it: checked the VUI and colr atoms, inspected our VideoFrame color-space options, ran encode round-trips, scanned for time-alignment offsets, generated difference maps.

We found nothing, because there was nothing to find.

ffprobe was reading our untagged source file and guessing the YUV matrix. It guessed wrong. The "0.81× + 23" was an artifact of the measuring tool, not a defect in our code.

The real test: decode source and output in the same decoder (Chrome) and compare flat regions — delta ≤ 3, which is just normal lossy-compression noise.

We were one commit away from "fixing" a correct color pipeline and breaking it.

Lesson: when a measurement gives you a textbook-perfect diagnosis, be suspicious. Confirm the tool before you trust the verdict.

6. `SHA256` is not `SHA-256`

await crypto.subtle.digest('SHA256', data);
// → NotSupportedError

WebCrypto wants the hyphenated form: 'SHA-256'. The un-hyphenated spelling fails with an error that gives you no hint about the format being the problem.

Our hash tool now maps friendly names to the exact WebCrypto identifiers:

const webcryptoNames = {
  sha1: 'SHA-1', sha256: 'SHA-256', sha384: 'SHA-384', sha512: 'SHA-512'
};

We checked the output byte-for-byte against Python's hashlib to be sure. It matches.

7. Transparent canvas pixels have garbage color channels

The signature tool has a mode that turns a photo of a signature on paper into a clean transparent PNG: threshold away the paper, keep the ink, recolor, auto-crop.

Bug: it kept hallucinating ink in empty areas.

Cause: in a canvas, a fully transparent pixel can still have color values — and drawing operations often leave them at 0,0,0 (black). Our threshold ("dark pixels = ink") read the entire transparent region as ink.

Fix: gate on alpha before thresholding.

if (alpha === 0) continue;  // never trust the color of an invisible pixel

Lesson: transparent pixels are not "empty." Their color channels are whatever the last write left behind. Always check alpha first.

What this actually costs you (the honest section)

Client-side isn't free. The real trade-offs:

Download size. Background removal needs a U²-Net model via ONNX Runtime Web — about 15 MB, lazy-loaded. OCR needs Tesseract WASM — about 8 MB. First use of those two tools is a real wait.
Browser floors. The video tools need WebCodecs — Chrome/Edge, and Safari 17+. Older browsers can have the PDF and image tools, not the video ones.
Threading requires headers. ONNX Runtime's multithreaded path needs COOP: same-origin + COEP: require-corp. That's fine for a site with no third-party embeds, and it means those two headers are now load-bearing.
And there's a ceiling. Anything that genuinely needs a large model or a server-side API — LLM summarization, translation, image generation — we don't build. We say so instead of shipping a fake version.

But the floor is much higher than it was two years ago, and WebCodecs is the reason. Video processing in the browser went from "compile ffmpeg to WASM" to "call the platform."

The stack

Everything is permissively licensed and self-hosted — no CDN dependencies, no third-party calls:

Video/audio: WebCodecs · MP4Box.js · mp4-muxer · lamejs
PDF: pdf-lib · pdf.js
Images: native canvas · heic2any
ML: ONNX Runtime Web (U²-Net) · Tesseract.js

The whole thing is 208 tools with no build step, no backend, and no accounts. If you want to poke at the implementation, it's at toolpantry.app — and the raw measurements behind the numbers above are written up with methodology at compression-benchmarks and local-processing-benchmarks.

Which of these have you hit? The constructor.name one feels like it should be common knowledge and somehow isn't. And I'd genuinely like to know if anyone has a case where ffmpeg.wasm was still the right call — I couldn't find one that fit inside a 25 MiB limit, but that's a deployment constraint, not a general truth.