Analyser les sites en JavaScript | Screaming Frog Club

Introduction aux sites en JavaScript

Il y a encore quelques années, l’un des problèmes SEO les plus répandus était de faire indexer des pages dont le contenu était généré dynamiquement en JavaScript. Les robots des moteurs ne savaient pas crawler ni indexer ces ressources et ne tenaient compte que du contenu présent dans le code source HTML statique.

En parallèle, des frameworks comme AngularJS, React et Vue.js, les applications monopages (SPA) et les progressive web apps (PWA) ont évolué, poussant Google à progresser nettement jusqu’à comprendre pleinement les pages comme un navigateur moderne.

Pourtant, même si Google sait aujourd’hui crawler et indexer la plupart des contenus JavaScript, il recommande le rendu côté serveur, le pré-rendu ou le rendu dynamique plutôt que de s’appuyer sur le JavaScript côté client, car les crawlers ont encore du mal à traiter le JavaScript avec succès ou immédiatement.

C’est pourquoi, lors d’une analyse, il est essentiel de comprendre les différences entre le DOM, une fois que JavaScript a construit la page, et la réponse HTML statique.

JavaScript, SEO Spider et quelques mises en garde

Screaming Frog t’aide avec son mode « JavaScript Rendering », qui intègre la bibliothèque Chromium pour émuler au mieux le comportement de Googlebot.

Onglet JavaScript de Screaming Frog avec Word Count, les filtres JavaScript dans la barre latérale et l’aperçu Rendered Page

Pour aller plus loin : en 2019, Google a mis à jour son Web Rendering Service (WRS), jusque-là basé sur Chrome 41, vers la dernière version stable de Chrome, ce qui a ajouté la prise en charge de plus de mille fonctionnalités.

Voyons quelques aspects des sites en JavaScript :

1. Active le « JavaScript Rendering » avec prudence

Comprendre les différences entre le DOM et le HTML statique après l’exécution du JavaScript est très important, mais je te déconseille d’activer le mode « JavaScript Rendering » pour tous les sites sans distinction.

Le crawl avec JavaScript est plus lent et plus lourd pour le serveur, car toutes les ressources (JavaScript, CSS, images, etc.) doivent être récupérées pour le rendu de chaque page. Sans importance pour les petits sites, cela peut devenir un obstacle en temps et en RAM pour les gros portails ou e-commerces.

1. Tiens compte des principes et limites du crawl JavaScript

Toutes les ressources d’une page (JS, CSS, images) doivent être disponibles pour être crawlées, rendues et indexées.

Google exige toujours des URL propres et uniques pour une page, et les liens doivent être dans de vraies balises d’ancre HTML (tu peux proposer un lien statique tout en appelant une fonction JavaScript).

Googlebot n’interagit pas comme les utilisateurs : par exemple, il ne clique pas pour charger des événements supplémentaires après le rendu (un clic, un survol ou un défilement).

La capture de la page rendue est prise quand l’activité réseau est jugée terminée, ou au-delà d’un seuil de temps. Si une page met longtemps à se rendre, elle risque d’être ignorée et ses éléments de ne pas être vus ni indexés.

En général, Google fait le rendu de toutes les pages, mais il ne les met pas en file de rendu si elles ont un ‘noindex’ dans la réponse HTTP initiale ou le HTML statique.

Enfin, le rendu de Google est distinct de l’indexation. Google crawle d’abord le HTML statique d’un site et reporte le rendu jusqu’à ce qu’il ait des ressources disponibles.

Quand tu commences le développement d’un site, connaître ces conditions est vital pour la réussite ou l’échec du projet en matière de classement organique.

JavaScript côté serveur et côté client

Google déconseille de s’appuyer sur le JavaScript côté client et recommande le « progressive enhancement » : construire la structure et la navigation du site en HTML seul, puis améliorer l’apparence et l’interface avec AJAX.

Si tu utilises un framework JavaScript, Google recommande donc le rendu côté serveur, le pré-rendu ou le rendu hybride, qui peuvent améliorer les performances pour les utilisateurs et les crawlers.

Avec le rendu côté serveur (SSR) et le pré-rendu, l’exécution du JavaScript fournit une première version HTML rendue et prête à être crawlée.

Le rendu hybride (parfois appelé « isomorphique ») exécute le JavaScript côté serveur pour le premier chargement et le HTML, et côté client pour les éléments non critiques et les pages suivantes.

De nombreux frameworks comme React ou Angular Universal permettent le rendu côté serveur et hybride.

Autre solution : le rendu dynamique.

Il est particulièrement utile quand tu ne peux pas modifier le code front-end. Le rendu dynamique sert le rendu côté client aux utilisateurs et un contenu pré-rendu aux moteurs.

Les délais de crawl de Google

