Avec le "Single Page Applications" (SPA), en règle générale, le contenu HTML n'est pas chargé dans le navigateur lors du chargement initial de la page web. Ajax utilise JavaScript pour communiquer de manière dynamique avec le serveur web pour créer le code HTML "à la volée" en fonction du comportement de l'utilisateur. (Il y a une technique appelée "Server-Side Rendering" où le JavaScript est effectivement exécuté sur le serveur et la page demandée est retournée avec le rendu HTML. Cependant, cette approche n'a pas encore été prise en charge sur tous les Frameworks SPA et ajoute de la complexité au développement.)

Un des problèmes récurrents avec les sites Ajax c'est le SEO. En fait, Google est capable de crawler des contenus JavaScript depuis un certain temps. Une récente série de tests ont confirmé la capacité de Google à explorer les liens, les métadonnées et les contenus insérés via JavaScript. En revanche, les sites Web en pure SPA Ajax Framework ont des défis historiquement vécus avec le SEO.

En 2009, Google a proposé une solution pour rendre l'Ajax "explorable". Cette méthode se base sur la création d'URL "escaped fragment" ou plus récemment, des URLs "propres" incluant un Meta = "fragment" tag sur la page.

Les "URL Escaped Fragment" ou le "Meta Fragment Tag" obligent Google à sortir une version "prérendue" de la page, issue de l'exécution de l'ensemble des éléments Javascript avec tout le HTML que Google peut analyser et indexer. Avec cette méthode, Google peut explorer tous les codes sources des différentes pages (HTML, JavaScript, etc.)

Depuis que Google a annoncé qu'il explore le JavaScript, de nombreux sites ont décidé de laisser Google explorer leurs sites en SPA Ajax. Globalement, cela n'a pas été une réussite. Sur un ensemble de sites Web utilisant en particulier AngularJS, la conclusion est la suivante: au final, environ seulement 30% des pages sont bien indexées correctement avec l'ensemble du contenu HTML, et 70% apparaissaient blanches !

Un site de vente de nourriture très connu est récemment passé en full-AngularJS, croyant que Google pourrait le crawler. Ils ont perdu environ 70% de leur trafic organique et se remettent encore de cette débâcle. Ils ont été obligés de mettre en place le prérendu HTML, seule technique réellement efficace du moment.

Et puis, le 14 octobre 2015, Google a affirmé :

"Nous ne recommandons plus l'exploration Ajax selon les instructions que nous avions publiées en 2009".

Il faut noter que le moteur soutient toujours ces anciennes instructions. (Il y a eu quelques articles annonçant qu'ils ne la soutenaient plus, mais ce n'est pas la réalité, tout simplement il ne recommande plus cette approche)

En dévalorisant ainsi l'ancienne recommandation, Google semble indiquer qu'il peut désormais indexer l'Ajax.

Mais pourquoi? Google affirme qu'il peut explorer l'Ajax.

Jetons un regard plus profond sur la nouvelle recommandation de Google à l'égard de l'Ajax.

Les nouvelles recommandations de Google pour Ajax

En expliquant pourquoi Google dévalorise l'ancienne recommandation, il affirme :

"Nous sommes en général capables d'afficher et d'interpréter vos pages Web comme les navigateurs modernes."

Beaucoup de gens pourraient conclure que Google peut désormais explorer l'Ajax sans problème.

Google dit "En général capables"? Cela veut dire qu'une entreprise met en risque son chiffre d'affaires si elle se base sur l'affirmation de Google "qu'il est généralement capable de comprendre les pages" ?

Lors de l'exploration, Google pourrait-il simplement analyser le côté sémantique d'un site ? Examinons l'annonce de Google à l'égard de l'Ajax:

"Les hypothèses de notre proposition de 2009 ne sont plus valables, nous recommandons désormais de suivre les principes de l'amélioration progressive."

Google ne le déclare pas dans son annonce, mais il recommande une amélioration progressive (charger le HTML pour les navigateurs qui ne prennent pas en charge le JavaScript). Google semble dire implicitement "Ne comptez pas sur nous pour l'exploration de votre JavaScript". Pourquoi Google recommande cette méthode tant qu'il peut toujours analyser les sites SPA Ajax ?

John Mueller confirme, Google a encore des problèmes avec l'Ajax

Le 27 octobre (moins de deux semaines après l'annonce initiale), John Mueller confirme sur son webmaster Hangout que Google a en effet toujours des problèmes avec l'Ajax.

Vous pouvez voir l'échange à autour de 1:08:00 dans la vidéo, où il y avait une question relative à une mise en œuvre Angular spécifique.

Google a encore du mal avec le rendu, et il espère faire mieux au fil du temps. John recommande certaines actions pour aider à déboguer les problèmes.

En fin de compte, il a recommandé d'utiliser des instantanés HTML jusqu'à ce que Google indexe mieux l'Ajax (oui, la méthode qui vient d'être officiellement obsolète).

Alors, que faire ?

L'amélioration progressive : Le rendu côté serveur serait la première étape facilitant le travail de l'exploration et l'indexation. À la prochaine mise à jour, Angular 2.0 prendra en charge le rendu côté serveur. Le Server-Side Rendering le permet présentement.

Ceci représente cependant plus de travail que la simple création de HTML Snapshots. Vous devez vous assurer que vous prévoyez tous les liens nécessaires afin que Google puisse analyser et indexer le contenu supplémentaire qui est chargé dans la page.

Néanmoins, pour les sites utilisant un Framework Ajax, ce serait l'approche recommandée par Google. (Et, bien sûr c'est l'approche recommandée par Google)

Le prérendu HTML Snapshots : Encore une fois, ne soyez pas confus si vous avez lu ou vous avez entendu que Google ne supporte plus cette méthode. Google va continuer à la soutenir dans un avenir proche.

Cependant, l'écriture du code de pré rendu n'est pas triviale. La bonne nouvelle vient de certains applicatifs comme "Prerender.io" qui feront le travail pour vous à un coût relativement faible. Cela est probablement l'approche la plus simple.

Cette méthode n'est toutefois pas idéale. Générer un code source différent pour les robots et les navigateurs (HTML vs JavaScript) peut être problématique. Cela peut être considéré comme une technique de cache et il n'est pas nécessairement évident que les robots les explorent. Il est important de surveiller le cache de Google pour vous assurer que les robots indexent les bonnes pages.

Néanmoins, si vous utilisez une plateforme qui ne supporte pas le Server-Side Rendering, alors cela peut être votre seule et unique solution.

Mieux vaut prévenir que guérir

Même s'il y a la preuve que Google peut analyser constamment des sites Ajax, il faut encore se méfier. Cela nécessite beaucoup plus de ressources et beaucoup plus de temps pour retourner une page entière comparée au chargement d'une simple page HTML.

Que va-t-il arriver aux sites avec des centaines de milliers ou des millions de pages ? Quel sera l'impact de l'exploration ? La vitesse d'exploration restera-t-elle cohérente ? Toutes ces questions n'ont pas encore de réponses claires.

Avant de recommander cette approche, il vaut mieux attendre des preuves solides de Google, s'il peut toujours explorer des pages d'applications Ajax sans aucun impact négatif sur le taux d'exploration, l'indexation et le classement.

Il faut noter que le moteur soutient toujours ces anciennes instructions. (Il y a eu quelques articles annonçant qu'ils ne la soutenaient plus, mais ce n'est pas la réalité, tout simplement il ne recommande plus cette approche)   En dévalorisant ainsi l'ancienne recommandation, Google semble indiquer qu'il peut désormais indexer l'Ajax.