Si vous êtes dans le jeu SEO depuis assez longtemps (et surtout dans un scénario agence / client), vous connaissez le jeu du «poke the bear» auquel nous jouons tous régulièrement avec les moteurs de recherche : faites un changement sur le site, attendez que les moteurs de recherche prennent le changement, puis surveillez les effets positifs, neutres ou négatifs. Si vous avez de la chance, vous avez des années d’expérience ou une bonne tutelle, et vous savez que l’ours aime vraiment que vous vous grattiez derrière son oreille gauche. Ou vous modifiez le site avec un abandon sauvage pour constater que piquer l’ours dans les yeux est un voyage garanti aux urgences, et vous aurez de la chance si votre classement se rétablit un jour.
Mais la réalité des expériences de nombreux référenceurs est quelque part entre les deux. Une fois que nous avons effectué les optimisations des meilleures pratiques de base, nous passons ensuite au domaine de l’hypothèse : essayer de deviner ce qui fonctionnera pour nos sites et nos niches en nous basant sur notre expérience antérieure, l’analyse SERP, l’analyse concurrentielle et les fragments d’un million de blog SEO des messages qui flottent à l’arrière de notre cerveau. Sur la base de ces hypothèses, nous apportons des modifications progressives à nos sites et «poussons l’ours». Parfois, le «GoogleBear» est affable et gratifiant. D’autres fois, c’est assez grincheux. Parfois, il est lent à répondre. D’autres fois, il réagit à une vitesse fulgurante. Et plusieurs fois, il regarde en arrière sans émotion et clignant des yeux, comme pour se demander pourquoi nous pensions que tout cela ferait une différence en premier lieu.
Le sort des tests SEO
Si vous êtes comme moi, vous avez souhaité plus d’une fois qu’il y ait un meilleur moyen de faire des tests SEO à un niveau évolutif. Ou une façon moins douloureuse de pousser le GoogleBear.
Sur des sites plus petits et personnalisés, apporter des modifications pour le référencement et tester les résultats peut être assez simple. Plus la portée du site est petite, généralement moins il est modélisé, ce qui le rend plus malléable aux modifications du contenu, du balisage, de la structure, de la navigation et d’autres éléments. Vous effectuez ces changements, puis surveillez les positions SERP pour un impact positif. Chaque fois que votre expérimentation SEO vous induit en erreur, il est relativement facile de corriger le cours en annulant les modifications sur quelques pages.
Plus le site devient grand, plus le backend est complexe et les pages sont de plus en plus modélisées afin de gérer le volume de contenu. Chez ROI Revolution, nous travaillons principalement avec des sites Web de commerce électronique contenant des milliers à des millions de produits. Si je souhaite tester une nouvelle modification sur une page de produit pour voir si elle a un impact positif sur le référencement, je vais probablement devoir tester cette modification sur toutes les pages de produit en raison de sa nature de modèle. Les changements appliqués à ces sites peuvent être une affaire de «tout ou rien» avec des conséquences considérables (pour le meilleur ou pour le pire) lorsque, par exemple, un quart de million de pages ont soudainement un nouveau format basé sur mon hypothèse. Si mon hypothèse est correcte, alors ce sont tous des cinq hauts et des arcs-en-ciel. Mais si mon hypothèse est erronée, la réindexation de toutes les pages de produits peut prendre un certain temps après avoir annulé les modifications qui m’ont causé des problèmes en premier lieu. Google est rapide à retirer les gains mais tarde à annuler les pertes.
Ce n’est qu’un exemple des maux de tête qui peuvent découler des tests d’améliorations du référencement à grande échelle sur de grands sites. Le problème n’est pas que nous ne pouvons pas le faire évoluer, c’est que nous devons le faire évoluer complètement ! Nous ferions mieux de tester une plus petite partie de nos pages pour déterminer si elles génèrent des résultats positifs avant d’appliquer ces modifications à toutes les pages.
Un point de vue unique – Un aperçu des tests A / B du site Web
En tant que dirigeant du groupe de services d’optimisation de site Web de ROI Revolution, j’ai eu la chance de diriger des équipes spécialisées dans deux domaines très uniques du marketing en ligne : le référencement (optimisation des moteurs de recherche, que vous connaissez probablement) et CRO (optimisation du taux de conversion ). Ces deux disciplines visent à optimiser l’expérience utilisateur sur un site Web pour atteindre un résultat souhaitable. L’objectif de l’équipe CRO est d’augmenter la probabilité d’une action spécifique de l’utilisateur (pour les sites de commerce électronique, il s’agit généralement de l’achèvement d’un achat ou d’une action plus tôt dans l’entonnoir). L’objectif de l’équipe SEO est également d’augmenter la probabilité d’une action spécifique de l’utilisateur. Mais dans leur cas, «l’utilisateur» est un moteur de recherche, et le but est que le moteur de recherche classe bien le site.
Avec le référencement, il y a évidemment des implications pour les utilisateurs humains des optimisations que vous apportez à votre site, mais aux fins de cette discussion, nous allons supposer que tout ce que vous faites pour bien vous classer est également bon pour les utilisateurs humains de votre site..
Test A / B du site Web
La majorité du travail que nous faisons pour nos clients du côté CRO est de créer et d’exécuter des stratégies d’expérimentation utilisateur. La manière la plus courante de procéder consiste à utiliser des plates-formes de test A / B, telles que AB Tasty, VWO ou Google Optimize.
Si vous n’êtes pas familier avec les tests A / B, cela fonctionne en transférant tout le trafic vers une page spécifique (ou un type de page) et en offrant l’expérience normale à la moitié des utilisateurs, tandis que l’autre moitié rencontre une expérience différente et modifiée :
Illustration simple d’un flux de trafic de test SEO A / B. En réalité, vous pouvez diviser le trafic en pourcentages presque infinis sur plusieurs expériences modifiées différentes, mais le test A / B classique 50% / 50% vous donne l’exemple le plus simple du fonctionnement de ce test.
La base de ce type d’expérimentation est de faire l’hypothèse d’une expérience de site dans laquelle l’utilisateur est plus susceptible de mener à bien une action (comme terminer la commande sur un site de commerce électronique). Ensuite, vous modifiez votre expérience sur le site en fonction de cette hypothèse et diffusez cette expérience modifiée contre une partie de vos utilisateurs. Les types de modifications que vous apportez à votre site peuvent aller du simple (une bannière en haut de la page annonçant la livraison gratuite) au très complexe (reconstruction totale du flux de paiement) et tout le reste.
Les plates-formes de test utilisent une variété de modèles statistiques afin de déterminer si le résultat de votre test est fiable. Ceci est généralement appelé «signification statistique». Si le résultat du test est statistiquement significatif, vous êtes plus sûr que le résultat du test n’a pas été le fruit du hasard.
Si votre hypothèse est correcte (votre test a gagné), vous pouvez alors implémenter en permanence vos modifications testées sur votre site, en étant convaincu qu’elles auront un impact positif. Si votre hypothèse était incorrecte (votre test a été perdu), vous vous êtes sauvé d’une erreur potentiellement coûteuse qui semblait être une bonne idée à l’époque.
C’est un excellent moyen de prouver la valeur des modifications avant de les apporter, ce qui est d’une grande importance lorsque le moindre changement de taux de conversion peut avoir un impact sur des millions de dollars de revenus chaque mois.
Un avantage marginal de la plupart des plates-formes de test A / B de sites Web
En plus d’être simplement un moyen formidable d’obtenir des informations sur les déclencheurs de motivation et les points de friction de vos utilisateurs, un avantage supplémentaire de bon nombre de ces plates-formes de test A / B est qu’elles fonctionnent indépendamment de la file d’attente de développement de votre entreprise (ou de votre client), ce qui vous permet de aller plus vite avec moins de paperasse.
Traditionnellement, vous avez besoin des approbations de votre équipe de développement et d’autres parties prenantes pour intégrer les modifications du site dans vos sprints de développement, puis vous devez attendre que votre tour apparaisse dans la file d’attente avant de voir vos modifications mises en ligne sur le site. En utilisant des méthodes de script côté client, les plates-formes de test vous permettent de créer du code (via des éditeurs WYSIWYG ou des éditeurs de code) qui s’exécute lorsque la page se charge dans le navigateur de l’utilisateur. Le code de la plate-forme de test s’exécute lors de la création de la page dans le navigateur et réorganise la page en quelques millisecondes. L’utilisateur final n’est pas plus avisé de ce changement, et votre équipe de développement n’a pas à lever le petit doigt.
Si l’expérience de test modifiée est gagnante, ce n’est qu’alors que vous impliquez vos développeurs – et vous pouvez facilement leur montrer l’impact sur les revenus de vos suggestions de modifications de site Web.
Application des principes de test A / B au référencement
Si vous êtes comme moi, la première fois que j’ai regardé le travail de référencement que nous faisions et que je l’ai comparé au travail de CRO que nous faisions, je me suis dit: «Bingo. Faisons des tests fractionnés A / B SEO pour déterminer si une tactique fonctionnera avant de la déployer à grande échelle. »
Bien que cela semble bien en théorie, il y a quelques pierres d’achoppement:
Une base d’utilisateurs de 1
Ce qui rend possible le test A / B traditionnel des sites Web, c’est la taille de la population (c’est-à-dire le nombre de personnes participant au test), qui détermine la durée d’un test. Une fois qu’un nombre suffisant de personnes ont participé au test, nous pouvons parvenir à une conclusion statistiquement significative sur l’impact de notre test.
Le problème est que si nous exécutons un test pour déterminer l’impact d’une modification de site sur l’algorithme de classement de Google, alors il n’y a qu’un seul « utilisateur » dans notre test: Googlebot. Cela en soi fait exploser toute l’idée de faire des tests A / B traditionnels pour le référencement.
Alors, comment pouvons-nous contourner cela?
Tests A / B basés sur les robots
Si vous vous souvenez de la présentation précédente sur les tests A / B, nous avons besoin d’une expérience de «contrôle» et d’au moins une expérience de «variante» (c’est-à-dire la nouvelle modification que nous testons). Ensuite, nous avons besoin d’une page ou de pages sur lesquelles tester, et nous avons besoin d’une grande population d’utilisateurs pour montrer le contrôle et la variation. Nous comparons ensuite les performances des deux expériences l’une par rapport à l’autre :
Illustration simple d’un flux de trafic de test SEO A / B.
Avec le test fractionné SEO, vous devez retourner le modèle sur sa tête. Comme vous ne pouvez pas tester une population d’utilisateurs, vous devrez tester une population de pages à la place. Plutôt que de diviser vos utilisateurs entre deux expériences, vous diviserez les pages de manière égale, appliquerez une expérience différente (aka modification) à chaque groupe de pages, puis alimenterez ces pages dans le moteur de recherche via sa routine d’exploration normale :
Illustration simple d’un processus de test fractionné SEO. Cela ressemble beaucoup aux tests A / B pour vos utilisateurs humains, sauf que ce n’est pas le cas.
Vous surveillerez ensuite le classement et le trafic des deux expériences sur trente jours, par rapport à la base de référence actuelle. Si les pages qui sont incluses dans le groupe d’expérience modifié voient des gains de classement positifs sur la durée de l’expérience (et que le groupe de contrôle est stable ou vers le bas), vous pouvez être sûr de mettre en œuvre ces modifications à votre modèle, en appliquant le changement à tous pages similaires sur votre site.
Implémentation côté serveur
Dans mon aperçu du fonctionnement des tests A / B, j’ai mentionné à quel point l’utilisation des tests côté client présente un avantage marginal : cela peut vous empêcher d’impliquer vos développeurs chaque fois que vous souhaitez tester un changement.
En raison des capacités historiquement faibles des moteurs de recherche à restituer JavaScript, toute sorte de test A / B utilisant la méthode de test A / B basée sur les robots décrite ci-dessus a été une tâche onéreuse. Plutôt que d’utiliser la simple méthode de script » côté client » comme la plupart des plates-formes de test axées sur l’utilisateur, toute sorte d’outil de test SEO A / B nécessitait auparavant une intégration dans le serveur et / ou CDN de votre site Web afin d’apporter des modifications aux pages avant qu’elles ont été envoyés «sur le fil». Souvent, ces solutions étaient locales et maladroites. Certains fournisseurs de services sont entrés sur le marché pour proposer des solutions de test SEO, mais le rendu côté serveur pour les tests était toujours nécessaire, introduisant les mêmes maux de tête que les solutions locales.
La beauté des bots à feuilles persistantes
Dans les temps anciens du référencement, les moteurs de recherche ne «rendaient» pas les pages Web. Ils ont simplement parcouru le code source et pris des décisions de classement basées sur ces informations. Finalement, les moteurs de recherche ont réalisé qu’ils devaient vraiment prendre des décisions en fonction de ce que les utilisateurs finaux voyaient réellement, et pas seulement de ce qui était inséré dans (ou omis) de la réponse du code source du serveur. Pour résoudre ce problème, ils ont commencé à afficher des pages Web de la même manière qu’un navigateur et ont utilisé cette version visuellement rendue d’une page pour prendre des décisions de classement.
Alors que de plus en plus de sites ont commencé à utiliser JavaScript pour créer ce que les utilisateurs finaux voyaient dans leurs navigateurs, les moteurs de recherche avaient du mal à suivre. Pendant très longtemps, Google s’est appuyé sur des versions obsolètes de Chrome pour afficher la page. En tant que référenceurs, nous jouions constamment à un jeu de taupe en ce qui concerne les clients utilisant des JS de pointe sur leurs sites, mais Google ne pouvait pas «voir» le contenu car il ne pouvait pas le rendre correctement.
En 2019, Google a annoncé que le moteur de rendu de GoogleBot allait être «permanent». Cela signifie que chaque fois que le navigateur Chrome de Google est mis à jour, GoogleBot utilisera la version la plus récente du navigateur comme moteur de rendu. Peu de temps après, Bing a annoncé que BingBot serait également permanent et utiliserait toujours le moteur de rendu le plus récent du navigateur Edge.
C’ÉTAIT UNE ÉNORME AFFAIRE pour les tests A / B pour le référencement.
Si les moteurs de rendu de BingBot et de GoogleBot sont permanents, nous pouvons être sûrs que presque tous les JavaScript que nous exécutons sur un site via un outil de test seront reconnus par les moteurs de recherche.
Cela signifie que les mêmes mécanismes de codage côté client qui rendent les tests A / B axés sur l’utilisateur si faciles à mettre en œuvre peuvent désormais être mis à la disposition des testeurs SEO A / B !
Attendez-vous à un boom de test SEO A / B
Je serai honnête. Parce que j’ai passé près de 15 ans à me demander comment les moteurs de recherche ne pouvaient pas gérer correctement JavaScript, lorsque les bots à feuilles persistantes ont été annoncés, je ne voulais pas le croire. Les idées préconçues sont mortes dans le monde du référencement. Relier les points entre les bots à feuilles persistantes et la possibilité de faire plus de tests de référencement n’était pas une conclusion évidente pour les mêmes raisons.
Cependant, compte tenu de ce que j’ai vu au cours de l’année dernière avec GoogleBot capable de rendre la plupart du JavaScript correctement au chargement de la page, je pense que nous sommes à un véritable tournant dans les tests de référencement. Je suis personnellement très heureux que des entreprises comme Semrush lancent des plates-formes de test A / B côté client comme SplitSignal. Mon expérience dans le secteur des CRO a construit ma foi dans les tests côté client, qui se déroulent avec succès depuis de nombreuses années maintenant. Les robots des moteurs de recherche évoluant dans l’air du temps, il est tout à fait logique de combiner la méthodologie de test A / B basée sur les robots avec une plateforme de test côté client.
Les tests A / B basés sur les robots peuvent être exagérés pour les petits sites. Mais pour les grands sites basés sur un CMS comme les plates-formes de commerce électronique et les grands centres de contenu avec des dizaines de milliers (et plus) de pages, c’est un excellent moyen d’être encore plus stratégique avec nos stratégies d’optimisation.
Ou, en d’autres termes, rendez le jeu de «piquer l’ours» beaucoup plus gratifiant !
Si tu es intéressé
