Le domaine de la création de sites web utilise de plus en plus des frameworks plus complexes, à base de langage Javascript (React, Angular, Vue.js...), produisant des sites également complexes à crawler et à analyser par les robots des moteurs. La situation évolue petit à petit, mais la maßtrise de ces plateformes est absolument indispensable pour créer des sites web "SEO friendly". Les obstacles sont encore nombreux et il faut savoir les déjouer pour obtenir une visibilité maximale sur les les différents moteurs de recherche de la planÚte Web.

Par Philippe Yonnet

 

Les frameworks Javascript ont mauvaise rĂ©putation chez les rĂ©fĂ©renceurs. Mais est-ce vraiment mĂ©rité ? A l’heure oĂč le code Javascript envahit de plus en plus les pages web, au point de rendre beaucoup de sites strictement inutilisables dans un navigateur dont le support du Javascript est dĂ©sactivĂ©, la majoritĂ© des moteurs de recherche (Ă  l’exception notable de Google) disposent de bots incapables de comprendre les contenus gĂ©nĂ©rĂ©s en Javascript dans les navigateurs.

Cette situation crĂ©e un challenge nouveau et d’une rare complexitĂ© pour les moteurs de recherche et pour les webmasters. Pour les moteurs, il s’agit de moderniser leurs crawlers pour qu’ils soient capables de supporter ces nouvelles mĂ©thodes pour coder des sites webs, et pour les webmasters, de savoir rendre leurs contenus « SEO Friendly » malgrĂ© l’emploi de ces nouvelles techniques.

En quelques annĂ©es, la situation a beaucoup Ă©volué : aprĂšs un bref rappel de l’historique de l’emploi du langage Javascript, nous allons essayer d’expliquer pourquoi il est en train d’envahir nos sites web, quels problĂšmes ils posent pour le rĂ©fĂ©rencement. Et nous ferons un point sur l’état actuel des recommandations pour rendre un site fait en React, Angular ou Vue.js SEO Friendly.


Fig. 1. React, Angular et Vue.js sont les 3 frameworks les plus employés en 2019.

Mais d’abord c'est quoi, un "framework Javascript" ?

Les frameworks Javascript sont des bibliothÚques de fonctions en langage Javascript  permettant de réaliser des programmes complexes sans avoir à redévelopper tous les composants.

Ils existent depuis de nombreuses annĂ©es maintenant, et ont notamment permis de rendre plus commodes l’utilisation de l’Ajax et des requĂȘtes XHR.

Plus rĂ©cemment, les framework Javascript sont devenus des outils de dĂ©veloppement d’applications complĂštes, aussi bien cĂŽtĂ© serveur que fonctionnant cĂŽtĂ© « client », dans votre navigateur favori. L’apparition de frameworks comme NodeJS a Ă©galement inaugurĂ© la possibilitĂ© d’utiliser le langage Javascript pour dĂ©velopper des applications desktop.

Petite histoire du Javascript

Avant de devenir un langage Ă©voluĂ© et (presque) universel, Javascript a connu des dĂ©buts plutĂŽt modestes. Il a Ă©tĂ© créé au dĂ©part pour rĂ©soudre les problĂšmes de standardisation du World Wide Web dans les annĂ©es 90 : chaque navigateur supportait diffĂ©remment le langage HTML, et surtout, les CSS. L’une des solutions trouvĂ©es a Ă©tĂ© d’introduire la possibilitĂ© d’exĂ©cuter du code dans le navigateur : cela a donnĂ© le langage Livescript, renommĂ© plus tard Javascript (notons qu’il n’y a aucun rapport entre le langage de programmation Java et Javascript).

Il a fallu du temps et une longue guerre entre le navigateur de Microsoft et Netscape pour que Javascript devienne le langage exĂ©cutĂ© par les navigateurs modernes. Et la standardisation du langage lui-mĂȘme est arrivĂ©e au dĂ©but des annĂ©es 2000, grĂące au travail du consortium ECMA en charge de la supervision des normes et de l’évolution du langage (il joue un rĂŽle similaire Ă  celui du W3C pour le HTML).

