Newsletter Novalem Actualités et Tendances SEO-SEA !

Vers un meilleur référencement d’application web single-page

AngularJS, Backbone.js ou Ember.js : vers quoi se dirige-t-on d’un point de vue SEO ?
Auteur
Awais Walayat
Chef de Projet SEO

De plus en plus de sites sont créés avec les frameworks AngularJS, Backbone.js ou Ember.js pour fournir une fluidité de navigation à l’internaute mais le référencement de telles applications reste délicat. Ces frameworks permettent de créer des applications web single-page.

Qu’est-ce qu’une Single Page App (SPA)?

Une application web « single-page » est une application dont les différents contenus sont appelés via une seule page unique. Ces applications utilisent en grande partie le JavaScript et l’AJAX. Ajax (acronyme de Asynchronous JavaScript and XML) est une technologie permettant d’effectuer des requêtes serveur sans recharger une page web. Ainsi, il est possible d’interagir plus rapidement avec une source d’informations, généralement une base de données, et d’effectuer toutes les actions classiques de lecture, création, modification, ou suppression de données.

Une application de ce type fonctionne globalement de la manière suivante :

Le gros avantage de ce type d’application est donc de permettre de fluidifier la navigation de l’internaute sur le site car il n’y a pas de rechargement de page entière dans le navigateur mais uniquement un chargement dynamique de nouveaux blocs.

Remarque : A ne pas confondre avec un SPT (single page template ou one page template) qui est une page unique composée de plusieurs portions représentant chacune une rubrique du site. Ou une page à scroll infini qui injecte de nouveaux contenus au fur et à mesure du scroll et non lors de la navigation de page en page.

Cependant lorsque les contenus sont générés de cette manière, cela pose un problème de crawl et d’indexation des contenus pour les robots des moteurs de recherche.

En quoi une SPA est problématique pour les moteurs de recherche ?

Les robots des moteurs de recherches n’indexent pas de base le contenu généré par Ajax car les robots ne peuvent y accéder. AJAX utilise en grande partie le JavaScript qui s’exécute côté client et que les moteurs de recherche n’interprètent pas. Ainsi lorsque l’Ajax génère du contenu sur une page, il est invisible pour les robots d’indexation qui ne voit que le code HTML généré à l’origine par le serveur.

A l’heure actuelle une aide doit être fournie aux moteurs de recherche pour éviter les problèmes de crawl et d’indexation.

La technique proposée par Google pour crawler le contenu généré en Ajax

Les recommandations de Google

Les différents états de la page sont représentés par une URL de la forme : http://domaine.com/#etat.
Google ne considère pas les URL sous cette forme comme des pages uniques, le fragment « #etat» désignant une ancre interne au site.

Google préconise d’utiliser la technique dite du « hashbang » (#!) : tous les états doivent être représentés sous la forme http://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 en AJAX.

Dans le détail, Google va remplacer le « #! » par « ?_escaped_fragment_= ». L’URL sous la forme http://domaine.com/#!etat deviendra donc http://domaine.com/?_escaped_fragment_=etat . Cette URL devient lisible pour le serveur et sera demandée par Google pour lire le contenu généré par Ajax.

Remarque : Les « URL » sous la forme http://domaine.com/?_escaped_fragment_=etat ne sont pas visibles, seules les URL sous la forme http://domaine.com/#!etat doivent être renseignées dans les liens, canonique, sitemap, etc. Pour le cas particulier de la page d’accueil qui ferait appel à de l’AJAX sans hashbang dans l’URL, la balise <meta name= »fragment » content= »! »> peut être utilisée en alternative.

Maintenant que l’on a indiqué à Google que nos URL font appel à du contenu généré par AJAX, il faut lui fournir ce contenu. Pour cela nous devons lui fournir des instantanés (snapshots) de nos pages telles qu’elles sont présentées à l’internaute.

Plusieurs solutions existent dont l’utilisation d’un navigateur « headless » (sans rendu graphique) qui est la solution la plus optimale mais aussi complexe à mettre en œuvre. Une fois mis en place, ce navigateur côté serveur fournira à Google la page incluant le contenu embarqué par le JavaScript.

Cette technique fonctionne bien pour le crawl et l’indexation des pages et ne nécessite pas de modifications sur le site à part l’ajout « ! » dans les URL. L’inconvénient majeur est la difficulté à la mettre en place au niveau du serveur, des outils existent pour faciliter sa mise en œuvre.

Les solutions à disposition

Des solutions externes existent pour aider à implémenter ces recommandations de Google comme Prerender.io, Brombone ou encore Ghostwriterjs (solution développée par Ekino conjointement avec Novalem). Ces solutions permettent de fournir aux crawlers 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 (via PhantomJs dans le cas de prerender.io) si celui n’est pas disponible.

Ne pas oublier d’indiquer toutes les URL dans le sitemap.xml nécessaires pour la génération de cache et de tester le crawl de ces pages dans la Search Console.

Le prix de ces services dépend du nombre de pages et de la fraîcheur du cache souhaitée. De nouvelles technologies apparaissent qui par leur fonctionnement répondent au problème d’accessibilité.

L’isomorphisme, une nouvelle manière de concevoir des SPA

Plusieurs librairies ont vu le jour ces derniers temps dont ReactJs pour augmenter les performances d’une application SPA et avoir quasiment des applications en temps réel. Déjà utilisées par des sites comme Instagram, Facebook, Airbnb, ces librairies ont aussi un avantage SEO dû à leur fonctionnement.

Comme vu précédemment, la génération de nouveaux contenus est demandée depuis le côté client dans une SPA. Ces librairies ont la particularité de pouvoir exécuter du code côté client et côté serveur, d’où le terme d’application isomorphique. Le rendu final étant fourni par le serveur, il devient donc accessible aux moteurs de recherche.

Ces librairies fonctionnent avec Node.js, un programme s’utilisant comme serveur web et traite le code fourni en JavaScript. Ainsi il est possible d’utiliser le JavaScript côté serveur à l’image de PHP.

Plus besoin de configuration serveur et de navigateur headless cependant l’inconvénient reste la difficulté à mettre en place ce type de librairie. La documentation est aussi pauvre à ce sujet.

Un référencement compliqué mais des progrès

En conclusion, le référencement de SPA n’est pas de tout repos et reste complexe à gérer. Les technologies évoluent et commencent à apporter des solutions de manière native pour l’accessibilité des contenus par les moteurs de recherche. Avec une plus grande utilisation du JavaScript dans les applications par les développeurs, il est probable qu’à l’avenir Google interprète correctement l’ensemble du JavaScript et indexe de manière native les contenus générés dans les SPA. John Mueller déclarait sur ce sujet en août 2015 que Google sera capable d’indexer une page telle qu’elle serait obtenue dans le navigateur de l’internaute.

Newsletter Septembre 2015