SEO pour JavaScript : Une expérience pour tester les moteurs de recherche

Cet article se penche sur les meilleures ressources SEO pour JavaScript et sur un test permettant de comprendre comment les moteurs de recherche (Google, Bing et Yandex) se comportent lorsqu’ils doivent crawler et indexer des pages rendues par JS. Nous examinerons également quelques points à prendre en compte par les experts en SEO et les développeurs.

JavaScript est un acteur majeur du web d’aujourd’hui, et comme l’a dit John Mueller, « il ne disparaîtra pas facilement ».

Le sujet JavaScript est souvent diffamé par la communauté SEO, mais je pense que cela est dû à un manque de compétences techniques en matière de développement JavaScript et de rendu de pages web. Mais cela dépend aussi de la difficulté à communiquer entre les experts SEO et les équipes de développement.

Ce billet est divisé en deux parties : la première (courte) propose quelques ressources pour approfondir le sujet ; dans la seconde (plus approfondie), nous regardons une expérience très simple qui teste les moteurs de recherche sur une page web rendue en JavaScript.

Quelques ressources qui expliquent le SEO pour JavaScript

Dans la vidéo suivante, Martin Splitt, se référant à Google, introduit le sujet en expliquant l’importance de réfléchir d’un point de vue SEO lors du développement de projets réalisés en JavaScript. Il fait notamment référence aux pages qui rendent du contenu critique en JS et aux applications de type page simple.

« Si vous voulez que les ressources soient indexées le plus rapidement possible, assurez-vous que le contenu le plus important se trouve dans la source de la page (rendu côté serveur).« 

Quelle en est la raison ? Parce que nous devons toujours garder à l’esprit le schéma suivant, à savoir les deux vagues d’indexation.

Le flux du crawl, de l’indexation, du rendu et de la réexamination. Et les deux vagues de traitement.

Le contenu généré par JavaScript est considéré dans la deuxième vague d’indexation, car il doit attendre la phase de rendu.

Dans la vidéo suivante, cependant, des conseils fondamentaux de SEO sur les projets développés en JavaScript sont expliqués.

“Nous évoluons vers des expériences utilisateur extraordinaires, mais nous nous dirigeons également vers la nécessité de compétences techniques toujours plus importantes.« 

Un test simple pour comprendre comment les moteurs de recherche traitent le JavaScript

Je vais vous exposer un test que j’ai effectué dans le seul but de retracer les étapes décrites par la documentation de Google (crawl, indexation, rendu, réexamination). Un test, cependant, qui s’étend également au-delà du moteur de recherche de Mountain View.

Note : il s’agit d’un test assez « extrême » en termes de solution technique appliquée, et il a été réalisé à l’aide de simples fonctions JavaScript, sans l’utilisation de frameworks particuliers. L’objectif est uniquement de comprendre la dynamique du moteur de recherche, et non un exercice de style.

1) La page web

Tout d’abord, j’ai créé une page web avec les caractéristiques suivantes :

• Une page HTML contenant les principales balises structurelles, sans texte, à l’exception du contenu de la balise <title>, d’un sous-titre dans une balise <h4> et d’une chaîne dans le pied de page.
• Le contenu, disponible dans le HTML source, a un but précis : fournir aux moteurs de recherche des données dès le premier traitement.
• Une fonction JavaScript, une fois que le DOM (Document Object Model) est complet, se charge de rendre tout le contenu (un article complet généré avec GPT-3).

$(document).ready( function () {
  hydration();
});

• Le contenu rendu par la fonction n’est pas présent sur la page sous forme de chaînes JavaScript ou JSON, mais est obtenu par des appels à distance (AJAX).
• Les données structurées sont également « injectées » via JavaScript qui obtient la chaîne JSON par un appel à distance.
• J’ai volontairement fait en sorte que la fonction JavaScript remplace le contenu de la balise <title>, génère le contenu de la balise <h1> et crée la description. La raison est la suivante : si les données rendues par JS avaient été prises en compte, le snippet du résultat dans SERP aurait complètement changé.
• L’une des deux images qui sont rendues par JS, a été indiquée dans l’en-tête de la page dans une balise <link> (rel = « preload ») pour comprendre si cette action peut accélérer l’indexation de la ressource.

