Big, Fast, and Strong: Définir la norme pour les comparaisons d'index backlink

Tout est faux

Ça l'a toujours été. La plupart d'entre nous le savions. Mais avec des ressources limitées, nous ne pouvions vraiment pas vraiment comparer la qualité, la taille et la vitesse des index de liens. Franchement, la plupart des comparaisons de l'indice de liaison inverse passeraient à peine pour un projet d'expo-sciences à l'école secondaire, et encore moins pour un examen par les pairs rigoureux.

Ma tentative la plus sérieuse de déterminer la qualité d'un index de liens remonte à 2015, avant de rejoindre Moz comme chercheur principal. Mais je savais à l'époque qu'il me manquait une clé énorme pour toute étude de ce genre qui espère s'appeler scientifique, autoritaire ou, franchement, vraie: un échantillon aléatoire et uniforme du web .

Mais permettez-moi de commencer par une demande rapide S'il vous plaît, prenez le temps de lire ceci. Si vous ne pouvez pas aujourd'hui, planifiez un peu plus tard. Vos entreprises dépendent des données que vous apportez, et cet article vous permettra d'arrêter de prendre la qualité des données sur la foi seule. Si vous avez des questions sur certains aspects techniques, je répondrai dans les commentaires, ou vous pouvez me joindre sur twitter à @rjonesx . Je souhaite désespérément que notre industrie finisse par bien faire les choses et à nous imposer comme fournisseur de données selon des normes de qualité rigoureuses.

Liens rapides:

1. Accueil
2. Bien faire les choses
3. Quel est le problème avec les aléas?
4. Maintenant quoi? Définition des métriques
5. Avertissements
6. Tableau de bord des métriques
7. Taille des sujets
8. Vitesse
9. Qualité
10. Les Jeux Olympiques de l'Index des Liens
11. À propos de PA et DA

Bien faire les choses

L'une des meilleures choses que Moz offre est une équipe de direction qui m'a donné la liberté de faire ce qu'il faut pour «faire les choses correctement». J'ai d'abord rencontré ça quand Moz a accepté de dépenser énormément d'argent sur les données clickstream pour que nous puissions améliorer notre outil de recherche de mots clés (un énorme risque financier pluriannuel dans l'espoir d'améliorer littéralement une mesure dans notre industrie). Deux ans plus tard, Ahrefs et SEMRush utilisent maintenant la même méthodologie parce que c'est juste la bonne façon de le faire.

Environ 6 mois dans ce projet pluriannuel pour remplacer notre index de lien avec l'énorme Link Explorer j'ai été chargé de la question ouverte de " comment savons-nous si notre lien "Je pensais à cette question depuis que cet article a été publié en 2015 et je savais que je n'allais pas aller de l'avant avec autre chose qu'un système qui commence par un" échantillon aléatoire "du web " Une fois de plus, Moz m'a demandé de faire ce qu'il faut pour «bien faire les choses», et ils m'ont laissé courir avec.

Quel est le gros problème avec le hasard?

Il est vraiment difficile d'affirmer à quel point un bon échantillon aléatoire est important. Laisse-moi diverger une seconde. Disons que vous regardez un sondage qui dit que 90% des Américains croient que la Terre est plate. Ce serait une statistique terrifiante. Mais plus tard, vous découvrez que l'enquête a été prise lors d'une convention Flat-Earther et les 10% qui n'étaient pas d'accord étaient des employés du centre de convention. Cela aurait un sens total. Le problème est que l'échantillon de personnes interrogées n'était pas des Américains aléatoires – au contraire, il était biaisé parce qu'il a été pris lors d'une convention Flat-Earther.

Maintenant, imaginez la même chose pour le web. Supposons qu'une agence veuille effectuer un test pour déterminer quel index de lien est le meilleur, de sorte qu'ils regardent quelques centaines de sites à des fins de comparaison. Où ont-ils trouvé les sites? Clients passés? Ensuite, ils sont probablement biaisés vers des sites SEO-friendly et ne reflètent pas le web dans son ensemble. Des données clickstream? Ensuite, ils seraient biaisés vers des sites et des pages populaires – encore une fois, ne reflétant pas le web dans son ensemble!

Commencer avec un mauvais échantillon garantit de mauvais résultats.

Mais c'est encore pire. Des index comme Moz rapportent nos statistiques totales (nombre de liens ou nombre de domaines dans notre index). Cependant, cela peut être terriblement trompeur. Imaginez un restaurant qui prétendait avoir la plus grande sélection de vins au monde avec plus de 1 000 000 de bouteilles. Ils pourraient faire cette affirmation, mais ce ne serait pas utile s'ils avaient en réalité 1 000 000 du même type, ou seulement du cabernet, ou des demi-bouteilles. Il est facile de tromper lorsque vous jetez de gros chiffres. Au lieu de cela, il serait préférable d'avoir une sélection aléatoire des vins du monde et de mesurer si ce restaurant l'a en stock, et combien. Ce n'est qu'alors que vous aurez une bonne mesure de leur inventaire. La même chose est vraie pour mesurer les index de lien – c'est la théorie derrière ma méthodologie.

