Les tests de non-régression pour la pratique du SEO

Les SEOs doivent toujours faire face aux mêmes problèmes : Parmi ceux-ci, les modifications intempestives sur des éléments qui comptent pour le ranking peut être stressant. Surtout quand la personne qui fait la modification ne prévient pas (oui, je sais, c’est dans la définition d’intempestif), fait tout de travers, n’est pas ou mal formé au SEO, ou globalement, surtout, n’est pas au courant de l’impact de ses actions.

C’est un problème qu’on rencontre fréquemment dans les cas de figures du SEO in house, qui doit mener un combat de tous les instants car de nombreux utilisateurs ont des droits d’édition sur un site internet sans connaître les implications de leurs modifications. C’est un problème qu’on peut retrouver dans une activité de conseil, car le client, quelle que soit sa taille, ne prends pas le temps d’indiquer les modifications qu’il va faire à son consultant.

En SEO, la stabilité des éléments qui comptent est un vrai sujet. Et pour éviter que Google ne découvre un élément instable, ou pour réagir au plus vite afin d’éviter un déclassement, il y a une solution : les tests de non-régression.


Qu’est-ce qu’un test de non-régression ?

Dans le cadre du développement, un test de non-régression (TNR) est une méthodologie pour vérifier l’état attendu d’un comportement ou d’un élément important, afin d’assurer la stabilité de cet élément ou de ce comportement.

Qu’est-ce qu’un test de non-régression dans le cadre du SEO ?

Pour le SEO, il y a plein d’éléments à tester. La stabilité étant un élément clé pour une url, un test de non-régression permet d’éviter les erreurs, et d’être prévenu en cas de problèmes, ou au mieux d’identifier la date à laquelle un problème est survenu. Dans le cadre d’un accompagnement SEO, c’est assez important de ne pas oublier ce genre d’atouts qui permettent de prévenir des comportements involontaires du point de vue de Google. On peut donc coupler ces tests avec des alertes mail qui permettront de prévenir en cas de problèmes.

Quels éléments peut-on tester pour vérifier la non-régression de signaux importants pour le SEO ?

Il y a beaucoup d’éléments qu’on peut tester, mais les principaux sont les basiques : la balise title, l’attribut description de la balise méta, les H1 à H6…* Mais également les liens qui viennent de l’extérieur, car leur présence est importante pour l’autorité de votre page, spécifiquement s’ils sont obtenus à l’issue d’une stratégie d’acquisition ou d’un partenariat.

Comment utiliser donc un script de non-régression ?

Sur la partie on-site, la fréquence du script de non-régression devrait dépendre de la fréquence de mise à jour du site de façon générale. Si le site a beaucoup de contributeurs réguliers, et que ceux-ci publient, modifient, ou suppriment des pages plusieurs fois par semaine, une fréquence élevée d’actualisation implique une fréquence élevée de tests de vérification. On peut donc contrôler la non-régression plusieurs fois par jour sur les éléments stratégiques d’une url (ou plusieurs) pour savoir à peu près quand un problème survient.

Dans le cadre d’une migration, les tests de non-régression sont particulièrement utiles pour suivre l’impact du changement de version du site web, même si ce n’est que le header* ou le footer* qui change, ça peut avoir des impacts.

Sur la partie off site, spécifiquement pour vérifier la présence d’un lien, l’exécution du script peut avoir lieu plusieurs fois par mois, une fois par semaine, même une fois par jour si vous le souhaitez. Ici tout dépend de votre capacité à stocker cette information.

Comment doit se composer un script de non-régression ?

Globalement il y a 2 parties sur la non-régression, il faut penser comme un crawler web ou une application qui simule des tests à la manière d’un bot de moteur de recherche :
La partie de récolte de la donnée, et la partie d’interprétation.
Pour la récolte, c’est assez simple. Il vous suffit de récupérer l’information à intervalles réguliers et de stocker cette information dans une base de données que vous allez pouvoir exploiter en parallèle.

Pour l’exploitation et l’interprétation de cette donnée, c’est un peu plus complexe, car selon les éléments que vous vérifiez ou que vous surveillez, une simple mise à jour peut impliquer des corrections et des modifications qui vont alerter le système de la présence d’une modification. Par exemple si vous souhaitez vérifier l’emplacement d’un lien entrant, et que la source du lien fait une modification graphique du site, Le Xpath* peut changer, et donc vous allez avoir un potentiel faux positif sur l’exploitation de la donnée. Sur l’off site, c’est particulièrement plus impactant, car vous n’avez pas la main et vous n’êtes pas prévenu d’éventuelles modifications de vos partenaires. (D’où l’importance d’un test de non-régression).

Que tester dans le cadre d’un test de non-régression SEO ?

