Analyse de sites en Javascript

Comment analyser les sites web qui contiennent du contenu Javascript et qui pourraient gêner l'exploration des robots des moteurs de recherche.

Introduction de sites Javascript

Il y a encore quelques années, l’un des problèmes les plus courants en matière d’optimisation du référencement était l’indexation, via Javascript, des pages dont le contenu était créé de manière dynamique. Le problème était lié aux robots des moteurs de recherche qui n’étaient pas en mesure de scanner et d’indexer ces ressources et ne prenaient en compte que le contenu du code source du HTML statique.

Parallèlement, on a assisté à une évolution des frameworks tels que AngularJS, React, Vue.JS, des applications à page unique (SPA) et des applications web progressives (PWA), ce qui a conduit Google à évoluer de manière significative et à atteindre une pleine maturité dans la compréhension des pages web en tant que navigateur moderne.

Toutefois, bien que Google soit aujourd’hui généralement en mesure d’analyser et d’indexer la plupart des contenus JavaScript, il est recommandé d’utiliser un rendu côté serveur, un pré-rendu ou un rendu dynamique plutôt que de s’appuyer sur le JavaScript côté client, car il est encore difficile pour les robots d’indexation de traiter le JavaScript avec succès ou immédiatement.

Pour ces raisons, il est essentiel, lors de l’analyse, de comprendre les différences entre le DOM, une fois que JavaScript est entré en jeu et a construit la page web, et la réponse statique du HTML.

Javascript, le spider seo et quelques contre-indications

Pour remédier à ce besoin, Screaming Frog vous vient en aide avec son mode “Javascript Rendering”, qui a intégré la bibliothèque “Chromium” afin d’émuler au mieux le comportement du Google Spider.

javascript rendering per seo audit di siti web in Javascript

Aperçu: en 2019, Google a mis à jour le service de rendu Web (WRS) qui était auparavant basé sur Chrome 41 avec la dernière version stable de Chrome, ce qui lui a permis de prendre en charge plus d’un millier de fonctions supplémentaires.

1. Examinons quelques aspects inhérents aux sites en Javascript :

  • 1. Activez soigneusement la fonction “Javascript Rendering”.

Bien qu’il soit très important de comprendre les différences entre le DOM et le html statique après l’exécution de Javascript, je vous déconseille d’activer le mode “Javascript Rendering” sans discernement pour tous les sites web.

L’exploration avec JavaScript est plus lente et plus intensive pour le serveur, car toutes les ressources (JavaScript, CSS, images, etc.) doivent être récupérées pour le rendu de chaque page web. Cette criticité n’est pas pertinente pour les petits sites, mais pour les grands portails ou le commerce électronique, elle peut devenir un obstacle à votre numérisation en termes de temps et de Ram.

  • 2. Examinez les principes et les limites de l’analyse Javascript

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

Google exige toujours des URL propres et uniques pour une page, et les liens doivent figurer dans des balises d’ancrage HTML appropriées (vous pouvez proposer un lien statique ou appeler une fonction JavaScript).

Le Google Spider n’interagit pas comme les utilisateurs, c’est-à-dire qu’il ne clique pas sur les ressources en chargeant des événements supplémentaires après le rendu (un clic, un survol ou un défilement, par exemple).

L’instantané de la page rendue est pris lorsqu’il est déterminé que l’activité du réseau s’est arrêtée, ou au-delà d’un certain seuil de temps. Si une page prend beaucoup de temps à s’afficher, elle risque d’être ignorée et des éléments peuvent ne pas être vus et indexés.

En général, Google rend toutes les pages, mais ne les met pas en file d’attente pour le rendu si elles ont un “noindex” dans la réponse HTTP initiale ou un code HTML statique.

Enfin, le rendu de Google est distinct de l’indexation. Google analyse d’abord le code HTML statique d’un site web et reporte le rendu jusqu’à ce qu’il n’y ait plus de ressources.

Lorsque vous commencez le développement d’un site web, la connaissance de ces conditions est vitale pour le succès ou l’échec du projet en termes de référencement organique.

Javascript côté serveur et côté client

Google déconseille de s’appuyer sur le JavaScript côté client et recommande de développer avec un “enrichissement progressif”, en construisant la structure et la navigation du site en utilisant uniquement le HTML, puis en améliorant l’apparence et l’interface du site à l’aide d’AJAX.

Par conséquent, si vous utilisez un framework JavaScript, Google recommande le rendu côté serveur, le pré-rendu ou le rendu hybride qui peuvent améliorer les performances pour les utilisateurs et les robots d’indexation des moteurs de recherche.

Grâce au rendu côté serveur (SSR) et au pré-rendu, l’exécution JavaScript des pages fournit une version HTML initiale rendue et prête à être numérisée.