Malheureusement, il s'avère que l'obtention d'un échantillon aléatoire du web est vraiment difficile. La première intuition de la plupart d'entre nous chez Moz était de prendre un échantillon aléatoire des URL dans notre propre index. Bien sûr, nous ne pouvions pas – cela biaiserait l'échantillon vers notre propre indice, nous avons donc abandonné cette idée. La pensée suivante a été: "Nous connaissons toutes ces URL des SERPs que nous collectons – peut-être pourrions-nous les utiliser." Mais nous savions qu'ils seraient biaisés en faveur de pages de meilleure qualité. La plupart des URL ne se classent pour rien – grattez cette idée. Il était temps de regarder de plus près.

J'ai lancé Google Scholar pour voir si d'autres organisations avaient tenté ce processus et trouvé littéralement un article, produit par Google en juin 2000, intitulé " On Near-Uniform URL Sampling ." J'ai hâtivement sorti ma carte de crédit pour acheter le papier après avoir lu seulement la première phrase du résumé: " Nous considérons le problème de l'échantillonnage des URL uniformément au hasard sur le Web " C'était exactement ce dont j'avais besoin.

Pourquoi pas Common Crawl?

Beaucoup de SEO plus techniques lisant cela pourraient se demander pourquoi nous n'avons pas simplement sélectionné des URLs aléatoires d'un index tiers du web comme le fantastique Common Crawl ensemble de données. Il y a plusieurs raisons pour lesquelles nous avons envisagé, mais avons choisi de passer, sur cette méthodologie (bien qu'elle soit beaucoup plus facile à mettre en œuvre).

1. Nous ne pouvons pas être certains de la disponibilité à long terme de Common Crawl. Le premier million de listes (que nous avons utilisé dans le cadre du processus d'amorçage) est disponible à partir de plusieurs sources, ce qui signifie que si Quantcast disparaît, nous pouvons utiliser d'autres fournisseurs.
2. certain qu'il n'y a pas de biais implicite ou explicite en faveur de l'index de Moz, même marginal.
3. L'ensemble de données Common Crawl est assez volumineux et serait plus difficile à utiliser pour beaucoup de ceux qui tentent de créer leurs propres listes d'URL aléatoires . Nous voulions que notre processus soit reproductible.

Comment obtenir un échantillon aléatoire du Web

Le processus d'accès à un «échantillon aléatoire du Web» est assez fastidieux, mais l'essentiel est le suivant. Premièrement, nous commençons par un ensemble biaisé d'URL bien compris. Nous essayons ensuite de supprimer ou d'équilibrer ce biais, en faisant la meilleure liste d'URL pseudo-aléatoire possible. Enfin, nous utilisons une exploration aléatoire du Web en commençant par ces URL pseudo-aléatoires pour produire une liste finale d'URL qui s'approchent vraiment au hasard. Voici les détails complets.

1. Le point de départ: obtenir des URL de démarrage

Le premier gros problème avec l'obtention d'un échantillon aléatoire du web est qu'il n'y a aucun vrai point de départ aléatoire . Penses-y. À la différence d'un sac de billes où vous pourriez juste atteindre et en attraper aveuglément un au hasard, si vous ne connaissez pas déjà une URL, vous ne pouvez pas le prendre au hasard . Vous pourriez essayer de créer des URL aléatoires en forçant des lettres et des barres obliques les unes après les autres, mais nous savons que la langue ne fonctionne pas de cette façon, donc les URL seraient très différentes de ce que nous avons tendance à trouver sur le web. Malheureusement, tout le monde est obligé de commencer par un processus pseudo-aléatoire.

Nous devions faire un choix. C'était dur. Commençons-nous par un biais fort connu qui ne favorise pas Moz, ou partons-nous d'un biais plus faible connu qui le fait? Nous pourrions utiliser une sélection aléatoire de notre propre index pour le point de départ de ce processus, qui serait pseudo-aléatoire mais pourrait potentiellement favoriser Moz, ou nous pourrions commencer avec un index public plus petit comme le Quantcast Top Million qui serait fortement biaisée vers de bons sites.

Nous avons décidé d'utiliser ce dernier point de départ car les données de Quantcast sont:

1. Reproductible . Nous n'allions pas faire de la «sélection d'URL aléatoire» une partie de l'API Moz, nous avions donc besoin de quelque chose d'autre dans l'industrie. Quantcast Top Million est gratuit pour tout le monde.
2. Pas de préjugé envers Moz : Nous préférerions pécher par excès de prudence,
    même si cela signifiait plus de travail pour éliminer les préjugés.
3. Biais bien connu : Le biais inhérent au Top 1 000 000 de Quantcast a été facilement compris – ce sont des sites importants et nous devons supprimer ce biais.
4. Le biais de Quantcast est naturel: Tout graphique de lien partage déjà une partie du biais Quantcast (les sites puissants sont plus susceptibles d'être bien liés)

Dans cet esprit, nous avons sélectionné au hasard 10 000 domaines du Quantcast Top Million et commencé le processus de suppression des biais .

2. Choisir en fonction de la taille du domaine plutôt que de l'importance

Comme nous savions que le Quantcast Top Million était classé par trafic et que nous voulions atténuer ce biais, nous avons introduit un nouveau biais basé sur la taille du site. Pour chacun des 10 000 sites, nous avons identifié le nombre de pages sur le site selon Google en utilisant la commande "site:" et également saisi les 100 premières pages du domaine. Nous pouvons maintenant équilibrer le «biais d'importance» par rapport à un «biais de taille», ce qui reflète davantage le nombre d'URL sur le Web. Ce fut la première étape pour atténuer le biais connu des seuls sites de haute qualité dans le Top Million Quantcast.

3. Sélection de points de départ pseudo-aléatoires sur chaque domaine

L'étape suivante consistait à sélectionner aléatoirement des domaines à partir de 10 000, en privilégiant les sites plus importants. Lorsque le système sélectionne un site, il sélectionne aléatoirement parmi les 100 premières pages que nous avons recueillies sur ce site via Google. Cela aide à atténuer le biais d'importance un peu plus. Nous ne commençons pas toujours avec la page d'accueil. Bien que ces pages ont tendance à être des pages importantes sur le site, nous savons qu'ils ne sont pas toujours la page la plus importante, qui a tendance à être la page d'accueil. C'était la deuxième étape pour atténuer le biais connu. Les pages de qualité inférieure sur les sites plus importants équilibraient le biais intrinsèque aux données de Quantcast.

4. Explorer, ramper, ramper

Et voici où nous faisons notre plus grand changement. En fait, nous explorons le Web en commençant par cet ensemble d'URL pseudo-aléatoires pour produire l'ensemble réel des URL aléatoires. L'idée ici est de prendre toute la randomisation que nous avons construit dans l'ensemble d'URL pseudo-aléatoire et laissez les robots d'exploration cliquer sur des liens de façon aléatoire pour produire l'ensemble d'URL vraiment aléatoire. Le robot sélectionne un lien aléatoire à partir de notre analyse crawlset pseudo-aléatoire, puis démarre un processus de cliquage aléatoire des liens, chaque fois avec 10% de chances de s'arrêter et 90% de chances de continuer. Partout où le robot s'arrête, l'URL finale est placée dans notre liste d'URL aléatoires. C'est ce dernier ensemble d'URL que nous utilisons pour exécuter nos métriques. Nous générons environ 140 000 URL uniques à travers ce processus tous les mois pour produire notre ensemble de données de test

Ouf, maintenant quoi? Définir des métriques

Une fois que nous avons l'ensemble aléatoire d'URL, nous pouvons commencer à vraiment comparer les index de liens et à mesurer leur qualité, leur quantité et leur vitesse. Heureusement, dans sa quête pour «bien faire les choses», Moz m'a donné un généreux accès payant aux API des concurrents. Nous avons commencé par tester Moz, Majestic Ahrefs et SEMRush mais finalement abandonné SEMRush après leur partenariat avec Majestic.

Alors, à quelles questions pouvons-nous répondre maintenant que nous avons un échantillon aléatoire du web? Ceci est la liste de souhaits exacte que j'ai envoyé dans un courriel aux dirigeants sur le projet de lien à Moz:

1. Taille:
   • Quelle est la probabilité qu'une URL sélectionnée au hasard soit dans notre index par rapport aux concurrents?
   • Quelle est la probabilité qu'un domaine sélectionné au hasard se trouve dans notre index par rapport aux concurrents?
   • Quelle est la probabilité? un index rapporte le plus grand nombre de backlinks pour une URL?
   • Quelle est la probabilité qu'un index rapporte le plus grand nombre de domaines de liaison racine pour une URL?
   • Quelle est la probabilité qu'un index rapporte le plus grand nombre de backlinks pour un domain
   • Quelle est la probabilité qu'un index rapporte le plus grand nombre de domaines de liaison racine pour un domaine?
2. Speed:
   • Quelle est la probabilité que le dernier article d'un flux sélectionné au hasard soit dans notre index vs.
   • Quel est l'âge moyen d'une URL sélectionnée au hasard dans notre index par rapport aux concurrents?
   • Quelle est la probabilité que le meilleur backlink pour une URL sélectionnée au hasard soit toujours présent sur le web? est la probabilité que le meilleur backlink pour un rando mly domaine sélectionné est toujours présent sur le web?
3. Qualité:
   • Quelle est la probabilité que l'état d'un index d'une page sélectionnée au hasard (inclus ou non dans l'index) dans Google soit le même que le nôtre Quelle est la probabilité que l'état d'index d'une page sélectionnée au hasard dans Google SERPs soit le même que le nôtre par rapport aux concurrents?
   • Quelle est la probabilité que le statut d'un domaine sélectionné au hasard dans Google soit le même que le nôtre
   • Quelle est la probabilité que l'index d'un domaine sélectionné au hasard dans Google SERPs soit le même que le nôtre par rapport aux concurrents?
   • Dans quelle mesure notre indice se compare-t-il avec celui de Google exprimé comme "un rapport proportionnel de pages par
   • Dans quelle mesure nos métriques d'URL sont-elles en corrélation avec les classements Google américains par rapport à nos concurrents?

Réalité contre théorie

Malheureusement, comme toutes les choses dans la vie, j'ai dû faire quelques coupures. Il s'avère que les API fournies par Moz, Majestic, Ahrefs et SEMRush diffèrent de certaines manières importantes – dans la structure de coûts, les ensembles de fonctionnalités et les optimisations. Par souci de politesse, je ne mentionnerai que le nom du fournisseur quand il manque Moz. Regardons chacune des métriques proposées et voyons lesquelles nous pourrions garder et que nous avons dû mettre de côté …

1. Taille: Nous avons pu surveiller tous les 6 métriques de taille!
2. Speed:
   • Nous avons été en mesure d'inclure cette métrique Fast Crawl.
   • Quelle est la moyenne âge d'une URL sélectionnée au hasard dans notre index par rapport aux concurrents?
     Obtenir l'âge d'une URL ou d'un domaine n'est pas possible dans toutes les API, nous avons donc dû abandonner cette métrique.
   • Quelle est la probabilité le meilleur backlink pour une URL sélectionnée aléatoirement est toujours présent sur le web?
     Malheureusement, faire cela à l'échelle n'était pas possible car une API est prohibitive pour les tris de liens supérieurs et une autre extrêmement lente pour les grands sites. Nous espérons exécuter un ensemble de métriques de liens en direct indépendamment de notre collection de mesures journalières dans les mois à venir.
   • Quelle est la probabilité que le meilleur backlink pour un domaine sélectionné au hasard soit toujours présent sur le web? 19659081] Encore une fois, faire cela à l'échelle n'a pas été possible parce qu'une API coûte prohibitif pour les tris de liens supérieurs et qu'une autre était extrêmement lente pour les grands sites. Nous espérons pouvoir utiliser un ensemble de métriques de liens en direct indépendamment de notre collection quotidienne de mesures au cours des prochains mois.
3. Qualité:
   • Nous avons pu conserver cette statistique
   • Quelle est la probabilité que l'état d'une page sélectionnée au hasard dans Google SERPs soit le même que le nôtre
     Nous avons choisi de ne pas poursuivre en raison des besoins internes de l'API, en cherchant à ajouter bientôt.
   • Nous avons pu conserver cette métrique.
   • Quelle est la probabilité qu'un index soit sélectionné au hasard? dans Google SERPs est le même que le nôtre contre les concurrents?
     A choisi de ne pas poursuivre en raison des besoins API internes au début du projet, cherchant à ajouter bientôt.
   • Dans quelle mesure notre indice se compare-t-il à Google? comme un rapport proportionnel de pages par domaine par rapport à nos concurrents?
     A choisi de ne pas poursuivre en raison des besoins API internes.
   • Dans quelle mesure les statistiques de nos URL sont-elles en corrélation avec les classements Google américains par rapport à nos concurrents?
     Nous avons choisi de ne pas poursuivre en raison des fluctuations connues du DA / PA. La métrique n'aurait aucun sens tant que l'indice ne serait pas stable.

En fin de compte, je n'ai pas réussi à obtenir tout ce que je voulais, mais il me restait 9 métriques solides et bien définies.

Au sujet des liens actifs:

Dans l'intérêt d'être TAGFEE j'admettrai ouvertement que je pense que notre index a plus de liens supprimés que d'autres comme l'Ahrefs Live Index. Au moment de l'écriture, nous avons environ 30 trillions de liens dans notre index, 25 billions de dollars que nous croyons être en direct, mais nous savons que certaines proportions ne le sont probablement pas. Bien que je crois que nous avons le plus de liens en direct, je ne crois pas que nous ayons la plus forte proportion de liens actifs dans un index. Cet honneur ne va probablement pas à Moz. Je ne peux pas en être certain parce que nous ne pouvons pas le tester complètement et régulièrement, mais dans l'intérêt de la transparence et de l'équité, je me suis senti obligé de le mentionner. Je pourrais, cependant, consacrer un article plus tard à juste tester cette métrique pendant un mois et décrire la méthodologie appropriée pour le faire équitablement, car il s'agit d'une mesure trompeuse difficile à mesurer. Par exemple, si un lien est extrait d'une chaîne de redirections, il est difficile de dire si ce lien est encore en ligne, sauf si vous connaissez la cible du lien d'origine. Nous n'allions pas suivre de mesure si nous ne pouvions pas «faire les choses correctement», nous avons donc dû mettre des liens en direct comme mesure en attente pour le moment.

Mises en garde

Ne lisez plus avant de lire cette section. Si vous posez une question dans les commentaires qui montre que vous n'avez pas lu la section des mises en garde, je vais juste dire «lisez la section des mises en garde». Alors voilà …

• Il s'agit d'une comparaison des données qui reviennent via les API, et non dans les outils eux-mêmes. De nombreux concurrents proposent des types d'indices en direct, frais, historiques, etc. qui peuvent différer de manière importante. Ceci est juste une comparaison des données API en utilisant les paramètres par défaut.
• Certaines métriques sont difficiles à estimer, en particulier comme "si un lien est dans l'index", car aucune API – même Moz – n'a un appel qui vous dit ils ont vu le lien avant. Nous faisons de notre mieux, mais toutes les erreurs sont sur le fournisseur de l'API. Je pense que nous (Moz, Majestic et Ahrefs) devrions tous envisager d'ajouter un point de terminaison comme celui-ci.
• Les liens sont comptés différemment. Si les liens dupliqués sur une page sont comptés, si les redirections sont comptées, si les canoniques sont comptés (ce qui Ahrefs vient de changer récemment), etc. tous affectent ces métriques. Pour cette raison, nous ne pouvons pas être certains que tout est des pommes à pommes. Nous ne faisons que rapporter les données à leur valeur nominale.
• Par la suite, l'élément le plus important de tous ces graphiques et métriques est la direction . Comment les index se déplacent-ils les uns par rapport aux autres? Est-ce qu'on se rattrape, est-ce qu'un autre est en retard? Ce sont les questions auxquelles on répond le mieux.
• Les paramètres sont contradictoires. Pour chaque URL ou domaine aléatoire, un index de lien (Moz, Majestic, ou Ahrefs) obtient 1 point pour être le plus grand, pour lier avec le plus grand, ou pour être "correct". Ils obtiennent 0 points s'ils ne sont pas gagnants. Cela signifie que les graphiques ne totalisent pas 100 et ont tendance à exagérer les différences entre les index.
• Enfin, je vais tout montrer, les verrues et tout, même si c'était de ma faute. Je vais expliquer pourquoi certaines choses ont l'air bizarre sur les graphiques et ce que nous avons corrigé. Ce fut une grande expérience d'apprentissage et je suis reconnaissant de l'aide que j'ai reçue des équipes de soutien de Majestic et d'Ahrefs qui, en tant que client, ont répondu honnêtement et ouvertement à mes questions

Le tableau de bord des métriques

Nous suivons ces 9 mesures de base (mais avec des améliorations) depuis novembre 2017. Avec un œil attentif sur la qualité, la taille et la vitesse, nous avons méthodiquement construit un incroyable indice de backlink, non basé sur des chiffres au lieu de mesures complexes et mesurées. Passons en revue chacune de ces mesures maintenant.

La taille compte

C'est le cas. Admettons-le. La taille minuscule de l'index de Mozscape a été une limitation pendant des années. Peut-être qu'un jour nous écrirons un long post sur tous les efforts que Moz a faits pour faire grandir l'indice et quels sont les problèmes qui se dressent sur notre chemin, mais c'est un post pour un autre jour. La vérité est, autant que la qualité compte, la taille est énorme pour un certain nombre de cas d'utilisation spécifiques pour un index de lien. Voulez-vous trouver tous vos mauvais liens? Plus c'est mieux. Voulez-vous trouver beaucoup d'opportunités de liens? Plus c'est mieux. Nous avons donc mis au point un certain nombre de paramètres pour nous aider à déterminer où nous étions par rapport à nos concurrents. Voici chacune de nos métriques de taille.

L'index a l'URL

Quelle est la probabilité qu'une URL sélectionnée au hasard se trouve dans notre index par rapport aux concurrents?

C'est l'une de mes métriques préférées parce que je pense que c'est un reflet de la taille de l'index. Il répond à la question simple: "si nous avons saisi une URL aléatoire sur le web, quelle est la probabilité qu'un index le sache?" Cependant, vous pouvez voir ma courbe d'apprentissage dans le graphique (j'ai fait une fausse déclaration de l'API Ahrefs en raison d'une erreur de ma part) mais une fois corrigé, nous avons eu un bon reflet des index. Permettez-moi de répéter ceci – ce sont des comparaisons dans les API, pas dans les outils web eux-mêmes. Si je me souviens bien, vous pouvez obtenir plus de données sur les rapports en cours dans Majestic, par exemple. Cependant, je pense que cela démontre que le nouvel explorateur de liens de Moz est un concurrent sérieux, sinon le plus grand, car nous avons mené dans cette catégorie tous les jours sauf un. Au moment d'écrire ce post, Moz est en train de gagner.