Nous en sommes maintenant à la version 6 du langage Javascript et entre temps, ses possibilités ont été largement étendues :

  • Il permet de changer l’apparence de la page en modifiant le contenu du code HTML, ou ses propriĂ©tĂ©s.
  • Il permet de dĂ©clencher des actions dans le navigateur.
  • Il permet aussi de changer le contenu d’une page en envoyant des requĂȘtes XHR au serveur web pour rafraĂźchir une partie de la page ou sa totalitĂ© (c’est ce que l’on appelle la technologie AJAX).
  • Et il permet enfin de gĂ©nĂ©rer du code HTML qui est ensuite interprĂ©tĂ© par le navigateur, et c’est cette possibilitĂ© qui est exploitĂ©e abondamment par les frameworks rĂ©cents.

Pourquoi les frameworks Javascript sont-ils si populaires chez les développeurs ?

Depuis l’apparition des langages de script spĂ©cifiques aux navigateurs web, les dĂ©veloppeurs se sont spĂ©cialisĂ©s pour faire face au challenge de dĂ©velopper les diffĂ©rentes parties d’un site web dans des langages diffĂ©rents. On a vu ainsi apparaĂźtre :

  • les dĂ©veloppeurs « front end » : chargĂ©s de dĂ©velopper le code exĂ©cutĂ© dans les navigateurs, ils sont spĂ©cialisĂ©s dans les langages HTML/CSS et Javascript.
  • les dĂ©veloppeurs « backend » : chargĂ©s de dĂ©velopper le code exĂ©cutĂ© cĂŽtĂ© serveur, ils se spĂ©cialisent dans un ou plusieurs langages de programmation orientĂ©s serveur (PHP, ASP.net, Java, Python
).

Dans la pratique, il est devenu assez difficile aujourd’hui de bien maĂźtriser TOUS les langages de programmation nĂ©cessaires pour construire un site web. CĂŽtĂ© dĂ©veloppeurs front-end, le langage qu’ils plĂ©biscitent est le Javacript.


Fig. 2. 81,7% des dĂ©veloppeurs web dĂ©clarent prĂ©fĂ©rer le Javascript comme langage de programmation. Cette popularitĂ© est plus due Ă  la grande familiaritĂ© de ces dĂ©veloppeurs avec ce langage, qu’à des critĂšres techniques (puissance du langage, efficacitĂ©, facilitĂ© d’apprentissage).

Un seul langage pour tout programmer

Avec les frameworks Javascript modernes, on peut utiliser un seul langage (le Javascript) pour tout programmer, depuis le code Ă  exĂ©cuter cĂŽtĂ© serveur, jusqu’au code exĂ©cutĂ© dans le navigateur web de l’internaute.

Cela permet aux développeurs front end de devenir des développeurs « full stack » (capable de gérer le front et le back) sans avoir à apprendre de nouveaux langages. Ce qui est évidemment un gros progrÚs.

Des pages web (vraiment) interactives

Evidemment, ces frameworks permettent aussi de transformer les pages web en de mini applications interactives, capables de s’adapter Ă  toutes les fantaisies des dĂ©veloppeurs et de leurs donneurs d’ordre. En fait, les frameworks comme AngularJS ou ReactJS ont d’abord Ă©tĂ© conçus pour fabriquer ce type d’applications tournant dans un navigateur, et notamment les fameuses SPA (les Single Page Applications).

Assembler les infos des web services dans le navigateur

Cette interactivitĂ© requiert de plus en plus d’assembler des donnĂ©es issues de « web services », qui fonctionnent comme de mini-serveurs capables de rĂ©pondre aux requĂȘtes d’une application pour renvoyer des donnĂ©es ou des contenus. S’il est possible d’assembler ces informations cĂŽtĂ© serveur pour gĂ©nĂ©rer une page web (c’est la mĂ©thode classique), il est Ă©galement possible d’interroger via le langage Javascript ces web services depuis la page web exĂ©cutĂ©e par votre navigateur. Cette possibilitĂ© est notamment sĂ©duisante lorsque l’on veut prĂ©senter un contenu rĂ©guliĂšrement mis Ă  jour en Ajax.

La premiÚre génération de Frameworks Javascripts orientée applications client

AprĂšs une premiĂšre sĂ©rie de frameworks destinĂ© Ă  fournir des fonctions prĂȘtes Ă  l’emploi pour de mutiples usages (on pense notamment Ă  Dojo) ou Ă  amĂ©liorer l’expĂ©rience utilisateur, notamment en facilitant le recours Ă  l’Ajax (avec JQuery par exemple), sont apparus une premiĂšre gĂ©nĂ©ration de frameworks destinĂ©s Ă  construire des pages web dont le seul objectif Ă©tait de charger du code Javascript dans le navigateur, ce code crĂ©ant le contenu de la page (y compris Ă©ventuellement 
 du Javascript inline dans le code HTML).

