No lawyers on retainer. No manual monitoring. Just a scheduler, two search APIs, and some very strongly worded emails — sent automatically.
The problem
A client runs multiple brands online. One day they noticed a clone of their app on the Play Store — same name, similar icon, fake reviews. They'd had it for weeks without knowing.
That's when I realized: brand abuse is quiet. Clones, impersonator websites, and fake apps don't announce themselves. By the time you find them, the damage is done — lost revenue, confused users, diluted SEO.
The traditional fix? Hire an IP firm to monitor manually, or pay for expensive brand protection SaaS. Neither option made sense for an agency managing multiple mid-size brands.
So I built my own — in n8n, over a few weekends.
What the system does
Three workflows, chained together, running silently on a schedule:
- Workflow A — Scans Google/Bing search results and app stores for unauthorized use of brand names
- Workflow C — Enriches each detection with registrar and hosting data via RDAP
- Workflow B — Generates and sends legally-structured DMCA takedown notices to the right targets, automatically
From detection to takedown notice: zero human intervention.
Why two search APIs instead of one
This is the architectural decision I get asked about most, so let me address it upfront.
I use Monitorank for web search (Google and Bing SERPs) and DataForSEO for app store searches (Google Play and Apple App Store). Not because I couldn't find a single API that does both — but because each one is genuinely better at what it does.
Monitorank is built specifically for SERP monitoring. It handles ranking data cleanly, supports geolocation, and gives reliable results for web search across desktop and mobile. It was the natural fit for catching impersonator websites showing up in organic search.
DataForSEO is where I go for app store data. Its Play Store and App Store search APIs are more mature, return richer metadata (developer name, ratings, install counts), and the async task model (task_post → wait → task_get) handles rate limits gracefully without me having to engineer a retry system from scratch.
Using both means the pipeline covers the full surface area of brand abuse — web and mobile — without compromising on data quality in either channel.
How Workflow A works
Workflow A is the detection engine. It runs on a schedule, reads a list of active brands from a Google Sheet (config_brands), and loops through each one.
For each brand, it runs two parallel tracks:
Web search via Monitorank — brand search terms are batched and sent to the Monitorank API. Results come back as ranked URLs, which get filtered and deduped against previously known detections in the sheet.
App store search via DataForSEO — two parallel requests hit the Google Play and Apple App Store endpoints. DataForSEO's async model means I post the task, wait for it to complete, then fetch the results. This is more reliable than hitting the live endpoint and hoping for a fast response.
After both tracks complete, every surviving URL gets a live 404 check. If the infringing page is already gone, there's nothing to do — it gets dropped before it ever reaches enrichment. Only live detections make it forward.
New findings get appended to the detections sheet, and a Gmail alert fires summarizing what was found.
How Workflow C works (RDAP enrichment)
Before you can send a DMCA notice anywhere useful, you need to know who to send it to. That's Workflow C's job.
For each new detection, it runs three lookups in sequence:
-
RDAP domain lookup (
rdap.org/domain/{domain}) — returns the registrar, registration date, and crucially, the registrar's abuse contact email -
DNS A record lookup (
dns.google/resolve) — resolves the domain to an IP address -
RDAP IP lookup (
rdap.org/ip/{ip}) — identifies who is hosting that IP and their abuse contact
The results get written back to the detections sheet, filling in registrar_abuse_email and hosting_abuse_email.
One gotcha here: RDAP APIs are public infrastructure and rate-limited. I added a wait node between detections to pace the loop — without it, you'll start getting throttled and silently losing data.
How Workflow B works (DMCA sending)
Workflow B is where it gets interesting. It takes the enriched detections and builds the actual takedown notices.
Smart routing by source — the target of a DMCA notice depends on where the abuse was found:
| Source | Emails sent to |
|---|---|
| Google SERP | Google DMCA agent + registrar + hosting |
| Bing SERP | Microsoft DMCA agent + registrar + hosting |
| Google Play | Google DMCA agent + registrar |
| Apple App Store | Apple copyright agent (with CC) + registrar |
Domain grouping — if the same rogue domain has five infringing URLs, they all get bundled into one complaint rather than five separate emails. This is both more professional and less likely to get marked as spam.
Two sending modes — brands can configure whether notices go out directly in their name (direct) or signed by an agency acting on their behalf (on_behalf_of). The email template adjusts accordingly, pulling complainant or agent details from the config sheet.
Auto-send gate — each brand has an auto_send flag. If it's off, the detection gets marked skipped and nothing is sent. This lets cautious clients review detections before any emails go out.
Every sent notice gets logged to a complaints sheet with a follow_up_date set 10 days out.
Lessons learned
Filter aggressively before sending. Early versions of the pipeline sent notices to hosting providers like Google Cloud and Akamai for domains they just happened to host. Those abuse desks ignore automated notices instantly. I added a filter to skip known CDN and hyperscaler abuse emails — they're useless targets.
Dedup at multiple stages. I deduplicate at the detection level (to avoid re-reporting known infringers), at the domain level (to group URLs into one complaint), and again after sending (to update individual detection IDs back to complaint_sent). Skipping any of these layers causes duplicate emails, which undermines your credibility.
RDAP returns inconsistent formats. Some registrars follow the spec cleanly, others return abuse contacts buried in nested entities, and some return nothing at all. The parsing code needs to handle all three gracefully — don't assume the field you want is where the spec says it should be.
Build in the auto_send flag from day one. I almost shipped without it. It seems like overhead until the first false positive, at which point it becomes the most important feature in the system.
The tech stack
- n8n (self-hosted) — orchestration
- Monitorank API — web SERP monitoring
- DataForSEO API — app store search
- rdap.org + dns.google — domain/IP enrichment
- Gmail — outbound DMCA notices
- Google Sheets — config, detections, complaints log
No database, no custom backend. The whole thing runs on n8n and a spreadsheet.
What's next
The system handles detection and first-contact takedown well. What it doesn't do yet:
-
Follow-up tracking — the
follow_up_datecolumn is there, but I haven't built the follow-up workflow yet - Response parsing — when a registrar replies, someone still has to read it
- Counter-notice handling — if a takedown gets disputed, that's currently a manual process
These are Workflow D and beyond. For now, the pipeline catches real abusers, sends legally-sound notices automatically, and has saved my client hundreds of hours of manual monitoring.
If you're managing brand protection for multiple clients and doing this by hand, it's worth automating. The hardest part is the first detection — everything after that is plumbing.
Built with n8n. Questions? Drop them in the comments.
Top comments (2)
Automating the discovery side makes a lot of sense. The part I would keep deliberately human is the final takedown decision, especially when confidence is low. False positives get expensive fast once the system is sending legal notices on its own.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.