Index de domaine

Quelle est la probabilité qu'un domaine sélectionné au hasard se trouve dans notre index par rapport aux concurrents?

Quand j'ai dit que je montrerais "des verrues et tout", je le pensais. Déterminer si un domaine est dans un index n'est pas aussi simple que vous le pensez. Par exemple, un domaine a peut-être des pages dans l'index, mais pas la page d'accueil. Eh bien, il m'a fallu un certain temps pour comprendre celui-ci, mais en Février de cette année, je l'avais baissé.

L'échelle de ce graphique est également importante à noter. La variation est comprise entre 99,4 et 100% entre Moz, Majestic et Ahrefs au cours des derniers mois. Cela indique à quel point les index de liens sont proches des domaines racine. Majestic a toujours eu tendance à gagner cette métrique avec une couverture de près de 100%, mais vous devez sélectionner 100 domaines aléatoires pour en trouver un que Moz ou Ahrefs n'a pas d'information. Cependant, la croissance continue de Moz nous a permis de rattraper le retard. Bien que les index soient très proches, Moz est en train de gagner.

Backlinks par URL

Quel index a le nombre de liens le plus élevé pour une URL sélectionnée au hasard?

C'est une métrique difficile à cerner. Malheureusement, il n'est pas facile de déterminer quels backlinks devraient compter et ce qui ne devrait pas. Par exemple, imaginez qu'une URL comporte une page qui la lie, mais cette page inclut ce lien 100 fois. Est-ce 100 backlinks ou un? Eh bien, il s'avère que les différents indices de liens mesurent probablement ces types de scénarios différemment et obtenir une définition exacte de chacun est comme tirer les dents parce que la définition est si compliquée et il y a tellement de cas limites. En tout cas, je pense que c'est un bon exemple d'où nous pouvons montrer l'importance de la direction. Quelles que soient les statistiques, Moz et Majestic rattrapent Ahrefs, qui a été le leader pendant un certain temps. Au moment d'écrire ce post, Ahrefs est en train de gagner.

