Surveiller ses backlinks avec n8n et l'API DataForSEO (nouveaux liens, liens perdus, alertes)

Vérifier son profil de backlinks à la main consiste, pour la plupart des praticiens SEO, à ouvrir un tableau de bord une fois par mois et à comparer deux exports à l'œil. Le problème n'est pas la fréquence — c'est l'absence totale d'alerte entre deux vérifications : un lien stratégique obtenu après des semaines de prospection peut disparaître (refonte du site source, changement de CMS, nettoyage éditorial) sans que personne ne s'en aperçoive avant le mois suivant. Ce guide construit dans n8n un workflow qui interroge l'API de backlinks de DataForSEO sur un cron régulier, compare le résultat à un historique stocké dans Supabase, et n'alerte que sur ce qui a réellement changé.

Pourquoi DataForSEO plutôt qu'Ahrefs pour une automatisation

Ahrefs reste l'outil de référence pour l'analyse manuelle de backlinks, mais son API v3 n'est ouverte qu'aux comptes Enterprise, sur demande auprès de leur équipe commerciale — un abonnement Ahrefs classique (Lite, Standard, Advanced) ne donne pas accès à l'API de backlinks. Pour un praticien ou une petite agence qui veut brancher un workflow n8n sans renégocier son contrat, DataForSEO propose une API de backlinks équivalente en facturation à l'usage, sans palier Enterprise ni engagement mensuel imposé : c'est ce qui la rend réellement accessible à un premier projet d'automatisation, contrairement à l'API Ahrefs.

Pourquoi automatiser plutôt que vérifier ponctuellement

Un profil de backlinks n'est pas une photo figée : des liens apparaissent, d'autres disparaissent, en continu et pour des raisons rarement liées à votre propre site. Le phénomène est documenté au-delà du seul SEO : une étude de Hennessey et Ge, A cross disciplinary study of link decay and the effectiveness of mitigation techniques, publiée dans BMC Bioinformatics (2013), a mesuré le taux de disparition des liens externes dans plusieurs disciplines scientifiques et montre qu'une part significative des liens pointant vers une ressource donnée cesse de fonctionner au fil du temps, quel que soit le domaine. Appliqué à un profil de backlinks, ce constat implique qu'un suivi ponctuel sous-estime systématiquement le nombre de liens réellement perdus entre deux vérifications espacées.

L'autre raison d'automatiser tient à la structure même du classement des moteurs de recherche : l'article fondateur de Page, Brin, Motwani et Winograd, The PageRank Citation Ranking: Bringing Order to the Web (Stanford InfoLab, 1998), a posé le principe selon lequel la structure des liens entrants agit comme un vote de confiance qui se propage à travers le graphe du web. Un lien perdu n'est donc jamais un événement neutre : il retire une part de ce vote, et un lien gagné depuis un domaine de référence en apporte un nouveau — ce qui justifie de traiter chaque variation comme un signal à examiner plutôt qu'une statistique à archiver passivement.

Authentifier n8n auprès de l'API DataForSEO

DataForSEO n'a pas de node dédié officiel côté n8n Cloud : l'API se pilote avec le node HTTP Request, comme pour l'API Google Search Console ou n'importe quel service REST sans intégration native. La configuration se fait en deux étapes :

