Vérifier les backlinks d'une page via une API et les mettre en cache honnêtement
Notre index est mis à jour une fois par mois, la plupart des requêtes peuvent donc être servies depuis la mémoire. Une recette pour des caches qui économisent les crédits sans afficher de fausses informations obsolètes aux utilisateurs.
Équipe éditoriale AlfaLinks ·
La règle
Mettre en cache jusqu'au prochain rafraîchissement de l'index, pas pour une durée fixe
Comme les données changent environ tous les mois, un TTL horaire ne vous apporte rien en plus, juste du coût. Une clé portée sur un mois donne la même réponse tout au long du mois et s'invalident d'un seul coup.
Clé : action + domaine + paramètres + mois de l'index
TTL : jusqu'à la fin du mois, plus un jour de grâce
Ne jamais mettre en cache une réponse d'erreur
Pourquoi un TTL court est une simple donation à votre solde de crédits
Les équipes débutantes dans les données de liens copient les habitudes des trackers de position. Habitude n°1 : un cache horaire, car les positions bougent. Les graphes de liens bougent à peine.
Un appel backlinks à 2 crédits coûte $0.0002. Cela semble peu jusqu'à ce qu'une vue de liste déclenche 50 appels par chargement de page sur 400 workspaces actifs, répétés chaque heure pour des réponses identiques.
Les chiffres détaillés ci-dessous sont un exemple, pas une mesure du trafic de qui que ce soit. Supposons 400 workspaces, 20 vues de domaine chacune par jour, 2 crédits par vue, et un cache d'1 heure qui ne fonctionne peut-être qu'un cinquième du temps. La plupart des vues atteignent toujours l'API. Avec une clé mensuelle, le même trafic ne l'atteindrait qu'une fois par domaine et par mois, donc l'écart est tout l'intérêt de la recette.
Les outils de recherche de mots-clés ont besoin de données plus fraîches, et pour ceux-ci, les grandes suites restent le meilleur choix. Pour le contexte des liens, le mensuel est le produit.
TTL par action
Suggéré, pas imposé. Toutes les actions lisent le même index mensuel.
Action
Crédits
TTL suggéré
Pourquoi
aperçu, statistiques
0
Jusqu'à la fin du mois
Gratuit, mais votre serveur économise toujours de la latence
bulk_dr
1
Jusqu'à la fin du mois
Tableau client entier en un seul appel
refdomains, backlinks
2
Jusqu'à la fin du mois, par paramètre page
Inclure page, per, sort dans la clé
anchors, toppages
2
Jusqu'à la fin du mois
Stable entre les rafraîchissements
search, keyword
3
7 jours
Rarement répété, peu coûteux de sauter la mise en cache
Exemple de requête : chauffer le cache pour un tableau client
Appelez bulk_dr une fois par client, pas une fois par ligne. Jusqu'à 2 000 domaines tiennent dans un seul corps POST et coûtent un crédit.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Construire le cache en cinq étapes
Chaque étape a un seul travail. Sautez-en une et la panne apparaîtra plus tard, généralement sous forme de facture.
01
Choisissez la clé
Utilisez l'action, le domaine, les paramètres de pagination et de tri, et le mois de l'index. Omettez tout ce que l'utilisateur peut modifier sans changer la réponse, comme une couleur d'affichage ou un nom d'onglet.
02
Stockez la réponse analysée
Conservez le JSON décodé avec son indicateur ok et les données, pas les octets bruts. Une vue ultérieure peut alors reconstruire tout le tableau depuis la mémoire sans un second appel.
03
Expiration à la fin du mois
Définissez l'expiration à la fin du mois de l'index, plus le jour de grâce de la règle ci-dessus. Utilisez la même règle pour chaque action, afin que la logique vive dans une seule fonction et non en cinq endroits.
04
Journalisez le solde à chaque appel
Lisez l'objet _credits object sur chaque réponse authentifiée et écrivez le solde restant dans votre propre journal. Une baisse lente de cette ligne est souvent le premier signe qu'une clé de cache est incorrecte.
05
Surveillez le taux de réussite
Suivez la fréquence à laquelle une vue est servie depuis le cache. Un taux faible signifie que la clé est trop spécifique, ou que les utilisateurs ouvrent un nouveau domaine à chaque visite. Chaque constat est utile lorsque vous planifiez le budget.
Les données obsolètes sont-elles un choix produit ou un bug ?
Un chiffre de lien peut avoir un mois et être toujours correct pour l'index dont il provient. La vraie question est de savoir si votre écran le dit. La plupart des tickets de support concernant des chiffres anciens sont des problèmes d'étiquetage. Les étiquettes les résolvent généralement.
Donnez à chaque chiffre son mois d'index. Affichez-le aux utilisateurs. Une fois qu'ils peuvent voir la date, le nombre cesse de ressembler à un flux cassé, et cette petite ligne fait plus qu'un TTL plus court ne pourrait jamais le faire.
Quel âge est trop vieux pour un chiffre de lien ?
Notre index est actualisé environ une fois par mois, donc un chiffre mis en cache le premier jour décrit le même index que celui mis en cache le dernier jour. Rien dans la réponse ne change à l'intérieur du mois. Les ennuis commencent quand un utilisateur s'attend à un lien d'hier, et alors la solution est une étiquette claire, comme couvert dans labels de score.
Les appels d'aperçu gratuits ont-ils besoin d'un cache ?
L'action overview ne coûte aucun crédit, donc le cache ici protège la vitesse plutôt que le solde. Votre serveur paie toujours pour chaque aller-retour, et une page qui s'ouvre cinquante fois par minute le ressentira. Stockez également les réponses gratuites, avec la même clé mensuelle, et la page reste rapide tandis que votre proxy reste silencieux. Les notes de recherche publique expliquent la même idée pour les visiteurs.
Un lien frais doit-il contourner le cache ?
Généralement non. Un contournement coûte des crédits pour une réponse qui est probablement identique à celle mise en cache. Si un client insiste, expliquez le mois de l'index et offrez une actualisation manuelle par workspace et par mois, plutôt qu'un bouton ouvert que n'importe qui peut appuyer en boucle.
Protection contre les tempêtes et autres petites choses
Single-flight : si dix utilisateurs ouvrent le même domaine, faites un seul appel amont et partagez la promesse.
Réchauffez le premier du mois avec un job en arrière-plan, pas à 9h quand les utilisateurs arrivent.
Stockez la réponse _credits.remaining et alertez en dessous d'un seuil que vous choisissez.
Mettez en cache le résultat négatif 'domaine non trouvé' pendant un jour, pas un mois.
Exposez l'âge du cache dans l'UI pour que le support puisse répondre 'quand cela a-t-il été récupéré ?'.
Pourquoi un cache bat le scraping pour les vérifications de liens
Les équipes qui doivent vérifier les backlinks de pages à grande échelle commencent souvent avec des scripts qui interrogent directement les moteurs de recherche. Ces scripts se bloquent. Ils semblent bon marché le premier jour, c'est pourquoi les équipes les conservent bien plus longtemps qu'ils ne le devraient. Un cache devant une API stable est généralement la conception la moins chère, avec moins de pièces mobiles à surveiller.
La différence se fait sentir en heures d'ingénierie plus que sur la première facture. Gardez le cache ennuyeux, et la plupart de ces heures n'arriveront jamais.
Pourquoi les vérificateurs de liens maison se bloquent-ils toujours ?
Les moteurs de recherche limitent les requêtes automatisées, donc un script qui fonctionne proprement pour cinquante URL peut se bloquer à cinquante mille. Les nouvelles tentatives, les pools de proxy et les délais aléatoires ajoutent tous un coût qui n'apparaît jamais sur une ligne de crédits, et ils cassent sans préavis lorsque la cible change ses réponses.
Comment garder un job de longue liste redémarrable ?
Écrivez chaque domaine terminé dans le cache au fur et à mesure. Si le job s'arrête en cours de route, un redémarrage saute tous les domaines qui ont déjà une réponse stockée et reprend là où il s'est arrêté. Rien n'est facturé deux fois pour le même mois, car la clé contient déjà la réponse.
Lancez le job à un rythme régulier plutôt qu'en une seule rafale. Espacer les appels garde les journaux lisibles et rend tout changement dans l'utilisation des crédits facile à expliquer.
Combien coûte une liste de 22 000 URL avec un cache ?
Disons que vous devez vérifier 22 000 URL de liens pour un client. Beaucoup d'entre elles partagent un domaine, donc déduplexez d'abord aux domaines. Ces 22 000 liens pourraient se réduire à quelques milliers de domaines uniques, et un appel bulk_dr prend jusqu'à 2 000 d'entre eux pour un seul crédit. Stockez chaque résultat par domaine et mois, et la liste cesse d'être un job par URL. Gardez l'arithmétique dans une courte note à côté du job, afin que la prochaine personne puisse le relancer avec une taille de liste différente. Un nombre avec son calcul montré est plus facile à croire qu'un total seul.
Où cela se connecte
Le cache est la couche intermédiaire dans la configuration du compteur. Une fois qu'il fonctionne, le coût par siège devient prévisible et vous pouvez tarifier un plan autour de cela avec la comparaison par siège. Les pages courtes méritent une fin claire. Celle-ci l'a.
Questions sur le cache que nous voyons en revue de code
Le cache doit-il vivre aussi dans le navigateur ?
Un court cache navigateur aide la navigation retour, mais le cache partagé sur votre serveur fait la vraie économie. Gardez le stockage côté client à quelques minutes, car les utilisateurs sur différentes machines verraient autrement des chiffres différents pour le même domaine le même jour.
Que faire si un client dit qu'un nouveau lien manque ?
Vérifiez le mois de l'index affiché dans votre UI. Si le lien a été ajouté après le dernier rafraîchissement, il apparaîtra après le prochain. Offrez une note, pas un remboursement, car rien n'est cassé.
Puis-je contourner le cache à la demande ?
Vous pouvez, mais chaque contournement coûte des crédits pour une réponse qui est probablement identique. Offrez-le uniquement aux administrateurs, et limitez-le par workspace pour éviter les boucles accidentelles.
Pagination et clé de cache
La pagination mord tout le monde une fois. Incluez-la dans la clé.
Les actions backlinks et refdomains retournent jusqu'à 1 000 lignes par appel, avec page et per entre 10 et 5000, et la pagination profonde est limitée à 50 000 lignes, donc une clé sans ces paramètres servira la page un pour chaque requête.
Le tri appartient aussi à la clé. Un utilisateur qui passe de DR descendant à alphabétique s'attend à une liste différente, et le cache doit s'y conformer sans un nouvel appel amont lorsque l'ensemble complet est déjà stocké.
Un test rapide attrape la plupart des erreurs de clé. Demandez la page deux, changez le tri, puis vérifiez que la page deux mise en cache diffère de la page un mise en cache. Si ce n'est pas le cas, la clé manque un paramètre. Trouvé tôt, cela coûte des minutes. Un client ne le voit jamais. Relancez le test avant chaque release, car une nouvelle option de tri est la raison habituelle pour laquelle la clé casse. Écrivez-le dans votre checklist de release.
Planifiez le bouton d'exportation séparément : un job en arrière-plan, un fichier stocké, et une notification quand il est prêt.