2) Soumission de la page aux moteurs de recherche et le testing

Après avoir publié la page, je l’ai signalée aux moteurs de recherche, et en particulier à Google (via la « vérification des URL » de la Search Console), à Bing (via « soumettre l’URL » du Webmaster Tool) et à Yandex (via « réindexer les pages » du Webmaster Tool).

A ce stade, j’ai réalisé quelques tests.

• L’outil « Fetch & Render » de Merkle, que j’utilise habituellement pour réaliser des tests de rendu, a généré la page correctement. L’outil simule Googlebot en utilisant Chromium 79 headless.Note : parmi les outils Merkle, il y a aussi un « Pre-rendering Tester« , qui vous permet de vérifier la réponse HTML en fonction de l’agent utilisateur qui fait la demande.

Merkle Fetch & Render : outil de test de rendu

• Le test des résultats riches de Google a généré avec succès le DOM et la capture d’écran de la page. L’outil a également détecté correctement les données structurées, identifiant l’entité de type « Article« .

Le DOM généré par le test Google Rich Results

• L’outil de vérification des URL de la Search Console présentait initialement un rendu imparfait par moments. Mais je pense que la raison en était le temps d’exécution.

3) L’indexation

À ce stade, tous les moteurs de recherche ont eu le même comportement : après quelques heures, le résultat était présent dans toutes les SERPs.

Le snippet généré dans la première phase sur Bing, Yandex et Google

Les snippets, comme on peut le voir dans les images, sont composés du contenu de la balise <title> et d’une description obtenue à partir des informations disponibles dans le contenu principal.

Aucune image de la page n’a été indexée.

4) Opérations d’édition, sitemap, API d’indexation Google

Le jour suivant, les extraits étaient les mêmes. J’ai réalisé quelques actions pour envoyer des signaux aux moteurs de recherche.

• J’ai modifié le HTML de la page, en ajoutant le favicon, le nom de l’auteur du billet et la date de publication. L’objectif était de savoir si les moteurs de recherche mettraient à jour le snippet avant une éventuelle analyse du contenu rendu.
• En même temps, j’ai mis à jour le JSON des données structurées en actualisant la date de modification (« dateModified »).
• J’ai envoyé le sitemap contenant l’URL de la page web aux outils pour webmasters des différents moteurs de recherche.
• J’ai signalé aux moteurs de recherche que la page a été modifiée, et en particulier, pour Google, à travers l’API d’indexation.

[Étude de cas] Optimiser le SEO après une refonte de site web

Un an après la refonte de leur site web, EasyCash ont réalisé que la performance qu’ils avaient visée n’était pas au rendez-vous. Ils ont ainsi identifié et résolu différents points SEO bloquants.

Lire l'étude de cas

Les résultats

Que s’est-il passé après quelques jours ?

Google a rendu et retravaillé le snippet

1) Google a rendu le contenu en traitant le JavaScript, puis a retravaillé le résultat sur la SERP en utilisant le contenu de manière correcte.

Google a indexé le contenu rendu à l’aide de JavaScript.

2) La première image de l’article a également été indexée et est apparue sur Google Images.

L’image du post, rendue par JavaScript, apparaît sur Google Images.

3) Les snippets sur Bing et Yandex n’ont pas changé. Cela signifie que dans les jours qui ont suivi la publication, ils n’ont pas pris en compte le DOM final.

4) L’image montrée dans le lien pour la précharge n’a pas reçu un traitement favorable par rapport à l’autre.

Rendu de page JavaScript (β) par Yandex

Dans les outils pour webmasters de Yandex, il existe une fonction « bêta » qui vous permet de spécifier le comportement du robot lorsqu’il crawle les pages.

Le panneau de configuration du rendu Yandex

Vous pouvez suggérer d’exécuter le JavaScript pour compléter le rendu, ou de ne pas l’exécuter. L’option par défaut laisse à l’algorithme la « liberté » de choisir la meilleure action.