On peut tester plusieurs éléments, dans l’exemple j’ai choisi de faire des tests plutôt basiques : pour la partie on site, au lieu de vérifier le contenu text (balises p et autres)*, j’ai choisi de rester sur la title, la meta description et les h1, h2 etc…* Avec le script, je m’assure de tester la présence et la stabilité de ces éléments, et j’enregistre dans une table séparée les changements qui peuvent survenir. Ainsi je m’assure que le signal de stabilité soit respecté.

Pour la partie off site, j’ai choisi de faire assez simple : on cherche à récupérer l’information de la présence d’un lien et son emplacement dans la page. On peut ajouter l’information rel* de la balise du lien, le meta robots de la page source*, etc… Attention, l’idée ici est surtout de rester simple sur ce qui est testable rapidement et qui est fondamental pour l’utilisation.

Pour aller plus loin :

On peut crawler le site à intervalles réguliers, afin d’ajouter la répartition du PageRank en interne, ou bien faire un peu plus en testant l’optimisation sémantique via l’API Yourtext Guru (je pense que je ferai un code spécifique là-dessus si suffisamment de gens le demandent), ce qui permettra de tester aussi la modification du vocabulaire attendu par la page de résultat Google.

Globalement, un script ou une application web réalisant des tests de non-régression est un élément essentiel du métier de SEO, car il permet d’évaluer la stabilité des pages stratégiques d’un site web.

Je vous partage un script python donc plutôt basique sur les tests réalisés, mais une fois montés sur une machine tournant en continu, vous avez la possibilité de surveiller les évolutions de ces éléments basiques pour votre url stratégique, (ou vos liens importants).

Le code en question est accessible ici

Comment utiliser ce code ?

 Ouvrez votre terminal et commencez par vous déplacer jusqu’à l’emplacement du dossier téléchargé et décompressé. Exemple :

cd D:\user\folder\dezipped_folder\

 Puis, installez les dépendances (les librairies utilisées) en tapant :

pip install -r requirements.txt

Puis assurez-vous d’avoir bien créé un fichier avec les liens existants à vérifier (un csv avec une colonne « source » et une colonne « target », sans les guillemets). Et / ou les pages dont vous souhaitez tester la non-régression des éléments title, meta description, h1, h2, h3, h4, h5, h6.

Pour l’exemple, je vais appeler mon fichier de liens « links.csv » et mon fichier de pages « pages.txt »

Il ne manque plus qu’à exécuter le script (qui tournera tant que l’ordinateur est allumé et connecté à internet, et jusqu’à ce que vous le coupiez (ctrl +c interrompt le script)).

 Pour l’exécuter, voilà la commande (faites entrée sur la première ligne et répondez par y (yes : oui) ou n (no : non) pour intégrer vos fichiers à la demande de vérification).

python basics_seo_non_regression_tests.py

INFO:root:Initialized DB : [ici le chemin du dossier]\seo_data.db

Do you want to provide a CSV file with source and target URLs? (y/n) : y

Enter the path to the CSV file with source and target URLs: links.csv

Do you want to provide a text file with URLs of pages to check? (y/n) : y

Enter the path to the text file with URLs of pages to check: pages.txt

Enter the frequency of the task in minutes (default is 1 minute):180

Ici, j’ai programmé le script pour qu’il s’exécute toutes les 3h : (3 x 60min = 180 min).

Le fichier seo_data.db qui se crée est une base de donnée SQLITE. Tout le monde ne sait pas forcément utiliser une base de donnée SQLITE, aussi j’ai prévu le coup :

Pendant que votre script tourne, ou après une interruption du script, si vous souhaitez exporter le contenu de la base de donnée sous format csv, vous pouvez le faire en utilisant le 2e code python que je mets à votre disposition dans le dossier : « non_regression_to_csv.py ».

Ce script vous permettra d’exporter le contenu des 2 tables présentent dans la base de données : seo_data et differences. seo_data est la table qui recense tous les passages et l’état des éléments lorsque le script passe dessus. C’est l’élément essentiel de toutes comparaisons : sans donnée, pas de comparaisons. differences est la table qui recense toutes les modifications qu’on peut identifier entre chaque exécution du script.

Et afin d’alléger un peu la mémoire de votre ordinateur, ce script d’export csv vous permet également de supprimer après export le contenu des deux tables (par sécurité, seo_data gardera toujours la dernière entrée, afin de permettre la comparaison lors de l’exécution suivante, ce qui peut avoir lieu rapidement si votre script initial tourne encore). Je ne recommande pas forcément de le faire, surtout si vous craignez de perdre l’information, mais parfois, la quantité de données stockées est tellement importante qu’on n’a pas le choix.

Comment l’utiliser ?

De la même façon qu’il vous faut aller jusqu’au dossier, assurez vous que ce soit le dossier du fichier python & du fichier seo_data.db

cd D:\user\folder\dezipped_folder\

 puis exécutez le :

python non_regression_to_csv.py