C’est ce concept que l’on appelle couramment une « Single Page Application » : le navigateur charge une seule page web, ensuite le contenu est changĂ© de maniĂšre interactive sans qu’une nouvelle page web soit redemandĂ©e au serveur.

L’un des frameworks de ce type les plus populaires a Ă©tĂ© AngularJS version 1.x . Le fait que le framework Angular soit un projet soutenu par Google n’a pas Ă©tĂ© Ă©tranger Ă  son succĂšs. Mais cela a aussi fait croire aux dĂ©veloppeurs qu’AngularJS version 1.x « était forcĂ©ment SEO Friendly, puisque c’était un produit Google ».

Sauf que c’était parfaitement faux.

Les frameworks premiÚre génération n'étaient pas SEO friendly

Lors des premiĂšres implĂ©mentations Ă  l’aide de ces frameworks, il Ă©tait courant de voir des sites dĂ©veloppĂ©s Ă  l’aide d’Angular, apparemment parfaits d’un point de vue expĂ©rience utilisateur, mais impossible Ă  rĂ©fĂ©rencer correctement.

Voici un exemple de site fait en AngularJS v1.0 que j’ai souvent pris comme exemple dans mes confĂ©rences : le site de Virgin Mobile USA. AprĂšs une migration au cours de l’étĂ© 2015 vers une plateforme Angular, le site ressemblait Ă  cela :


Fig. 3. Site web de Virgin Mobile en 2015 (Javascript activé).

Sauf que si on désactivait le Javascript dans le navigateur, le site se mettait à ressembler à ceci :


Fig. 4. Site web de Virgin Mobile en 2015 (Javascript désactivé).

C’est-à-dire une jolie page blanche, ne comportant rien du contenu visible dans le navigateur !

Le problĂšme c’est qu’à l’époque, les moteurs de recherche avaient une capacitĂ© limitĂ©e Ă  « rendre » (gĂ©nĂ©rer) le contenu fabriquĂ© dans le navigateur en Javascript, et a fortiori de le crawler et de l’indexer.

Le rĂ©sultat est que la visibilitĂ© du site Virgin Mobile dans les moteurs de recherche a fortement diminuĂ©. Dans Bing (un moteur important aux USA), seule la page d’accueil Ă©tait indexĂ©e (normal pour une Single Page Application). Bingbot ne savait pas Ă  l’époque indexer du contenu gĂ©nĂ©rĂ© en Javascript : et mĂȘme si Bing a fait des progrĂšs en ce domaine, Bingbot supporte encore le Javascript de maniĂšre trĂšs limitĂ©e aujourd’hui). CĂŽtĂ© Google, les consĂ©quences ont Ă©tĂ© moins importantes, car Googlebot en 2015 disposait dĂ©jĂ  de capacitĂ©s plus avancĂ©es dans le support du Javascript. Mais la visibilitĂ© de la nouvelle version AngularJS du site a quand mĂȘme Ă©tĂ© impactĂ©e de maniĂšre assez violente :


Fig. 5. L’indice de visibilitĂ© du site Virgin Mobile USA donnĂ© par l’outil SearchMetrics a fortement chutĂ© aprĂšs la migration du site vers AngularJS.

Conclusion : en 2015/2016 (autant dire hier), faire un site avec un framework Javascript de type Angular version 1 était clairement une mauvaise idée si on souhaitait avoir un bon référencement.

Les concepts Ă  connaĂźtre : SSR, CSR, et Hybrid Rendering

A ce stade des explications, il convient de définir quelques termes qui seront utiles pour comprendre la suite de nos explications.

Tout d’abord, dĂ©finissons le terme « rendering » (qui se traduit en français par rendition). Le rendering, c’est le travail effectuĂ© par un navigateur web pour transformer le code HTML + CSS + Javascript en une page lisible par l’utilisateur final.

Ensuite, lorsque l’on parle des frameworks Javascripts, on diffĂ©rencie :

  • le SSR : le Server Side Rendering (la rendition cĂŽtĂ© serveur) ;
  • et le CSR : le Client Side Rendering (la rendition cĂŽtĂ© serveur).

Le SSR reprĂ©sente la mĂ©thode utilisĂ©e depuis plus de vingt ans pour fabriquer des sites web Ă  l’aide de langages de programmation : le code HTML est gĂ©nĂ©rĂ© cĂŽtĂ© serveur AVANT d’ĂȘtre envoyĂ© au « client », c’est-Ă -dire le navigateur web.

