L’escaped_fragment et Ajax, un peu d’histoire :

Charger un contenu avec de l’Ajax possède de nombreux avantages. Un temps de chargement très rapide et une grande fluidité dans

l’affichage du contenu sont autant de points qui améliorent fortement l’expérience utilisateur. Toutefois cette technologie n’a pas toujours eu bonne presse auprès des moteurs de recherche.Ajax logo

Le souci principal des robots était qu’ils n’arrivaient pas à comprendre, d’une URL Ajax à une autre, quelle était l’étendue du contenu qui changeait. Sont-ce seulement quelques pixels, une nouvelle image ou presque l’intégralité du contenu de la page ? Pour économiser leur budget de crawl, les moteurs de recherches, Google en tête, décidèrent de ne pas crawler les URLs en Ajax.

S’est donc posée à l’époque la question de l’indexation des sites web présentant du contenu en Ajax, notamment pour les sites développés sous Angular JS. En effet, aucun site en Ajax ne pouvait décemment espérer performer en termes de SEO si son contenu était illisible pour Google. C’est pourquoi en 2009, les développeurs proposèrent de suivre le protocole du hashbang #! et de l’escaped_fragment pour rendre le contenu sur des URLs Ajax visibles pour Google.

http://www.monsite.fr/index.php#!exemple-d-url-en-ajax-avec-escape-fragment

Comment cela fonctionne-t-il ?

La méthode de l’escaped_fragment consiste à faire comprendre aux robots crawleurs que, s’ils cherchent à connaître le contenu d’une page Ajax, ils vont devoir aller chercher une version statique de cette même page en interrogeant une URL de substitution.

crawlable-ajax-applications

  1. Le moteur arrive sur une page et trouve les liens sortants dont les URLS possèdent le symbole hashbang #! exemple : http://www.monsite.fr/index.php#!exempledurl
  2. Le robot convertit le #! Selon le protocole escaped_Fragment et transcrit l’URL ainsi http://www.monsite.fr/index.php?_escaped_fragment_= exempledurl
  3. Le robot interroge le serveur en lui demandant de lui fournir la page correspondant à l’ULR ainsi transformée,
  4. Le serveur fournit une version HTML statique de la page,
  5. Le robot analyse la page statique renvoyée et remonte les éléments clés. L’algorithme se servira des éléments remontés pour positionner la page dans l’index mais montrera dans ses résultats la page avec l’URL avec hashbang et pas l’URL de substitution en Escaped_Fragment

L’avantage de cette méthode, et non des moindres était de rendre ainsi accessibles aux moteurs les contenus appelés en Ajax. L’inconvénient est qu’elle nécessitait du développement, une parfaite correspondance entre l’URL version Ajax et la page statique, et, s’il était possible d’indiquer aux robots d’utiliser un autre symbole que le #!, les webmasters étaient néanmoins obligés d’en utiliser un et n’avaient donc pas le total contrôle de la nomenclature de l’URL.

Si la méthode de l’Escaped_fragment fut largement employée pour rendre les sites Ajax Google Friendly au début des années 2010, une nouvelle  façon de procéder, plus efficace vint peu à peu la remplacer.

pushState(), l’Ajax en mieux :

La méthode du pushState() apparue vers 2012, possède de nombreux avantages au-delà de rendre les seuls contenus en Ajax Google Friendly.  En effet, window.history.pushState() est une fonction JavaScript pour HTML 5 permettant tout simplement de changer le chemin de l’URL qui apparaît dans la barre de recherche de l’internaute. Et c’est tout. Pas d’appel à un serveur, pas de requête d’une nouvelle page, rien de plus.

Le contenu Ajax va être appelé et affiché de la même façon,  sauf que la nouvelle URL poussée par le PushState au moment du chargement de l’Ajax correspond bien à la véritable version de la page statique stockée sur le serveur. Ainsi quand le crawleur passera, il ne verra qu’une URL propre, sans #!, qu’il pourra crawler et indexer.

L’avantage est bien sûr de bénéficier de toutes les fonctionnalités de l’Ajax en termes de rapidité d’affichage du contenu, tout en conservant les bénéfices SEO d’avoir ses URLs propres et crawlables. L’autre avantage est de pouvoir partager (sur les réseaux sociaux notamment) une URL qui remontera le bon contenu appelé en Ajax. Les inconvénients sont bien moindres que pour la méthode de l’escaped_fragment, avec notamment des coûts de développement plus réduits. En revanche certaines (très) vieilles versions de certains navigateurs ne prennent pas en compte le pushState().

Pourquoi en parler ?

Parce que dans un Google Hangout daté du 20 octobre 2017, John Muller, Webmaster Trends Analyst et grand prohète chez Google, a laissé entendre que si jusque-là l’escaped_fragment n’était plus recommandé mais toujours bien crawlé par les robots, cela ne serait bientôt plus le cas.

Ce qu’il a dit : « I would expect that at some point we would be turning off crawling of the escape fragment URLs [..] So if you’re only serving the structured data on the escape fragment version of the page then I suspect that will kind of make things a bit more complicated in your specific setup”

(« Je m’attends à ce que nous arrêtions l’exploration des URL en Escape_fragment […] Donc, si vous ne servez que les données structurées sur la version Escape_Fragment de la page, alors je pense que cela compliquera un peu plus votre configuration. »)

Ainsi, dans le mesure où l’essentiel de votre site est en Ajax et que ce contenu est rendu accessible via l’Escaped_fragment, c’est l’intégralité de vos pages qui ne sera plus crawlée, ce qui impactera très fortement votre SEO. Si vous utilisez l’escaped_fragment, nous recommandons donc très fortement à la place d’utiliser la méthode pushState().

Comment savoir si mon site utilise l’Ajax avec escape_fragment ?

  • Votre site affiche très rapidement du contenu
  • Votre site ne semble pas recharger une page lorsque vous cliquez sur un lien
  • Vos URLs contiennent #! ou un autre symbole avant la fin de l’URL

Dans le doute n’hésitez pas à solliciter votre équipe technique.