Vérifiez les backlinks gratuitement d'abord, puis dépensez les 100 $ à bon escient
Quatre actions sont gratuites. Le solde de départ est de 1 000 000 de crédits. Ces budgets montrent jusqu'où cela va pour des projets de développeurs typiques.

La grille des prix en un seul endroit
Prépayé, sans abonnement, sans minimum mensuel. Un crédit vaut 0,0001 $.
Trois budgets, tous hypothétiques
Il s'agit d'exemples de planification, pas de rapports provenant de comptes réels. Modifiez les volumes et le calcul reste valable, donc substituez les vôtres.
Budget A, un widget public
Un vérificateur DR gratuit sur votre blog utilise domain, ce qui coûte 0 crédit. Dix mille vérifications par mois sont gratuites à l'API, et la seule facture que vous avez est celle de l'hébergement, qui n'a rien à voir avec nous. Un outil de vérification des backlinks gratuit sur un blog effectue le même appel, visible depuis une page qu'un visiteur peut voir.
Mettez en cache les appels gratuits pendant une journée, comme le fait le guide Next.js. Un widget qui reçoit mille vérifications depuis un article populaire puis effectue un appel amont par domaine par jour, ce qui garde le calcul court et la page rapide.
La facture qui compte pour un widget est celle de son hébergement et de sa gestion du trafic, donc estimez-les en premier et traitez l'API comme le petit élément qu'elle est.
Budget B, un rapport d'agence
Mensuellement, 300 domaines clients, un appel refdomains chacun à 2 crédits. Cela représente 600 crédits par mois et 7 200 par an, soit 0,72 $. Petit. Le solde de 100 $ couvrirait environ 139 ans à ce rythme, donc le stockage et votre temps dominent, pas l'API.
Le calendrier est le levier ici. Exécuter les mêmes 300 domaines hebdomadairement au lieu de mensuellement signifie environ quatre fois plus d'exécutions, et puisque l'index se rafraîchit environ mensuellement, la plupart des réponses hebdomadaires répètent la dernière.
Budget C, une exportation complète
Un domaine, 50 appels de 1 000 lignes pour atteindre le plafond de 50 000, à 2 crédits chacun : 100 crédits, soit un centime. Répétez pour 1 000 domaines et vous dépensez 100 000 crédits, soit 10 $ des 100 $ et un dixième du solde.
Le coût en crédits est faible, mais les lignes stockées ne le sont pas. Planifiez l'espace disque pour elles de la même manière que vous planifiez pour les crédits, et ne gardez que les colonnes que vos rapports lisent.
Si l'exportation doit être répétée chaque mois, le chiffre mensuel est celui à mettre dans le budget, pas le total unique.
Ce que les budgets omettent
Remarquez ce qui manque : un plan mensuel. Il n'y a pas d'abonnement à renouveler, et vous payez pour les appels, pas pour les places. Pas cher. Chaque budget s'appuie sur le même fait. Le script en vrac et les notes de pagination montrent le code derrière ces comptes d'appels.
Un budget qui ignore le temps est incomplet, donc la section suivante ajoute les coûts qui se situent en dehors de la grille des prix.
Une ligne supplémentaire appartient à chaque budget : le coût de relancer un job échoué. Si un arrêt et redémarre depuis le début, les appels payants se répètent, donc la logique de reprise est aussi un élément de budget.
Même argent, un autre vendeur
| API SEOMasters.dev | API Ahrefs (tel que cité) | |
|---|---|---|
| Point d'entrée | 0 $, puis crédit prépayé | À partir de 129 $ par mois |
| Allocation | 1 000 000 de crédits gratuits à l'inscription | 200 000 unités par mois |
| Minimum par demande | Aucun ; les actions gratuites coûtent 0 | Au moins 50 unités |
| La plupart des demandes par mois à ce minimum | Non applicable | 4,000 |
| Mots-clés, suivi du classement, crawl quotidien | Non proposé | Oui, et Semrush les propose également |

