Site en Javascript : les bonnes pratiques pour que Google le crawle efficacement
Le Javascript est un langage prisé par les développeurs : présent depuis les débuts du web, l'évolution des frameworks lui permet de rester à jour. Fédérant une impressionnante communauté grâce aux nombreuses possibilités offertes par le langage, Javascript est présent dans de très nombreux sites. Pourtant, il reste une épine dans le pied des référenceurs. "La problématique du framework JS, c'est que le contenu n'est pas visible aux yeux de Google", explique Olivier Papon, fondateur de SEOlyzer. Pour comprendre cela, il faut se pencher sur le fonctionnement du crawl par Googlebot.
Une question de liens
Sur un site, Google va lire le HTML de la page d'accueil, puis va suivre les différents liens présents sur la page pour faire de même sur les autres pages. Cela va lui permettre d'établir un index des pages présentes, d'où l'importance d'un maillage interne de qualité. Dans le cas d'un site comportant seulement du HTML, le contenu va être détecté par Google, indexé, puis l'opération sera répétée sur chaque page que le bot aura détectée. Dans le cas d'un site possédant du Javascript, une troisième étape apparaît : le rendering. Googlebot va exécuter le Javascript durant cette phase, mais comme celle-ci est coûteuse, elle peut ne pas être réalisée immédiatement. Le robot va différer cette étape et se concentrer sur autre chose. Ce qui signifie que le contenu d'un site en Javascript prendra plus de temps pour être compris, indexé et actualisé par Google dans le search. "Le rendering coûte des ressources et du temps à Google. Par rapport à un site normal, on rajoute une étape de traitement. Tout ce HTML généré en plus, seuls Google et le Googlebot le verront, pas l'utilisateur" détaille Olivier Papon.
"Faciliter la vie de Google"
Heureusement, des solutions existent pour palier à ce problème. "Pour faciliter la vie de Google, il faut s'assurer que les liens vers les plus grosses pages du site sont en HTML", explique Audrey Schoonwater, directrice de l'agence Witamine. Comment s'en assurer ? "Via les logs serveurs, sinon via des crawlers Javascript comme Screaming Frog. Ces solutions vont nous permettre de simuler ce que voit Googlebot au moment du crawl", précise l'experte. En effectuant cette opération en amont, l'idée est de détecter des parties importantes du site, comme une page catégorie par exemple, dont les liens peuvent être cachés par le temps de chargement du Javascript et donc mises en attente par Googlebot. Une fois le problème détecté, il suffira de le corriger.
Le pré-rendering, la solution ?
Autre solution, l'affichage dynamique. C'est d'ailleurs la solution que Google recommande. Autrement dit, servir le contenu "normal" aux internautes et servir un contenu pré-affiché pour les robots d'exploration. Concrètement, il s'agit d'effectuer le rendering soi-même pour offrir à Google un fichier HTML sans Javascript à exécuter. Deux solutions s'offrent aux webmasters pour exécuter le pré-rendering : faire appel à un service externe, soit le faire en interne. "Dans les deux cas, on utilise un navigateur headless. C'est comme si on faisait tourner Google Chrome mais sans interface visuelle", précise Olivier Papon. Le navigateur va exécuter les pages, télécharger les images et le CSS, comme le ferait un navigateur classique. Il en sort un fichier HTML appelé HTML final ou rendu. Le pre-rendering est terminé… pour une seule page. "Il faut faire le pre-rendering de toutes les pages du site, ou en tout cas, les plus importantes, et fournir le HTML brut à Googlebot pour améliorer la crawlabilité d'un site en JS", affirme le fondateur de SEOlyzer.
Des outils comme Pupeteer, Rendertron ou Prerender.io permettent de faire du pre-rendering. Leur fonctionnement est simple : "Le logiciel vérifie si la page demandée est le fait d'un crawler comme Googlebot, si c'est le cas il demande le HTML rendu final au service distant et là deux cas de figure se posent. Si la page est en cache, elle est retournée immédiatement, si elle n'était pas en cache, la page est générée puis retournée", explique Olivier Papon. Le principal avantage de ces outils est de ne pas supporter la charge (conséquente) d'un rendering en local. Un avantage contrebalancé par deux inconvénients majeurs, notamment pour Prerender.io, qui est un SaaS. En effet, en utilisant cette solution, le site devient dépendant à 100% d'un service externe pour sa disponibilié. "Autre point faible de la solution, si les pages doivent être générées à la volée, le service peut être ralenti car le rendering se fait sur un serveur distant" indique l'expert. A l'inverse, Rendertron s'opère en interne, ce qui replace la dépendance à l'outil en interne mais oblige le site a supporter la charge du pre-rendering.