Même si ces trois solutions règlent la plupart des problèmes de crawl, il faut tenir compte d’un autre aspect.

Google indexe en deux phases : il crawle et indexe d’abord le HTML statique, puis revient plus tard, quand des ressources sont disponibles, pour faire le rendu de la page et crawler et indexer le contenu et les liens du HTML rendu.

Pipeline de Googlebot pour le crawl, le rendu et l’indexation : Crawl Queue, Crawler, Processing, Render Queue, Renderer et Index — Le pipeline de Googlebot. Source : Google Search Central.

Le délai entre crawl et rendu peut être très long (jusqu’à 7 jours), ce qui pose problème aux sites dont les contenus sont par nature urgents ou périssables (sites d’actualité, d’événements, etc.) ; le délai médian (annoncé au Chrome Dev Summit 2019) est de 5 secondes.

Comment identifier le JavaScript

Identifier un site construit avec un framework JavaScript peut être assez simple, mais diagnostiquer des sections, des pages ou de petits éléments adaptés dynamiquement en JavaScript peut être bien plus difficile. Au début d’un audit SEO, il est bon d’établir tout de suite si du JavaScript est en jeu et si le site risque de poser problème lors des crawls des différents user agents.

Il existe plusieurs façons de savoir si un site est construit avec un framework JavaScript :

1. Identifier le JavaScript avec Screaming Frog

Par défaut, SEO Spider crawle avec l’« ancien schéma de crawl AJAX » : le JavaScript est désactivé et seul le HTML brut est crawlé.

Si le site n’utilise que du JavaScript côté client, ton crawl ne renverra que la page d’accueil en 200 avec quelques fichiers JavaScript et CSS.

Crawl d’angular.io sans rendu JavaScript dans Screaming Frog : seulement la page d’accueil et les fichiers JS et CSS — Sans rendu, le Spider ne trouve que la page d’accueil et les ressources.

Comme tu le vois, l’onglet « Outlinks » ne contient pas non plus de liens, car ils ne sont pas dans le HTML brut et SEO Spider ne peut pas les voir.

Onglet Outlinks de Screaming Frog avec seulement des liens JavaScript et CSS et aucun lien hypertexte

C’est souvent le signe que le site utilise un framework JavaScript rendu côté client, mais cela ne te dit pas s’il existe d’autres dépendances JavaScript sur le site.

Par exemple, un site peut n’utiliser JavaScript que pour charger les produits sur les pages catégories ou mettre à jour les titles.

Comment les trouver facilement ?

Pour identifier le JavaScript plus efficacement, passe en mode de rendu JavaScript (1Configuration›2Spider›3Rendering) et crawle le site, ou un échantillon de modèles de tout le site.

SEO Spider crawlera le HTML d’origine et le HTML rendu pour identifier les pages dont le contenu ou les liens ne sont disponibles que côté client, et signaler d’autres dépendances clés.

Menu des filtres de l’onglet JavaScript de Screaming Frog SEO Spider 24.3, de Pages with Blocked Resources à Pages with Chrome Issues — Les 18 filtres de l’onglet JavaScript de SEO Spider 24.3.

Pour t’orienter parmi les problèmes courants des sites en JavaScript côté client, tu disposes d’une liste complète de filtres qui guideront ton audit SEO.

SEO Spider signalera les contenus qui n’existent que dans le HTML rendu après l’exécution du JavaScript, pour une vision complète du comportement du site.

Filtre Contains JavaScript Content de Screaming Frog avec la colonne JS Word Count % à 100 %

Dans cet exemple, 100 % du contenu n’existe que dans le HTML rendu, car le site repose entièrement sur JavaScript.

Ici, l’examen portait sur le nombre de mots du contenu, mais tu peux aussi trouver, par exemple, les pages dont les liens n’existent que dans le HTML rendu, et y remédier en suivant les recommandations de Google.

Filtre Contains JavaScript Links de Screaming Frog avec les liens découverts seulement après le rendu JavaScript

Cette fonction de Screaming Frog est aussi très utile pour vérifier si les balises meta ou d’autres éléments SEO sont présents dans le HTML statique, ou ne sont servis et/ou modifiés qu’après l’exécution du JavaScript.

1. Désactiver JavaScript dans le navigateur

Autre façon de comprendre la nature d’un site : désactiver JavaScript directement dans le navigateur et recharger la page. Si elle s’affiche blanche, aucun doute, le site a été conçu en JavaScript.

Réglages des Chrome DevTools avec l’option Disable JavaScript activée — Désactive JavaScript depuis les DevTools de Chrome.

1. Chercher le JavaScript dans le code source

Troisième solution : faire un clic droit sur la page et afficher le code source, en regardant si le HTML contient du texte, des liens ou des traces des bibliothèques des frameworks JS.

Tu vois ainsi le code avant son traitement par le navigateur, ce qui correspond à ce que crawle SEO Spider hors mode de rendu JavaScript.