Le rendu hybride (parfois appelé “isomorphe”) identifie une version du rendu qui exécute Javascript côté serveur pour le chargement initial de la page et HTML et Javascript côté client pour les éléments non critiques et les pages suivantes.

De nombreux frameworks JavaScript, tels que React ou Angular Universal, permettent un rendu côté serveur et hybride.

Vous pouvez également opter pour l’utilisation du rendu dynamique.

Cela peut être particulièrement utile lorsqu’il n’est pas possible d’apporter des modifications à la base de code frontale. Le rendu dynamique permet de passer d’un rendu côté client pour les utilisateurs à un contenu pré-rendu pour les moteurs de recherche.

Temps d’exploration par Google

Bien que les trois solutions susmentionnées permettent de résoudre la plupart des problèmes liés au crawling, il est bon de tenir compte d’un autre aspect.

Google dispose d’un processus d’indexation en deux étapes, dans lequel il analyse et indexe d’abord le code HTML statique, puis revient plus tard, lorsque les ressources sont disponibles, pour rendre la page et pour analyser et indexer le contenu et les liens dans le code HTML rendu.

Le temps nécessaire entre l’exploration et le rendu pourrait également être très long (jusqu’à 7 jours) et cette condition est un problème pour les sites qui s’appuient sur du contenu qui, par nature, présente des caractéristiques d’actualité ou qui expire simplement (par exemple, site d’actualités, événements, etc.) ; alors que le temps moyen (déclaré au Chrome Dev Summit en 2019) est de 5 secondes.

Comment identifier Javascript

Identifier un site construit à l’aide d’un cadre JavaScript peut être assez simple, mais diagnostiquer des sections, des pages ou simplement des éléments plus petits qui sont adaptés dynamiquement à l’aide de JavaScript peut s’avérer beaucoup plus difficile. Lors de la mise en place d’un audit Seo, il est bon de déterminer immédiatement s’il y a présence de Javascript et d’essayer de comprendre si le site peut avoir des problèmes lors des différents crawls des agents utilisateurs.

Il existe plusieurs façons de savoir si le site est construit à l’aide d’un cadre JavaScript :

  • 1. Identifier Javascript avec Screaming Frog

Par défaut, Seo Spider analyse en utilisant l'”ancien schéma d’analyse AJAX”, ce qui signifie que JavaScript est désactivé et que seul le HTML brut est analysé.

Si le site n’utilise que du JavaScript côté client, vous n’obtiendrez qu’une réponse 200 à la suite de votre analyse de la page d’accueil, avec quelques fichiers “Javascript et CSS”.

Comme vous pouvez le voir, l’onglet “Outlinks” ne contient pas non plus d’hyperliens car ils ne sont pas rendus en html brut et ne peuvent pas être vus par le Seo Spider.

analisi oulinks con screaming frog

Bien que ce soit souvent le signe que le site Web utilise un cadre JavaScript, avec un rendu côté client, cela ne vous indique pas si d’autres dépendances JavaScript existent également sur le site.

Par exemple, un site web peut ne disposer de JavaScript que pour charger des produits sur des pages de catégories ou pour mettre à jour des éléments de titre.

Comment les trouver facilement ?

> > Afin d’identifier JavaScript plus efficacement, il est nécessaire de passer en mode de rendu JavaScript (‘Config Spider Rendering’) et d’analyser le site, ou un échantillon de modèles du site entier.

Le SEO Spider analysera à la fois le code HTML original et le code HTML rendu pour identifier les pages dont le contenu ou les liens ne sont disponibles que du côté client et pour signaler d’autres dépendances clés.

filtri della scheda Javascript previsti su screaming frog

Pour vous aider à résoudre les problèmes courants des sites Javascript côté client, vous disposez d’une liste complète de filtres pour vous guider dans la définition de votre audit Seo.

Le Seo Spider vous alertera s’il y a du contenu qui ne se trouve que dans le HTML rendu après l’entrée en jeu du JavaScript, vous donnant ainsi une vue complète du comportement du site web.

Dans cet exemple, 100 % du contenu se trouve uniquement dans le rendu HTML, car le site est entièrement basé sur JavaScript.

Dans ce cas, l’examen a porté sur le nombre de mots trouvés dans le contenu des pages, mais vous pouvez également trouver, par exemple, des références de pages avec des liens uniquement dans le code HTML rendu et y remédier en suivant les instructions de Google.

analisi links scoperti dopo renderizzazione javascript

Cette fonction de Screaming Frog est également très utile pour vérifier si les métabalises ou d’autres éléments de référencement sont présents dans le code HTML statique ou s’ils ne sont servis et/ou modifiés qu’une fois que le code Javascript a été exécuté.

  • 2. Désactiver Javascript dans le navigateur

