SEO Parity Audit.

Audit SEO comparatif

Dans ce tutoriel, on voit le SEO Parity Audit avec Screaming Frog : une analyse souvent sous-estimée, qui peut pourtant révéler de nombreux problèmes freinant la bonne indexation organique.

Grâce à cette analyse, tu peux évaluer s’il existe des différences dans la façon dont le site est servi selon les scénarios, au fil du passage du crawler.

Les cas les plus intéressants pour un SEO Parity Audit sont les suivants :

• Site mobile vs site desktop.
• JavaScript vs HTML brut.
• Site en production vs site en staging (essentiel pendant les migrations).

Avec SEO Spider, tu peux isoler les éléments SEO on-page qui varient entre les versions et qui pourraient affecter le crawl et, par conséquent, l’indexation et le classement attribué par le moteur.

Parmi les éléments les plus courants à considérer :

• Structure des pages ;
• Code de réponse HTTP ;
• Title de la page ;
• Titres (headings) ;
• Canonicals ;
• Hreflang ;
• Données structurées ;
• etc.

Parity Audit JavaScript

Configurer le rendu JavaScript

La première étape d’un Parity Audit sur un site qui utilise des ressources JS consiste à régler le mode de crawl JavaScript Rendering :

En activant le crawl JavaScript, SEO Spider crawle et restitue à la fois le HTML statique et le HTML rendu après l’exécution du JavaScript. Dans l’onglet de configuration, en plus de « JavaScript Rendering », je te conseille de régler le Viewport sur « Googlebot Mobile Smartphone », vu l’orientation du moteur vers le Mobile First Indexing.

Une fois le mode de crawl défini, active les ressources à examiner dans le menu 1Configuration›2Spider›3Crawl. N’oublie pas que si certaines ressources sont sur un sous-domaine ou un autre domaine racine, tu dois aussi cocher Check external links, sinon SEO Spider ne les utilisera pas pour le rendu.

Cela fait, il ne reste qu’à lancer le crawl : SEO Spider crawlera le site et fera le rendu des pages avec Chrome en mode headless.

HTML brut et HTML rendu

Une fois le crawl terminé, tu peux consulter les filtres de l’onglet JavaScript et commencer à évaluer les différences entre le HTML brut et le HTML rendu. Les filtres montrent quelles pages ont du contenu JavaScript et s’il y a des différences dans les balises meta, les canonicals ou d’autres éléments on-page comme les titles et les titres mis à jour seulement après l’exécution du JavaScript.

Simplement et intuitivement, tu vois les pages au contenu JS et surtout quels éléments n’apparaissent qu’après le rendu.

Quand tu trouves des différences, consulte la fenêtre inférieure de Screaming Frog, sélectionne l’onglet View Source, choisis le filtre Visible Content et affiche l’aperçu des deux versions en activant Show Differences.

Ici, le Parity Audit est très utile pour repérer les liens présents uniquement dans le HTML rendu, que le robot du moteur pourrait ne jamais découvrir, donc ne jamais suivre ni indexer.

Pour voir quels liens n’existent qu’après l’exécution du JS, clique sur l’onglet Outlinks et choisis le filtre Rendered HTML. Pour une analyse plus poussée, tu peux les exporter depuis le menu :

Au-delà des liens, tu peux évaluer toute une série d’éléments qui changent après l’exécution du script JS, selon les besoins de ton projet.

Les filtres de l’onglet JavaScript

Les filtres proposés par Screaming Frog sont une aide indispensable pour mener ton Parity Audit. Dans la version actuelle de SEO Spider, l’onglet JavaScript en compte 18.

123

1Onglet JavaScriptL’onglet qui compare HTML brut et HTML rendu.2FiltresLe menu déroulant avec tous les filtres de l’onglet.3Word CountMots dans le HTML brut et rendu, avec la différence et le pourcentage JS.