Si tu cherches un élément et ne le trouves pas dans le code source, il est sans doute généré dynamiquement dans le DOM et ne sera visible que dans le code rendu.

Code source d’un site avec un conteneur app vide et les fichiers JavaScript qui génèrent le contenu

Ici, la balise <body> est complètement vide : signe clair que le site utilise JS.

1. Auditer le code rendu

Première question à se poser : à quel point le code rendu diffère-t-il du source HTML statique ? Pour le savoir, fais un clic droit et utilise « Inspecter » dans Chrome pour voir le HTML rendu. Tu peux souvent y voir le nom du framework JS, comme ‘React’ dans l’exemple ci-dessous.

Chrome DevTools avec le menu Copy › Copy outerHTML sur l’élément html pour copier le code rendu — Copy › Copy outerHTML sur l’élément html.

Tu verras que le contenu et les liens sont dans le code rendu, mais pas dans le source HTML d’origine. C’est ce que voit SEO Spider en mode de rendu JavaScript.

En cliquant sur l’élément HTML d’ouverture, puis « Copy › outerHTML », tu peux comparer le source rendu et l’original.

Crawler du JavaScript avec Screaming Frog

Une fois la présence de JS établie et les pièges compris, tu peux commencer ton audit SEO avec Screaming Frog en mode de rendu JavaScript. Tu peux ainsi crawler des sites dynamiques riches en JavaScript et en frameworks comme Angular, React et Vue.js.

1. Pour crawler un site JavaScript, ouvre SEO Spider, va dans 1Configuration›2Spider›3Rendering et passe ‘Rendering’ sur ‘JavaScript’.
1. Configure le User-Agent et la Window Size

Configure le user agent dans 1Configuration›2User-Agent.

Et la taille de la fenêtre dans 1Configuration›2Spider›3Rendering.

Par défaut, le viewport est réglé sur « Googlebot Mobile: Smartphone », conformément au mobile first indexing du moteur.

Crawl Config › Spider › Rendering de Screaming Frog SEO Spider 24.3 avec rendu JavaScript, AJAX Timeout et Window Size Googlebot Mobile: Smartphone — La fenêtre Spider › Rendering : moteur JavaScript, timeout et appareil simulé.

1. Vérifie les ressources et les liens externes

Assure-toi que les ressources comme les images, CSS et JS sont cochées dans 1Configuration›2Spider›3Crawl. Si elles sont sur un autre sous-domaine ou un domaine racine distinct, active aussi les liens externes dans 1Configuration›2Spider›3Crawl›4External Links, sinon elles ne seront ni crawlées ni rendues.

Crawl Config › Spider › Crawl de Screaming Frog SEO Spider 24.3 avec Images, CSS, JavaScript et SWF activés dans Resource Links — Crawl et Store des images, CSS et JavaScript sont nécessaires au rendu.

1. Lance le crawl

Crawl d’un site en JavaScript dans Screaming Frog avec Crawl Data et l’aperçu Rendered Page

1. Consulte l’onglet JavaScript

L’onglet JavaScript propose 18 filtres pour tenir compte des dépendances JavaScript et isoler les problèmes les plus courants.

