Erreurs de contrôle qualité de l'ordre des liens : sept rapports de bug avec corrections
Chaque entrée ci-dessous est rédigée comme un ticket : ce qui était attendu, ce qui s'est produit, et la correction. La plupart coûtent peu à réparer.
Équipe de recherche LinksVerifier ·
Sept défauts, dans l'ordre où nous les rencontrons
01
Bug 1 : vous acceptez une capture d'écran comme preuve
Attendu : une page récupérée. Réel : une image que n'importe qui peut modifier. Correction : sauvegardez le HTML brut avec un horodatage et un dump des en-têtes curl -I le jour où le vendeur signale qu'il est en ligne.
02
Bug 2 : vous vérifiez la page d'accueil, pas l'URL exacte
Attendu : un lien sur l'article payant. Réel : un lien dans le pied de page de la page d'accueil qui disparaît lors du prochain déploiement. Correction : stockez l'URL source exacte dans votre feuille et testez cette chaîne.
03
Bug 3 : vous re-vérifiez quotidiennement contre un index mensuel
Attendu : des résultats frais. Réel : trente réponses identiques. Correction : planifiez une seule vérification après chaque actualisation ; voir le tableau des coûts.
04
Bug 4 : vous comparez le DR entre les outils comme s'il s'agissait d'un seul chiffre
Attendu : 55 égale 55. Réel : Ahrefs, Moz et notre formule ne sont pas d'accord. Correction : choisissez une seule métrique pour le contrat et nommez-la par écrit.
05
Bug 5 : vous ne testez jamais l'URL cible
Attendu : votre page renvoie 200. Réel : elle effectue deux redirections, ou une règle de staging bloque les robots. Correction : exécutez curl -I sur votre propre URL dans le même script.
06
Bug 6 : vous ignorez l'attribut rel
Attendu : un lien suivi. Réel : rel="sponsored" ou nofollow ajouté par un plugin. Correction : analysez rel dans le HTML récupéré et échouez la ligne si elle diffère de la commande.
07
Bug 7 : vous faites confiance à un remplacement sans le re-tester
Attendu : le nouveau lien est égal à l'ancien. Réel : un domaine différent avec une note inférieure. Correction : envoyez chaque remplacement via les mêmes vérifications que l'original.
Pourquoi les corrections sont mineures
Remarquez qu'aucune d'entre elles ne nécessite un deuxième abonnement. Le contrôle qualité des liens achetés est surtout de la comptabilité, et la comptabilité qui compte a lieu à la date de livraison.
Ce qui coûte cher, c'est la découverte tardive. Toujours. Un lot de 40 liens payés d'avance, trouvés cassés trois mois plus tard, vous laisse à argumenter sur une fenêtre de garantie qui est peut-être déjà fermée. Exécutez les vérifications au jour 0, au jour 30 et au jour 60 et la fenêtre joue en votre faveur.
Pour un calendrier concret avec des chiffres inventés mais plausibles, voir l'exemple de commande de 40 liens. Pour les termes utilisés dans cette liste, le glossaire est à un clic.
Un script minimal pour les bugs 1, 5 et 6
Cette boucle shell lit un fichier avec une URL source par ligne, sauvegarde les en-têtes et le HTML, et grep votre domaine. Il utilise uniquement curl et grep.
Il ne peut pas vous dire si Google a indexé la page, et il n'exécutera pas JavaScript. Un lien inséré côté client par un script sera lu comme manquant ici même si les visiteurs le voient.
Où notre API rejoint la boucle
Après la boucle shell, appelez refdomains une fois pour le domaine client et diff la liste des hôtes contre la feuille. Cela coûte 2 crédits, 0,0002 $, et une requête couvre jusqu'à 1 000 lignes.
Les hôtes présents dans la feuille et absents de la liste reçoivent l'étiquette pending jusqu'à la prochaine actualisation mensuelle. Les hôtes présents dans les deux sont croisés et confirmés. Une courte liste, clairement étiquetée, est le livrable que votre manager lit vraiment. Personne n'ouvre le JSON brut, et personne ne devrait avoir à le faire. Gardez le dump en stockage au cas où un vendeur contesterait une ligne six semaines plus tard.
Combien de temps devrait prendre une passe de contrôle qualité de commande de liens
Le contrôle qualité de l'ordre des liens prend moins de temps que la plupart des gens ne le pensent. Le temps va à un seul endroit. Il évolue avec le nombre d'URL sources et avec le nombre de celles que vous lisez à la main, tandis que la taille du propre site web du client a beaucoup moins d'importance.
Comptez les URL sources, pas les pages client
Imaginez un site de petite entreprise d'environ 200 pages qui a reçu 40 liens de l'extérieur. Le travail concerne les 40 pages sources plus les URL cibles. Les 200 autres pages du côté client ne font pas partie d'une vérification de liens. Disons que ces 40 liens proviennent de 12 hôtes distincts. La boucle de récupération s'exécute alors 40 fois, une fois par URL, et le diff refdomains s'exécute une fois par client. Compter de cette façon transforme l'estimation en arithmétique.
Si quelqu'un cite plusieurs jours de travail pour une vérification de liens, demandez quelles tâches couvrent le devis. Une audit complet de site et une vérification de liens sont des travaux différents, et un seul d'entre eux nécessite un crawler de tout le domaine.
Scriptez la récupération, puis lisez les exceptions
La boucle shell dans ce guide récupère chaque page source et grep pour le lien. Une personne lit uniquement les lignes que le script n'a pas pu confirmer, comme une ancre manquante ou une valeur rel inattendue.
Cela déplace l'effort de la lecture de chaque page à la décision sur une poignée de lignes.
Ce qu'une revue manuelle ajoute encore
Une revue manuelle attrape ce qu'un script ne peut pas. Des exemples sont un lien injecté par JavaScript, un paywall ou une mise en page qui cache l'ancre. Budgetisez-le sur les lignes qui comptent le plus, pas sur toute la feuille.
Écrivez le budget avant que le travail ne commence, afin que la revue ait un point de fin. Une habitude utile est d'échantillonner trois ou quatre lignes à la main après chaque lot, pas chaque ligne, et de consigner quelles lignes ont été lues.
Lequel des sept bugs apparaît en premier
Tous les bugs ne se manifestent pas au jour 0. Certains attendent une redirection, une mise à jour de plugin ou un changement de règle de staging. Sachez lesquels sont tardifs. Cela façonne les deuxième et troisième points de contrôle.
Les redirections et les règles de staging apparaissent tôt
Si l'URL cible effectue deux redirections, ou qu'une règle de staging bloque les robots, le problème apparaît généralement dans la première semaine. C'est pourquoi le bug 5 appartient au script du jour 0 et non à un script ultérieur.
Exécutez curl -I sur votre propre URL le même jour où le lien est signalé en ligne.
La dérive rel arrive après les mises à jour de plugin
Une mise à jour de plugin peut réécrire un attribut rel longtemps après la livraison. Un lien qui était suivi au jour 0 peut être lu comme sponsored au jour 60, sans que personne ne touche à l'article.
Donc la vérification rel appartient à chaque re-vérification, pas seulement à la première. Analysez l'attribut à partir du HTML récupéré chaque fois et comparez-le avec la commande.
Les mauvaises URL et les mauvaises notes sont trouvées à l'étape de la feuille
Le bug 2, la page d'accueil au lieu de l'article payant, et le bug 4, la comparaison des notes entre les outils, sont généralement détectés avant toute récupération. Les deux proviennent de la feuille elle-même, donc ils sont peu coûteux à corriger à ce stade.
Corrigez-les avant la première exécution du script. Chaque étape ultérieure hérite de ce que dit la feuille, et une récupération de la mauvaise URL renvoie une réponse propre concernant la mauvaise page.
Une feuille qui nomme une URL source exacte pour chaque ligne, et une métrique pour la note, supprime deux des fausses alertes les plus courantes dans tout le processus.
Les remplacements nécessitent les mêmes sept vérifications
Un lien de remplacement est un nouveau lien. Il mérite les mêmes sept vérifications que le premier lot, et il lance son propre chronomètre. Traitez l'échange comme une nouvelle ligne de commande. Pas un correctif.
Pourquoi l'ancienne ligne ne se transmet pas
L'ancienne preuve décrit une page qui ne porte plus votre lien. Elle ne prouve rien sur le nouveau. Gardez-la pour le dossier de litige, et commencez un nouvel ensemble de preuves pour le remplacement.
Enregistrez les deux URL sources dans la même ligne, afin que la piste soit lisible plus tard.
Tester dans la fenêtre de remplacement
Si le contrat nomme une fenêtre pour échanger un lien mort, testez l'échange dans cette fenêtre. Un remplacement testé à son dernier jour laisse peu de marge pour corriger un deuxième problème.
Utilisez la fenêtre comme une date limite pour vérifier, et réservez la vérification avant qu'elle ne se ferme.
Noter à nouveau le nouveau domaine
Un remplacement provient souvent d'un domaine différent, et ce domaine peut avoir une note inférieure à celle qu'il a remplacée. Exécutez à nouveau la vérification de plancher sur le nouvel hôte avant d'accepter l'échange.
Un seul appel bulk_dr couvre toute la liste des remplacements, donc il y a peu de raisons de le sauter.
Ce que la feuille du manager devrait montrer
Une feuille de contrôle qualité de commande de liens est le livrable. Chaque ligne porte un statut et quelques dates, et la preuve est derrière la ligne dans le stockage. La preuve reste hors de vue. Le manager lit le résumé.
Un statut par ligne
Utilisez pass, pending ou fail, et rien d'autre entre eux. Une ligne qui est en ligne mais pas encore indexée est pending, pas un demi-pass. Les demi-pass renvoient la revue mensuelle dans une argumentation sur le libellé.
Si vous avez besoin d'un quatrième état, nommez-le d'abord dans le contrat.
Des dates à côté de chaque statut
Chaque ligne a besoin du jour où vous avez récupéré la page, du jour de la dernière actualisation que vous connaissiez, et du jour de la prochaine vérification. Ces trois dates répondent à la plupart des questions qu'un manager pose.
Une ligne sans dates invite à la question de savoir si la vérification a eu lieu ou non.
Conserver le dump brut pour un litige
Stockez le HTML sauvegardé, les dumps d'en-têtes et les réponses API dans un dossier nommé d'après le lot. Conservez le dossier aussi longtemps qu'un litige pourrait encore être ouvert, car un vendeur peut contester une ligne bien après la clôture du résumé.
Rendez le dossier en lecture seule une fois le lot fermé, afin que la preuve corresponde à ce que vous avez rapporté.
Avant de fermer le ticket
La feuille nomme une URL source exacte pour chaque ligne, pas un domaine.
La preuve du jour 0 est stockée : HTML, en-têtes, date et heure.
La date de la prochaine re-vérification tombe après une actualisation mensuelle.
Les remplacements ont passé les mêmes sept vérifications que le premier lot.