Cette mĂ©thode permet Ă  un crawler de moteur de recherche de rĂ©cupĂ©rer le contenu de la page via une simple requĂȘte http et sans avoir Ă  exĂ©cuter de Javascript. Tous les crawlers des moteurs de recherche (et les algorithmes de ces moteurs) ont Ă©tĂ© conçus pour une Toile dans laquelle tous les sites fonctionnent en mode SSR.


Fig. 6. Site conçu en SSR : le contenu de la page est généré par le serveur, et entiÚrement disponible pour un bot.


Fig. 7. Par contre, si le site fonctionne en mode CSR, alors le contenu (et le code HTML qui en assure la rendition) est gĂ©nĂ©rĂ© APRES la requĂȘte du navigateur, qui reçoit une page rĂ©duite Ă  l’appel du code Javascript nĂ©cessaire pour assurer la rendition finale du contenu.

C’est ce type de rendition (CSR) qui Ă©tait utilisĂ© dans le cas de Virgin Mobile USA Ă©voquĂ© plus haut.

Le problĂšme, avec la rendition CSR, est que les bots des moteurs de recherche Ă©taient jusqu’à une Ă©poque rĂ©cente conçus comme des navigateurs trĂšs trĂšs limitĂ©s et en pratique incapables d’exĂ©cuter le code Javascript parfois trĂšs complexe utilisĂ© pour gĂ©nĂ©rer le code HTML dans le navigateur de l’internaute.

Dans un premier temps, la solution prĂ©conisĂ©e classiquement pour les sites faits avec des Frameworks de premiĂšre gĂ©nĂ©ration Ă©tait d’utiliser une solution de prĂ©rendition.

PremiÚre méthode pour rendre une SPA CSR SEO Friendly : la prérendition

Le concept de prerendering (prĂ©rendition en Français) consiste Ă  Ă©muler un navigateur cĂŽtĂ© serveur web, pour prĂ©gĂ©nĂ©rer le code HTML produit par le code Javascript, avant de l’envoyer au navigateur. Ces navigateurs spĂ©ciaux sont appelĂ©s des « headless browsers » (des navigateurs sans tĂȘte) car ils ont pour particularitĂ© de ne pas avoir d’interface utilisateur car ils ne sont pas destinĂ©s Ă  produire une page visible par un humain mais juste d’intĂ©ragir avec un programme pour fabriquer la version prĂ©gĂ©nĂ©rĂ©e (prĂ©rendue) de la page.

Dans la pratique, le code ainsi prĂ©-rendu n’est souvent envoyĂ© 
 qu’aux moteurs de recherche, qui voient du code HTML facile Ă  crawler et indexer (cela crĂ©e un site web SSR), l’utilisateur continuant de recevoir la version « CSR » de la page.

Oui, c’est du cloaking (on prĂ©sente une version diffĂ©rente aux moteurs qu’aux utilisateurs) mais c’est du cloaking autorisĂ© par Google, et mĂȘme recommandĂ© (c’est ce que Google prĂ©conise sous le terme Dynamic Rendering).


Fig. 8. Le concept de  « dynamic rendering » : Google prĂ©conise cette solution en cas de site conçu en full CSR. Quand le serveur web dĂ©tecte qu’une page est demandĂ©e par un crawler (reconnu par son User Agent) il renvoie un code HTML prĂ©rendu. La version CSR est par contre envoyĂ©e Ă  tous les autres navigateurs.

La solution proposĂ©e ressemble Ă  celle jadis prĂ©conisĂ©e pour rendre l’Ajax crawlable (la mĂ©thode des « hash bangs »), mĂ©thode qui on le rappelle est devenue obsolĂšte pour Google.

Au dĂ©but, il fallait avoir recours Ă  des solutions tierces pour rĂ©aliser la prĂ©rendition, comme Prerender.io, ou des browsers headless comme PhantomJS. Google, avant de prĂ©coniser le Dynamic Rendering a lancĂ© ses propres outils : Puppeteer et Rendertron, qui permettent de rĂ©aliser la mĂȘme chose.

Les limites du Dynamic Rendering

Le Dynamic Rendering est une solution qui fonctionne, mais qui a ses limites dans la pratique.

