Audit de parité Seo

Découvrez comment analyser les différentes versions de votre site web et corriger les éventuels points critiques.

Audit comparatif Seo

Dans ce tutoriel, nous allons nous pencher sur l‘” Audit de paritéSeo ” à l’aide de Screaming Frog, une analyse souvent sous-estimée, mais qui peut mettre en évidence de nombreuses criticités qui empêchent une bonne indexation organique sur le moteur de recherche.

Grâce à cette analyse, vous serez en mesure d’évaluer s’il existe des différences dans la manière dont le site web est servi dans différents scénarios lors des raids du Crawler.

Les cas les plus intéressants pour réaliser l'”audit de parité Seo” sont les suivants :

  • Site mobile vs. site de bureau.
  • Javascript contre HTML brut.
  • Site réel ou site de transit (crucial lors des migrations).

Grâce à l’utilisation du Seo Spider, vous serez en mesure d’isoler les éléments SEO on-page qui varient d’une version à l’autre et qui pourraient avoir un impact sur le crawling et, par conséquent, sur la phase d’indexation et sur le classement attribué par le moteur de recherche.

Parmi les éléments les plus courants à prendre en compte dans ce processus, on peut citer

  • Structuration des pages ;
  • Code de réponse HTTP ;
  • Titre de la page ;
  • Rubriques ;
  • Les normes canoniques ;
  • Hreflangs ;
  • Données structurées ;
  • etc.

Audit de parité Javascript

configurazione del rendering JS sul Seo Spider

La première étape pour réaliser un audit de parité sur un site web contenant des ressources JS consiste à configurer le mode d’analyse “Javascript Rendering”.

La première étape pour réaliser un audit de parité sur un site web contenant des ressources JS consiste à configurer le mode d’analyse “Javascript Rendering”.

> > Config Spider JS Rendering

En activant l’analyse Javascript, le Seo Spider analyse et sert à la fois le HTML statique et le HTML rendu après l’exécution Javascript. Dans l’onglet configuration, en plus de choisir “Javascript rendering”, je vous recommande de définir l’option “Googlebot Mobile Smartphone” comme “Viewport”, étant donné l’orientation du moteur de recherche vers le“Mobile First Indexing“.

> Une fois le mode de balayage défini, vous devez activer les ressources à balayer en les activant à partir du menu de configuration de Spider Crawl.
N’oubliez pas que si certaines ressources sont présentes dans un sous-domaine ou dans un “domaine racine” différent, vous devez également sélectionner l’option“Vérifier les liens externes“, sinon le Seo Spider n’utilisera pas ces éléments dans le rendu.

Une fois cette étape terminée, il ne reste plus qu’à lancer le crawl ; le Seo Spider analysera le site web et vous proposera un rendu des pages en utilisant le mode “headless Chrome”.

Une fois l’analyse terminée, vous pouvez consulter les 12 filtres disponibles dans l’onglet “Javascript” et commencer à évaluer s’il existe des différences entre le HTML brut et le HTML rendu. En utilisant des filtres, vous serez en mesure de savoir quelles pages ont un contenu Javascript, s’il y a des différences dans les balises méta, les canoniques ou d’autres éléments sur la page tels que les titres, les en-têtes ou autres qui ne sont mis à jour qu’après l’exécution du Javascript.

Filtri per analisi JS con il seo spider

D’une manière simple et intuitive, vous pouvez visualiser les pages avec un contenu JS et surtout quels sont les éléments qui ne sont présents qu’après le rendu du contenu.

Lorsque vous trouvez des différences, il vous suffit de consulter la fenêtre inférieure de Screaming Frog et de sélectionner l’onglet“Voir la source“, de choisir“Contenu visible” comme filtre et de prévisualiser les deux versions en activant l’option“Voir les différences“.

Dans ce contexte, l'”audit de parité” est très utile pour déterminer s’il existe des liens qui ne sont présents que dans le HTLM rendu et qui pourraient ne jamais être découverts par le robot du moteur de recherche et donc ne pas être indexés et suivis.

analisi links scoperti dopo renderizzazione javascript

Pour savoir quels liens ne sont présents qu’après l’exécution du JS, cliquez sur l’onglet“Outlinks” et définissez les liens“Rendered HTML” comme filtre. Pour une analyse plus approfondie, vous pouvez décider de les exporter via l’option de menu“Exportation en bloc“.

> > Exportation en masse de Javascript Contient des liens Javascript

dettagli pagine renderizzate

En plus de l’analyse des liens, vous pouvez évaluer toute une série d’éléments qui varient après l’exécution du script JS en fonction des exigences de votre projet.

