Backlink tracking in Make that only speaks up on change
Pull referring domains for each site, compare against last week's stored list and send an alert for the difference. The Data Store module does the remembering.
Deeplinkify research team ·
A tracker is a diff, not a dashboard
Most people building this want to know one thing. Did anyone new link to us?
That question has a cheap answer: store the set of referring domains you saw last time, fetch the set you see now, and alert on anything in the second that is missing from the first. Make has a Data Store for exactly this kind of memory, and the API call is the same two-credit refdomains request used elsewhere.
One caveat shapes the schedule. Our index refreshes about once a month, so a run in the middle of the month will usually find no change. Weekly is fine for your own sanity; monthly is when the diff is most likely to show something. The pacing table has the interval advice for Make.
The scenario, module by module
1
Scheduler
Every Monday at 08:00 is a sensible default. Set it to run once, not per item.
2
Google Sheets: Search Rows
Read your list of sites, one per row. Output is a bundle per row.
3
HTTP: Make a request
GET https://deeplinkify.com/api.php with action=refdomains, q from the row, per=1000, and header Authorization: Bearer sk_live_.... Turn on Parse response so you get fields, not a string.
4
Iterator
Point it at the array of rows inside the response. Use the response structure from a first run to pick the exact path.
5
Data Store: Search records
Look up each referring domain under the key site|domain. If nothing is found, the domain is new.
6
Router
Route one: not found, so add a record and collect the domain for the alert. Route two: found, do nothing.
7
Slack or Email, after an Array aggregator
Aggregate the new domains per site into a single message. One alert with twelve names beats twelve alerts.
The request body for the HTTP module
Values to type into the HTTP module. The per parameter allows 10 to 5000, and one call returns up to 1,000 rows at a flat price.
text
URL: https://deeplinkify.com/api.php
Method: GET
Headers: Authorization: Bearer sk_live_...
Query string: action = refdomains
q = {{2.domain}}
per = 1000
page = 1
Parse response: Yes
Evaluate all states as errors (except 2xx): Yes
Wiring the alert so it is read
Short alerts get read. Long ones get muted.
Group by site, show the count of new referring domains, then list at most ten names and a link to the sheet that holds the rest. If a site gains hundreds of domains in one refresh, say so in one line instead of pasting them; that usually means a sitewide or syndicated link, which deserves a human look, not a Slack scroll.
Also keep the first run silent. On day one the Data Store is empty, so every domain looks new, and you would otherwise get an alert listing the entire link profile. Seed the store with a run that skips the Router, then switch the alert on. The error runbook covers the failures to expect after that.
Operations per run
Make counts one operation per module execution per bundle. Numbers below are a hypothetical 10-site list; the response is assumed to hold 800 rows per site.
Module
Runs
Operations
Scheduler
1
1
Search Rows
1
1
HTTP request
10
10
Iterator
10
10 plus the bundles it emits
Data Store search (per domain)
8,000
8,000
Total for the first run
About 8,000 plus the router and alerts
Cost warning
The diff is cheap in credits and expensive in operations
The API side is 20 credits for the run, $0.002. The Make side is thousands of operations, because the Data Store is searched row by row. If that hurts, push the comparison into a Google Sheets formula or an n8n Code node and let the scenario only fetch and store.
Store one record per site holding the whole domain list as text, and compare in one step.
Or keep the previous week in a Sheets tab and use a formula to flag new ones.
Either way, keep the call itself at refdomains, 2 credits.