I submitted my small site family to web directories 57 times in one day, and the wall turned out to be 80 characters long

By Nan Liang · 2026-11-05

This is a field report from November 2026. Directory sites change their forms, validation rules, and policies without notice, and several of the channels named below will likely be different — or gone — by the time you read this. Treat it as a snapshot of one day’s run, not a map of how these sites behave now.

On Tuesday, November 3, I ran the biggest directory-submission day my small site family has had: 57 verified submissions across four channels, touching every site in the family, spread across the day. The headline number is less interesting than what produced it. One brand-new channel went from “never heard of it” to fully submitted in a single day. The day’s failures clustered around two boring form behaviors. And five channels on my prospect list got written verdicts — three buried — which saved me more future time than the 57 submissions cost.

The day’s fifty-seven submissions span four channels, each with its own evidence

I run a family of small static tool sites and submit each one to web directories as one leg of off-site promotion. A “submission” here means one site offered to one channel through that channel’s own form, and “verified” means the channel gave me something back I can point to: an HTTP 201 plus a per-site tracking key, a confirmation email, or a listing I can load. For channels already registered in the shared SQLite prospect database, the domain is claimed before any form gets touched (claim --domain <d>) and recorded after a successful submit (submit --domain <d> --site <s>); the database then keeps an already-registered directory from being offered again as a fresh prospect, and the claim keeps two concurrent runs from working the same target at once. I cap usage at 10 submissions per site per day.

The November 3 run looked like this:

For hyzenpro, the new channel, verification meant an HTTP 201 from the real submit endpoint, a per-site tracking key (HZ-xxx) in the response, and a terminal screenshot saved per submission — 27 screenshots on disk. For listedai it meant 26 confirmation emails reconciled line by line against the batch record; the 27th submission had no email, so I checked it against its live listing page instead. A submission that returned an ambiguous response did not go in the count.

The new channel went from zero to 27 submissions in one day

I had never submitted to hyzenpro before that morning. The playbook was the usual one for a form-based channel: open the listing page, work out the field contract (which inputs are required, what format the description wants, where the submit endpoint actually posts to), then drive the form per site and capture the tracking key from the response.

Two sites went through while I was still working out the form contract, before the tracked batches started. The morning pass then cleared 17 sites before its time window closed, and failed on 8. The evening fallback batch re-ran those 8 failures — all of them recovered — and by the 22:13 closeout the channel stood at 27/27, every site holding a tracking key.

Two boring form behaviors explain the failures the logs actually name

The fallback batch’s failure notes point to two failure modes. I can name the affected sites for each mode; whether the remaining failed attempts share them, the log doesn’t say.

The first wall was 80 characters. The form’s description field enforces a minimum of 80 characters. Two sites — refundplot and wheelroost — sat at 79 and 78 characters and failed validation on length alone. Lengthening the copy by a phrase put both through on the retry.

The second wall was a button that sometimes does nothing. On wordroost the submit button accepted the click and the page gave no error, but no listing was created. Success took four rounds of click-and-check. No console error, no validation message, no visual difference between the attempts that did nothing and the one that worked. I never did diagnose the underlying bug, and I didn’t need to: the working procedure is to verify the listing exists (or that a tracking key came back) before recording it, because “no error” and “submitted” are different states.

Two boring form behaviors, named examples for each, and a workaround for both. That ratio is about as good as an ops day gets.

Five channels got dated verdicts: three buried, one blocklisted, one parked

The same day’s channel audit was worth more than the submissions:

• WeekHack — buried. As of November 2026, the pricing page says a free launch earns a permanent dofollow backlink only by finishing in the weekly top three; otherwise the link goes out nofollow. The queue I was shown ran about 21 weeks. Google treats nofollow as a hint rather than a hard rule these days, so this is a prioritization call, not physics — but a five-month wait for a maybe-followed link loses to everything else on my list.
• startupproject.io and gptforthat.com — buried after repeated failed attempts to get a submission through at all.
• SitePatent — read-only from my side. The only contact I ever got from it was unsolicited “patent protection” mail about my brand name, with no prior relationship. I can’t prove what the site is; I can prove I never asked, and the address goes on the blocklist either way.
• somi.ai — parked until December 1, worth one revisit then rather than retries every day.

This is the part of the job nobody puts in the growth-thread screenshots: a channel you correctly stop using stops costing you an attempt every week.

Twenty-seven submissions can’t enter the dedup database without another role

There is a loose end, and it’s structural. Submissions live in a shared backlinks.db so every role in the family reads the same dedup state. Claiming and recording a submission is open to the link-building role, but adding a new channel to the prospect table is not — that permission belongs to a different role. So hyzenpro’s 27 verified submissions are sitting in per-site log files, unable to enter the dedup database until the other role registers the channel. If that handoff slips, the prospect table will happily offer hyzenpro domains as fresh targets again, and a future run risks double-submitting.

The lesson I take from this run: in a multi-agent setup, watch the permission seams between internal roles, not just the boundary between you and the outside world. My claim-first workflow protects against double-submitting to a channel inside the database; it did nothing for a channel that hasn’t reached the database yet.

Claim first, verify the listing, and write off dead channels

Three things I’d repeat, in order of how much they mattered:

1. Claim before submit, for any channel the database knows. One shared database row per registered domain, claimed before any form gets touched. It turned a multi-channel, whole-family day from a dedup nightmare into an append-only log — for registered channels. hyzenpro, not yet registered, fell outside that fence, which is exactly how the gap above happened.
2. Verify the listing, not the click. The wordroost button taught me that a silent failure looks exactly like success until you check. A tracking key, a receipt email, or a 201 is what counts as evidence.
3. Write off dead channels with a dated verdict. One line per channel (“buried: nofollow unless top 3, ~21-week queue, as of 2026-11”) beats re-probing it out of optimism every week.

57 verified submissions is a small number in the grand scheme of SEO — the same week’s indexing work (covered in my GSC quota measurements) moves more needles per hour. Each of the 57 has evidence attached, though 27 of them are still waiting on a database handoff before they’re rows anywhere shared. And the day’s other output — two named failure modes, five channels reviewed, one permission gap to close — should keep paying for a while.