Domaines de liens racines par URL

Quel index indique le nombre de RLD le plus élevé pour une URL sélectionnée au hasard?

Simple, n'est-ce pas? Non, même cette métrique a ses nuances. Qu'est-ce qu'un domaine de liaison racine? Les sous-domaines comptent-ils s'ils se trouvent sur des sites de sous-domaines tels que Blogspot ou WordPress.com? Si oui, combien y a-t-il de sites sur le web qui devraient être traités de cette façon? Nous avons utilisé une méthodologie apprise par machine basée sur des enquêtes, des données SERP et des données de liens uniques pour déterminer notre liste, mais chaque concurrent le fait différemment. Ainsi, pour cette métrique, la direction compte vraiment. Comme vous pouvez le voir, Moz a régulièrement rattrapé son retard et, au moment d'écrire aujourd'hui, Moz est finalement en train de gagner.

Backlinks par domaine

Quel index indique le nombre le plus élevé de backlinks pour un domaine sélectionné aléatoirement?

Cette mesure n'était pas gentille avec moi, car j'ai trouvé une terrible erreur dès le début. (Pour les autres techniciens qui lisent ceci, je stockais les compteurs de backlink comme INT (11) plutôt que BIGINT, ce qui causait beaucoup de liens pour les grands domaines quand ils étaient plus grands que la taille maximale. .) Néanmoins, Majestic a volé le spectacle sur cette mesure pendant un petit moment, bien que l'histoire soit plus profonde que cela. Leur domination est tellement aberrante qu'elle doit être expliquée.

