Recettes
Vérifier les backlinks d'un site web : cinq recettes curl
Courtes, copiables et datées. Chaque recette indique ce qu'elle coûte, ce qu'elle prouve et ce qu'elle ne prouve pas. Remplacez la clé par la vôtre et les domaines par ceux de votre étude de cas.
Une vérification ponctuelle dans le navigateur ne peut pas être présentée à un collègue le mois prochain, alors qu'un appel curl enregistré le peut. C'est cette différence qui justifie l'existence de ces cinq recettes.
Chacune est une requête simple que vous pouvez coller dans un terminal pour vérifier les backlinks site par site, avec le coût indiqué à côté. Commencez par la recette gratuite et arrêtez-vous dès que la question est résolue.
Recette 1 : premier regard, gratuit
Pas de clé, aucun coût. Exécutez ceci avant toute opération payante.
curl "https://theanchornet.com/api.php?action=overview&q=example.com" | jq .Recette 2 : évaluer une liste en un seul appel
Jusqu'à 2 000 domaines pour 1 crédit. Placez les candidats dans le paramètre domains, séparés par des virgules, ou envoyez un corps POST pour une liste plus longue.
curl "https://theanchornet.com/api.php?action=bulk_dr&domains=a.com,b.com,c.com&key=sk_live_..." \
| jq . > rated_$(date +%F).jsonRecette 3 : référents communs
Deux à dix domaines, 2 crédits. C'est l'appel derrière la méthode des empreintes.
curl "https://theanchornet.com/api.php?action=intersect&domains=rival-a.com,rival-b.com,rival-c.com&per=1000&key=sk_live_..." \
-o overlap_$(date +%F).jsonRecette 4 : ancres, mois par mois
Archivez avec la date dans le nom du fichier, puis comparez avec diff après avoir normalisé les clés. Deux crédits par exécution.
curl -s "https://theanchornet.com/api.php?action=anchors&q=yoursite.com&per=1000&key=sk_live_..." \
| jq -S . > anchors_$(date +%Y-%m).json
diff anchors_2026-09.json anchors_2026-10.json | head -80
Recette 5 : arrêter si l'appel a échoué
Une protection pour les scripts. Chaque réponse contient ok, et celles avec clé incluent _credits avec le coût et le solde restant.
R=$(curl -s "https://theanchornet.com/api.php?action=refdomains&q=yoursite.com&key=sk_live_...")
echo "$R" | jq -e '.ok' >/dev/null || { echo "call failed"; exit 1; }
echo "$R" | jq '._credits'Exécutez les recettes dans l'ordre
Commencez par le regard gratuit
Exécutez la recette 1 en premier chaque fois que vous vérifiez les données de backlinks d'un site web pour une nouvelle cible. Pas de clé et aucun coût. Si le chiffre des domaines référents répond à la question, arrêtez-vous là et enregistrez la sortie.
Évaluez la liste courte une fois
Exécutez la recette 2 sur la liste complète des candidats plutôt qu'un domaine à la fois. Un seul appel couvre jusqu'à 2 000 domaines pour 1 crédit, donc la liste reste peu coûteuse quelle que soit sa longueur.
Croisez uniquement les survivants
La recette 3 coûte 2 crédits par appel, alors ne l'appliquez qu'aux concurrents qui ont passé les deux premières étapes. Deux à dix domaines tiennent dans une seule requête, et tout ce qui dépasse nécessite un deuxième appel.
Archivez, puis comparez
Enregistrez chaque fichier avec sa date. Exécutez le diff de la recette 4 sur la même action deux mois plus tard. Un diff vous indique ce qui a changé, pas pourquoi, donc la raison nécessite toujours une intervention humaine.
Ce que chaque recette peut et ne peut pas montrer
| Recette | Prouve | Ne prouve pas |
|---|---|---|
| 1 : aperçu | Position approximative d'un domaine | Tout ce qui concerne la qualité de ses liens |
| 2 : bulk_dr | Qu'un domaine a peu ou beaucoup de référents | Que ses liens sont bons ou payés |
| 3 : intersect | Des référents communs existent | Une propriété commune |
| 4 : diff ancres | Que la formulation a changé | Qui l'a changé, ou pourquoi |
| 5 : garde | Votre script a géré une erreur | Que les données sont fraîches |
Avant d'acheter un domaine expiré
L'ancienneté est une histoire séduisante. Un domaine enregistré il y a longtemps, puis mis en attente pendant des années, peut sembler un raccourci. Avant de vous fier à cette histoire, lisez les données telles qu'elles se présentent aujourd'hui.
La question est de savoir ce qui pointe vers le domaine maintenant. Son âge ne peut pas y répondre. Les liens existent ou ils n'existent pas.
Lisez l'historique dans une archive
Une archive web montre ce que le domaine servait dans les années précédentes. Cherchez les pages d'attente, les redirections vers des sites non liés et les changements soudains de sujet. Chacun peut laisser des liens qui ne mènent plus nulle part utile. Lisez les dates de l'archive à côté de vos propres notes et marquez les lacunes. Une lacune n'est pas une preuve en soi, mais c'est une raison de lire les redirections plus lentement.
Comptez ce qui survit aujourd'hui
Exécutez overview sur le domaine, puis refdomains si le chiffre gratuit mérite un examen plus approfondi. Deux crédits achètent la liste. Enregistrez-la avec la date avant de prendre une décision. Les noms de fichiers portent la date, donc les fichiers enregistrés se trient automatiquement.
Comparez avec ses concurrents les plus proches
Exécutez bulk_dr sur le domaine et ses concurrents les plus proches en un seul appel. La comparaison montre si le domaine se distingue ou s'il semble simplement ancien. Imaginez un domaine avec trois référents à côté de concurrents avec trois cents. Son âge n'a pas acheté ces liens.
Vérifiez la redirection le jour où elle devient active
Si vous redirigez le domaine vers un nouvel endroit, vérifiez que la redirection fonctionne et aboutit sur une page qui correspond à son sujet. Une redirection vers une page non liée gaspille les liens que le domaine possède encore.
Habitudes à copier
Nommer les fichiers par date ne coûte rien et vous épargne un débat avec votre propre mémoire. Le mois prochain, vous voudrez l'ancien fichier.
Gardez les clés hors de la commande elle-même. C'est la première règle. Stockez-les dans une variable d'environnement et faites-en tourner une si elle fuit dans un copier-coller. La référence de champ liste les erreurs que vous verrez, et le glossaire couvre le vocabulaire. Rappelez-vous que l'index se rafraîchit environ une fois par mois, donc exécutez ces scripts selon un calendrier qui le respecte.
Budget pour une petite enquête
| Étape | Appels | Crédits | Dollars |
|---|---|---|---|
| Aperçu gratuit sur 4 concurrents | 4 | 0 | $0.00 |
| refdomains sur chaque concurrent | 4 | 8 | $0.0008 |
| intersect sur les quatre | 1 | 2 | $0.0002 |
| ancres sur chaque concurrent | 4 | 8 | $0.0008 |
| Évaluation de 1 500 domaines de queue avec bulk_dr | 1 | 1 | $0.0001 |
| Total | 14 | 19 | $0.0019 |
Vérification d'un lien que vous avez payé
Les placements payants peuvent disparaître sans préavis. Notre index se rafraîchit environ une fois par mois, donc il ne peut pas vous dire qu'un lien a disparu cette semaine. Pour cela, vous devez consulter la page qui fait le lien vous-même, selon un calendrier que vous définissez. Prévoyez-le.
Récupérez la page qui vous a été promise
Gardez une liste des pages qui contiennent votre lien, avec l'ancre et la cible pour chacune. Récupérez chaque page selon un calendrier fixe et cherchez les deux chaînes. Une ancre manquante est une découverte même si la page se charge toujours. Stockez l'adresse de la page et la date à laquelle le lien est apparu pour la première fois à côté de la liste, afin que le registre montre quand un lien a disparu ainsi que s'il l'a fait.
Gardez l'ancre et la cible ensemble
Un lien peut rester tandis que son ancre change, ou pointer ailleurs après une modification. Vérifiez les deux, car le propriétaire peut avoir réécrit le texte sans supprimer le lien.
Alertez, puis attendez une personne
Un script peut signaler un lien manquant. Il ne devrait pas envoyer d'e-mails ni désavouer quoi que ce soit de lui-même. Lisez la page, datez la découverte, puis seulement décidez quoi faire. Gardez la liste d'alerte assez courte pour la lire à chaque fois.
Cherchez votre lien sur la page
Une vérification en une ligne. Elle récupère la page et compte les correspondances pour votre adresse cible. Exécutez-la selon un calendrier et conservez la sortie avec la date.
curl -s "https://example.org/partner-article" | grep -c "yoursite.com/landing-page"Garder un script shell honnête
Une recette devient un script une fois qu'elle est exécutée deux fois. Les scripts échouent silencieusement. Ajoutez les protections avant la boucle, pas après la facture. Donnez à chaque protection un commentaire qui explique pourquoi elle existe.
Limitez le nombre d'appels
Définissez un compteur et un plafond en haut du script. Une boucle avec une faute de frappe peut répéter un appel payé des milliers de fois, et un plafond transforme cela en une exécution arrêtée plutôt qu'en une grande facture. Imprimez le compteur au fur et à mesure.
Imprimez les crédits au fur et à mesure
Journalisez _credits de chaque réponse avec clé dans le même fichier que les données. Le total en cours est le seul registre honnête de ce que la tâche a coûté, et il suffit d'une ligne pour le lire.
Réessayez uniquement ce qui a échoué
Réessayez un appel qui a retourné une erreur autre que 401 ou 402, et seulement un nombre limité de fois avec une pause entre les tentatives. Un 401 nécessite une clé corrigée et un 402 nécessite un rechargement, donc aucun ne s'améliore avec les réessais. Une boucle de réessai est un bug jusqu'à preuve du contraire.
Une structure de dossiers qui survive une année
Une structure de dossiers est la forme la moins coûteuse de chaîne de traçabilité. Choisissez-en une et utilisez-la pour chaque cas dès le premier appel.
Écrivez également le contenu dans un fichier index court. Une ligne par fichier donne l'action, la date et le coût en crédits. Cela prend quelques minutes à écrire. Ça vaut le coup.
Un dossier par cas, un fichier par appel
Nommez chaque dossier après le cas et chaque fichier après l'action, le domaine et la date. Un lecteur qui ouvre le dossier dans un an devrait voir la séquence des appels sans ouvrir un seul fichier.
Gardez le script à côté de la sortie
Stockez le script qui a produit un fichier à côté de celui-ci, inchangé. Quelqu'un qui veut répéter le pull peut alors exécuter les mêmes commandes plutôt que de deviner les paramètres à partir de la sortie seule.
Erreurs courantes
Mettre une clé dans un script partagé est la première erreur. Coûteuse. Quiconque peut lire le fichier peut dépenser vos crédits. Utilisez une variable d'environnement et un dépôt privé.
La seconde est de faire confiance à un nombre sans date. Un DR de 41 signifie très peu sans le jour où il a été récupéré, et l'index change environ tous les mois, donc un fichier enregistré avec sa date dans le nom vaut dix chiffres mémorisés.
La troisième est demander trop. Un seul appel retourne jusqu'à 1 000 lignes, et la pagination profonde s'arrête à 50 000. Si vous atteignez ce mur, affinez la question avec sort et order plutôt que de paginer indéfiniment, ou divisez le cas par ancre ou par page cible. Affinez d'abord.
Un quatrième mérite une mention : exécuter le même pull deux fois par accident. C'est bon marché à 2 crédits, mais une boucle avec une faute de frappe peut le répéter dix mille fois, alors ajoutez un compteur et imprimez _credits au fur et à mesure.