C’est un moyen de contourner le problĂšme, mais pas de l’éviter. Cela augmente la complexitĂ© de l’architecture logicielle d’un site web (dans la pratique, tout se passe comme si on avait deux sites webs Ă  maintenir au lieu d’un). Cela suppose d’envoyer du code statique et potentiellement obsolĂšte aux moteurs, et non personnalisĂ© (par la gĂ©olocalisation par exemple).

Qui plus est, une implĂ©mentation 100% fiable et rĂ©ussie demande des compĂ©tences techniques minimales cĂŽtĂ© front, back et infra, et un bon niveau de dialogue entre tous ces acteurs, ainsi qu’avec le rĂ©fĂ©rent SEO (interne ou externe). C’est en fait assez simple Ă  dĂ©ployer, mais s’il manque une compĂ©tence dans votre Ă©quipe, vous risquez de buter sur des difficultĂ©s que vous ne saurez pas rĂ©soudre.

Il arrive par exemple frĂ©quemment que le « Dynamic Rendering » tombe en panne et qu’il faille attendre des jours pour que quelqu’un le dĂ©tecte. OĂč que les pages ne se mettent plus Ă  jour. OĂč que la dĂ©tection du User Agent fonctionne mal et produise des effets de bord.

Bref, c’est une rustine, pas une solution Ă©lĂ©gante et durable. Mais c’est une solution qui a du sens pour corriger une situation oĂč le site a dĂ©jĂ  Ă©tĂ© dĂ©veloppĂ© en full CSR.

Si le site n’est pas encore dĂ©veloppĂ©, il vaut mieux le concevoir diffĂ©remment en utilisant les possibilitĂ©s des frameworks Javascript de derniĂšre gĂ©nĂ©ration.

Les solutions apportées par les frameworks "universels" ou "isomorphes" : la 2e génération de frameworks Javascript

Car les frameworks Javascript ont beaucoup Ă©voluĂ© depuis leurs premiers balbutiements en 2009. Ils sont conçus pour autoriser la crĂ©ation de code dit « Isomorphes », c’est-Ă -dire un code qui est utilisable aussi bien cĂŽtĂ© client que cĂŽtĂ© serveur. Chez AngularJS, on prĂ©fĂšre parler de code « Universel », un concept que l’on retrouve depuis la version 2 d’Angular dans Angular Universal.

Cette Ă©volution permet de construire des sites webs diffĂ©remment de l’approche « full CSR », en utilisant le langage Javascript pour gĂ©nĂ©rer du code Ă  n’importe quel stade de la rendition.


Fig. 9. Les frameworks de deuxiĂšme gĂ©nĂ©ration les plus populaires d’aprĂšs l’activitĂ© dans GitHub : de gauche Ă  droite Angular, Backbone, Ember, React et Vue.js. Le podium est clairement Angular en 1er, React en second, et Vue.js en 3e

Solution 1 : Utiliser le framework pour générer le code cÎté serveur (SSR)

C’est possible avec Angular Universal, mais aussi avec les autres frameworks populaires comme Vue.js (grñce à l’extension Nuxt), avec React (grñce à l’extension Next, oui les noms sont proches, et ce n’est pas un hasard).

Nuxt ou Next permettent de gĂ©nĂ©rer le HTML cĂŽtĂ© serveur, et donc d’avoir un site qui, bien que codĂ© en langage Javascript, fonctionne comme un site « normal », en SSR. Le Javascript est utilisĂ© Ă  la place du PHP ou de l’ASP.net.

Si le code HTML peut ĂȘtre mis en cache, on aura un site web rapide. Sinon
 Et bien c’est le problĂšme que pose cette solution : on peut avoir des problĂšmes de performance.

Cette solution est SEO friendly par construction (à condition que le code HTML généré soit optimisé pour le SEO) et elle fonctionne avec tous les moteurs (Yandex, Baidu, Bing
 et bien sûr Google).

Solution 2 (Hybride) : utiliser le framework pour générer une partie du HTML cÎté serveur (SSR), et le reste cÎté navigateur (CSR)

Cette approche est souvent appelĂ©e « Hybrid Rendering » (rendition hybride). Elle n’est pas forcĂ©ment « SEO friendly », tout dĂ©pend de ce que l’on gĂ©nĂšre cĂŽtĂ© serveur ou cĂŽtĂ© client.

Une bonne implĂ©mentation en hybrid rendering demande dans la pratique une collaboration forte entre l’expert SEO et les dĂ©veloppeurs, car il faut choisir avec soin les parties du code gĂ©nĂ©rĂ©es cĂŽtĂ© serveur.