Dans le cas spécifique où la quasi-totalité du contenu est généré côté client, mais plus généralement, par exemple pour un framework JavaScript, il est conseillé de forcer le rendu.

Rendu dynamique

Dans la dernière phase de testing, j’ai appliqué une solution de rendu dynamique pour Bing et Yandex. Cette solution permet de différencier la réponse qui est envoyée au client afin que :

• Les navigateurs des utilisateurs reçoivent la réponse contenant le HTML et le JavaScript nécessaires pour effectuer le rendu ;
• Le crawler seo reçoit une version statique de la page, contenant tout le contenu critique dans la source.

Comment fonctionne le rendu dynamique

Après avoir terminé la mise en œuvre, j’ai demandé une nouvelle indexation par le biais des outils Bing et Yandex.

Yandex, en quelques heures, a reconstruit le snippet dans les SERP comme suit. Yandex a donc considéré que la nouvelle version avait été rendue côté serveur.

Le snippet de Yandex après le rendu dynamique

Bing n’a pas modifié le résultat dans le temps prévu pour le test, mais l’aurait certainement (ehm… du moins je l’espère) intégré dans les jours suivants.

Conclusions

Ce test simple démontre que Google fonctionne comme le précise la documentation, en respectant les deux phases du schéma vu dans la première partie du post. Dans la première phase, en effet, il a indexé presque instantanément le contenu présent dans la source de la page (le HTML généré côté serveur) ; dans la seconde, en quelques jours, il a indexé les parties rendues via JavaScript.

Bing et Yandex, en revanche, ne semblent pas détecter le contenu généré via JavaScript… du moins dans les jours qui suivent la publication.

Ces éléments mettent en évidence certains aspects liés à JavaScript que je vais essayer d’expliquer un peu plus en détail ci-dessous.

• L’accent mis sur les marchés de référence pour la communication doit être maintenu : si nous nous adressons à un public qui utilise d’autres moteurs de recherche que Google, nous risquons de ne pas être aussi visibles que nous le souhaiterions.
• Même si les utilisateurs utilisent Google, il faut tenir compte du temps nécessaire pour obtenir l’information complète dans la SERP. La phase de rendu, en effet, est très coûteuse en termes de ressources : dans le cas du test, avec une seule page en ligne, le snippet a été correctement obtenu en quelques jours. Mais que se passerait-il si l’on travaillait sur un site web de très grande taille ? Le « budget » que le moteur de recherche met à notre disposition et les performances du site deviennent déterminants.
• Je suis convaincu que JavaScript nous permet d’offrir aux utilisateurs des expériences supérieures, mais les compétences requises pour y parvenir sont nombreuses et coûteuses. En tant qu’experts en SEO, nous devons évoluer pour proposer les meilleures solutions. Le pré-rendu ou le rendu dynamique restent des techniques utiles pour générer du contenu critique sur des projets qui doivent assurer une visibilité globale.
• Tous les frameworks de JavaScript modernes, basés sur l’architecture JAMstack, tels que Astro, Gatsby, Jekyll, Hugo, NuxtJS et Next.JS, offrent la possibilité de rendre le contenu côté serveur, afin de fournir une version statique des pages. De plus, Next.JS, qui à mon avis est le plus avancé, permet un mode de rendu « hybride », appelé « Incremental Static Regeneration » (ISR). L’ISR permet de générer des pages statiques de manière incrémentielle, avec un traitement de fond constant. Cette technique permet une navigation très performante.

“ La question est la suivante : cela vaut-il le coup d’introduire une telle « complexité » dans un projet ? La réponse est simple : oui, si l’on veut produire une expérience utilisateur exceptionnelle ! « 

 

Notes Complémentaires

• Il faut faire attention à la différence entre les événements « document ready » et « window loaded » : le premier intervient après la génération du DOM, tandis que le second intervient lorsque le DOM a été généré et que les ressources ont été chargées.
• Il est bien évident que pour des tests comme celui-ci, cela n’a aucun sens d’analyser la copie de cache de Google, car lorsque les pages sont ouvertes, le JS serait ré-exécuté, ne donnant pas la perception du contenu pris en compte par Google.

Bon JavaScript, et bon SEO !