Monitoring backlinks with n8n and the DataForSEO API (new links, lost links, alerts)

For most SEO practitioners, checking a backlink profile by hand means opening a dashboard once a month and eyeballing two exports side by side. The problem isn't the frequency — it's the total absence of any alert between two checks: a strategic link earned after weeks of outreach can disappear (source site redesign, CMS migration, editorial cleanup) without anyone noticing until the following month. This guide builds an n8n workflow that queries DataForSEO's backlinks API on a regular cron, compares the result against a history stored in Supabase, and only alerts on what actually changed.

Why DataForSEO instead of Ahrefs for automation

Ahrefs remains the reference tool for manual backlink analysis, but its v3 API is only open to Enterprise accounts, on request to their sales team — a standard Ahrefs subscription (Lite, Standard, Advanced) doesn't include access to the backlinks API. For a practitioner or small agency who wants to wire up an n8n workflow without renegotiating their contract, DataForSEO offers an equivalent backlinks API on pay-as-you-go billing, with no Enterprise tier or imposed monthly commitment — which is what actually makes it accessible for a first automation project, unlike the Ahrefs API.

Why automate rather than check periodically

A backlink profile isn't a fixed snapshot: links appear and disappear continuously, and rarely for reasons related to your own site. The phenomenon is documented well beyond SEO: a study by Hennessey and Ge, A cross disciplinary study of link decay and the effectiveness of mitigation techniques, published in BMC Bioinformatics (2013), measured the rate at which external links break across several scientific disciplines and shows that a significant share of links pointing to any given resource stop working over time, regardless of the field. Applied to a backlink profile, this implies that periodic manual checks systematically underestimate how many links are actually lost between two spaced-out checks.

The other reason to automate lies in the very structure of how search engines rank pages: the foundational paper by Page, Brin, Motwani and Winograd, The PageRank Citation Ranking: Bringing Order to the Web (Stanford InfoLab, 1998), established the principle that the structure of inbound links acts as a vote of confidence that propagates through the web graph. A lost link is therefore never a neutral event: it withdraws part of that vote, and a link gained from a reference domain adds a new one — which is why every variation deserves to be examined rather than passively archived as a statistic.

Authenticating n8n against the DataForSEO API

DataForSEO has no official dedicated node on n8n Cloud: the API is driven with the HTTP Request node, the same way as the Google Search Console API or any REST service without a native integration. Setup takes two steps:

1. In the DataForSEO dashboard, generate an API identifier (a login and password dedicated to the API, separate from the account login password).
2. In n8n, create an HTTP Basic Auth credential, enter that login and password, and attach it to every HTTP Request node that calls the API.

This same credential is reusable across every DataForSEO endpoint (backlinks, keywords, SERP) if the SEO pipeline later grows beyond link tracking alone.

Building the tracking workflow

The workflow rests on four blocks:

1. Schedule Trigger — a weekly cron (Monday morning, for example) kicks off the run, the same pattern as the weekly Search Console SEO report if you already run that workflow.
2. HTTP Request — a POST call to DataForSEO's backlinks endpoint, with a JSON body specifying the target domain and the filters you want (active links only, dofollow prioritized). The response includes, for each backlink, the source URL, the target URL, the anchor text, the first-seen date, and a rank score for the source domain.
3. Code node — compares the received list against the history stored in Supabase (see below): any link present in the response but missing from the history is a new backlink; any link present in the history but missing from the response is a lost backlink.
4. IF / Switch — routes new links to a digest (less urgent) and lost links to an immediate alert, especially when the source domain exceeds a predefined rank threshold.

This pattern — extract, compare against a known state, only notify on the delta — is the same one used to detect 404 dead links on your own site: here, the object being tracked is no longer an internal page but an external link pointing to you.

Storing the history in Supabase

Without persistent state, the workflow can only compare against its own previous run if that run was archived manually — which is fragile. A dedicated Supabase table solves this, with a minimal schema:

create table backlinks_tracking (
  id uuid primary key default gen_random_uuid(),
  source_url text not null,
  target_url text not null,
  anchor_text text,
  source_domain_rank integer,
  dofollow boolean,
  first_seen date not null,
  last_seen date not null,
  status text default 'active',
  unique (source_url, target_url)
);

On every run, a link that's already known gets its last_seen date updated; a link that's missing from the API response but still marked active in the table flips to status = 'lost' before triggering the alert. This logging mechanism follows the same principle as the GDPR audit trail with Supabase: keeping a dated history rather than a single snapshot, so you can answer exactly "since when has this link been gone?"

Prioritizing alerts instead of reporting everything

A site with several hundred backlinks naturally sees movement every week: low-quality links that appear and disappear, satellite sites that change structure. Notifying on every variation would quickly drown the useful alert in noise. Two simple filters avoid this trap:

• Only trigger an immediate alert for the loss of a link whose source domain rank exceeds a predefined threshold (for example, the top 20% of domains in your profile) — links lost below that threshold simply join the weekly digest.
• Batch new links into a digest rather than one alert per link, the same model as the daily email digest from the Inbox AI Pack: the information stays available without interrupting anyone for a non-urgent event.

Common pitfalls

• Confusing a temporarily invisible link with a truly lost one: backlink indexes aren't updated in real time; a link can be missed on one crawl pass without actually being gone. Only marking a link "lost" after two consecutive checks fail to find it again limits false positives.
• Querying the API too often: calls are billed per use; a daily cron on a profile of several thousand backlinks costs noticeably more than a weekly one for a marginal benefit, except during an active link-building campaign.
• Ignoring the dofollow attribute: a lost nofollow link rarely carries the same impact as a lost dofollow link; filtering at the API call stage avoids treating both categories with the same priority.
• Forgetting to handle pagination: a sizeable backlink profile often exceeds a single API response's row limit; a Loop Over Items node combined with HTTP Request pagination is needed to pull the full profile rather than a truncated subset.

Going further

This pipeline — API extraction, comparison against persistent state, threshold-filtered alerting — is the same one described for the weekly Search Console SEO report or for content decay tracking: all three workflows can share the same Supabase history table and feed a single consolidated SEO report instead of three separate digests. If you manage this tracking for several client sites, our guide on hosting n8n for a multi-client agency covers how to isolate API credentials and Supabase tables per client without duplicating the workflow for every new contract.