Les Frameworks JavaScript sont de plus en plus utilisés dans le développement d’applications web et permettent d’offrir des interfaces plus réactives et donc une meilleure expérience utilisateur à l’internaute. Parmi ces Framework JS : Backbone.js, Ember.js ou le plus connu AngularJS, qui rappelons le a été conçu par des ingénieurs de Google. Quelle est la marche à suivre en terme SEO ?
Qu’est-ce qu’une application web single-page (SPA)?
Une application web single-page est une application accessible via une unique page. Ainsi les contenus sont injectés dans une seule unique page sans rechargement complet de page du serveur. Ces applications fonctionnent grâce à la méthode Ajax. L’Ajax (acronyme de Asynchronous JavaScript and XML) utilise différentes technologies dont le JavaScript s’exécutant côté client (navigateur) pour effectuer un transfert de données entre le client et le serveur web. Par conséquent en éliminant le rechargement de page, il est possible d’interagir plus rapidement avec une source d’informations comme une base de données.
Exemple d’utilisation de l’Ajax :
- L’infinite scroll : Des contenus sont injectés dynamiquement depuis une base de données via des appels Ajax effectués au fur et mesure du scroll d’un internaute sur une page
- L’auto-complétion : La recherche d’un internaute est complétée dynamiquement lors de la saisie dans un champs de recherche, cette fonctionnalité nécessite l’utilisation de l’Ajax pour faire des requêtes au serveur et aller chercher dans une base de données les correspondances.
Sur ce même principe, les applications web single-page simulent différentes pages sur une seule unique page. Le fonctionnement est globalement le suivant :
- Le serveur délivre initialement à l’internaute un cadre HTML et les différents fichiers servants au fonctionnement de l’application (JS, CSS, …)
- Lors de la navigation de l’internaute, l’application va générer le code HTML correspondant et l’injecter côté front. On parle d’« état » de page : à chaque état correspond donc une page avec un contenu unique.
Il n’y a plus de rechargement de page par le serveur lors de la navigation de l’internaute. Ce fonctionnement permet de fluidifier la navigation de l’internaute mais le référencement d’une telle application devient plus complexe.
Le référencement SEO problématique des applications Web single-page
Historiquement, les robots des moteurs de recherches n’indexaient pas les contenus générés via Ajax car tout simplement les robots étaient incapables d’exécuter le JavaScript, un langage côté client (navigateur). Ainsi le code visible et compris par un robot était le code HTML initialement servi par le serveur.
La recommandation était donc de fournir aux moteurs de recherche la page finale directement pour qu’elle puisse s’indexer.
La première recommandation de Google est toujours valable
On l’a vu précédemment, le contenu est injecté dans une seule et unique page lors de la navigation d’un internaute. Ce qui correspond à chaque « état » de page. Afin de différencier chaque état de page grâce à une url, l’utilisation d’un fragment était historiquement nécessaire, ce qui donne des URL de type : http://www.domaine.com/#etat. Par exemple, dans un SPA nous aurons différentes pages représentées de la manière suivante http://www.domaine.com/#qui-sommes-nous ou encore http://www.domaine.com/#contact . (L’utilisation d’un fragment était le seul moyen technique de faire varier une url sans rechargement de page via le serveur)
Les URL sous cette forme ne sont pas considérées comme des pages uniques, le fragment « #etat» désignant une ancre interne à une page du site . Google préconisa d’utiliser la technique dite du « hashbang » (#!) : tous les états doivent être représentés sous la forme http://www.domaine.com/#!etat . Ainsi lorsque Google crawlera le site web et rencontrera ce type d’URL, Google comprendra qu’il s’agit de contenus générés dynamiquement et qu’il devra demander la page finale via une seconde url pour pouvoir indexer le contenu.
Concrètement, Google remplace le « #! » par « ?_escaped_fragment_= » dans l’URL. L’URL sous la forme http://www.domaine.com/#!etat deviendra donc http://www.domaine.com/?_escaped_fragment_=etat . C’est cette URL qui sera demandé au serveur.
Maintenant que l’on a indiqué à Google que nos URLs font appel à du contenu généré par Ajax, il faut lui fournir ce contenu. Pour cela nous devons lui fournir des instantanés de nos pages telles qu’elles sont présentées à l’internaute.
Plusieurs solutions existent dont l’utilisation d’un navigateur « headless » (un navigateur « sans tête » est un navigateur web sans interface graphique) qui est la solution la plus optimale. Une fois mis en place, ce navigateur côté serveur mettra en cache les instantanés finaux des pages (avec le code JavaScript déjà exécuté). Ce sont ces instantanés qui seront servi à Google lorsqu’une URL de type http://www.domaine.com/?_escaped_fragment_=etat sera demandée.
Cette technique ne nécessite pas de modifications sur le site à part l’ajout « ! » dans les URLs. L’inconvénient majeur est la difficulté à la mettre en place au niveau du serveur, des solutions prêtes à l’emploi existent pour faciliter sa mise en œuvre.
Des solutions externes existent pour aider à implémenter ces recommandations de Google comme Prerender.io pour ne citer que la plus connue. Cette solution permet de fournir aux crawler des instantanés des différentes pages.
Lorsqu’un robot demande la page, le service sert un instantané mis préalablement en cache ou génère l’instantané via un navigateur headless (exemple PhantomJs dans le cas de prerender.io) si celui n’est pas disponible. Ce navigateur sans interface graphique va interpréter correctement le JavaScript et fournir le HTML final de la même manière qu’un navigateur classique d’un internaute.
Remarque : Les « URL » sous la forme http://www.domaine.com/?_escaped_fragment_=etat ne sont pas visibles, seules les URL sous la forme http://www.domaine.com/#!etat doivent être utilisées côté front dans les liens, canonique, sitemap, etc. Pour le cas particulier de la page d’accueil sans hashbang dans l’URL, la balise <meta name= « fragment » content= « ! »> peut être utilisée en alternative.
Le prix de ces services dépend du nombre de pages et de la fraîcheur du cache souhaitée.
Les progrès réalisés par Google depuis des années amènent du changement dans les recommandations.
La nouvelle recommandation de Google pour le SEO
Google recommande en octobre 2015 de ne plus suivre l’ancienne recommandation consistant à prérendre les pages via la méthode du « hashbang ». Cette recommandation fait suite à la précédente communication de Google un an plus tôt de ne pas bloquer les fichiers JS et CSS car les robots sont désormais capables de crawler et d’indexer une page faisant appel à du JavaScript de manière native. Ou plus simplement : Google a accès au même rendu d’une page que celui présent dans le navigateur d’un internaute. (Google demande pour cela de ne pas bloquer les fichiers JS et CSS).
A noter que les précédentes recommandations restent valables, ainsi les sites utilisant la technique de l’_escaped_fragment_ continuent d’être supportées par Google. Doit-on pour autant abandonner le pré-rendu des pages ?
SEO: Laisser Google interpréter le JavaScript ou pré-rendre ?
Ne plus pré-rendre les pages a des inconvénients et peut aussi avoir des effets néfastes sur la visibilité du site web dans les moteurs de recherche. Plusieurs facteurs expliquent cela.
Le crawl se retrouve directement impacté. En effet, chaque site dispose d’un temps alloué par Google pour le parcourir et indexer les contenus. On parle de « crawl budget ». Ainsi lorsque que Google doit reconstruire une page, c’est un temps consommé du crawl budget. Ce temps pourrait être économisé avec un pré-rendu fourni par le serveur. Forcément, sur un gros site comportant énormément de pages et mis régulièrement à jour, cela peut être un inconvénient de taille pour la visibilité du site dans les résultats de recherche.
Également, un code JavaScript lourd et complexe peut empêcher Google d’avoir un rendu de qualité, il faut veiller notamment à limiter le nombre de ressources JavaScript et les temps de réponses sous peine de fournir une page partielle aux robots.
A l’heure actuelle, seul Google est capable d’interpréter le JavaScript. Ne pas pré-rendre les pages impactera la visibilité sur les autres moteurs de recherche comme Bing utilisant la méthode de l’_escaped_fragment_. Même si Google représente en France plus de 90% du marché, Bing progresse et surtout aux USA où il représente 20% des parts de marché.
Enfin, la maintenance du site devient également plus compliquée en éliminant le pré-rendu de base qui pouvait être utilisé pour monitorer et accéder aux différents contenus du site. Donc il faudra toujours mettre en place à côté une solution technique permettant d’interpréter le JavaScript et ainsi pouvoir suivre l’état du site.
Pré-rendre reste le meilleur moyen d’éviter les problèmes de crawl et d’indexation.
Remarque : Screaming frog dans sa dernière version (6.0) qui vient de paraître, permet d’interpréter le JavaScript.
La solution optimale : Pré-rendre et HTML5
Le HTML5 a introduit des nouveautés comme la méthode pushState() qui permet de créer une nouvelle entrée dans l’historique du navigateur. En d’autres termes, l’url affichée dans le navigateur peut être modifiée dynamiquement sans rechargement de page. Ainsi pour différencier les états de pages nous avons la possibilité d’avoir des url propres telles que : http://domaine/etat1 et http://domaine/etat2 au lieu de http://domaine#etat1 et http://domaine#etat2.
Cependant, il reste toujours à indiquer que le robot doit demander l’url de type « ?_escaped_fragment_= » pour avoir l’instantané de la page et l’indexer. Auparavant lorsque Google rencontrait une url de type « #! «, l’url était automatiquement traduite sous la forme « ?_escaped_fragment_= » . Avec la méthode pushState(), il faut rajouter sur toutes les pages la meta : <meta name= »fragment » content= »! »> . Lorsque Google rencontrera cette meta dans la page, l’url demandée par le robot sera de la forme « ?_escaped_fragment_= » . Exemple l’url http://domaine/etat1 deviendra http://domaine/etat?_escaped_fragment_= . C’est cette dernière qui fournira le code complet de la page aux robots des moteurs de recherche.
Exemple de mise en place sur le site de prerender.io qui a implémenté sa propre solution :
- Le code généré via l’URL https://prerender.io/ , ne comporte que le cadre HTML et les différents fichiers JS notamment servant au fonctionnement de l’application.
- Le code généré via l’URL https://prerender.io/?_escaped_fragment_= contient l’ensemble des contenus.
Cette solution permettra de pré-rendre les pages avec des urls propres et un minimum de risque concernant le référencement de notre SPA. Ne pas hésiter à utiliser l’outil « explorer comme Google » dans la search console ou voir le cache Google (moins fiable d’après Google) pour avoir un aperçu de la page finale vu par Google.
Le référencement SEO des web single-page reste délicat
En conclusion, le référencement de SPA n’est pas de tout repos et reste complexe à gérer. Google interprète le JavaScript et indexe de manière native les contenus générés dans les SPA. Mais pré-rendre les pages avec des urls propres faisant appel à la méthode pushState() reste la solution fiable à ce jour et nécessite une équipe technique web / SEO maitrisant les SPA. En l’état actuel, dans le cas d’un site pour lequel le SEO est fondamental, l’utilisation de SPA n’est pas conseillée.