Pages with Blocked Resources : identifie les pages dont des ressources (images, JavaScript, CSS) sont bloquées par le robots.txt. Cela peut poser problème, car les moteurs risquent de ne pas accéder aux ressources nécessaires au rendu précis des pages. Je te conseille de mettre à jour le robots.txt pour que toutes les ressources critiques puissent être crawlées et utilisées pour le rendu. Les ressources non critiques (par ex. l’intégration de Google Maps) peuvent être ignorées.
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 un 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 ; utiliser JavaScript pour retirer le ‘noindex’ dans le HTML rendu ne fonctionnera donc 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 un lien canonique dans le HTML statique (ou l’en-tête HTTP) pour que Google le voie, sans compter uniquement sur le HTML rendu.
Canonical Mismatch : les pages dont le lien canonique diffère entre le HTML statique et le HTML rendu après le JavaScript. 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 après le JavaScript. Un moteur doit donc 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. Pense à inclure le contenu important côté serveur dans le HTML statique.
Meta Description Only in Rendered HTML : les pages avec une meta description uniquement dans le HTML rendu après le 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 après le JavaScript. Un moteur doit faire le rendu pour prendre en compte le titre. Pense à inclure 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 (URL avec un fragment #!), officiellement abandonné depuis octobre 2015. Envisage le rendu côté serveur ou le pré-rendu quand c’est possible, et le rendu dynamique comme solution de contournement.
Uses Old AJAX Crawling Scheme Meta Fragment Tag : les URL qui contiennent une balise meta fragment indiquant que la page utilise encore l’ancien schéma de crawl AJAX, abandonné depuis octobre 2015. Mets à jour les URL pour suivre l’évolution du JavaScript sur les sites actuels. Envisage le rendu côté serveur ou le pré-rendu, et le rendu dynamique comme contournement. Si le site a encore l’ancienne balise meta fragment par erreur, supprime-la.
Pages with JavaScript Errors : les pages avec des erreurs JavaScript relevées dans la console de Chrome pendant le rendu. Pour les voir, active « Enable JavaScript Error Reporting » dans 1Configuration›2Spider›3Rendering.
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, comme des ressources bloquées ou des problèmes de sécurité.
1. Surveille les ressources bloquées

Garde un œil sur tout ce qui apparaît dans le filtre « Pages with Blocked Resources » de l’onglet « JavaScript ».

Filtre Pages with Blocked Resources dans l’onglet JavaScript de Screaming Frog

Les ressources bloquées s’affichent aussi pour chaque page dans l’onglet ‘Rendered Page’, à côté de la capture rendue dans le panneau inférieur. Dans les cas graves, si un site JavaScript bloque entièrement ses ressources JS, il ne sera tout simplement pas crawlé.

Ressources bloquées par le robots.txt dans la fenêtre inférieure de Screaming Frog avec un aperçu Rendered Page en erreur

Tu peux aussi voir chaque ressource bloquée dans l’onglet « Response Codes », sous 1Response Codes›2Blocked Resource.

Les pages et ressources bloquées peuvent aussi être exportées en masse avec 1Bulk Export›2Response Codes›3Blocked Resource Inlinks, pour être débloquées et optimisées.

Bulk Export › Response Codes › Blocked Resource Inlinks dans Screaming Frog

1. Affiche les pages rendues

Avec Screaming Frog, tu peux voir la page rendue dans l’onglet ‘Rendered Page’, qui apparaît en bas de l’interface quand le crawl se fait en mode de rendu JavaScript.

Onglet Rendered Page de la fenêtre inférieure de Screaming Frog avec la capture de la page rendue

Si le rendu des pages ne se charge pas, pense à ajuster le timeout AJAX directement dans la configuration de SEO Spider.

Voir la page rendue est vital pour analyser ce qu’un robot moderne peut voir, et c’est particulièrement utile pour revoir un site en staging, où tu ne peux pas utiliser le test en direct de l’outil d’inspection d’URL de la Search Console.

Si tu as réglé le user agent et le viewport sur Googlebot Smartphone, tu vois par exemple exactement comment chaque page se rend sur mobile.

1. Compare le HTML brut et le HTML rendu

En travaillant avec JavaScript, tu peux vouloir enregistrer et afficher le HTML et le HTML rendu dans SEO Spider, depuis 1Configuration›2Spider›3Extraction.

En cochant « Store HTML » et « Store Rendered HTML », tu compares facilement les deux versions et leurs différences, pour t’assurer que le contenu critique et les liens sont présents dans le DOM.

Comparaison entre Original HTML et Rendered HTML dans l’onglet View Source de Screaming Frog avec Show Differences

C’est très utile dans de nombreux cas, par exemple pour déboguer les différences entre ce qu’on voit dans un navigateur et dans SEO Spider, ou simplement pour analyser le rendu du JavaScript et vérifier la présence de certains éléments dans le code.

Si le filtre « Contains JavaScript Content » s’est déclenché pour une page, tu peux passer du filtre ‘HTML’ à ‘Visible Content’ pour voir exactement quel texte n’existe que dans le HTML rendu.

Comparaison du Visible Content entre Original HTML et Rendered HTML dans l’onglet View Source de Screaming Frog

1. Identifier les liens uniquement JavaScript

Autre contrôle important : les liens présents uniquement dans le code rendu. Avec le filtre « Contains JavaScript Links », tu identifies les liens découverts après l’exécution du JavaScript.

Une fois les données collectées, il suffit de cliquer sur une URL dans la fenêtre supérieure, puis sur l’onglet inférieur « Outlinks », et de choisir le filtre « Rendered HTML ».

Onglet Outlinks de Screaming Frog filtré sur les liens présents uniquement dans le Rendered HTML

1. Configurer l’AJAX Timeout

Selon les réponses de ton crawl, tu peux régler le timeout, fixé par défaut à 5 secondes. Très utile en cas de problèmes de rendu des pages avec SEO Spider, depuis 1Configuration›2Spider›3Rendering.

Réglage de l’AJAX Timeout dans la configuration du rendu de Screaming Frog

Le timeout de 5 secondes convient à la plupart des sites, et Googlebot est généralement plus souple : il s’adapte au temps de chargement du contenu, en tenant compte de l’activité réseau et en utilisant beaucoup de cache.

Onglets associés : Onglets inférieurs | Barre latérale | Rapports

Analyser les sites en JavaScript.