• Pages with Blocked Resources : les pages dont des ressources (JavaScript, CSS, images) sont bloquées par le robots.txt ou en erreur, ce qui peut compromettre le rendu.
• Contains JavaScript Links : les pages qui contiennent des liens découverts dans le HTML rendu seulement après l’exécution du JavaScript. Ces liens ne sont pas dans le HTML brut : mieux vaut inclure les liens importants côté serveur dans le HTML statique.
• Contains JavaScript Content : toutes les pages dont le texte principal n’existe que dans le HTML rendu après l’exécution du JavaScript. Google sait faire le rendu et voir le contenu côté client, mais pense à inclure le contenu important côté serveur dans le HTML brut.
• Noindex Only in Original HTML : les pages avec une balise noindex dans le HTML statique mais pas dans le HTML rendu. Quand Googlebot rencontre un noindex, il saute le rendu et l’exécution du JavaScript : retirer le noindex en JavaScript dans le HTML rendu ne fonctionnera pas.
• Nofollow Only in Original HTML : les pages avec un attribut nofollow dans le HTML statique mais pas dans le HTML rendu. Les liens du HTML brut, avant l’exécution du JavaScript, ne seront donc pas suivis. Retire le nofollow si les liens doivent être suivis, crawlés et indexés.
• Canonical Only in Rendered HTML : les pages avec une balise canonical uniquement dans le HTML rendu après l’exécution du JavaScript. Je te conseille d’inclure la canonical dans le HTML statique (ou l’en-tête HTTP) pour que Google la voie, sans compter uniquement sur le HTML rendu.
• Canonical Mismatch : les pages dont la canonical diffère entre le HTML statique et le HTML rendu. Cela peut envoyer des signaux contradictoires et provoquer des comportements indésirables du moteur.
• Page Title Only in Rendered HTML : les pages avec un title uniquement dans le HTML rendu. Un moteur doit alors faire le rendu pour le voir : pense à inclure le contenu important côté serveur dans le HTML brut.
• Page Title Updated by JavaScript : les pages dont le title est modifié par JavaScript, c’est-à-dire différent entre HTML statique et HTML rendu.
• Meta Description Only in Rendered HTML : les pages avec une meta description uniquement dans le HTML rendu après l’exécution du JavaScript.
• Meta Description Updated by JavaScript : les pages dont la meta description est modifiée par JavaScript, donc différente entre HTML statique et HTML rendu.
• H1 Only in Rendered HTML : les pages avec un H1 uniquement dans le HTML rendu. Un moteur doit faire le rendu pour prendre en compte le titre : inclus les titres côté serveur dans le HTML statique.
• H1 Updated by JavaScript : les pages dont le H1 est modifié par JavaScript, c’est-à-dire différent entre HTML brut et HTML rendu.
• Uses Old AJAX Crawling Scheme URLs : les URL qui utilisent encore l’ancien schéma de crawl AJAX avec le fragment #!, que Google ne prend plus en charge.
• Uses Old AJAX Crawling Scheme Meta Fragment Tag : les pages qui contiennent la balise meta fragment de l’ancien schéma AJAX.
• Pages with JavaScript Errors : les pages avec des erreurs JavaScript relevées dans la console de Chrome pendant le rendu.
• Pages with JavaScript Warnings : les pages avec des avertissements JavaScript dans la console de Chrome.
• Pages with Chrome Issues : les pages avec des problèmes signalés par Chrome pendant le rendu.

Mobile vs desktop

Avec le Mobile First Indexing, le moteur a clairement affirmé l’importance du mobile pour le classement organique : le Parity Audit entre les versions mobile et desktop est une étape essentielle de l’optimisation d’un site.

Le Parity Audit se fait en trois étapes distinctes :

1. Crawl du site avec le user agent « Googlebot (Smartphone) ».
2. Crawl avec le user agent « Googlebot (Desktop) » ou un autre user agent desktop.
3. Utilisation du mode Compare pour comparer les deux crawls.

