JavaScript et SEO

Guillaume André

5 novembre, 2020

9 min

Développement

Au cours de cet article nous allons tenter d’expliquer comment fonctionne le moteur de recherche Google lorsqu’il est confronté à du JavaScript. Nous allons aussi voir si JavaScript et SEO sont si antinomiques que ça !

Chez Wex IT en fonction des demandes et des attentes de nos clients nous sommes amené à faire différent choix de technologies pour ce qui concerne la dynamique des interfaces web : Javascript vanilla, React, VueJS… Une chose est sûre c’est que nous apportons la même qualité finale à nos pages qu’elles soient avec ou sans JavaScript. Nous allons voir comment avec les bons outils il est possible d’arriver au même résultat en terme de SEO.

Les cas de figures

Afin d’aborder la problématique dans son ensemble nous allons aborder 3 cas de figures possibles :

Cas de figure n°1

Votre site n’utilise quasiment pas de JavaScript : Nous sommes dans le cas d’un référencement de site traditionnel. Le moteur de recherche Google sait lire la totalité du contenu et récupérer les informations importantes. Hormis le balisage, la sémantique, les données structurées et les recommandations d’une bonne agence de SEO, aucune autre technologie spécifique est à mettre en place.

Cas de figure n°2

Votre site utilise du Javascript pour afficher des listes spécifiques ou rafraîchir des données ponctuelles :

Dans ce cas de figure il peut s’avérer que certaines parties de vos pages soit générées avec du JavaScript. On pense par exemple aux listing, à la pagination (sans rafraichissement de page), aux scroll infini, aux slides, aux carrousels, à certains liens de type onclick, etc. Ce sont ces interactions JavaScript qui peuvent, parfois, rendre invisible certaines parties de vos contenus aux yeux d’un moteur de recherche.

Astuce : Pour vérifier si vous vous trouver dans ce cas de figure rien de tel que la source de votre page qui est ni plus ni moins ce que voit un moteur de recherche. Clique droit > « Afficher le code source de la page » identifiez l’élément en question et vérifier si le contenu est visible ou pas. Si vous avez affaire à une balise vide c’est que par défaut les moteurs de recherche n’y ont pas accès et c’est ce point qu’il va falloir travailler.

Cas de figure n°3

Votre site ou une portion de votre site est une Single Page Application (SPA) :

Ce cas décrit les applications et site web entièrement réalisés en JavaScript mais aussi les sites qui ont une approche JavaScript spécifique dans l’objectif d’améliorer l’expérience utilisateur d’une portion de votre site (exemple : un tunnel de commande complètement dynamisé, une page de filtre à facette, etc). On parle ici des technologies React, Vue, et Angular.

Par défaut et sans configuration aucune, les sites faisant parti de ce cas de figure présentent un code source extrêmement léger, en effet, JavaScript injecte la totalité du site au sein d’une seule et même balise parente appelée le shell. On voit très vite la problématique que va rencontrer un moteur de recherche à la lecture de cette source “vide”.

En fonction de la situation dans laquelle vous vous trouvez nous allons découvrir quelles solutions nous pouvons apporter pour être bien compris et lu des moteurs de recherche.

Le rendering qu’est ce que c’est ?

Les cas de figures présentés ci-dessus traitent tous de la même problématique : le rendering.

Le rendering c’est le processus qui consiste à remplir un template html avec de la donnée reçue depuis une API ou une base de donnée. Ce processus peut-être réalisé à deux niveaux en fonction des choix technologiques du projet :

Du côté du serveur (Cas de figure 1 et 2), c’est le cas par exemple avec un usage classique de PHP (WordPress, Prestashop, avec des paramètres par défaut). On parle alors de rendering server side, celui-ci expose aux moteurs de recherches la totalité du contenu html ;
Du côté du client (Cas de figure 2 et 3), on parle alors de rendering client side, c’est l’approche via JavaScript et les frameworks front (React, Vue, Angular). Ici le client (ou le robot) télécharge le template vide d’un côté, le javascript de l’autre, et c’est le client (le navigateur) qui s’occupe de faire le rendu après avoir récupéré les données.

