Vérification de mon backlink a retourné rien : un tableau d'erreurs

La règle qui couvre la plupart des cas

Relancez les erreurs réseau. Ne relancez jamais un 401 ou un 402. Le premier se résout de lui-même en quelques secondes ; le second nécessite une intervention humaine, et le surcharger ne remplit que vos logs.

Chaque réponse JSON comporte un champ ok, et celles qui sont authentifiées ajoutent _credits avec le coût de l'appel et le solde restant. Vérifiez ok dans le corps de la réponse même si le statut HTTP semble correct.

Les délais de relance ci-dessous sont nos conseils d'ingénierie, pas des limites documentées. La documentation de l'API que nous détenons ne publie pas de limite de débit, donc établissez votre propre plafond et gardez-le modeste.

Pourquoi les 401 et 402 ne sont jamais relancés

Un 401 est un problème de clé, et un 402 est un problème de solde. Aucun des deux ne se résout entre deux tentatives espacées d'une seconde, donc une relance ajoute du bruit dans vos logs et rien d'autre.

Attendre ne résout pas non plus un 402. Le solde reste tel quel jusqu'à ce que quelqu'un le recharge depuis la page du compte, donc la seule réaction utile est un message clair et une alerte à la personne qui gère le budget.

Un 401 mérite un examen de l'en-tête ou du paramètre clé, et une vérification que la clé n'a pas été remplacée. Relancer la même clé erronée plusieurs fois ne prouve rien.

Une clé invalide et un solde vide se présentent également différemment dans votre tableau de bord. Mettez-les sur des alertes séparées, afin que la personne qui recharge ne soit pas réveillée pour une faute de frappe sur la clé, et que celle qui rotate les clés ne soit pas alertée pour un problème de solde.

Erreurs réseau et backoff

Un timeout ou une réinitialisation de connexion peuvent se résoudre d'eux-mêmes, ce sont donc les seuls cas méritant une nouvelle tentative. Attendez 1, 2, 4 puis 8 secondes, ajoutez un peu de jitter, et arrêtez après la quatrième tentative.

Ces délais sont nos conseils, pas une limite documentée. Gardez votre propre plafond, loggez chaque relance, et alertez lorsque le nombre de relances augmente, car un taux de relance croissant est généralement le premier signe d'un problème en amont.

Gardez le timeout de votre côté explicite, dans une constante nommée. Une valeur par défaut implicite qui change avec une mise à jour de bibliothèque est une raison courante pour laquelle un job nocturne commence à échouer sur une seule machine.

Surveillez également le temps de réponse en amont ainsi que le taux d'échec. Une réponse lente qui ne rate jamais peut toujours bloquer vos workers, et une boucle de relance aggrave ce ralentissement.

Normalisez le domaine avant l'appel

La plupart des appels échoués commencent dans la boîte de saisie, pas dans le réseau. Les utilisateurs collent ce qu'ils ont copié, et votre code doit transformer cela en un domaine nu avant que l'API ne le voie.

Supprimez le schéma et le chemin

Supprimez le schéma, tout chemin et la chaîne de requête. Une adresse d'article collée devient son hôte, et seul l'hôte va en amont.

Mettez également l'hôte en minuscule. Gardez le nettoyage dans une seule fonction, afin que la même règle s'applique dans le formulaire, dans le job par lots et dans les tests.

Testez le nettoyage avec cinq ou six entrées collées réelles, y compris une avec un slash final et une avec une chaîne de requête. Ces cas révèlent les bugs qu'un exemple propre ne montre jamais.

Décidez une fois quoi faire avec www.

Choisissez une règle pour www. et appliquez-la dans une seule fonction, afin qu'un même site ne soit jamais recherché sous deux orthographes.

Écrivez la règle à côté de la fonction. Le prochain développeur qui rencontrera un www errant trouvera alors la décision, pas un deuxième avis.

Quelle que soit la règle que vous choisissez, gardez-la dans un seul fichier et écrivez un seul test pour elle. Le test est la trace de la décision, et il est court.

Rejetez ce qui ne peut pas être un domaine

Refusez les entrées avec des espaces ou des étiquettes vides, et affichez un message court dans le formulaire. Une chaîne rejetée ne coûte rien, tandis qu'une mauvaise coûte un appel échoué et un utilisateur confus.

Les points finaux sont le cas étrange. Supprimez un point à la fin de l'hôte et traitez tout le reste comme invalide.

Affichez le rejet à côté du champ, pas comme une notification toast qui disparaît. Un utilisateur qui voit ce qui ne va pas le corrige en un essai.

Résultats vides et âge de l'index

Lorsque quelqu'un saisit "vérifiez mon backlink" dans votre formulaire et ne reçoit rien, une réponse vide n'est pas toujours une erreur. Cela signifie souvent que le domaine est nouveau, trop petit ou simplement pas encore dans l'index, et l'écran devrait le dire.

Un site tout nouveau

Un site lancé la semaine dernière peut n'avoir aucun domaine référençant dans l'index. Affichez "pas encore indexé" avec la date d'indexation, et proposez l'appel gratuit overview comme contre-vérification.

Ne mettez pas cette réponse vide en cache pendant longtemps. Quelques heures suffisent, et la prochaine reconstruction peut inclure le site.

Indiquez au visiteur quand l'index a été reconstruit pour la dernière fois, en mots simples. Une date à côté d'un résultat vide explique mieux l'écart qu'un message plus long.

Une note d'une ligne dans votre propre interface suffit ici. Personne ne s'attend à un index en temps réel, et une phrase simple à côté de la date d'indexation se lit comme honnête.

Un nombre qui diffère d'un autre outil

Différents crawlers voient différentes parties du web. Lisez le chiffre DR comme une position au sein d'un seul outil, et dirigez les lecteurs vers la référence DR pour la formule.

Une courte note sous le chiffre fait gagner plus de temps de support que n'importe quelle excuse après coup.

Si deux lectures diffèrent, comparez d'abord les comptes de domaines référençant. La formule DR est simple, donc la plupart des désaccords se résument au compte.

Les lignes qui s'arrêtent à 50 000

Lorsqu'une liste s'arrête au plafond, la réponse est correcte pour ce que l'API permet. Étiquetez le seuil et liez les notes sur la pagination au lieu d'essayer une page plus profonde.

Les pages plus profondes au-delà de ce point ne sont pas une relance. Ce sont une requête différente, et les traiter comme une seule est la façon dont une boucle tourne pendant des heures.

Gardez le seuil visible dans l'export également, afin qu'une feuille de calcul ouverte un mois plus tard montre toujours que la liste était limitée.

Afficher le nombre de lignes à côté du tableau transforme un seuil en un fait visible. Un lecteur qui voit 50 000 lignes sait qu'il doit poser une question plus précise.