1. Dans le tableau de bord DataForSEO, générer un identifiant API (login + mot de passe dédiés à l'API, distincts du mot de passe de connexion au compte).
2. Dans n8n, créer un credential HTTP Basic Auth, y renseigner ce login et ce mot de passe, puis l'associer à chaque node HTTP Request qui appelle l'API.

Ce même credential est réutilisable pour tous les endpoints DataForSEO (backlinks, mots-clés, SERP) si le pipeline SEO s'étend au-delà du seul suivi de liens.

Construire le workflow de suivi

Le workflow repose sur quatre blocs :

1. Schedule Trigger — un cron hebdomadaire (par exemple chaque lundi matin) déclenche l'exécution, sur le même principe que le rapport SEO hebdomadaire Search Console déjà en place si vous suivez ce guide.
2. HTTP Request — un appel POST vers l'endpoint de backlinks de DataForSEO, avec en corps JSON le domaine cible et les filtres voulus (liens actifs uniquement, dofollow en priorité). La réponse contient, pour chaque backlink, l'URL source, l'URL cible, l'ancre, la date de première détection et un score de rang du domaine source.
3. Node Code — compare la liste reçue à l'historique stocké dans Supabase (voir plus bas) : tout lien présent dans la réponse mais absent de l'historique est un nouveau backlink ; tout lien présent dans l'historique mais absent de la réponse est un backlink perdu.
4. IF / Switch — route les nouveaux liens vers un digest (moins urgent) et les liens perdus vers une alerte immédiate, surtout quand le domaine source dépasse un seuil de rang défini à l'avance.

Ce pattern — extraire, comparer à un état connu, ne notifier que le delta — est le même que celui utilisé pour détecter les liens morts en 404 sur votre propre site : ici, l'objet suivi n'est plus une page interne mais un lien externe qui pointe vers vous.

Stocker l'historique dans Supabase

Sans état persistant, le workflow ne peut comparer qu'à sa propre exécution précédente si elle a été archivée manuellement — ce qui est fragile. Une table Supabase dédiée règle le problème, avec un schéma minimal :

create table backlinks_suivi (
  id uuid primary key default gen_random_uuid(),
  url_source text not null,
  url_cible text not null,
  ancre text,
  rang_domaine_source integer,
  dofollow boolean,
  premiere_detection date not null,
  derniere_detection date not null,
  statut text default 'actif',
  unique (url_source, url_cible)
);

À chaque exécution, un lien déjà connu voit sa derniere_detection mise à jour ; un lien absent de la réponse API mais toujours marqué actif en base passe à statut = 'perdu' avant de déclencher l'alerte. Ce mécanisme de journalisation reprend le même principe que la piste d'audit RGPD avec Supabase : conserver un historique daté plutôt qu'un simple instantané, pour pouvoir répondre à la question « depuis quand exactement ce lien a-t-il disparu ? ».

Prioriser les alertes plutôt que tout signaler

Un site avec plusieurs centaines de backlinks génère naturellement du mouvement chaque semaine : liens de faible qualité qui apparaissent et disparaissent, sites satellites qui changent de structure. Notifier chaque variation sur Slack noierait rapidement l'alerte utile dans le bruit. Deux filtres simples évitent ce piège :

• Ne déclencher une alerte immédiate que pour la perte d'un lien dont le rang de domaine source dépasse un seuil défini (par exemple, les 20 % de domaines les mieux classés de votre profil) — les liens perdus en dessous de ce seuil rejoignent simplement le digest hebdomadaire.
• Regrouper les nouveaux liens dans un digest plutôt qu'une alerte par lien, sur le même modèle que le digest quotidien d'emails du Pack Inbox IA : l'information reste disponible sans interrompre qui que ce soit pour un événement non urgent.

Pièges fréquents

• Confondre un lien temporairement invisible et un lien réellement perdu : les index de backlinks ne sont pas mis à jour en temps réel ; un lien peut manquer une passe de crawl sans avoir disparu. Ne marquer un lien « perdu » qu'après deux vérifications consécutives sans le retrouver limite les faux positifs.
• Interroger l'API trop souvent : les appels sont facturés à l'usage ; un cron quotidien sur un profil de plusieurs milliers de backlinks coûte nettement plus qu'un cron hebdomadaire pour un bénéfice marginal, sauf en pleine campagne de netlinking active.
• Ignorer l'attribut dofollow : un lien nofollow perdu a rarement le même impact qu'un lien dofollow perdu ; filtrer dès l'appel API évite de traiter les deux catégories avec la même priorité.
• Oublier de gérer la pagination : un profil de backlinks conséquent dépasse souvent la limite de lignes d'une seule réponse API ; un node Loop Over Items combiné à la pagination du HTTP Request est nécessaire pour récupérer l'ensemble du profil plutôt qu'un sous-ensemble tronqué.

Pour aller plus loin

Ce pipeline — extraction API, comparaison à un état persistant, alerte filtrée par seuil — est le même que celui décrit pour le rapport SEO hebdomadaire Search Console ou pour le suivi du content decay : les trois workflows partagent la même table Supabase d'historique et peuvent alimenter un unique rapport SEO consolidé plutôt que trois digests séparés. Si vous gérez ce suivi pour plusieurs sites clients, notre guide sur l'hébergement n8n en agence multi-clients détaille comment isoler les identifiants API et les tables Supabase par client sans dupliquer le workflow à chaque nouveau contrat.