Filtres d’onglets Javascript

Les filtres fournis par Screaming Frog sont un support indispensable pour gérer votre audit de parité :

Contient des liens JavaScript: le filtre affiche les pages qui contiennent des hyperliens qui ne sont découverts dans le rendu HTML qu’après l’exécution de JavaScript. Ces hyperliens ne sont pas en HTML brut. C’est une bonne pratique que d’envisager l’inclusion de liens importants côté serveur dans le code HTML statique.
Contient du contenu JavaScript: affiche toutes les pages qui contiennent un corps de texte uniquement en HTML rendu après l’exécution de JavaScript. Google est capable d’afficher les pages et de ne voir que le contenu côté client, alors que le contenu important côté serveur n’est pas inclus dans le code HTML brut.
Noindex Only in Original HTML: toutes les pages qui contiennent une balise noindex dans le HTML statique mais pas dans le HTML rendu. Lorsque Googlebot rencontre une balise noindex, il ignore le rendu et l’exécution de JavaScript. Étant donné que Googlebot ignore l’exécution de JavaScript, l’utilisation de JavaScript pour supprimer le “noindex” dans le code HTML rendu ne fonctionnera pas.
Nofollow Only in Original HTML: identifie les pages qui contiennent un attribut nofollow dans le HTML statique, et non dans le HTML rendu. Cela signifie que tout hyperlien contenu dans le code HTML brut avant l’exécution de JavaScript ne sera pas suivi. Supprimez “nofollow” si les liens doivent être suivis, analysés et indexés.
Canonical Only in Rendered HTML : renvoie toutes les pages qui contiennent une balise canonical only dans le code HTML rendu après l’exécution de JavaScript. Je recommande d’inclure un lien canonique dans le code HTML statique (ou dans l’en-tête HTTP) afin de s’assurer que Google puisse le voir et d’éviter de se fier uniquement au lien canonique dans le code HTML rendu.
Mauvaise correspondance canonique : identifie les pages qui contiennent un lien canonique différent dans le code HTML statique et dans le code HTML rendu après l’exécution du JavaScript. Cette situation peut entraîner des signaux contradictoires et un comportement indésirable de la part du moteur de recherche.
– Titre de la page uniquement dans le code HTML rendu: renvoie les pages qui contiennent un titre de page uniquement dans le code HTML rendu après l’exécution de JavaScript. Cela signifie qu’un moteur de recherche doit rendre la page pour les voir. Pensez à inclure le contenu important côté serveur dans le code HTML brut.
Titre de la page mis à jour par JavaScript: identifie les pages dont le titre a été modifié par JavaScript. Cela signifie que le titre de la page en HTML statique est différent du titre de la page en HTML rendu. Envisagez d’inclure le contenu important côté serveur dans du HTML statique.
– Méta description uniquement dans le HTML rendu: renvoie les pages qui contiennent une méta description uniquement dans le HTML rendu après l’exécution de JavaScript.
Méta description mise à jour par JavaScript: toutes les pages dont les méta descriptions sont modifiées par JavaScript. Cela signifie que la méta-description en HTML statique est différente de la méta-description en HTML rendu.
H1 Only in Rendered HTML : pages qui contiennent un h1 uniquement dans le rendu HTML après l’exécution de JavaScript. Cela signifie qu’un moteur de recherche doit rendre la page pour prendre en compte l’intitulé.
Envisagez d’inclure des titres côté serveur dans le code HTML statique
– H1 mis à jour par JavaScript: pages dont les titres h1 ont été modifiés par JavaScript. Cela signifie que le h1 en HTML brut est différent du h1 en HTML rendu.

Mobile et ordinateur de bureau

Le moteur de recherche avec son orientation “Mobile First Indexing” a défini sans équivoque l’importance du “mobile” en termes de positionnement organique, et l’audit de parité entre le mobile et l’ordinateur est une activité essentielle dans la phase d’optimisation d’un site web.

Pour réaliser l’audit de parité, vous devez effectuer trois actions distinctes :

  1. Analyse du site web avec l’agent utilisateur ‘GoogleBot pour Smartphones’.
  2. Effectuez un balayage avec l’agent utilisateur “GoogleBot” (ou un autre agent pour les versions de bureau).
  3. Utilisez le mode d’exploration “Comparer” pour comparer les deux explorations précédentes.

Veuillez noter que pour ce scénario, le mode de stockage des données de Screaming Frog doit être réglé sur “Mode de stockage”.

Agent utilisateur GoogleBot
pour les smartphones

