Vérificateur de backlinks PageRank ou DR : quoi stocker dans un champ
Votre modèle de contenu nécessite un nombre, une date et une note. Cette page présente la conception du champ et un exemple concret avec la formule du DR.
Équipe de recherche Contentin ·
Pourquoi le PageRank n'est pas une option de champ
Les gens recherchent encore un outil de vérification de backlinks PageRank, mais le chiffre public a disparu. Google a supprimé l'affichage du PageRank de la barre d'outils en 2016, et aucun remplacement n'est jamais venu de Google lui-même.
Ce qui subsiste, ce sont les scores des éditeurs. Ahrefs propose le DR, Moz propose le DA, et nous publions notre propre Domain Rating avec une formule ouverte. Choisissez-en un et tenez-vous-y. Mélanger deux scores dans une colonne rend toute comparaison ultérieure sans objet.
Une règle pratique pour les équipes headless : stockez ce que vous afficherez ou filtrerez, et rien d'autre. Chaque champ supplémentaire est une source potentielle d'erreur pour un rédacteur, une colonne supplémentaire dans une exportation, et un mappage supplémentaire qui peut échouer lors d'une migration d'un CMS à un autre.
Le nom compte. Appelez le champ link_dr, pas authority. Le premier indique de qui est le chiffre. Le second invite à remplacer le score d'un autre éditeur dans un an.
Nommer le champ selon sa source
Nommez le champ d'après l'éditeur qui a produit le chiffre, à chaque fois. Un champ appelé link_dr indique au prochain lecteur d'où provient la valeur et empêche un changement silencieux vers un autre éditeur.
Seule l'étiquette passe, pas le chiffre. Le DR d'Ahrefs, le DA de Moz et notre propre Domain Rating sont des mesures différentes, donc une valeur copiée d'un outil dans un champ nommé pour un autre induira le prochain lecteur en erreur.
Peut-on stocker les scores de deux éditeurs ?
Vous le pouvez, dans deux champs avec deux noms. La plupart des équipes n'en ont pas besoin, car deux chiffres invitent à une comparaison, et c'est cette étape qui pose problème.
Si un responsable demande les deux, montrez-lui les deux formules côte à côte. Les échelles sont construites différemment, et cette différence explique la plupart des surprises.
Le score est-il le même d'un outil à l'autre ?
Non. Un DR d'un outil et un DA d'un autre proviennent de graphes de liens différents et de formules différentes, donc ils peuvent pointer dans la même direction tout en différant sur le chiffre.
Notre propre formule est publique. L'échelle logarithmique est la raison pour laquelle un saut de 1 000 à 100 000 domaines référents fait varier le score moins que ne le suggèrent les comptes bruts.
Exemple concret : la formule sur cinq domaines inventés
Les comptes de domaines référents sont fictifs à des fins d'illustration. Formule : round(100 · log(ref_domains+1) / log(2·10^7)).
Domaine inventé
Domaines référents
DR
Bande suggérée
tiny-docs.example
10
14
Faible
small-saas.example
50
23
Faible
mid-blog.example
1,000
41
Moyen
big-publisher.example
100,000
68
Élevé
theoretical-top.example
20,000,000
100
Élevé
Ce que le tableau dit sur la conception des champs
L'échelle est logarithmique. Dix domaines et 1 000 domaines sont séparés de 27 points, tandis que 1 000 et 100 000 sont séparés de la même distance. Stockez donc l'entier, mais lisez-le par bandes.
Un champ de bande aide souvent plus un rédacteur que le chiffre brut. Personne ne peut agir sur 41 contre 43. Ils peuvent agir sur une étiquette qui dit moyen. Gardez-le simple.
Les dates comptent autant que les scores. Un score stocké sans date ressemble à une lecture en direct, et un an plus tard, quelqu'un le citera en réunion comme s'il l'était. Tamponnez-le, et actualisez-le selon un calendrier que vous pouvez nommer, comme le balayage nocturne bulk_dr depuis le tableau des coûts.
Le champ note doit rester simple, car sa tâche est modeste. Une phrase suffit. Sa tâche est de rappeler au lecteur que l'index bouge environ mensuellement et que Google Search Console détient la propre vision de Google.
Maintenir l'honnêteté du champ dans le temps
Un champ écrit une fois et jamais revisité devient silencieusement un fait du passé. Le travail d'actualisation est ce qui le maintient comme une lecture, et il doit s'exécuter selon un calendrier que vous pouvez nommer en une phrase.
Commencez par le calendrier, car il définit tout le reste. Mensuel correspond à l'index, et les balayages nocturnes ajoutent du coût sans ajouter d'information, car l'index bouge environ une fois par mois.
À quelle fréquence le score doit-il s'actualiser ?
Mensuellement, dans la plupart des cas, car c'est le rythme que suit l'index. Les balayages nocturnes ont encore du sens pour une équipe qui veut une date fraîche sur chaque entrée, même lorsque le chiffre n'a pas bougé.
Le coût n'est pas la raison de reculer. Un appel bulk_dr nocturne de jusqu'à 2 000 domaines coûte un crédit, et le tableau des coûts liste le reste.
Que doit faire le travail avec une valeur manquante ?
Laissez l'ancien score et l'ancienne date en place, et marquez la tentative comme échouée dans votre propre journal. Écrire une valeur vide à la place d'une bonne lecture semble propre, mais cela efface l'unique historique dont vous disposez.
Une valeur manquante et un zéro sont des faits différents. Votre type de champ doit les séparer, afin qu'un rédacteur ne lise jamais un vide comme un mauvais score.
Comment garder chaque lot sous la limite ?
Divisez la liste en chunks de pas plus de 2 000 domaines, et envoyez un appel par chunk. Gardez la taille du chunk dans une constante unique, afin qu'un changement de limite ne touche qu'une ligne.
Journalisez le nombre de domaines envoyés et le nombre de lectures stockées. Un désaccord entre les deux est le premier indice qu'un lot a échoué.
Ce qu'un rédacteur devrait voir à côté du score
Un rédacteur lit le champ en quelques secondes, donc le champ doit répondre en quelques secondes. Affichez la bande en premier, la date en deuxième et l'entier en dernier, car c'est l'ordre dont un lecteur pressé a besoin.
L'étiquette compte autant que la mise en page. Un champ appelé link_dr_band qui dit moyen n'indique rien à l'éditeur sur l'index, donc la note à côté doit porter cette mise en garde.
La bande doit-elle colorer l'entrée ?
Un badge coloré peut aider un rédacteur pressé, mais il peut aussi faire paraître une lecture moyenne comme un échec. Limitez les couleurs aux noms de bande, et évitez le rouge pour tout sauf un problème majeur.
La bande est un conseil pour une revue, pas une règle pour la publication. Dites-le dans l'étiquette à côté, afin qu'un badge vert ou ambre ne soit jamais lu comme un passage.
Lorsque la même bande apparaît sur de nombreuses entrées, vérifiez la règle avant de vérifier les entrées. Une bande qui signale la moitié du site indique généralement le seuil, pas le contenu.
Que mettre dans la note lorsque la date est ancienne ?
Une date ancienne doit changer la note, pas masquer le score. Une ligne qui dit que la lecture est plus ancienne que la dernière actualisation indique au rédacteur quoi faire, à savoir vérifier à nouveau avant de s'y fier.
Générez cette ligne dans votre code, afin que chaque entrée la dise de la même manière. Les notes manuscrites dérivent, et après quelques mois, personne ne se souvient de ce qu'elles étaient censées dire.
Un croquis du modèle de contenu
Les noms de champs sont les nôtres à des fins d'illustration. Contentful, Sanity, Strapi et Payload déclarent chacun des champs à leur manière, donc traduisez.
Exécutez overview sur un domaine connu et lisez le JSON à l'œil. Vérifiez les vrais noms de champs dans la réponse, car cette page ne les liste pas pour vous.
2
Sélectionnez la valeur DR
Copiez le score de 0 à 100 dans un champ entier. Rejetez tout ce qui est hors de cette plage afin qu'une réponse malformée ne puisse pas atteindre l'entrée.
3
Dérivez la bande dans votre propre code
Moins de 20 est faible, 20 à 50 est moyen, plus de 50 est élevé. Les seuils sont une suggestion et appartiennent à votre équipe, pas à l'API.
4
Tamponnez la date
Écrivez la date d'aujourd'hui à côté du score. L'index s'actualise environ mensuellement, donc la date fait partie des données.
Quatre champs et la question à laquelle chacun répond
Chaque champ répond à une question qu'un rédacteur se posera.
01
link_dr
Le score entier de 0 à 100. Il répond à la question de la force du domaine sur l'échelle.
02
link_dr_band
Une étiquette simple telle que faible, moyen ou élevé. Elle répond à la question de savoir si une personne doit regarder de plus près, sans demander à personne de lire un chiffre.
03
link_checked_on
La date de la lecture. Elle répond à la question de l'ancienneté du chiffre, ce qui est plus important que la plupart des équipes ne l'imaginent.
04
link_check_note
Une phrase sur l'index. Elle répond à ce que le score ne peut pas montrer, comme l'actualisation mensuelle et le délai pour les nouveaux liens.
Champs à exclure
Les lignes brutes de backlinks : elles vieillissent mal et gonflent l'entrée
Les listes d'ancres, sauf si un humain les examine (voir le runbook)
Un booléen de passage ou d'échec : il invite à un blocage strict
Les scores d'éditeurs de deux outils dans une seule colonne
Une mise en garde sur l'exemple
Les cinq domaines ci-dessus n'existent pas, et les comptes sont choisis uniquement pour rendre l'arithmétique visible. Pour de vrais chiffres, exécutez le vérificateur DR gratuit sur votre propre site.