L'une des décisions les plus difficiles à prendre par une entreprise en ce qui concerne son index backlink est de savoir comment gérer le spam. D'une part, le spam est cher à l'index et probablement ignoré par Google. D'un autre côté, il est important que les utilisateurs sachent s'ils ont reçu des tonnes de liens de spam. Je ne pense pas qu'il y ait une réponse correcte à cette question; chaque indice a juste à choisir. Un examen attentif de la raison pour laquelle Majestic gagne (et continue à augmenter leur avantage) est à cause d'un réseau de spam clone Wikipedia particulièrement néfaste. Tous les sites avec des backlinks de Wikipédia obtiennent des tonnes de liens de ce réseau, ce qui entraîne une augmentation rapide de leur nombre de backlinks. Si vous êtes inquiet au sujet de ces types de liens, vous devez jeter un oeil à Majestic et chercher des liens se terminant principalement par .space ou .pro, y compris des sites comme tennis-fdfdbc09.pro, troll-warlord-64fa73ba.pro, et badminton-026a50d5.space. Lors de mes derniers tests, il y a plus de 16 000 domaines de ce type dans le réseau de spam de l'index de Majestic. Majestic gagne cette mesure, mais à des fins autres que la recherche de réseaux de spams, ce n'est peut-être pas le bon choix.