Ce qu'un budget ne couvre pas
La ligne API est l'élément le plus faible dans la plupart des projets. Trois autres coûts pèsent généralement plus lourd, et une page budgétaire devrait les nommer.
Hébergement et stockage
Votre serveur, votre base de données et votre hôte cron facturent séparément, et ensemble ils peuvent coûter plus cher que les appels eux-mêmes. Imaginez un travail nocturne sur un petit VPS : le VPS est la ligne à surveiller, pas les appels.
Un tableau brut de réponses stockées prend également de l'espace disque. Estimez sa croissance à partir d'un lot sauvegardé, multiplié par les exécutions prévues.
Évaluez le coût du travail avant de choisir l'hôte. Une tâche cron qui s'exécute une fois par mois nécessite bien moins qu'un worker qui reste actif toute la journée, et cette différence décide souvent du budget.
Les logs sont aussi un coût. Une ligne par appel, conservée pendant un an, s'accumule sur une tâche fréquente, alors décidez de la période de rétention volontairement plutôt que par défaut.
Déménagement dans deux ans
Prévoyez un budget pour la sortie, pas seulement pour le démarrage. Si une refonte ou un nouveau fournisseur arrive dans deux ans, le travail porte sur la couche de récupération et le mappage des champs, et le script en masse conserve les corps bruts qui facilitent ce mappage.
Conservez les anciennes réponses aussi longtemps que l'historique a de la valeur pour vous, car elles sont le seul enregistrement des chiffres utilisés par vos rapports.
Noter la sortie maintenant coûte une heure. S'en rendre compte dans deux ans parce que les corps bruts n'ont jamais été conservés coûte une reconstruction de l'historique.
Stockez une brève description de chaque champ que vous lisez, dans le même dossier que les corps bruts. Cette description est ce qui permet à une équipe future de mapper l'historique sans deviner.
Votre propre temps sur la couche de récupération
La couche de récupération, les tentatives et la liste autorisée prennent un après-midi à écrire et plus de temps à tester. Comptez ce temps avant de décider qu'un outil gratuit est vraiment gratuit.
C'est la ligne que la plupart des budgets omettent, et c'est généralement l'élément le plus important après l'hébergement. Notez-le de toute façon, pour que la comparaison soit honnête.
Un bon test est le temps qu'il faut à un nouveau développeur pour faire un appel à partir de zéro. Si cela prend une journée, la couche de récupération est le véritable coût du projet, pas les crédits.
Indiquez un chiffre horaire approximatif à côté de ce temps, même une estimation. Une estimation notée est plus facile à contester qu'un coût qui n'apparaît jamais dans le tableau.
Vérifier l'arithmétique avant de lui faire confiance
Un budget n'est bon que s'il est bien multiplié. Deux vérifications capturent la plupart des erreurs avant qu'une exécution planifiée ne les révèle.
Commencez par le prix par crédit
Un crédit vaut $0,0001. Cela fait 10 000 crédits $1 et les 1 000 000 de crédits de démarrage complets $100, ce qui est la seule conversion dont une feuille de planification a besoin.
Notez la conversion une fois, dans une cellule ou une constante, et réutilisez-la. La retaper à trois endroits est la raison pour laquelle un tableau finit avec trois prix différents.
Conservez le tableau en crédits jusqu'à la dernière ligne. Convertir tôt puis multiplier à nouveau est l'endroit habituel où un facteur dix peut se glisser sans être remarqué.
Une feuille de planification avec une colonne de devise invite à l'arrondi. Gardez une colonne de crédits à côté de la colonne de dollars, et laissez les dollars être la figure dérivée.
Testez un appel par rapport au solde
Faites un appel payant, lisez _credits avant et après, et vérifiez que la baisse égale le prix de l'action. Un appel refdomains devrait faire baisser le solde de 2 crédits, et un appel search de 3.
Si la baisse diffère, arrêtez-vous avant qu'une exécution planifiée ne multiplie l'écart. L'appel de test coûte des fractions de centime, ce qui en fait la vérification la moins chère de tout le budget.
Enregistrez le test dans le même journal que les exécutions. Un mois plus tard, la ligne de test montre combien a coûté chaque action lorsque le tableau a été écrit, ce qui est utile si la liste des prix change.
Vérifiez également le solde sur votre propre page de compte, une fois. Les deux nombres doivent correspondre, et un désaccord vaut une courte note dans le manuel d'exécution.
Définir un budget mensuel dans le code
- 1
Comptez les appels payants
Comptez vos appels payants par exécution et multipliez par les exécutions dans un mois. Notez le total dans un fichier de configuration à côté du code.
- 2
Convertissez les appels en crédits
Multipliez par le coût du crédit selon la liste des prix : 1 pour
bulk_dr, 2 pourrefdomains, 3 poursearch. Le résultat est le prélèvement mensuel en crédits. - 3
Définissez un niveau d'alerte
Choisissez un solde qui devrait envoyer un message à celui qui fait le rechargement. Comparez-le avec la valeur
_creditsde la dernière réponse. - 4
Revue après un mois
Comparez le prélèvement réel avec l'estimation. Un écart signifie généralement une boucle, une tentative ou une action que vous ne prévoyiez pas de voir s'exécuter.

Où nous le placerions
Dépensez pour les tirages profonds mensuels, gardez le reste gratuit
Comme l'index se rafraîchit environ une fois par mois, toute fréquence plus élevée que mensuelle répète la réponse d'hier. Planifiez les tirages payants mensuellement et laissez les quatre actions gratuites gérer les recherches quotidiennes.
- Mettez en cache les appels gratuits pendant une journée
- Autorisez les actions payantes dans le code
- Journalisez
_creditsaprès chaque appel - Rechargez uniquement en USDT (TRC-20) lorsque le solde le justifie
Questions d'argent
- Les $100 expirent-ils ?
- Le matériel que nous détenons pour ce site ne donne pas d'expiration, donc nous n'en indiquons pas. Consultez la page de compte, qui affiche votre solde et votre activité, avant de planifier un travail de longue durée.
- Une carte est-elle nécessaire pour commencer ?
- Non. Connectez-vous avec un compte Google et le crédit de $100 est ajouté sans carte. Les recharges ultérieures sont effectuées en USDT sur le réseau TRC-20 depuis la page de compte.