Par défaut on constate donc que le rendering client side est plus lourd que le rendering server side.

Comment Google gère-t-il JavaScript et jongle-t-il entre les différents types de rendu ?

Le schéma classique d’une visite de Google Bot sur une page web se présente comme suit :

Google Bot crawl votre site une première fois sans executer JavaScript. A ce stade il s’occupe d’indexer chaque page et d’aller de page en page en suivant les liens. Il Crawl et il index. Pour Google, l’objectif de cette étape est d’indexer le plus rapidement possible le plus de contenu possible. Si il détecte du JavaScript sur une de vos pages, il programme un futur passage pour effectuer la 3eme étape qui est le rendering. L’étape de rendering est décorrélé des étapes de crawling et d’indexing car celle-ci est gourmande, explications…

Ce futur passage du bot fera l’objet d’une attention particulière à JavaScript pour cela Google bot utilise un “Chrome headless” pour simuler un client (navigateur) classique (qui utiliserait Google Chrome) et récupérer le markup HTML généré par votre site avec JavaScript : c’est le rendering. Sur cette 2ème vague de passage Google ne s’engage pas sur les délais et la rapidité. D’où l’intérêt de capitaliser sur le premier passage. Google précise d’ailleurs que cette 2ème vague n’est pas optimum et efficace sur les sites importants avec beaucoup de contenus et où le contenu change souvent.

Source : https://developers.google.com/search/docs/guides/javascript-seo-basics?hl=fr

Dynamic Rendering

Le Dynamic Rendering est une solution poussée par Google qui consiste à faire du cloaking autorisé, elle est idéal dans les cas de figure 2 et 3. L’objectif de cette technique est de proposer 2 versions de votre site : une version pour Google Bot et une version pour les visiteurs. Cet aiguillage du trafic est réalisé sur base du User-Agent. Cela permet d’optimiser un maximum le contenu crawlable par Google Bot. On utilise principalement cette technique dans le cadre d’une Single Page Application pour qui le contenu change souvent. Le gros avantage du Dynamic Rendering c’est qu’il n’a pas besoin de la 2ème vague, c’est logique, il ne rencontre pas de JavaScript puisqu’il est se retrouve sur la version optimisée.