Lier les domaines racine par domaine

Quel index indique le nombre le plus élevé de LRD pour un domaine sélectionné au hasard?

OK, celui-ci m'a pris du temps pour bien faire les choses. Au milieu de ce graphique, j'ai corrigé une erreur importante où je regardais les domaines uniquement pour le domaine racine sur Ahrefs plutôt que le domaine racine et tous les sous-domaines. C'était injuste pour Ahrefs jusqu'à ce que je corrige finalement tout en février. Depuis lors, Moz a augmenté son index de manière agressive, Majestic a ramassé les comptes de LRD à travers le réseau précédemment discuté mais s'est stabilisé, et Ahrefs est resté relativement stable en taille. En raison de la nature «contradictoire» de ces mesures, cela donne l'impression fausse qu'Ahrefs baisse de façon spectaculaire. Ils ne le sont pas. Ils sont encore énormes, tout comme Majestic. La vraie recette est directionnelle: Moz se développe de façon spectaculaire par rapport à leurs réseaux. Au moment d'écrire ce post, Moz est en train de gagner.

Speed ​​

Être le «premier à savoir» est un élément important dans presque toutes les industries et avec les index de liens, il n'en est pas de même. Vous voulez savoir dès que possible quand un lien monte ou descend et à quel point ce lien est si vous pouvez répondre si nécessaire. Voici notre métrique de vitesse actuelle.