Do you want to export the differences? (y/n) : y

Do you want to export the SEO data? (y/n) : y

Differences have been exported to differences.csv.

Do you want to clear the ‘differences’ table after export? (y/n) : y

The ‘differences’ table has been cleared.

SEO data has been exported to seo_data.csv.

Do you want to clean the ‘seo_data’ table after export (keep only the last entry for each element)? (y/n) : y

The ‘seo_data’ table has been cleaned to keep only the last entry for each element.

Ici un exemple d’export des données sous differences.csv & seo_data.csv avec suppression des informations en base de donnée.

Attention : je n’ai pas prévu le cas où vous faisiez un export à la suite d’un autre export. Si vous faites 2 fois un export sans changer le nom des fichiers differences.csv & seo_data.csv, vous risquez, au pire, de réécrire les fichiers et de perdre l’information historique, au mieux, de ne pas pouvoir exporter la donnée parce que le fichier serait ouvert sur votre ordinateur et vous auriez une erreur mentionnant un manque de droits.

Les fichiers en sortie :
difference.csv, avec les colonnes suivantes :

id : numéro de ligne

timestamp : date et heure précise (sous forme UTC) de l’entrée dans la base (et donc de la comparaison : c’est la date à laquelle la modification a été observée).

type : link ou page, selon si on teste un lien ou une url

element : la source et la cible du lien testé, ou l’url testée

data : un « dictionnaire » stockant l’ensemble des informations testées dans le dernier état connu par le script au moment de la comparaison

difference : un commentaire automatique sur le changement observé.

Pour expliquer ce que vous allez voir :

Pour les liens : lorsque vous voyez le xpath changer, c’est que le lien (ou en tout cas la première occurrence du lien) a été déplacé dans la structure HTML de la page. Ça peut être simplement dû à une modification graphique pour le site, mais ça peut aussi être une modification du contenu ou de la page en particulier.

Lorsque vous voyez « xpath changed from […] to None, rel_attribute changed from […] to None, links_list changed from […] to None » c’est que le lien a été supprimé. Comme les 3 éléments sont testés, c’est logique de voir les 3 corrections être indiquées au lieu de juste « link deleted » qui a mon sens est un peu trop simple : ici on indique où était le lien avant sa suppression, quel attribut rel il avait et combien de fois il apparaissait dans la page.

Pour les pages :

Le changement de title, de description, de htags (mon nom pour les h1 à h6) et du nombre de htags sont tous stockés également pour avoir une idée précise du changement qui a eu lieu sur la page.

* Glossaire 

– balise title : balise HTML d’une page web, représentée dans les résultats de recherche par la ligne bleue soulignée. Correspond à un titre accrocheur qu’on pourrait utiliser pour attirer les lecteurs sur la page. Cette balise a un impact sémantique sur le classement de la page dans les résultats, et sa performance est mesurée avec celle de la méta description à travers le taux de clics sur la page depuis les résultats du moteur de recherche.

– attribut description de la balise meta, ou « meta description » : petit texte ayant pour but d’aider le lecteur à affiner sa compréhension de la page avant d’y accéder, compréhension qui a été initiée par la balise title, et est affinée ici par ce texte. Son apparence correspond aux lignes de textes sous les titles (dans les résultats), mais est parfois réécrite par Google pour mieux correspondre au contenu de la page. Son impact est uniquement sur le taux de clics, ce qui mesure également sa performance.

– H1, H2, H3, H4, H5, H6 : ce sont les titres et sous-titres du contenu textuel des pages d’un site. Leur intérêt est structurel et l’impact est sur le signal sémantique, spécifiquement pour le H1, les H2 et H3.

– header : c’est le haut d’une page web, en général représenté par le menu et d’autres éléments navigationnels.

– footer : c’est le bas d’une page web, en général on y indique des liens pratiques (contacts, mentions légales etc…).

– Xpath : Comme un document sur un ordinateur a un chemin d’accès, les éléments d’une page construite en HTML ont un chemin d’accès qui représente l’emplacement où cet élément est identifiable. C’est très pratique pour récupérer automatiquement une information via un robot.

– balise p : C’est la balise HTML qui permet de déclarer la présence d’un paragraphe de texte. Comme pour le xpath, c’est une information pratique à connaître pour qui veut automatiser un sujet de récupération d’information.

– information rel : c’est un attribut de la balise a, celle qui sert à créer un lien cliquable. Cet attribut permet d’indiquer à un robot si un lien doit être suivi ou non. S’il ne doit pas l’être, l’attribut est « nofollow » (mais il vaut mieux éviter).

– meta robots : c’est un attribut (robots) de la balise meta. Son objectif est d’indiquer spécifiquement à un robot si la page doit être indexée dans les résultats de recherche ou non. Si la page ne doit pas être indexée, il faut indiquer « noindex » (mais c’est souvent à éviter).