Une autre solution pour comprendre la nature des sites web consiste à désactiver Javascript directement dans le navigateur et à recharger la page. S’il apparaît en blanc, il ne fait aucun doute que le site web a été conçu avec Javascript.

  • 3. Recherche de Javascript directement dans le code source

La troisième solution consiste à faire un clic droit sur le site web et à visualiser le code source en examinant le contenu Html, qu’il s’agisse de texte, de liens ou de signes des bibliothèques des différents frameworks JS.

En suivant ce processus, vous voyez le code avant qu’il ne soit traité par le navigateur et qui correspondra à ce que le Seo Spider scanne, lorsqu’il n’est pas en mode de rendu JavaScript.

Si vous essayez de rechercher quelques éléments mais que vous n’obtenez aucune occurrence dans le code source, il est probable qu’ils sont générés dynamiquement dans le DOM et qu’ils ne seront affichés que dans le code rendu.

esempio source code sito web

<> Dans ce cas, le corps de la balise est complètement vide, ce qui indique clairement que le site dispose de JS.

  • 4. Auditer le code rendu

La première question à vous poser est la suivante : quelle est la différence entre le code rendu et la source HTML statique ? Pour le savoir, il suffit de faire un clic droit et d’utiliser “inspecter l’élément” dans Chrome pour voir le code HTML rendu. Vous pouvez souvent voir le nom du framework JS dans le code rendu, comme “React” dans l’exemple ci-dessous.

Vous constaterez que le contenu et les hyperliens se trouvent dans le code rendu, mais pas dans le code source HTML original. C’est ce que le Seo Spider verra lorsqu’il sera en mode de rendu JavaScript.

> En cliquant sur l’élément HTML d’ouverture, puis sur “copy outerHTML”, vous pouvez comparer le code source rendu avec l’original.

Javascript Crawl avec Screaming Frog

Après avoir défini la présence de JS et compris les pièges, vous pouvez commencer votre audit Seo avec Screaming Frog en le configurant en mode de rendu JavaScript. Cela vous permet d’analyser des sites web et des frameworks dynamiques et riches en JavaScript, tels qu’Angular, React et Vue.js.

  • 1. > > Pour analyser un site Web JavaScript, ouvrez Seo Spider, cliquez sur “Configuration Spider Rendering” et modifiez “Rendering” en “JavaScript”.
Rendering Javascript con il seo spider screaming frog
  • 2. Configurez l’agent utilisateur et la taille de la fenêtre

Configurez le user-agent

> > Configuration En-tête HTTP User-Agent

Et la taille de la fenêtre

> > Configuration Spider Rendering

Par défaut, la fenêtre de visualisation est définie sur “Google Mobile : Smartphone”, conformément à l’orientation “Mobile Index First” du moteur de recherche.

  • 3. Vérifier les ressources et les liens externes

> Assurez-vous que les ressources telles que les images, CSS et JS sont cochées dans la “Configuration du Spider”. Si les ressources se trouvent sur un sous-domaine différent ou sur un “domaine racine” distinct, activez également l’option “vérifier les liens externes”, sinon elles ne seront pas analysées et donc affichées.

configurazione crawl per siti Js
  • 4. Numérisation
crawl di sito in javascript
  • 5. Voir l’onglet Javascript

Dans l’onglet JavaScript, vous disposez de 15 filtres pour vous aider à prendre en compte les dépendances JavaScript et à isoler les problèmes courants.

