Javascript & SEO : les recommandations de Google évoluent et se clarifient
Ecrit par Mathieu CHAPON
le
Les recommandations de Google à propos de la bonne utilisation des frameworks javascript (Angular, React, Vue…) ont longtemps été inexistantes, et au mieux assez floues. Mais Martin Splitt, webmaster trends analyst chez Google, vient de clarifier ces recommandations, d’abord via une série de videos didactiques sur la chaine Youtube de Google destinée aux webmasters, et ensuite à l’occasion d’une conférence donnée à l’occasion du récent Google I/O avec Zoe Clifford, qui est l’employée de Google à l’origine du projet « Googlebot Evergreen ».
Et ce qui est particulièrement notable, c’est que ces recommandations ont sérieusement évolué… Listons ensemble les principaux enseignements que l’on peut tirer de l’analyse de ces principales videos
Le Dynamic Rendering n’est plus considérée comme une bonne solution à long terme
John Mueller a lontemps préconisé le « Dynamic Rendering » ». Le « Dynamic Rendering » consiste à présenter aux bots des moteurs de recherche une version « normale », c’est à dire dont le HTML est généré côté serveur, et de laisser les utilisateurs bénéficier d’une version dont l’UX est améliorée par l’utilisation intensive du javascript côté client. C’est un message implicite envoyé aux propriétaires de site que l’utilisation de frameworks javascript n’est pas idéal pour assurer un bon référencement de son site et que créer cette version alternative pour les robots était jugée comme une solution plus sûre.
Mais la position exprimée par Martin Splitt montre une évolution : le Dynamic Rendering n’est plus considéré comme une solution valide à long terme. C’est d’ailleurs également la position que nous avons défendue auprès des clients de SF depuis que Google a commencé à parler de Dynamic Rendering. En effet, les frameworks javascript sont des outils, qui comme tous les outils, peuvent être bien utilisés, mais aussi très mal employés. En soi, il est tout à fait possible de développer un site web de façon moderne, en utilisant les frameworks javascripts et les possibilités des browsers modernes sans créer des problèmes pour le référencement. Mais hélas, beaucoup d’implémentations sont catastrophiques. Martin Splitt explique dans ses différentes vidéos comment créer des sites parfaitement référençables avec VueJS, ReactJS ou AngularJS.
Si avoir un bon référencement est crucial pour vous, optez pour le « Server Side Rendering »
Martin Splitt et Zoe Clifford expliquent que Googlebot crawle et indexe le contenu en deux passes : dans un premier temps, Googlebot explore le web pour trouver les liens et indexe le contenu trouvé dans le code HTML téléchargé, mais sans exécuter le javascript. C’est le comportement traditionnel du Bot de Google, connu depuis son lancement en 1998. Le contenu généré côté client en javascript est exécuté ultérieurement dans une deuxième étape, (qui intervient parfois des jours après la première selon les expériences menées chez SF). Cette étape est appelée la phase de « rendition » par Google, et on sait qu’elle est réalisée dorévant via la dernière version de Chromium headless, ce qui était l’une des autres annonces de Google I/O
Pourquoi deux étapes ? En fait, Martin Splitt explique que la phase de rendition est extrêmement coûteuse en ressources informatiques, et beaucoup plus lente que la méthode traditionnelle. Pour continuer à crawler le web rapidement, Google doit utiliser en priorité la méthode traditionnelle, indexe le contenu trouvé ainsi, et ensuite va essayer d’aller chercher le contenu manquant dans le HTML généré dans le navigateur, mais beaucoup moins souvent.
La recommandation de Martin Splitt qui découle de ce comportement est simple : si votre contenu évolue souvent, ou si vous avez un gros site, vous avez besoin que votre contenu soit indexé dès la première passe de Googlebot. Ce qui implique d’utiliser les frameworks javascript pour générer le code HTML intégrant le contenu à faire indexer côté server (c’est ce qu’on appelle dans le jargon développeur le SSR : Server Side Rendering, rendition côté serveur). L’une des façons les plus élégantes de le faire est d’utiliser les possibilités de pré-rendition des frameworks javascript.
La prérendition : une solution efficace pour créer un site codé de façon moderne et rapide à crawler et indexer
La prérendition consiste à placer le code javascript générant le code à faire indexer côté serveur, et d’exécuter le code à l’avance, côté serveur également, pour pré-générer une version du HTML qui sera délivrée ensuite au navigateur (ou à Googlebot). Pour le crawler, le site se comporte comme un site traditionnel fait en PHP ou en Asp.net
Martin Splitt cite différentes solutions pour implémenter une prérendition : Rendertron et Puppeteer et Chromium Headless, ou React Snap pour ReactJS. Mais cette solution ne convient pas à tous les cas de figure : en effet, la rendition est aussi coûteuse pour votre serveur web que pour Googlebot. C’est donc une mauvaise idée de générer une image HTML du contenu à chaque requête du navigateur. Le code pré-rendu doit être généré comme vous le feriez avec un cache HTML (et en réalité : c’est un cache HTML).
Si votre contenu évolue très souvent, le risque est grand que vous envoyiez à vos utilisateurs une version obsolète de votre contenu.
Dans ce cas, vous avez le choix entre deux méthodes :
- le dynamic rendering (mais nous avons vu que ce n’est pas la solution la plus durable et la plus élégante)
- ou le SSR avec une « hydration »
L’hydration : le nouveau concept pour faire de l’hybrid rendering simple et efficace
A cause des limites du prerendering, mais aussi pour offrir une meilleure expérience utilisateur, beaucoup de développeurs finissent aujourd’hui par opter pour une génération du HTML côté navigateur de l’utilisateur. Mais nous l’avons vu, ce n’est pas la solution qui garantit un bon référencement.
Alors, faut-il arbitrer entre la peste et le choléra, ou peut-on avoir le meilleur des deux mondes ? En fait, il est possible d’imaginer des solutions hybrides (ce que l’on appelle « l’hybrid rendering »). Il est par exemple possible de générer côté serveur une partie du code HTML (contenant les balises SEO, le texte, les principales images). Et ensuite un code javascript complétera le contenu côté client pour offrir la meilleure expérience utilisateur possible.
Cette approche dite en « amélioration progressive » est incontestablement la plus élégante. L’une de ses vertus est d’offrir des performances élevées. Mais l’un de ses inconvénients est d’être difficile à coder rapidement. Un autre inconvénient est qu’elle oblige à générer du contenu frais côté serveur, même pour un site dont les pages changent toutes les secondes !
La solution moderne, c’est d’utiliser les possibilités d' »hydration » des frameworks javascripts. Le principe de l’hydration, c’est de générer une première version du HTML en SSR, puis le code javascript côté client modifiera le contenu de la page pour « rafraîchir » le contenu, et donc offrir une meilleure expérience utilisateur. Ce fonctionnement est facilité par les frameworks permettant la création d’un code dit « universel » ou « isomorphe », c’est à dire un code qui peut être utilisé côté serveur comme côté client. C’est ce que permet la version « Universal » d’Angular, mais c’est aussi possible de manière plus native avec Vue.js et et React.
Il existe même des librairies dédiées à l’hydration : Next pour React, et Nuxt pour Vue.js
Une fois de plus, l’hydration peut être la pire et la meilleure des choses : modifier le contenu côté client pour réactualiser le contenu, c’est ok. Mais changer la valeur de certaines balises peut vous conduire à d’énormes problèmes. Par exemple, implémenter une balise robots avec la balise noindex côté serveur, et ensuite faire passer cette valeur à « index » côté client est une idée désastreuse. Elle aura pour conséquence de désindexer la page, la phase de rendition ne sera jamais lancée ! D’une manière générale, nous ne recommandons pas chez SF de modifier de façon importante la structure de la page via l’hydration.
Quelques conseils spécifiques pour les frameworks les plus populaires
Martin Splitt donne également des exemples de code et des conseils pour les frameworks les plus populaires. Voici les informations à retenir selon moi.
Tout d’abord, une erreur souvent commise est de ne pas compléter les balises title et metas SEO correctement avec les frameworks javascript.
Sur Angular, c’est possible en utilisant les services « meta » et « title ». Sur React, grâce au composant Helmet. Et sur Vue, en exploitant l’extension vue-meta. Ces outils permettent de générer des versions dynamiques (calculées) du contenu des metas en fonction du contenu d’autres champs (comme créer une description avec le début du contenu d’un post pour un contenu de type blog). Donc avoir des balises meta uniques et adaptées est possible et facile avec ces frameworks (à condition d’y penser…)
Côté Vue.js, on fera attention à basculer les liens en mode « history API ». Cela permettra de générer des liens crawlables normaux, et non des urls avec des # suivis de paramètres. Googlebot ignore par principe ce qui se trouve derrière les #, du coup un site fait avec les urls par défaut prévues dans Vue n’est pas explorable du tout !
Pour finir, signalons que Googlebot, même en version « evergreen », continue de fonctionner avec une file d’attente d’urls à crawler, ne simule pas de « sessions » et donc oublie à chaque téléchargement de contenu toutes les informations de personnalisation stockées lors de la visite d’une url précédente. C’est vrai pour les cookies, mais aussi pour les service workers et plus généralement toutes les données d’environnement stockées par un utilisateur normal.
Test SEO : comment Google interprète les liens en JS (JavaScript) ?
On sait désormais que Googlebot a la capacité de suivre des liens construits à partir de JavaScript. Ce langage étant largement utilisé pour le développement des applications web, il est toujours intéressant, en bons SEO que nous sommes, de mettre Google à l’épreuve du javascript !
Environnement du test :
- Création de 5 pages avec contenu unique.
- Chaque page cible une expression qui n’existe pas.
- Chaque page est distribuée depuis la navigation.
Types de liens testés :
- 1 lien HTML classique de type <a href= »monsite.com/page-1.html>Page 1</a>
- 1 lien JS standard avec la fonction OnClick (script dans le Header page)
- 1 lien JS avec la fonction OnClick qui génère le lien (script dans le Header page)
- 1 lien jQuery (script dans le Header page)
- 1 lien JS avec la fonction OnClick via appel d’un script externe
Résultats du test
Moins de 24h après la mise en ligne, peu de surprise à l’arrivée, l’ensemble des contenus ont été indexé ! Même le lien JS qui appel une source externe a été compris par Google. On peut donc conclure et confirmer que des formats de liens en JS dans une structure de site sont parfaitement bien explorés et conduisent à l’indexation des contenus. On notera toutefois, même si cela reste un test sur des requêtes ne présentant aucune concurrence que côté ranking c’est la page maillée via un lien HTML standard qui se positionne le mieux.
La prochaine étape de réflexion à mener et un prochain test à envisager, serait de mesurer l’impact des formats de liens en matière de ranking.
Google met en cache vos fichiers CSS et Javascript pendant longtemps !
Une information pas tout à fait anodine est tombée le 18 Octobre via un tweet de John Mueller. En effet, John Mueller a confirmé que Google mettait en cache vos fichiers CSS et javascript pendant un certain temps sans vraiment nous indiquer exactement quelle était la durée maximale.
Ok, c’est sympa mais à quoi cela nous avance-t-il ? Y-a-t-il un risque ?
Oui tout à fait, cela peut impacter votre SEO surtout si ces fichiers changent une partie non négligeable de votre contenu sur la page ou si ceux-ci permettent de générer de nouvelles URLs. Si vous comptez sur ce mode de fonctionnement pour créer ou mettre à jour de nouveaux contenus sur votre site alors cela va vous impacter directement votre SEO car la version de la page mise en cache sera obsolète (vision Google) versus la nouvelle page desservie (vision internaute).
Il ne faut donc pas compter sur ce mode de fonctionnement pour démontrer à Google la fraîcheur de vos contenus. Si Google n’est pas en capacité d’intégrer ces changements aussi vite qu’ils se produisent en temps réel alors la stratégie utilisée n’est pas appropriée. Le risque étant que Google n’ait pas accès avant un long moment à la dernière version de votre site.
Quelle est la solution à adopter ?
Pour arriver au même objectif, il faudra utiliser une stratégie de contournement/une autre méthode et ne pas utiliser les fichier CSS et javascript pour le faire.
Générer du contenu en JS côté client n’est vraiment pas une bonne idée
Cela fait déjà un moment que Google prétend savoir crawler et indexer des contenus générés en Javascript. Cela pourrait être vu comme une bénédiction, tant la mode des frameworks Javascript (AngularJS, ReactJS, EmberJS) semble se répandre chez les développeurs comme une traînée de poudre.
Sauf que l’exercice a ses limites, et qu’on commence à mieux connaître et comprendre ces limites.
A tel point que l’on peut aujourd’hui affirmer que générer du contenu JS client, ce n’est définitivement pas une bonne idée.
Pourquoi ? Et bien faisons le point sur les problèmes que créés cette pratique calamiteuse pour le SEO.
Seul Googlebot est capable de crawler ou d’indexer le contenu généré en javascript côté client
Rappelons tout d’abord que Googlebot est l’un des rares bots à être capable de crawler et d’indexer du contenu généré en JS. Bingbot a un support tellement anecdotique du JS qu’il vaut mieux considérer qu’il ne sait pas faire, et quant aux autres robots d’exploration, les choses sont claires : ils ignorent superbement ce type de contenu !
Bref, si vous avez besoin de référencer un site aux USA ou en Russie, et bien, oubliez cette jolie technologie pratique et élégante qu’essaient de vous vendre vos développeurs, à savoir un site fait 100% à base de frameworks JS tournant côté client !
Googlebot a de sérieuses limites lorsqu’il crawle et indexe du javascript
Il est possible que vous vous fichiez des USA ou de la Chine et que votre site ne cible que la France ou l’un de ces nombreux pays d’Europe où Google représente plus de 90% de parts de voix. Et peut-être vous dîtes vous : puisque Google me dit qu’ils savent crawler et indexer le Javascript, tout va bien se passer pour mon site en Full Angular 1 !
Dans la pratique, ce n’est pas vrai du tout !
Déjà, crawler et rendre du Javascript demande des ressources beaucoup, beaucoup plus importantes qu’un crawl traditionnel. Un site fait avec un framework JS verra son contenu indexé plus lentement, mis à jour plus lentement… Et là on parle de jours, et pour l’avoir vu sur des exemples, d’une dizaine de jours potentiellement avant que les modifications de votre contenu générés en JS soient prises en compte !
Ce point a été confirmé récemment lors d’un hangout sur le sujet présenté à l’occasion du dernier Google I/O
En fait, le contenu généré en JS n’est pas indexé tout de suite, mais seulement dans un deuxième temps, une fois que les ressources nécessaires deviennent disponibles.
Bref, si vous voulez que vos actualités soient indexées rapidement, débrouillez-vous autrement et oubliez les frameworks JS côté client.
L’indexation est … aléatoire
Pour couronner le tout, il n’est pas sûr que le contenu généré en JS soit réellement correctement indexé ! Dans la pratique, on voit que ce n’est souvent pas le cas.
Bon évidemment, s’il y’a la moindre erreur dans le code JS, cela empêchera la rendition du contenu, et donc son indexation.
Mais même si votre code est parfait, il n’est pas sûr que ça fonctionne : en effet, Google n’indexera vos contenus qu’à deux conditions :1. Votre contenu doit être généré dans un délai raisonnable : moins de cinq secondes à l’expérience, sinon le bot abandonne la partie et tant pis pour les textes optimisés que vous avez amoureusement concoctés, Google les ignorera superbement
2. Et votre contenu doit être généré dans le premier état de la page : s’il faut une action complémentaire pour le charger, comme un clic de l’utilisateur, c’est mort
Et il y’a des balises que Google ne lit que si elles figurent dans le HTML statique
Qui plus est, John Mueller a récemment confirmé que la balise canonical notamment n’était prise en compte que si elle figurait dans le code HTML statique disponible pour le bot classique (le premier code HTML téléchargé par le navigateur). Si elle est générée en Javascript, Google l’ignore.
J’en profite pour signaler que toutes les techniques données ici et là pour injecter des balises SEO en utilisant Google Tag Manager ne sont que des béquilles qui ne marchent pas toujours.
En particulier, si vous essayer d’ajouter le balisage schema.org via GTM, il est fréquent que Google l’ignore, alors que si vous les injectez dans le HTML statique, vous êtes sûr que Google les lira correctement.
Même chose pour d’autres balises. Nous sommes en train de faire des tests plus systématiques chez SF pour avoir une idée plus claire de ce qui marche ou non et pourquoi.
Alors, on oublie les frameworks javascript ?
Bon puisque c’est si terrible, faut-il s’interdire les frameworks javascripts pour avoir un bon référencement ?
NON ! Il y’a trois modes d’implémentation possibles, et seulement un est à proscrire :
– le CSR : le Client Side Rendering. Le contenu est généré intégralement dans votre navigateur en JS. C’est cette implémentation qui est à proscrire
– le SSR : le Server Side Rendering. Le contenu est généré intégralement côté serveur. Votre navigateur reçoit un contenu complet en HTML généré comme d’habitude. Cette implémentation ne pose a priori aucun problème de SEO
– l’approche « hybride ». Une partie du contenu est générée côté serveur. Le reste côté client. Si ce qui est généré côté serveur comporte toutes les balises SEO et le contenu que vous voulez voir crawler et indexer, cette approche ne pose la aussi aucun problème pour le SEO
Bon, aujourd’hui, la plupart des sites faits avec un framework JS sont plutôt des CSR ou des méthodes hybrides mal fichues pour le SEO : l’éducation des développeurs va prendre du temps.
C’est d’ailleurs probablement à cause de cela que Google veut introduire le concept de dynamic rendering : une façon de générer du contenu en SSR pour les bots, et du CSR pour les utilisateurs. Le système s’appuie sur Puppeteer et Rendertron, deux outils développés chez Google. Mais c’est une fausse bonne idée selon moi, comme l’était la méthode des hash bangs !
Donc non, par pitié, dites à vos développeurs qu’ils peuvent continuer à se faire plaisir avec les frameworks javascript, mais à la condition expresse de faire du SSR !
Les outils pour faire du dynamic rendering
L’intervention de Tom Greenaway lors du Google I/O
L’outil puppeteer
L’outil rendertron