N’oublie pas que, dans ce scénario, le mode de stockage de Screaming Frog doit être réglé sur Database Storage Mode.

User agent Googlebot Smartphone

Crawle ton site avec le user agent « Googlebot (Smartphone) » depuis 1Configuration›2User-Agent. Si le site a du contenu ou des dépendances JS, active aussi le mode JavaScript Rendering.

123

1User-AgentLa section de la Crawl Config dédiée au user agent.2Googlebot (Smartphone)Le preset à choisir pour le crawl mobile.3OKConfirme la configuration pour lancer le crawl.

User agent Googlebot

Reviens dans la configuration, règle le User-Agent sur Googlebot (Desktop) ou un autre user agent desktop et lance le deuxième crawl avec Screaming Frog.

123

1Preset User-AgentsGooglebot (Desktop with Chrome Version) pour le crawl desktop.2HTTP Request User-AgentLa chaîne envoyée au serveur, remplie par le preset.3Robots User-AgentLe jeton utilisé pour lire les directives du robots.txt.

Comparaison mobile vs desktop

Une fois les deux crawls obtenus, il ne reste plus qu’à les comparer avec le mode Compare.

Clique maintenant sur l’icône d’engrenage en haut de l’écran ou va dans 1Configuration›2Compare. Tu peux y configurer la Change Detection, qui identifie les différences sur des éléments précis comme title, meta description, titres, nombre de mots, liens internes, données structurées et bien plus.

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

Si le site est responsive et sert des contenus différents entre mobile et desktop sur les mêmes URL, tu peux lancer la comparaison ; sinon, tu dois aussi configurer l’URL Mapping. Dans la même fenêtre, clique sur l’onglet correspondant et aligne les sous-domaines avec une Regex.

Il ne reste qu’à cliquer sur OK puis sur Compare pour lancer l’analyse.

Une fois l’analyse terminée, tu peux consulter les données dans la Change Detection, dans la barre latérale de SEO Spider.

Idéalement, les contenus devraient être identiques, mais il peut y avoir des incohérences entre mobile et desktop : tu les repères depuis l’écran principal grâce aux 4 filtres introduits avec la version 16 de Screaming Frog.

1. Added : les URL présentes dans les deux crawls mais avec des éléments entrés dans un filtre du crawl « Current ». Par exemple, une URL avait un meta title dans la version précédente, mais il manque dans la version actuelle : l’URL sera alors dans le filtre « Missing » de Page Title.
2. New : toutes les nouvelles URL absentes du crawl précédent mais présentes dans le crawl actuel.
3. Removed : les URL présentes dans les deux crawls avec des éléments qui étaient dans un filtre du crawl précédent mais n’y sont plus dans le crawl actuel. Pour reprendre l’exemple du Page Title, ce filtre montre les URL qui n’avaient pas de title et étaient dans « Missing », mais n’y sont plus car elles ont été optimisées.
4. Missing : les URL présentes dans le crawl précédent mais introuvables dans le crawl « Current ».

En descendant dans l’onglet Change Detection, tu trouves un Summary très utile qui affiche d’un coup tous les changements détectés.

En cliquant sur les filtres, tu vois les URL concernées par chaque changement. Voici un exemple de changement des Page Titles.

Et voici un exemple de changement de profondeur de crawl entre les deux versions.

Grâce à ces contrôles, tu évites des différences importantes entre les versions qui pourraient freiner ou compliquer le classement du site.

Sites en staging vs en production

Dernière comparaison, mais pas la moindre : les sites en staging face aux sites en production. Ce scénario est très délicat et doit toujours être pris très au sérieux pendant les migrations.

Le processus de Parity Audit suit les mêmes étapes que la comparaison mobile vs desktop, en incluant toujours l’URL Mapping pour aligner les URL de la version publiée et de celle encore en développement.