Alternative à l'API Ahrefs pour les re-vérifications de liens : coût et limites

Les limites qui façonnent votre script

Chaque appel est facturé une fois. Peu importe le nombre de lignes retournées, le prix est identique. Un seul appel retourne jusqu'à 1 000 lignes, et la pagination profonde est plafonnée à 50 000 lignes au total.

Le paramètre per accepte des valeurs de 10 à 5 000, et page parcourt le reste. Les valeurs de per supérieures à 1 000 ne retournent pas plus de lignes en un seul appel, prévoyez donc la boucle autour de 1 000.

Ce que vous disent un 401 et un 402

Un 401 signifie que la clé est manquante ou incorrecte. Il s'agit d'une erreur de configuration qui devrait arrêter le traitement. Un 402 signifie que le solde est épuisé, ce qui nécessite une recharge. Aucun de ces deux cas ne justifie une nouvelle tentative en boucle.

Lisez le statut avant de lire le corps. Chaque réponse contient un champ ok, vérifiez-le en premier et analysez le reste uniquement si l'appel a réussi.

Plafonds de lignes et pagination dans une boucle

Demandez la plus grande page dont vous avez besoin, jusqu'au plafond de lignes, et ne paginez que lorsque le résultat est tronqué. Parcourir page par page une longue liste coûte un appel à chaque fois, donc des appels moins nombreux mais plus complets sont moins chers et plus faciles à journaliser.

Une fois qu'une liste dépasse 50 000 lignes en profondeur, la pagination n'a plus d'intérêt. Limitez la requête avec les paramètres sort et order, et notez cette limite dans vos observations.

Rythme et temporisation après les erreurs

Aucun chiffre de requêtes par minute n'est publié ici, ne supposez donc pas qu'il en existe un. Temporisez après n'importe quelle erreur et maintenez un rythme modéré dans la tâche cron.

Une vérification nocturne de cent sites est une petite tâche qui ne nécessite pas de rafale d'appels parallèles pour s'achever.

Si une erreur survient sur un hôte, sautez cet hôte, journalisez-le et continuez, plutôt que d'arrêter toutes les lignes qui suivent. Journalisez l'heure de chaque exécution à côté de son statut, afin qu'un motif d'erreurs apparaisse dans le journal et non dans un e-mail client.

Contrairement aux unités API d’Ahrefs

Ahrefs vend des unités API au sein d’abonnements, à partir de 129 $ par mois pour 200 000 unités, avec un minimum de 50 unités par requête. À raison de 50 unités par requête, cette offre permet au maximum 4 000 requêtes par mois. Pour de nombreuses équipes, cela suffit amplement.

La comparaison n’est pas équivalente. Pas même de loin. Ahrefs et Semrush sont des produits plus complets pour le suivi des mots-clés, le positionnement et un crawl actualisé quotidiennement. Nous proposons des données de liens et un score à un faible coût par appel, avec une actualisation approximativement mensuelle.

Les vérifications en masse sont notre domaine d’expertise. Si votre travail consiste à vérifier des liens achetés en masse, le faible coût par appel est ce qui compte le plus. Si vous faites de la recherche de mots-clés pour le même client, vous aurez de toute façon besoin d’Ahrefs ou de Semrush, et les deux outils cohabitent sans conflit. Les utilisateurs de Majestic et Moz font face au même compromis, abordé dans le glossaire sous les rubriques DR et DA.

Des chiffres concrets basés sur une commande fictive figurent dans l’exemple de 40 liens, et les questions ouvertes sur la temporalité sont traitées dans pourquoi un lien acheté est introuvable.

Quand les unités d’abonnement ont du sens

Une équipe qui paie déjà un abonnement mensuel et l’utilise quotidiennement peut trouver les unités incluses pratiques. L’arithmétique de cette page ne dicte pas ce choix. C’est votre volume d’appels qui le détermine.

Quand la facturation prépayée à l’appel a du sens

Le crédit prépayé convient aux travaux par vagues, comme un lot de feuilles de fournisseurs qui arrive une fois par trimestre. Vous ne payez que les appels effectués, rien d’autre. Pas d’abonnement, pas de minimum mensuel.

Le travail sur les mots-clés reste du ressort des outils complets

Pour la recherche de mots-clés, le suivi du positionnement et un crawl actualisé quotidiennement, utilisez une suite SEO complète. Les deux peuvent coexister, et les vérifications de liens présentées dans ce guide ne remplacent rien de ce que vous utilisez déjà.

Budgétiser pour un portefeuille en croissance continue

Un calendrier peu coûteux pour dix sites peut sembler différent à deux cents. Le budget est une multiplication, et il est utile de noter cette multiplication avant que le portefeuille ne grossisse.

Compter les appels par client

Multipliez le nombre de clients par les vérifications par période, puis par le prix en crédits de chaque action. Imaginez un portefeuille de 250 sites clients vérifiés mensuellement, avec un appel refdomains par site. Cela représente 3 000 appels par an, soit 6 000 crédits, ce qui revient à 0,60 $.

Modifiez une variable à la fois, et l’impact sur le total reste facile à visualiser.

Une réserve pour les appels imprévus

Les vérifications planifiées ne représentent qu’une partie du coût. Un client transmet une question, un fournisseur conteste une ligne, et soudain, trois appels supplémentaires sont nécessaires un vendredi après-midi. Prévoyez une réserve couvrant quelques semaines de ces appels.

Une alerte réglée bien au-dessus de zéro coûte moins cher qu’un surprise 402 en plein milieu d’un batch.

Vérifier le solde après chaque exécution

Lisez le solde dans le champ _credits après chaque exécution, et comparez-le avec le nombre d’appels prévu. Un écart entre les appels prévus et réels signifie généralement qu’une boucle s’est exécutée deux fois, ce qui est un bug à corriger avant qu’il ne coûte plus cher.

Conservez le nombre d’appels prévu dans le journal du script. La comparaison ne prend alors qu’une minute au lieu d’un après-midi.

Ajout d’une vérification hebdomadaire de base

Un appel bulk_dr couvre jusqu’à 2 000 domaines pour 1 crédit. Ajouter une vérification hebdomadaire de base sur une liste de cette taille fait à peine bouger le total, c’est pourquoi la vérification de base est peu coûteuse à maintenir.

Questions sur le lancement du planning

Trois questions surgissent chaque fois qu’un planning est mis en production. Les réponses sont courtes, et chacune atteint une limite déjà définie par le tableau des coûts.

Une petite équipe peut-elle gérer cela sans développeur ?

Oui, si le planning est un seul script shell et une entrée cron. Le script nécessite curl, grep et la clé stockée dans une variable d’environnement. La partie difficile est la lecture, pas le code.

Commencez avec un client et une cadence. Ajoutez des clients une fois que le journal montre les mêmes comptes à chaque exécution.

Et si un exécution mensuelle révélait une surprise ?

Alors c'est une découverte, et non un échec du calendrier. Notez la date, récupérez la page le jour même et décidez si vous devez avancer la prochaine vérification. Une fréquence mensuelle n'interdit pas une exécution supplémentaire après un événement spécifique.

Un appel refdomains à bas prix suffit-il pour une contestation ?

Généralement non en soi. Un appel refdomains vous indique ce que contient l'index, tandis que le HTML enregistré vous indique ce que contient la page. Une contestation nécessite les deux, et le tableau des prix ne facture que le premier.