Analysez votre site web en utilisant l’agent utilisateur “Googlebot pour smartphones”. Si votre site web contient du contenu JS ou des dépendances, vous devez activer le “Mode de rendu Javascript” comme mode d’analyse.

Agent utilisateur GoogleBot

Retournez dans les configurations et changez l’agent utilisateur en Googlebot ou un autre agent utilisateur de bureau et démarrez votre deuxième analyse avec Screaming Frog.

Comparaison entre les mobiles et les ordinateurs de bureau

Une fois que vous avez les deux scans séparés, il vous suffit de les comparer à l’aide du nouveau mode“Comparaison“.

Comparazione sito mobile e desktop con funzione compare di screaming frog

> Cliquez ensuite sur l’icône de l’engrenage en haut de l’écran ou sur “Comparaison de configuration”. Vous pourrez ainsi configurer la fonction de détection des changements, qui vous permet d’identifier s’il existe des différences sur des éléments spécifiques tels que les titres de page, les méta-descriptions, les en-têtes, le nombre de mots, les liens internes, les données structurées et bien d’autres encore.

Pour inclure tous les éléments d’analyse, il suffit d’activer l’option “Select All” en haut de la fenêtre de configuration.

Elaborazione seo parity con funzione Change detection del seo spider

Si le site web est réactif et propose un contenu différent pour les mobiles et les ordinateurs de bureau, mais conserve les mêmes URL, vous pouvez procéder à l’analyse comparative ; sinon, vous devrez également configurer la fonction de mappage des URL. Dans la même fenêtre que précédemment, cliquez sur l’onglet correspondant et normalisez les sous-domaines en utilisant la syntaxe RegEX.

Il ne vous reste plus qu’à cliquer sur “ok” et “Comparer” pour lancer le processus d’analyse.

Pour en savoir plus sur la cartographie des URL et la détection des changements de Screaming Frog, cliquez ici.

Une fois l’analyse terminée, il ne vous reste plus qu’à consulter les données via les“onglets de détection de changement” dans la barre latérale de Seo Spider.

Overview su sidebar laterale dei cambiamenti sito live e in staging

Idéalement, le contenu devrait être identique, mais il peut y avoir quelques incohérences entre les mobiles et les ordinateurs de bureau. Vous pouvez les découvrir à partir de l’écran principal grâce aux quatre nouveaux filtres introduits dans la version 16.3 de Screaming Frog.

  1. Ajouté: identifie toutes les URL qui sont présentes dans les deux crawls mais dont les éléments modifiés sont inclus dans un filtre du crawl “actuel”. Par exemple, un URL avait un “meta_title” dans la version précédente alors que dans la version actuelle cet élément est absent. Dans ce cas, cette indication sera présente dans le filtre “Missing” de l’élément “Meta Title”.
  2. Nouveau: inclut tous les nouveaux URL qui n’étaient pas présents dans l’analyse précédente mais qui le sont.
    inclus dans l’analyse en cours.
  3. Supprimés: URL présents dans les deux analyses mais dont les éléments sont présents dans le filtre de l’analyse précédente, mais pas dans le filtre de l’analyse actuelle.
    En reprenant l’exemple du “Meta Title” ci-dessus, ce filtre identifie toutes les URL qui n’ont pas de
    présentaient le titre de la page et étaient inclus dans le filtre “Manquant”, mais dans l’analyse actuelle
    ne sont plus présents dans le filtre car ils ont été optimisés.
  4. Manquants: URL présents dans le crawl précédent mais non détectés dans le crawl “actuel”.

En défilant vers le bas jusqu’à l’onglet Détection des changements, vous obtenez un “Résumé” très utile qui vous permet d’avoir une vue d’ensemble immédiate de tous les changements détectés.

En cliquant sur les filtres, vous pouvez découvrir les URLs affectés par les différents changements.
Vous trouverez ci-dessous un exemple de modification du titre de la page.

Voici un exemple de l’évolution de la profondeur de balayage entre les deux versions.

Grâce à ces contrôles, vous pouvez éviter les différences substantielles entre les versions qui pourraient entraver ou rendre problématique le classement de votre site web.

Sites de démonstration et sites réels

La dernière comparaison, et non des moindres, concerne l’analyse des sites d’essai par rapport aux sites réels. Ce scénario est très sensible et doit toujours être pris en considération lors des phases de migration.

Le processus d’audit de parité suit les mêmes étapes que la comparaison Mobile vs. Desktop, en incluant toujours la phase “URL Mapping” pour standardiser les URL de la version publiée et de celle qui est encore en production.

Url Mapping tra sito staging e live
Seo Spider Tab