Les recherches DR gratuites ne nécessitent pas de clé. Connectez-vous pour obtenir 100 $ de crédit.
Hypothétique
Chaque chiffre ici est fictif pour illustrer la méthode. Aucun client, fournisseur ou résultat réel n'est décrit.
L'agence, le fournisseur, les domaines et tous les chiffres ci-dessous sont fictifs. Ils servent à illustrer l'arithmétique et la structure. Votre lot sera différent.
Imaginez une agence qui a acheté 40 emplacements pour un site client, à un prix fixe par lien, avec un seuil DR garanti de 30 et une fenêtre de remplacement de 60 jours. La fiche fournisseur liste 40 URLs source et 40 ancres.
Rien d'anormal ici. La question est de savoir comment transformer cette fiche en un tableau de validation/échec. Nous utilisons trois points de contrôle : jour de livraison, jour 30 et jour 60.
| Point de contrôle | Page live récupérée | Hôte dans la liste refdomains | Rel comme commandé | Notes |
|---|---|---|---|---|
| Jour 0 | 38 sur 40 | 0 sur 40 (pas encore indexé) | 36 sur 38 | 2 URLs en 404, 2 rel=sponsored ajoutés |
| Jour 30 | 37 sur 40 | 29 sur 40 | 35 sur 37 | 1 de plus supprimé, index actualisé le jour 22 |
| Jour 60 | 36 sur 40 | 34 sur 40 | 35 sur 36 | Remplacements en attente pour 4 |
Le jour 0 montre zéro hôte dans l'index. C'est normal. Un zéro à la livraison n'est pas un défaut ; un zéro après deux actualisations, si.
Au jour 60, quatre liens sont disparus. Deux autres ont changé, car ils portent une étiquette sponsored que la commande ne mentionnait pas. Notez la différence. Le fait que l'étiquette compte comme un défaut dépend du contrat, donc la fiche devrait indiquer clairement ce qui a été commandé. Le glossaire liste les valeurs rel que vous pouvez citer.
Le seuil de rating est vérifié une fois avec bulk_dr. Un seul appel. Dans l'exemple, 40 domaines en un appel coûtent 1 crédit, et 3 domaines ont un score inférieur à 30 selon notre formule. Ces trois-là passent en premier dans le ticket car ils sont objectifs et peu coûteux à prouver.
Un rating inférieur au seuil n'est pas une question de goût. Une règle qui se règle par un nombre gagne la confiance pour les lignes subjectives qui suivent.
Au jour 60, le lot fictif montre 4 pages manquantes et 2 étiquettes sponsored. Les deux groupes nécessitent une gestion différente, et le tri est l'étape qui transforme une liste de défauts en un ticket.
Parmi les 4 pages manquantes, supposons que 3 aient été supprimées par l'éditeur et 1 ait été déplacée vers une nouvelle URL. Le déplacement est facile à manquer. Une redirection de l'ancienne adresse apparaîtrait comme un 301 dans l'analyse des en-têtes sauvegardée, c'est pourquoi les en-têtes sont stockés à côté du HTML.
Les 2 étiquettes sponsored sont une classe différente de problème. Les liens fonctionnent. Le fournisseur dira probablement que l'étiquette est l'option honnête. Décidez à l'avance si une étiquette compte, car un litige réglé par le goût perd une semaine.
| Étape | Appels | Crédits | Dollars |
|---|---|---|---|
| bulk_dr sur 40 domaines | 1 | 1 | $0.0001 |
| refdomains aux jours 0, 30 et 60 | 3 | 6 | $0.0006 |
| ancres au jour 60 | 1 | 2 | $0.0002 |
| Total | 5 | 9 | $0.0009 |
La colonne page live provient de curl sur la machine du testeur, pas de notre API. Nous n'offrons pas cette vérification, et prétendre le contraire masquerait la partie la plus laborieuse du travail.
Les crédits sont presque accessoires. Le travail consiste à lire 40 pages. Si vous voulez réduire cela, scriptez le grep depuis la liste d'erreurs et gardez l'œil sur les 4 ou 5 lignes qui échouent.
Pour une vue mois par mois de tout un portefeuille client, passez à la table des coûts. Si les classements ont bougé après le lot, le runbook de chute de trafic est la prochaine étape.
Les mêmes quatre actions ont été exécutées au jour 0, au jour 30 et au jour 60, afin que chaque point de contrôle puisse être comparé au précédent.
Les 40 pages ont été récupérées une fois par point de contrôle, avec le HTML et les en-têtes sauvegardés et horodatés. Une récupération échouée est une ligne dans le tableau, jamais une cellule vide.
Un appel refdomains par point de contrôle a retourné la liste des hôtes pour le client. Une liste fine au jour 0 était attendue, donc la ligne a été marquée et laissée pour le point de contrôle suivant.
Chaque hôte et chaque valeur rel ont été comparés au point de contrôle précédent ainsi qu'à la commande. Un changement apparaît alors comme un changement, avec une date attachée.
Les règles à la fin de cette page ont été appliquées ligne par ligne. La preuve est restée à côté de chaque ligne, afin qu'un verdict contesté puisse être rouvert.
Chaque point de contrôle posait une question principale. Les mélanger est la raison habituelle pour laquelle un résultat du jour 0 est contesté au jour 60.
Au jour 0, la question est étroite. La page est-elle live, et l'ancre existe-t-elle dans le HTML sauvegardé ? L'index n'est pas censé le savoir encore, donc un compte d'hôtes nul ne répond à rien. Notez cela et laissez la question de l'index pour plus tard.
Un test utile au jour 0 est de savoir si le HTML récupéré contient exactement la chaîne d'ancre de la commande. Si oui, la ligne est pass-pending. Si non, la ligne échoue avant même que la question de l'index ne se pose.
Dans le lot fictif, l'index s'est actualisé le jour 22, donc le jour 30 est le premier regard honnête sur la liste des hôtes. Les hôtes qui apparaissent maintenant confirment la mise en place. Les hôtes qui n'apparaissent toujours pas sont des candidats pour la colonne en attente, et le point de contrôle suivant les tranchera.
Le dernier point de contrôle cherche les dérives : une valeur rel qui a changé, une ancre qui a bougé, ou une page qui redirige maintenant. Comparez chaque ligne avec le jour 30, pas seulement avec la commande, afin qu'un changement apparaisse comme un changement.
Le jour 60 est aussi le point naturel pour vérifier si les remplacements sont toujours dans leur fenêtre, car c'est à ce moment qu'une date limite non remarquée a tendance à passer.
Un exemple détaillé est rangé. Les vrais lots sont plus désordonnés d'une manière qu'un tableau fictif ne peut pas montrer, et il est utile de nommer ces différences avant de copier la mise en page.
Un hôte peut changer de propriétaire entre les points de contrôle, avec un nouveau contenu et un nouveau modèle. Le lien peut toujours être live, mais ne plus se trouver sur le type de site décrit dans la commande. Comparez le titre de la page et le bloc auteur, pas seulement l'URL.
Un changement de propriétaire ne fait pas automatiquement échouer la ligne, mais cela change ce que la ligne prouve.
Ajoutez la vérification de propriété aux règles de verdict si votre lot est assez long pour que cela compte.
Certaines pages n'affichent un lien que dans un module rotatif, une barre latérale qui change à chaque visite, ou une liste tronquée aux éléments les plus récents. La récupération peut manquer l'ancre lors d'une exécution et la capturer lors de la suivante. Lorsqu'une ligne échoue une fois, récupérez-la deux fois le même jour et enregistrez les deux résultats. Notez la rotation dans la ligne, car un résultat en attente d'un module rotatif n'est pas la même chose qu'un lien manquant.
Un lot qui mélange les langues rend la vérification de l'ancre plus difficile, car l'ancre peut être traduite ou fléchie sur la page donneuse. Comparez-la avec la formulation convenue dans la commande, et marquez la langue à côté de la ligne pour qu'un réviseur sache pourquoi elle diffère.
Cet exemple d'audit de backlinks est un modèle, pas un résultat. Sa structure se transfère à toute commande. Ses chiffres, non, et personne ne ne devrait les lire comme une référence.
Le tableau de points de contrôle, la liste des crédits et les règles de verdict se transfèrent à un nouveau lot. Les comptes non. Remplacez chaque chiffre fictif par le vôtre avant que quelqu'un ne lise le résultat. Gardez les dates des points de contrôle sous la forme jour 0, jour 30 et jour 60, afin qu'un réviseur puisse faire correspondre votre fiche à cette page en un coup d'œil.
Écrivez les règles de verdict avant la première récupération, et ne les modifiez pas lorsqu'une ligne déçoit. Une règle changée après le résultat est un litige en attente.
Si le contrat du fournisseur fait référence aux mêmes règles, les deux parties lisent le même texte. Une ligne en attente signifie alors ce que le contrat dit qu'elle signifie, et l'argument passe de l'interprétation à la preuve.
Une commande de 40 lignes a coûté 9 crédits dans l'exemple. Une commande plus grande change le nombre d'appels, pas la méthode. Comptez les appels par point de contrôle, multipliez, et vérifiez que le total correspond toujours au budget que vous avez fixé. La récupération est toujours par lien, donc le temps de lecture augmente avec les lignes tandis que la ligne de crédits bouge à peine.