On peut alors très vite se poser la question suivante à savoir si Google (https://developers.google.com/search/docs/guides/dynamic-rendering?hl=fr) ou Bing (https://blogs.bing.com/webmaster/october-2018/bingbot-Series-JavaScript,-Dynamic-Rendering,-and-Cloaking-Oh-My) peuvent considérer ca pour du cloaking. La réponse officielle des deux services est unanime. Non, dès lors que vous êtes de bonne foie et que vous délivrez le même contenu à vos utilisateurs et aux robots.

Pour mettre en oeuvre Dynamic Rendering il est possible d’utiliser ce qu’on appel un headless Chrome (navigateur sans tête) tel que Rendertron, PhantomJS, Puppeteer, etc. Il va servir d’intermédiaire, de passe plat. Cela permet de récupérer un code JavaScript de l’exécuter et d’obtenir son rendu final (dont le contenu à indexer). C’est un middleware que l’on va déclencher au niveau du user-agent si on est en présence de Google Bot ou Bing par exemple. Il simule le passage d’un utilisateur pour récupérer le code source rendu final et pas celui chargé au lancement de la page. Ainsi on évite de devoir attendre le 2ème passage de Google pour se faire indexer son contenu, c’est l’objectif !

Source : https://developers.google.com/search/docs/guides/dynamic-rendering?hl=fr

Quelles autres technologies possibles ?

Chaque framework propose des outils pour mettre en place des optimisations SEO par défaut que ce soit sur React, avec / React helmet , Vue avec vue-meta.

Ces fonctionnalités bien que très utiles restent tout de même limités. Elles permettent de modifier les balises méta d’une page mais nécessitent le passage de la 2ème vague de Google Bot ce qui n’est pas optimal.

Pour combler cette lacune l’idée est de coupler ces technologies à d’autres technologies pour arriver à se faire référencer dès la première vague. L’objectif va donc être de proposer un site dit classique à base de HTML / CSS comme on le faisait au début du web en termes de fichiers statiques. Ainsi si un robot passe il récupéra les documents statiques et si c’est un visiteur la page ayant du JavaScript se verra dynamisée par celui-ci.

Chez Wex IT sur les sites e-commerce on a pour habitude d’utiliser soit Next.JS quand on travaille sur React soit Nuxt quand on travaille sur Vue. Ce sont quasiment les mêmes outils ils permettent d’avoir une approche hybrid SSR et SSG. En plus de ces aspects ils apportent aussi une organisation dans l’arborescence du projet, et une structure de dossier à un projet full JavaScript. Notre objectif chez Wex IT c’est de tendre vers le full statique quand c’est possible étant donné que c’est le plus performant.

Pour Angular “l’équivalent” c’est Angular Universal qui est un module qui délivre du html statique au client et tourne sur le serveur.

SSG & SSR

Le SSG (pour STATIC SITE GENERATION) permet de générer des fichiers statiques de votre site à un instant T de l’autre côté le SSR (pour SERVER SIDE RENDERING) va effectuer la même opération mais au moment de l’appel de la page par l’utilisateur. son principal avantage c’est de pouvoir insérer des parties dynamiques facilement dans l’écran ce qui n’est pas le cas d’un site statique.

En fonction des usages, on va opter pour l’un ou l’autre voir d’un mode hybrid. Par exemple sur un blog où nous avons pas trop de contenu par jour on opterait plutôt pour du SSG. Ca fera moins travailler le serveur et ca sera donc plus performant. La seule contrepartie sera de régénérer les contenus statiques à chaque nouvel article. pour un site e-commerce en fonction des sites une approche NEXT.JS ou NUXT à base de SSR et de cache serait idéal. L’un n’empêche pas l’autre on peut aussi mixer ces 2 approches sur un même site.

JAMSTACK

Cette approche un peu extrême qui est de délivrer uniquement des statiques porte un nom : c’est la JAMSTACK (https://jamstack.wtf/ Javascript, API, Markup). Ce mouvement englobe une approche globale de développement web, ce n’est pas que du front, on parle de CDN, des atomics deploy, d’une approche avec du cache, des builds automatiques.

Gatsby et Hugo sont deux framework qui permettent d’adresser une approche JAMSTACK.

Cette approche a l’avantage d’être hyper performante car on obtient in fine uniquement des fichiers statiques, c’est le cas idéal pour un robot…

Tips & tricks

Quelques recommandations lorsqu’on parle de JavaScript et SEO :

Éviter d’utiliser les fragments dans les URLs (hashtag) : bien charger les urls en entières
Eviter les onclick, catcher les liens que vous souhaitez catcher avec l’API History. Cette API permet de traiter les liens et ce, de la meilleur des façons possible. Bonus, les lecteurs d’écran (accessibilité) vous remercieront.
Utiliser le mobile-friendly test de Google le plus souvent possible cela permet de récupérer des captures de Google Bot mais aussi et surtout de voir le code source du rendu de votre page ! Cet outil doit-être un réflex.
Désactiver le JavaScript pour voir ce que Google Bot voit. Les bons navigateurs permettent cette option.
La recommandation officiel de Google est de pouvoir voir le contenu en intégralité lorsque vous visualisez le code source de votre page (et pas l’outil inspecter) — Martin Splitt. Partant de cette déclaration vous savez ce qu’il reste à faire.