FastCrawl

Quelle est la probabilité que le dernier message d'un ensemble de fils RSS sélectionnés au hasard soit indexé?

Contrairement aux autres métriques discutées, l'échantillonnage ici est un peu différent. Au lieu d'utiliser la randomisation ci-dessus, nous faisons une sélection aléatoire parmi plus d'un million de flux RSS connus pour trouver leur dernier message et vérifier s'ils ont été inclus dans les différents index de Moz et des concurrents. Bien qu'il y ait quelques erreurs dans ce graphique, je pense qu'il n'y a qu'un seul message clair. Ahrefs a raison à propos de leurs robots. Ils sont rapides et ils sont partout. Alors que Moz a augmenté notre couverture de manière spectaculaire et rapide, il a à peine bougé dans cette métrique FastCrawl

Maintenant, vous pouvez vous demander, si Ahrefs est tellement plus rapide à ramper, comment Moz peut-il rattraper? Eh bien, il y a quelques réponses, mais le plus important est probablement que les nouvelles URL ne représentent qu'une fraction du web. La plupart des URL ne sont pas nouvelles. Supposons que deux index (un nouveau, un ancien) contiennent un ensemble d'URL qu'ils envisagent d'explorer. Les deux peuvent prioriser les URL sur des domaines importants qu'ils n'ont jamais vu auparavant. Pour l'index plus grand et plus ancien, ce pourcentage sera plus faible car il a été très rapide. Ainsi, au cours de la journée, un pourcentage plus élevé de l'analyse de l'ancien index sera consacré aux pages de rééchantillonnage déjà connues. Le nouvel index peut consacrer plus de son potentiel d'exploration aux nouvelles URL.

Cependant, il met maintenant la pression sur Moz pour améliorer l'infrastructure d'exploration alors que nous rattrapons et dépassons Ahrefs dans certaines mesures de taille. A partir de ce post, Ahrefs gagne la métrique FastCrawl.

Qualité

OK, maintenant nous parlons ma langue. C'est la chose la plus importante, à mon avis. Quel est le point de faire un graphique de lien pour aider les gens avec SEO s'il n'est pas similaire à Google? Bien que nous ayons dû réduire temporairement certaines mesures, nous en avons trouvé quelques-unes qui sont vraiment importantes et méritent d'être examinées.

Matches d'index de domaine

Quelle est la probabilité qu'un domaine aléatoire partage le même statut d'index dans Google et un index de lien?

Domain Index Matches cherche à déterminer quand un domaine partage le même statut d'index avec Google comme dans l'un des index de liens concurrents. Si Google ignore un domaine, nous voulons ignorer un domaine. Si Google indexe un domaine, nous souhaitons indexer un domaine. Si nous avons un domaine que Google n'a pas, ou vice versa, c'est mauvais.