Dans la pratique, le code gĂ©nĂ©rĂ© cĂŽtĂ© serveur contient toutes les balises SEO (title, metas, canonical etc
), ainsi que le code affichant le contenu que l’on souhaite voir absolument indexer (les principaux textes et images).

Au passage, les dĂ©veloppeurs peuvent profiter de cette approche pour faire de l’amĂ©lioration progressive et du mobile first : le code HTML gĂ©nĂ©rĂ© cĂŽtĂ© serveur est aussi le code minimal pour afficher une version ultrasimple de la page, qui se charge rapidement, et est navigable Ă©galement rapidement. Ensuite, la page est enrichie/amĂ©liorĂ©e par le Javascript cĂŽtĂ© serveur.

Cette approche est plus flexible, plus Ă©lĂ©gante, plus performante
 Mais c’est la plus difficile Ă  coder. Elle a Ă©tĂ© popularisĂ©e par React.JS et sa communautĂ© dont de nombreuses implĂ©mentations ont Ă©tĂ© rĂ©alisĂ©es en mode hybride.

Cette solution est LA solution pour avoir le meilleur de tous les mondes lorsqu’on veut un site SEO Friendly, performant, avec un code allĂ©gĂ©. Mais c’est souvent considĂ©rĂ© comme trĂšs complexe Ă  rĂ©aliser et Ă  mettre au point par les dĂ©veloppeurs, et il est impĂ©ratif de bien tester le bon fonctionnement du site, et de tester aussi si les contenus gĂ©nĂ©rĂ©s en CSR (cĂŽtĂ© navigateur) sont bien explorĂ©s, indexĂ©s et positionnĂ©s correctement.

Solution 3 : SSR + Hydration

La troisiÚme solution est beaucoup plus simple à déployer pour les développeurs, mais est moins élégante.

Elle consiste Ă  gĂ©nĂ©rer le code HTML cĂŽtĂ© serveur (en SSR) Ă  l’aide du framework (et l’aide d’outils comme Next ou Nuxt ou leur Ă©quivalent) comme dans la solution 1.

Mais comme le code est « isomorphe », on rĂ©utilise ce code de façon quasi identique dans le navigateur pour rafraichir le contenu (ou « l’ hydrater »).

L’hydration permet de corriger les problĂšmes posĂ©s par le SSR :

  • On peut gĂ©nĂ©rer cĂŽtĂ© serveur des contenus statiques, ou mis en cache. Tant pis s’ils sont obsolĂštes rapidement, l’utilisateur verra toujours du contenu frais « hydraté » ;
  • Les bots peuvent facilement crawler et indexer le contenu gĂ©nĂ©rĂ© en SSR, qui sera en gĂ©nĂ©ral suffisamment frais pour rĂ©pondre aux besoins en rĂ©fĂ©rencement ;
  • Le contenu SSR peut ĂȘtre mis en cache, on peut facilement avoir de trĂšs bonnes performances avec ce systĂšme.

C’est juste moins Ă©lĂ©gant Ă  cause de la redondance du code, qui alourdit la page par rapport aux solutions prĂ©cĂ©dentes.

Dans la pratique, cette solution est aussi SEO friendly que la solution 1 (full SSR ou code HTML statique cotĂ© serveur). A condition de faire attention Ă  ce que l’hydration ne vienne pas trop modifier le code HTML de la page initiale ou la contredire, car dans ce cas il faut s’attendre Ă  des effets de bord. Rafraichir une liste, ou une zone non fondamentale de la page pour le rĂ©fĂ©rencement ne pose aucun problĂšme, mais changer le contenu des balises SEO comme un attribut noindex ou une canonical est une mauvaise idĂ©e.

Le tableau suivant, que l’on trouve dans les pages dĂ©veloppeurs de Google, fournit un bon rĂ©sumĂ© des diffĂ©rentes solutions.


Fig. 10. Différentes solutions de rendering disponibles.

La (fausse) révolution en 2019 : Googlebot Evergreen

En mai dernier, Google a annoncĂ© avoir basculĂ© sur une version nouvelle de son crawler, capable d’utiliser la derniĂšre version stable de Chromium (la version open source de Chrome) comme browser headless.

Bref, cela voulait dire que le bot de Google était capable de se comporter comme les navigateurs les plus récents (version actuelle : 77), alors que pendant trÚs, trÚs longtemps, il émulait Chrome 41.

