Google peut t-il parcourir les sites en Ajax ou en Javascript ?

Dernière mise à jour le 9 Déc 2021
69bc9c3e85c501b0a6208cc7a55abbf9_L
Le 14 Octobre dernier, Google ont annoncé que les recommandations qu’ils ont publiées en 2009 ne sont plus valables et que vous pouvez maintenant compter sur Google pour explorer et indexer avec succès n’importe quel site contenant de l’Ajax, du JavaScript ou du jQuery. Les concepteurs de sites web et les ingénieurs aiment l’Ajax pour la construction en « Single Page Applications » (SPA), ou aussi appelées « One Page Design », avec des Frameworks populaires comme AngularJS et ReactJS. La pure implémentation d’Ajax permet d’aboutir à une application web plus interactive qui réagit comme une application desktop.

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é pris en charge sur tous les Frameworks SPA et ajoute de la complexité au développement.)

Un des problèmes récurrent 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é-rendu » 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és 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 soutien 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.

Puis, une semaine seulement après l’annonce, la vérification d’un site nouvellement lancé en Ajax, un site avec AngularJS avec une implémentation en SPA Ajax, en examinant l’index et le cache de Google, nous remarquons que quelques pages sont que partiellement indexées, l’ensemble du contenu n’avait pas été crawlé. Donc, la bonne recommandation c’est d’utiliser le HTML Snapshots ou réaliser une amélioration continue du code.

Ce site en AngularJS, qui ne supporte pas encore le « Server-Side Rendering  » (encore une fois, dans ce cas, le serveur retourne d’abord une page pour exécuter le code HTML), la mise en valeur de manière progressive est difficile à mettre en œuvre, et HTML Snapshots reste toujours la meilleure solution.

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 à environ autour de 1:08:00 dans la vidéo, où il y avait une question relative à une mise en œuvre Angular spécifique.

{youtube} i_xnKznRNCc{/youtube}

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. A 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é 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.

    Téléchargement du module

    Laissez-nous votre prénom et votre adresse de courriel pour vous envoyer le module par courriel:


      Pssssst Attendez...

      Laissez nous votre meilleure adresse email et vous recevrez le premier nos prochaines publications...


        Recevoir chaque semaine notre publication en avant première.

        Rejoignez nos 153 845 fidèles lecteurs et restez informés concernant le domaine du développement web, en étant le premier à recevoir notre publication chaque semaine.