filtri della scheda Javascript previsti su screaming frog
  • Pages avec ressources bloquées: identifie toutes les pages dont les ressources (telles que les images, JavaScript et CSS) sont bloquées par le fichier robots.txt. Cette situation peut poser un problème car les moteurs de recherche ne peuvent pas accéder aux ressources essentielles pour restituer les pages avec précision. Je vous recommande de mettre à jour le fichier robots.txt pour permettre à toutes les ressources critiques d’être analysées et utilisées pour rendre le contenu du site. Les ressources qui ne sont pas essentielles (par exemple, l’intégration de Google Maps) peuvent être ignorées.
  • 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 uniquement dans le HTML rendu : pages qui contiennent un h1 uniquement dans le HTML rendu 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 Updated by JavaScript: pages dont le h1 a été modifié par JavaScript. Cela signifie que le h1 en HTML brut est différent du h1 en HTML rendu.
  • Utilise les anciennes URL AJAX Crawling Scheme: identifie les URL qui utilisent encore l’ancien schéma de crawling AJAX (une URL contenant un fragment de hachage # !) qui a été officiellement déprécié en octobre 2015. Envisagez le rendu côté serveur ou le pré-rendu lorsque c’est possible, et le rendu dynamique comme solution alternative.
  • Uses Old AJAX Crawling Scheme Meta Fragment Tag: inclut les URL qui comprennent une balise meta fragment indiquant que la page utilise toujours l’ancien schéma de crawling AJAX qui a été officiellement mis au rancart en octobre 2015. Il est conseillé de mettre à jour les URL afin de suivre l’évolution de JavaScript sur les sites web actuels. Envisagez le rendu côté serveur ou le pré-rendu lorsque c’est possible, et le rendu dynamique comme solution de contournement. Si le site comporte encore l’ancienne balise méta fragment par erreur, celle-ci doit être supprimée.
  • 6. Surveiller les ressources bloquées

Gardez un œil sur tout ce qui apparaît sous le filtre “Pages avec ressources bloquées” dans l’onglet “Javascript”.

Les ressources bloquées peuvent également être affichées pour chaque page dans l’onglet “Page rendue”, à côté de l’écran rendu dans le volet inférieur de la fenêtre. Dans les cas les plus graves, si un site JavaScript bloque complètement les ressources JS, le site ne sera tout simplement pas analysé.

Les ressources bloquées sont également visibles dans l’onglet “Code de réponse”.

> Codes de réponse Ressource bloquée

> > Les pages et les ressources individuelles bloquées peuvent également être exportées en masse à l’aide du rapport “Bulk Export Response Code Blocked Resource Inlinks to be unblocked and optimised” (Exportation en masse des liens de ressources bloquées par le code de réponse à débloquer et à optimiser).

  • 7. Afficher les pages rendues

Avec Screaming Frog, il est possible d’afficher la page rendue dans l’onglet “Page rendue” qui apparaît dynamiquement au bas de l’interface utilisateur lors de l’exploration en mode de rendu JavaScript.

Si la page ne se charge pas, envisagez d’intervenir sur le délai d’attente AJAX directement dans la configuration de Seo Spider.

La visualisation de la page rendue est essentielle pour analyser ce qu’un robot de recherche moderne est capable de voir, et elle est particulièrement utile lors de l’examen en phase d’essai, lorsqu’il n’est pas possible d’utiliser la fonctionnalité native “Fetch & Render” de Google via la Search Console.

Si vous avez ajusté le user-agent et le viewport sur Googlebot Smartphone, vous pouvez voir exactement comment chaque page est rendue sur mobile, par exemple.

  • 8. Comparer le HTML brut et le HTML rendu

Vous pouvez souhaiter stocker et afficher du HTML et du HTML rendu dans Seo Spider lorsque vous travaillez avec JavaScript.

> > > Configuration Spider Extraction Store Html/Render Html

En cochant les options appropriées “Store HTML” et “Store HTML Rendered”, vous pouvez facilement comparer les deux versions et être en mesure de comparer les différences pour vous assurer que le contenu ou les liens critiques sont présents dans le DOM.

comparazione raw e rendered pages

C’est très utile pour une variété de scénarios, tels que le débogage des différences entre ce qui est vu dans un navigateur et dans le SEO Spider, ou simplement pour analyser la façon dont le JavaScript a été rendu, et si certains éléments sont dans le code.

Si le filtre “Contenu JavaScript” a été activé pour une page, il est possible de passer de “HTML” à “Contenu visible” pour identifier exactement le contenu textuel qui se trouve uniquement dans le rendu HTML.

  • 9. Identifier les liens JavaScript uniquement

Une autre vérification importante concerne les liens qui ne sont présents que dans le texte rendu. Grâce au filtre “Contient des liens JavaScript”, vous pouvez identifier les hyperliens qui sont découverts après l’exécution de JavaScript.

Une fois les données collectées, il vous suffit de cliquer sur un URL dans la fenêtre supérieure, puis sur l’onglet inférieur “Outlinks” et de sélectionner “Rendered HTML” comme filtre.

dettagli pagine renderizzate
  • 10. Configuration du délai d’attente AJAX

En fonction de vos réponses au crawl, vous pouvez choisir le délai d’attente, qui est fixé par défaut à 5 secondes. Cette fonction est très utile en cas de problèmes de rendu des pages avec le Seo Spider.

> > Configuration Spider Rendering

configurazione dell'AJAX timeout con screaming frog

Le délai de 5 secondes convient généralement à la plupart des sites web, et Googlebot est normalement plus souple : il s’adapte au temps de chargement d’une page, en tenant compte de l’activité du réseau et en effectuant une grande partie de la mise en cache.

Tutoriel vidéo sur le crawl des sites en Javascript

React vs. Google

Seo Spider Tab