Automated abuse pipeline for SEO operations
The client ran an SEO operation with a team of five specialists focused on competitive domain takedowns. Every day, someone on the team would spend three to four hours filling out abuse forms across six different domain registries — each with its own layout, its own required fields, and half of them protected by CAPTCHA. On a good day, they'd cover maybe 10-15 domains. The rest piled up.
how we built it
We built a pipeline that does this without anyone touching a browser. At its core are Playwright-based workers, each with an adapter tailored to a specific registry. The adapter pattern keeps things clean — one interface, registry-specific logic inside. Adding a new registry means writing one file, not reworking the pipeline. When a form has CAPTCHA, the system sends it to the primary solver; if that times out or fails, it falls back to a second provider. Success rate sits around 85-90%, with the rest going into a retry queue.
what made it hard
What made this tricky was the fragility. Registries change their forms without warning — a renamed field or a shifted selector breaks the adapter silently. Without monitoring, the only signal is a drop in success rate the next day. We added daily cron-driven statistics: submitted, accepted, rejected, broken down by registry. That turned out to be more valuable than the automation itself — the team started making strategic decisions based on actual rejection rates instead of gut feel.
email and evidence
For registries that only accept complaints via email, we split out a dedicated SMTP microservice. Keeping it isolated lets us monitor deliverability independently and scale it without touching the main application. Each complaint includes auto-generated screenshots of violations as evidence — Playwright captures them during the same session that fills the form.
results
The result: 50+ complaints per day with zero manual effort. The specialists shifted from filling forms to analyzing which registries respond fastest and which complaint strategies actually work. One architectural debt we're aware of — the workers still run in the same process as the main app. At current scale it holds, but the next iteration should move them behind a proper task queue with real-time alerting when an adapter breaks.
The bigger takeaway: automation without observability is blind. The daily stats dashboard became the team's main decision-making tool — not the bot itself. If we were starting this today, monitoring would be day-one, not an afterthought.
Stack
Backend: Next.js 14 (Route Handlers), Prisma, PostgreSQL
Automation: Playwright, CAPTCHA solvers (2 providers)
Email: Node.js + nodemailer (standalone service)
Infra: Vercel Cron, Docker