Ce graphique est un peu plus difficile à lire en raison de l'échelle (les premiers jours de suivi étaient des échecs), mais ce que nous voyons réellement est une différence statistiquement insignifiante entre Moz et nos concurrents. We can make it look more competitive than it really is if we just calculate wins and losses, but we have to take into account an error in the way we determined Ahrefs index status up until around February. To do this, I show wins/losses for all time vs. wins/losses over the last few months.

As you can see, Moz wins the "all time," but Majestic has been winning more over the last few months. Nevertheless, these are quite insignificant, often being the difference between one or two domain index statuses out of 100. Just like the Index Has Domain metric we discussed above, nearly every link index has nearly every domain, and looking at the long-term day-by-day graph shows just how incredibly close they are. However, if we are keeping score, as of today (and the majority of the last week), Moz is winning this metric.

Domain URL Matches

What is the likelihood a random URL shares the same index status in Google as in a link index?

This one is the most important quality metric, in my honest opinion. Let me explain this one a little more. It's one thing to say that your index is really big and has lots of URLs, but does it look like Google's? Do you crawl the web like Google? Do you ignore URLs Google ignores while crawling URLs that Google crawls? This is a really important question and sets the foundation for a backlink index that is capable of producing good relational metrics like PA and DA.

This is one of the metrics where Moz just really shines. Once we corrected for an error in the way we were checking Ahrefs, we could accurately determine whether our index was more or less like Google's than our competitors. Since the beginning of tracking, Moz Link Explorer has never been anything but #1. In fact, we only had 3 ties with Ahrefs and never lost to Majestic. We have custom-tailored our crawl to be as much like Google as possible, and it has paid off. We ignore the types of URLs Google hates, and seek out the URLs Google loves. We believe this will pay huge dividends in the long run for our customers as we expand our feature set based on an already high-quality, huge index.

The Link Index Olympics

Alright, so we've just spent a lot of time delving into these individual metrics, so I think it's probably worth it to put these things into an easy-to-understand context. Let's pretend for a moment that this is the Link Index Olympics, and no matter how much you win or lose by, it determines whether you receive a gold, bronze or silver medal. I'm writing this on Wednesday, April 25th. Let's see how things play out if the Olympics happened today:

As you can see, Moz takes the gold in six of the nine metrics we measure, two silvers, and one bronze. Moreover, we're continuing to grow and improve our index daily. As most of the above graphs indicate, we tend to be improving relative to our competitors, so I hope that by the time of publication in a week or so our scores will even be better. But the reality is that based on the metrics above, our link index quality, quantity, and speed are excellent. I'm not going to say our index is the best. I don't think that's something anyone can really even know and is highly dependent upon the specific use case. But I can say this — it is damn good. In fact, Moz has won or tied for the "gold" 27 out of the last 30 days.

What's next?

We are going for gold. All gold. All the time. There's a ton of great stuff on the horizon. Look forward to regular additions of features to Link Explorer based on the data we already have, faster crawling, and improved metrics all around (PA, DA, Spam Score, and potentially some new ones in the works!) There's way too much to list here. We've come a long way but we know we have a ton more to do. These are exciting times!

A bit about DA and PA

Domain Authority and Page Authority are powered by our link index. Since we're moving from an old, much smaller index to a larger, much faster index, you may see small or large changes to DA and PA depending on what we've crawled in this new index that the old Mozscape index missed. Your best bet is just to compare yourselves to your competitors. Moreover, as our index grows, we have to constantly adjust the model to address the size and shape of our index, so both DA and PA will remain in beta a little while. They are absolutely ready for primetime, but that doesn't mean we don't intend to continue to improve them over the next few months as our index growth stabilizes. Merci!

Quick takeaways

Congratulations for getting through this post, but let me give you some key takeaways:

1. The new Moz Link Explorer is powered by an industry-leading link graph and we have the data to prove it.
2. Tell your data providers to put their math where their mouth is. You deserve honest, well-defined metrics, and it is completely right of you to demand it from your data providers.
3. Doing things right requires that we sweat the details. I cannot begin to praise our leadership, SMEs, designers, and engineers who have asked tough questions, dug in, and solved tough problems, refusing to build anything but the best. This link index proves that Moz can solve the hardest problem in SEO: indexing the web. If we can do that, you can only expect great things ahead.

Thanks for taking the time to read! I look forward to answering questions in the comments or you can reach me on Twitter at @rjonesx.

Also, I would like to thank the non-Mozzers who offered peer reviews and critiques of this post in advance — they do not necessarily endorse any of the conclusions, but provided valuable feedback. In particular, I would like to thank Patrick Stox of IBMJR Oakes of Adapt PartnersAlexander Darwin of HomeAgencyPaul Shapiro of Catalyst SEMthe person I most trust in SEO, Tony Spencerand a handful of others who wished to remain anonymous.