Beaucoup de dĂ©veloppeurs se sont dit alors : mais pourquoi s’embĂȘter avec du SSR, de l’hybride ou de l’hydration puisque Googlebot est capable de gĂ©nĂ©rer ma page en CSR aussi bien que le navigateur d’un internaute lambda


Sauf que rien a changĂ© dans l’architecture de crawl : Google explore toujours le web en deux passes. Et cela a des consĂ©quences funestes pour les sites conçus en mode CSR.

Dans un premier temps, le vieux bot (qui n’exĂ©cute pas le Javascript, et ne voit pas le contenu gĂ©nĂ©rĂ© en CSR) explore le contenu et l’indexe. Et dans un deuxiĂšme temps seulement (parfois des jours aprĂšs), le « Web Rendering Service » (le service de Rendition Web) va exĂ©cuter le Javascript pour explorer le contenu gĂ©nĂ©rĂ© en Javascript et l’indexer.


Fig. 11. Le process de crawl et d’indexation de Googlebot : le passage Ă  une version Evergreen n’a pas changĂ© ce process, qui signifie que la plupart du temps, les pages sont explorĂ©es par la version « classique » du crawler, qui n’exĂ©cute pas le Javascript.

Comme la rendition complĂšte en exĂ©cutant le Javascript Ă  l’aide du WRS est trĂšs gourmande en ressources (chez Bing, on parle de 10x plus de ressources que pour un crawl « à l’ancienne »), cette rendition est non seulement faite « en diffĂ©ré » mais aussi beaucoup, beaucoup moins souvent.

Par ailleurs, le service WRS n’utilise pas exactement la derniĂšre version de Chromium, mais une version adaptĂ©e compte tenu des contraintes d’un crawler. Par exemple, toutes les fonctionnalitĂ©s demandant l’accĂšs des donnĂ©es stockĂ©es localement dans le navigateur, ne fonctionnent pas avec le Renderer (alias le WRS).

C’était dĂ©jĂ  vrai avec les cookies et le bot « antique » (toujours en action, rappelons-le), c’est vrai aussi aujourd’hui avec les fonctionnalitĂ©s basĂ©es sur les Service Workers et le stockage de donnĂ©es local.

Le CSR n’était pas SEO Friendly au dĂ©part, l’est-il aujourd’hui ?

CĂŽtĂ© Google, les progrĂšs effectuĂ©s ces derniers mois conduisent Ă  ne plus devoir rejeter systĂ©matiquement les architectures full CSR, oĂč le contenu est gĂ©nĂ©rĂ© dans le navigateur du client Ă  grand renfort de Javascript.

Mais c’est encore un no-go absolu si vous avez besoin d’ĂȘtre bien rĂ©fĂ©rencĂ© Ă  l’international. Car ce type de site ne pourra pas ĂȘtre bien rĂ©fĂ©rencĂ© chez les moteurs concurrents de Google.


Fig. 12. L’état des lieux Ă©tabli en 2018 par Bart Goralewicz de l’agence polonaise Elephate sur le caractĂšre SEO Friendly ou nom des frameworks Javascript en fonction des moteurs de recherche testĂ©s.

Le CSR sera dĂ©conseillĂ© Ă©galement si le trafic issu du rĂ©fĂ©rencement est vital pour vous. Car si un site en CSR est bien implĂ©mentĂ© techniquement, il n’y a pas de raison que le contenu ne soit pas explorĂ© et indexĂ© complĂštement par Google.

Mais il n’est pas certain qu’il soit bien positionnĂ©. Car l’un des dĂ©fauts de certaines implĂ©mentations est de faire disparaĂźtre la notion de page web associĂ©e Ă  des URL uniques. Fondamentalement, l’algorithme de Google s’attend Ă  trouver une arborescence sur un site, et dans une « single page application », cette arborescence peut ĂȘtre trĂšs diffĂ©rente de celle d’un site classique. Il est donc important de savoir techniquement manipuler en Javascript les URL de l’historique de navigation du browser (Ă  l’aide de la mĂ©thode pushstate()) pour recrĂ©er cette arborescence.

On ne sait pas exactement ce qui se passe par ailleurs quand le contenu vu par le « vieux » Googlebot et celui gĂ©nĂ©rĂ© par le WRS est trop diffĂ©rent ou contradictoire. Il est Ă©vident que certaines erreurs conduisent Ă  des impasses (par exemple, s’il y’a un noindex dans la mĂ©ta robots de la page envoyĂ©e par le serveur, le Renderer ne sera jamais appelĂ©, mĂȘme si, lui, contient une directive « index » !).

