Site en Javascript : les bonnes pratiques pour que Google le crawle efficacement

Referencement

SEO / Referencement 45 Views comments

Le Javascript est un langage prisé par les développeurs& : présent depuis les débuts du net, 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 websites. 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 seen 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 query de liens

Sur un website, Google va lire le HTML de la web page d'accueil, puis va suivre les différents liens présents sur la web 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 website 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 website possédant du Javascript, une troisième étape apparaît& : le rendering. Googlebot va exécuter le Javascript durant cette part, 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 selected. Ce qui signifie que le contenu d'un website 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 website regular, 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 options 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 website sont en HTML", explique Audrey Schoonwater, directrice de l'agence Witamine. Remark s'en assurer& ? "By way of les logs serveurs, sinon by way of 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 website, comme une web 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 answer& ?

Autre answer, l'affichage dynamique. C'est d'ailleurs la answer 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 options 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 pictures et le CSS, comme le ferait un navigateur classique. Il en type un fichier HTML appelé HTML last ou rendu. Le pre-rendering est terminé… pour une seule page. "Il faut faire le pre-rendering de toutes les pages du website, ou en tout cas, les plus importantes, et fournir le HTML brut à Googlebot pour améliorer la crawlabilité d'un website 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 ultimate au service distant et là deux cas de figure se posent. Si la web page est en cache, elle est retournée immédiatement, si elle n'était pas en cache, la web 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 answer, le website devient dépendant à 100% d'un service externe pour sa disponibilié. "Autre level faible de la answer, si les pages doivent être générées à la volée, le service peut être ralenti automotive le rendering se fait sur un serveur distant" indique l'professional. & A l'inverse, Rendertron s'opère en interne, ce qui substitute la dépendance à l'outil en interne mais oblige le website a supporter la charge du pre-rendering.

Comments