Vous aimez utiliser l’Ajax pour rendre votre site plus sympa? Que pense Google de tout ça ?

L’Ajax devient vraiment « à la mode » pour la conception des sites web. C’est normal car même si elle a ses contraintes, elle présente de très bons avantages :

  • Navigation dans le site sans jamais avoir à recharger la page du navigateur ;
  • Optimisation des temps de réponses en déportant les parties complexes une fois la page affichée ;
  • Intégration de contenus annexes pour améliorer l’expérience utilisateur ;
  • Le site se comporte comme une application ;
  • Amélioration de l’ergonomie et de l’expérience de navigation ;
  • De nouvelles possibilités de design et d’animations ;

Mais qu’en est-il d’un point de vue référencement naturel (SEO) ?

Actuellement, la plupart des sites créés qui chargent les contenus en Ajax, utilisent des URLs avec des hash (# ou #!). La bibliothèque AngularJS de Google est a été conçue pour aider à la conception de ce genre de site.

Par défaut, Google n’est pas capable d’accéder facilement à ces contenus pour les indexer (interprétation du JavaScript, complexité des pages…). Suite à la montée en puissance de ce genre de site, des recommandations officielles ont été faites pour faciliter le parcours de Googlebot.

La contrainte AngularJS : indexer vos pages dans Google – c’est bien, référencer parfaitement votre site – c’est mieux !

AngularJS est un framework JavaScript qui utilise un principe de composant dynamique pour construire les pages. Beaucoup d’autres librairies JavaScript permettent d’intégrer ce genre de comportement: Ember.js, Backbone.js

Ce genre de pratique offre un avantage important pour le chargement des pages web. Il est possible de ne télécharger le gabarit commun qu’une seule fois et ensuite de naviguer dans les pages en ne chargeant que les morceaux de contenus qui doivent changer.

Pour l’utilisateur, c’est un avantage certain en terme de performance de navigation même si ce principe ne se prête pas à tous les sites :

  • Si les différentes pages utilisent des gabarits très différents, le CSS pour gérer le style de toutes les pages peut être conséquent ;
  • Le code JavaScript nécessaire peut être vraiment important (de même tout le code nécessaire à toutes les pages du site doit être téléchargé dès la première page).

Il est possible de transformer ces contraintes en chargeant dynamiquement les CSS et les scripts nécessaires durant la navigation de l’utilisateur. Cette méthode peut vite devenir une « usine à gaz »…

La gestion d’URL : et oui, on revient aux « basiques »…

Lors de la navigation d’un utilisateur, les URLs des différentes pages du site peuvent être gérées de deux façons sur un site en Ajax :

  • Grâce au hash (# ou #!) on obtient alors: http://domain.com/url/arrivee#!/fragment/content/specifique
  • Grâce à l’API History d’HTML5 : http://domain.com/fragment/content/specifique

L’avantage de la première solution est qu’elle est très simple à utiliser. Par contre, l’utilisation du hash demande à Google de transformer l’URL pour indexer le contenu de destination.

La deuxième solution est clairement la plus pérenne car les URLs de navigation dynamique sont les mêmes que les URLs « normales » des contenus. C’est la surcouche faite pour dynamiser le chargement des contenus qui apporte une optimisation de navigation. Elle a aussi l’avantage de présenter un seul point d’entrée au site pour les internautes comme pour les robots et de permettre la navigation même lorsque l’internaute désactive le JavaScript.

La solution PhantomJS : vous pensez avoir trouvé la solution miracle ?

PhantomJS est un navigateur headless disposant d’une API JavaScript. Il permet de simuler le comportement d’un navigateur pour faire le rendu d’une page HTML. On obtient ainsi la structure HTML complète de la page ciblée.

Pour pouvoir aider Google à indexer les sites en Ajax utilisant la technique du hash, il est nécessaire de calculer le HTML complet représentant une page. Le robot accède ensuite à la structure générée en utilisant le bricolage du “_espaced_fragment_” décrit dans les recommandations. Googlebot n’utilise donc pas la même URL qu’un internaute.

PhantomJS permet de répondre à cette problématique en pré-calculant les différentes pages du site qui doivent être fournies à Googlebot. La complexité du JavaScript est cachée aux robots.

Attention cependant, le calcul de la structure HTML est beaucoup plus couteux en utilisant PhantomJS que pour un rendu de page « normal » car il simule le comportement d’un navigateur (téléchargement des CSS et scripts, interprétation du JavaScript, requêtes Ajax, …). C’est donc beaucoup plus long que le rendu du HTML par le serveur.

Il est clairement conseillé d’utiliser un cache de fichiers statiques (à plat ou avec un logiciel comme “Varnish”) pour éviter ce genre de calcul à chaque passage du robot.

Au final, prenez le temps de vous poser quelques questions …

Faites un test ! Si vous vous apercevez que vos CSS et JS sont vraiment gros, posez-vous bien la question est-ce que votre site ne contient que le nécessaire pour la page en cours ou est-ce qu’il contient tout le nécessaire pour l’affichage des différentes pages ?

Comme Google ne récupère que page à page, il peut être intéressant de lui fournir uniquement les CSS utiles. Qu’en pensez-vous ?

A noter que vous pouvez aussi aller un peu plus loin dans la démarche et vous challenger un peu. Exemple : l’utilisation d’un pipeline d’asset est clairement recommandée pour ce genre de problématiques (avec Gulp, Grunt, …) pour éviter les interventions manuelles. Réfléchissez aussi à l’utilisation de l’API HTML5 History pour la gestion des URLs plutôt que le Hash. Ainsi, plus de double logique de récupération du contenu….

Besoin d’un conseil ou d’une vérification ?  Vous souhaitez savoir si votre Phantom ne transforme pas notre ami Google en fantôme ? Contactez-nous.

Stéphane Hulard & Teodor Dachev

Cet article a 11 commentaires

  1. Le Saout Yannick

    Bonjour,

    Comme vous le dites à juste titre, l’utilisation de l’Ajax, via Angular ou autre, présente bien des avantages quand il s’agit de développer un site web. Le gros point noir aujourd’hui vis à vis de ces technologies concerne bel et bien l’indexation du contenu de ces sites par les moteurs de recherche, mais également les réseaux sociaux et les régies publicitaires qui souffrent du même problème.

    La mise en place d’une solution « maison » à base de PhantomJS permet de résoudre le problème sur de petits sites avec des contenus relativement statiques. Dès lors qu’il y a quelques milliers de pages cela peut devenir bien plus compliqué. C’est d’ailleurs pour cela que nous avons développé SEO4Ajax, un service qui gère cette problématique pour vous. En crawlant régulièrement le site, il s’assure que les captures sont mises en cache et toujours à jour. En plus des captures HTML, le service permet de gérer proprement les softs 404 en renvoyant aux robots un vrai code HTTP 404 ou une redirection HTTP le cas échéant grâce, notamment, au moteur de règles de réécriture intégré au service.

    1. Stéphane HULARD

      Bonjour Yannick,

      Vous proposez effectivement une solution intéressante pour aider à gérer PhantomJS. Cependant nous préconisons toujours la mise en place de l'API HTML5 avec un point d'entrée unique pour le visiteur comme pour Google.

      La technique du "hash" reste quand même une sorte de bricolage pour indexer un contenu par défaut non indexable. C'est la plus répandue car la plus simple et elle était historiquement utilisée par les site en flash mais les contraintes induites ne sont pas négligeables.

      Google pourrait arrêter de gérer le `_escaped_fragment_` mais il ne pourra pas arrêter de naviguer dans un site.
      La partie JavaScript a intégrée devient un peu plus complexe mais le jeu en vaut la chandelle, il faut avancer vers un web qui respecte les standard 😉

  2. Stéphane HULARD

    C’est maintenant officiel, dans un article publié très récemment, Google annonce qu’il va déprécier le hack du `_escaped_fragment_`. Il peut apparement crawler les site en Ajax grâce à de nouvelles fonctionnalités dans le moteur.

    Ils conseillent d’utiliser l’API History d’HTML5 pour gérer correctement l’indexation des contenus pour la plus grande partie des moteurs.

    À bon entendeur 🙂

  3. Cyril

    Bonjour Stéphane,

    Merci pour cet article instructif.

    Je suis en train de mettre en place un projet de site avec un développeur qui pense le construire sous Angular.js.

    Après quelques recherches, et étant référenceur de formation, je suis vite tomber sur les limites de ce language concernant le référencement seo.

    Votre article date de 2015, savez-vous si la donne à changé ?

    Que pensez-vous également d’un outil comme prerender.io ?

    1. Stéphane HULARD

      Bonjour Cyril,

      Je réponds un peu tard mais pour moi la logique présentée ici reste toujours la même. L’idée est « simplement » de chercher à aider Google ou tout autre robot d’indexation à faire son travail.
      On ne peut pas être sûr que si vous cachez votre contenu derrière des appels serveurs complexes les moteurs sauront l’interpréter. Par contre on est certain qu’ils comprennent les pages HTML de base.

      Les outils comme prerender.io jour le même rôle que Phantom.js et peuvent être utile dans notre cas. Les frameworks JavaScripts comme Angular, Vue.js ou React sont super cool pour les développeurs mais ce n’est pas une raison pour les utiliser partout tout le temps !

  4. f4b1

    Merci beaucoup pour cet article, j’étais à la recherche d’informations sur le sujet car j’étais un peu inquiet avec ces framework javascript et le SEO mais ca semble le faire avec vos explications !

    Bookmark obligé 🙂

  5. Anne

    Bonjour Stéphane,

    Merci pour votre article. Mais j’ai entendu dire qu’en 2016 Google a annoncé qu’il ne fallait plus utiliser d’outil comme Prerender pour aider au référencement des sites en javascript.
    J’ai un site en angular.js et node.js et j’hésite à retirer Prerender car j’ai récemment baissé en positions Google de manière très nette et je me dis que peut-être que désormais Google pénalise l’utilisation de Prerender : qu’en pensez-vous ?
    Merci pour votre aide !

    1. Stéphane HULARD

      Bonjour Anne,

      Le travers principal du rendu HTML côté serveur est qu’il faut être capable de détecter quel type de visiteur est en train d’accéder au site (un robot ou un internaute). C’est principalement le User Agent qui est utilisé pour ça hors il est tout à fait possible de falsifier son user agent lorsqu’on navigue sur le web (voir les extensions d’UA spoofing pour votre navigateur).

      Si cette détection est « mal » faite et ne fonctionne pas à tout les coups, Google peut accéder au site dynamique et ne pas réussir à récupérer le contenu HTML. C’est ce qui peut être une cause de la pénalisation.
      Il est aussi possible que Google utilise d’autres types de robots capable d’identifier sur quel techno repose un site pour savoir comment mieux le crawler. Malgré tout j’ai du mal à croire qu’il pénaliserait un site Angular.js sachant que ce framework a été développé par Google 🙂

      De tout façon les leçons à retirer de cette article restent valides : Il faut au maximum faciliter la vie de Google quand il passe sur votre site. Une techno / librairie / framework vient toujours avec son lot de défaut, il faut en avoir conscience et bien peser le pour et le contre avant de l’utiliser.

      D’expérience, il n’y a pas aujourd’hui de site qui ont été grandement pénalisés par l’utilisation d’outils comme Angular.js. Ce n’est pas tant le choix des outils que leur mise en place qui est importante. Je vous laisserai prendre contact avec nous si vous souhaitez que nous réalisions un audit de votre site 🙂

      1. Anne

        OK merci pour votre réponse. Mais je n’ai pas bien compris si vous recommandez de conserver ou d’enlever Prerender sur des sites en javascript ?
        Merci beaucoup pour votre retour !

        1. Stéphane HULARD

          Dans votre cas, j’aurais tendance à le laisser. En parallèle il faudrait analyser les logs serveurs pour voir quelles URLs Google utilise et comment il se comporte sur le site.
          Une baisse de trafic peut venir de beaucoup de choses, il faut prendre le temps d’analyser avant de modifier l’environnement technique du site.

Les commentaires sont fermés.