Dernier point qui incite Ă  la prudence : le service WRS (le Renderer) n’est pas du tout patient. Si le code Javascript, les services web appelĂ©s, ou votre serveur sont lents Ă  rĂ©pondre ou Ă  s’exĂ©cuter, alors le systĂšme rĂ©essaiera plus tard (on perd encore des heures, voire des jours), et risque
 d’abandonner. Dans ce cas, votre contenu CSR ne sera jamais indexĂ© (ou au mieux de maniĂšre incomplĂšte) !

Bref, les implĂ©mentations CSR sont Ă  dĂ©conseiller si le rĂ©fĂ©rencement est vital pour vous. Si c’est un site sans enjeu SEO, comme un site corporate, et que votre objectif est simplement que 100% de votre site soit explorĂ© et indexĂ©, alors le CSR est possible. Mais attention : il faut que l’implĂ©mentation technique soit parfaite, et que les performances de votre architecture logicielle soient correctes.

Conclusion : Frameworks Javascript & SEO ne sont plus incompatibles, mais


Comme nous l’avons vu avec les implĂ©mentations SSR, Hybrides, ou l’hydration, il est tout Ă  fait possible de faire des sites SEO Friendly avec des frameworks Javascript.

Si votre site est en Client Side Rendering, il existe toujours la solution du Dynamic Rendering (la prérendition) pour corriger le problÚme et le rendre SEO friendly.
Mais en pratique, les problĂšmes avec les frameworks Javascript proviennent plus de ceux qui les implĂ©mentent et des choix d’implĂ©mentation que de l'outil lui-mĂȘme !

Ces approches sont nouvelles, en constante évolution, et pas toujours bien maßtrisées par les développeurs. Comme le domaine est complexe et trÚs technique, la plupart des référenceurs ont du mal à challenger les équipes techniques sur ces sujets, et à tester et déboguer des sites fabriqués avec ce type de technologie.

Mais, messieurs et mesdames les spĂ©cialistes du SEO, ne vous lancez pas dans des combats d’arriĂšre-garde en disant : je ne veux pas de cela chez moi. Ces technologies ont de nombreux avantages, et sont lĂ  pour rester. La façon de crĂ©er des sites web est en train de changer, et vous devez vous adapter, comme Google est en train d’essayer de le faire. Les « progressive web apps » par exemple, sont le reflet de cette Ă©volution vers une frontiĂšre floue entre application et site web, et oĂč on ne sait plus trĂšs bien non plus oĂč est la frontiĂšre entre client et serveur et oĂč est produit le contenu.

Lisez les informations dans les liens utiles ci-aprÚs, familiarisez-vous avec les concepts : ce sera votre quotidien dans un avenir proche.

Webographie

La page de la rubrique developers de Google sur le Javascript et le SEO (mise à jour la semaine derniÚre en français)
https://developers.google.com/search/docs/guides/Javascript-seo-basics

Le « codelab » pour apprendre à coder avec les frameworks Javascripts de façon SEO friendly
https://codelabs.developers.google.com/codelabs/making-a-single-page-app-search-friendly/index.html#0

Le billet du blog webmasters de Google sur le Dynamic Rendering
https://webmasters.googleblog.com/2019/01/dynamic-rendering-with-rendertron.html

La sĂ©rie de videos de Martin Splitt de Google sur Javascript et le SEO (Ă  voir absolument si vous vous intĂ©ressez Ă  ces technologies. Avertissement : il faut avoir des bases en dĂ©veloppement web pour suivre, mais c’est trĂšs clair et trĂšs pĂ©dagogique)
https://www.youtube.com/playlist?list=PLKoqnv2vTMUPOalM1zuWDP9OQl851WMM9

Un billet du blog de l’agence Search Foresight dans lequel je commente ces vidĂ©os :
https://www.search-foresight.com/Javascript-seo-les-recommandations-de-google-evoluent-et-se-clarifient/

Un billet du blog de Search Foresight sur l’hybrid rendering vs le dynamic rendering
https://www.search-foresight.com/john-mueller-recommande-le-dynamic-rendering-chez-search-foresight-on-napprouve-pas/

L’annonce de Google sur Googlebot Evergreen
https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html

 

Philippe Yonnet, fondateur de l'événement SEO Search Y (https://www.search-y.fr)