Remarque : je ne suis pas un développeur AJAX, merci donc de me signaler toute erreur ou approximation que vous pourriez relever dans cet article.
L'article qui suit est issu d'une proposition décrite par Katharina Probst, ingénieur chez Google, développée avec son équipe (Bruce Johnson, Arup Mukherjee, Erik van der Poel et Li Xiao).
L'utilisation du signe # dans les URL
Sans doute le savez-vous, à la base le signe # (hash en anglais) dans une URL précède ce qu'on appelle une ancre nommée. Par exemple, l'URL http://www.example.com/produit.html#descriptif pointe vers l'ancre nommée descriptif située quelque part sur la page produit.html. Ca permet de pointer vers un endroit précis d'une (longue) page, c'est utile par exemple pour les sommaires (voyez sur Wikipédia). Au passage, lisez mon article sur l'optimisation des URL pour le référencement ou celui sur le vocabulaire utilisé pour les URL.
Le problème avec certaines applications AJAX, c'est que ce qui suit le signe # ne correspond pas à une ancre nommée mais à des paramètres qui définissent l'état (state), par exemple http://www.example.com/page-ajax#etat
Attention : ceci ne concerne qu'un seul type d'utilisation d'AJAX, celui des pages associées à un état (stateful pages).
Pour pallier ce problème, Google propose que les pages en AJAX ajoutent un caractère spécial après le #, afin qu'on puisse les identifier de façon distincte. Ce token, comme on dit dans le jargon, pourrait être par exemple le point d'exclamation, ce qui donnerait des URL de ce genre : !etat
Problème avec AJAX et le SEO : le JavaScript
En fait si AJAX est un frein au référencement, c'est qu'il utilise le langage JavaScript, qui n'est (quasiment) pas pris en compte par les moteurs de recherche. Pour l'instant c'est surtout Google qui interprète certains codes JavaScript, les plus simples, en général pour trouver des nouvelles URL à indexer.
La solution proposée par Google
Pour pallier ce problème, Google propose un mécanisme un peu particulier :
- quand un internaute parcourt le site, il consulte des URL du style
!etatet si son navigateur interprète bien le JavaScript, le code AJAX va pouvoir fonctionner. C'est le principe actuel des sites en AJAX. - quand un robot arrive sur le même site, il repère les URL particulières comportant
#!. Il transforme alors l'URL en remplaçant le fragment par un passage de paramètre classique, le nom de la variable étant avec l'exemple de Google_escaped_fragment_. Donc en résumé, les robots essaieront de crawler des URL de ce genre :http://www.example.com/page-ajax?_escaped_fragment_=etat. Si l'URL possèdait déjà un ou plusieurs paramètres, il suffit d'ajouter le nouveau à la fin, ce qui donnehttp://www.example.com/page-ajax?id=12&_escaped_fragment_=etat
Que se passe-t-il ensuite ?
Le serveur doit être configuré de sorte à détecter quand une URL contient la variable _escaped_fragment_. Dans ce cas, il doit non pas renvoyer une page HTML contenant du code JavaScript, mais une code HTML avec le code JavaScript déjà interprété. Pour ce faire, le serveur doit posséder un outil du genre HtmlUnit qui se chargera de cette partie. Google appelle ça un headless browser et HtmlUnit se définit comme étant un GUI-Less browser for Java programs. Pour ceux qui s'intéressent à ça, jetez un coup d'oeil au projet Golf hébergé sur Google Code.
Indexation AJAX : la proposition de Google (source de l'image : blog Google Webmaster Tools)
Quelle URL sera finalement indexée ?
Au final :
- Les pages du site font des liens vers des URL du genre
!etat - Les internautes consultent les URL comme
!etat; leur navigateur interprète le code JavaScript de cette page - Les robots consultent les URL comme
http://www.example.com/page-ajax?_escaped_fragment_=etat; le serveur web du site leur renvoie un code HTML sans JavaScript, ce dernier ayant été interprété sur le serveur par un headless browser. C'est ce code HTML qui sera indexé par le moteur de recherche. - L'URL proposée par les moteurs de recherche dans leurs pages de résultats ne sera pas celle qu'ils ont interrogée mais bien celle qui est présentée aux internautes.
Est-ce une bonne solution pour indexer AJAX ?
Je ne suis pas spécialiste du développement AJAX donc je ne peux pas donner mon avis de ce point de vue (j'espère que vous le ferez dans les commentaires). Par contre j'ai 2 remarques qui me viennent à l'esprit...
Googlebot pourrait faire lui-même ce qu'il exige des serveurs web !
Pourquoi Google demande aux serveurs de se charger de cette tâche alors que ses robots pourraient très bien interpréter eux-mêmes le code JavaScript ? Tout simplement parce que ça coûterait cher à Google en ressources machine ! Pourtant, la solution proposée par Google sera coûteuse pour les gestionnaires de sites qui devront supporter les coûts de développement et de maintenance de ces headless browsers...
Même si Google possède indéniablement un pouvoir de persuasion important, du fait de son écrasante domination sur le marche des moteurs de recherche, il faudra certainement attendre de nombreuses années avant que la majorité des serveurs web intègrent ce headless browser.
Le risque de cloaking est important !
Si le comportement du site est différent selon le type de visiteur (humain ou robot), alors le risque de cloaking est réel. C'est-à-dire que le webmaster pourrait choisir de ne pas renvoyer exactement le même contenu selon qu'il s'agit d'un internaute ou d'un robot, fournissant aux robots une version optimisée pour le référencement.
Ce problème n'existerait pas si le headless browser était géré par Googlebot et non par le serveur web...
Des questions sur le référencement avec AJAX ?
Si vous avez besoin d'aide pour référencer un site qui utilise AJAX, venez discuter des techniques d'indexation d'AJAX dans le forum WebRankInfo.
Si cela ne suffit pas, vous pouvez aussi venir vous former au référencement : j'explique dans mon cours sur le référencement de sites dynamiques comment contourner ce genre de problèmes (en plus de Flash, des identifiants de session, des formulaires et autres contenus dupliqués...).
J'ai aussi été interviewé à ce sujet par le magazine 01 Net Pro (l'article n'est plus disponible).
Bonjour,
Très bon article.
De notre coté, sachant que la vitesse d'exécution du javascript est dépendant du moteur qui l'exécute et que les résultats sont fonctions du temps d'attente, nous avons opté pour la technique du Dynamic Rendering proposé par Google. Pour atteindre nos objectifs, l'article ci-dessous et l'outil indiqué nous ont été très utiles :
Très bon article.
Toutes les techniques importantes y sont présentées. Sachant qu'aujourd'hui tous les sites modernes basculent vers des framework Javascript en SPA, de notre coté nous avons mis en place la technique du Dynamic Rendering proposée par google.
Qui bien entendu est complémentaire des techniques que tu exposes ici.
Nous avons suivi cet article et utilisé l'outil proposé afin d'atteindre nos objectifs :
https://app.cataleezr.com/direct-display-doc/5e6175125cf56d3e4510e234/comment-bien-faire-referencer-son-site-web-moderne-par-google-et-les-autres-moteurs-de-recherche-technique-que-vous-devez-savoir-pour-ameliorer-votre-seo
l'exemple d'un site full ajax avec une seul url n'est effectivement pas bonne mais il ne faut pas oublier que l'on peut très bien utiliser des urls d'envoie de header http request plutôt que xmlhttprequest sur les liens de menu principaux. On peut donc avoir tout à fait une application full ajax sans pour autant n'avoir qu'une seul url pour l'appelle d'autres contenus. Le mieux est de différencier le contenu global du site et le contenu variable à l'intérieur d'un bloque. Comme ça on peut déjà bénéficier de lien url classique dans nos menus. après en ce qui concerne le contenu au centre du site qui puisse changer c'est là le plus gros problèmes. Je part de l'idée de toute façon que ce qui n'est pas important pour l'apport du traffic je l'ajaxifie. Déjà les formulaires (pas tous).
Après on peut paramétrer son application de sorte à ce que l'on passe par un dispatcher ajax. les urls sont normales ainsi que les liens sauf les appelles du controller.
Imaginons que au lieu d'appeler un extends de controller on fasse un extends de notre class ajax_controller par exemple. Bien entendu ce type de processus est surtout intéressant que pour les requêtes de type get car en post on ne voit pas l'utilité. On peut si non placer et créer un dispatcher entre le controller et le bootstrap. dans notre méthode il suffirait d'ajouter à la fin public lenomdemafonction_Ajax(){} par exemple pour signaler que c'est une fonction qui ne sera utilisé qu'en mode ajax.
Enfin pour le moment l'idée de google me semble un peu trop contraignante, à voir sans doute avec de prochaines norme future du html5 sans doute
Une petite démo qui illustre cette technique et en illustration sur Google:
http://geo.marmits.com/ajax-headless-browser.html
A ce que je vois dans les commentaires, certains ont des doutes soit sur la méthode de Google, soit sur le fait que le moteur de recherche sait ou ne saurait pas indexer des contenus en Ajax.
La solution de Google (Headless Brwoser et Escaped Fragment avec les ancres #!) fonctionne à merveille, mais ne sera utile que si le webmaster a accès à la configuration de son serveur...
Pour ceux que cela intéresse, j'ai fait un test sur le référencement de l'Ajax et qui est très complémentaires des indications données ici par Webrankinfo.
Moi aussi Hubert .
Un article court mais plus éclairant sur le sujet:
http://s.billard.free.fr/referencement/?2009/10/08/571-google-propose-une-methode-pour-le-referencement-des-sites-ajax
@bruno, désolé!
no comment , je n'aime pas votre ton .
@ Bruno: vous dîtes:
"Je ne voit aucun problème a l’élaboration d’un site en Ajax . :
justement il y a des problèmes de référencement (d'où ce topic et les propositions de Google)! "d'expérience utilisateur" (bookmark) et d'accessibilité (voir solutions proposées par ARIA)
"Si le site est construit de façon classique et que la couche Ajax est définie selon des fonctions js ."
Il y a une façon classique de construire un site? Ajax c'est du javascript! sans javascript, ce n'est pas de l'AJAX!
"Les moteurs suivront les liens sans interpréter les fonctions js ."
On peut "déclencher" un appel AJAX sans lien (avec ARIA c'est même désormais accessible!), ou avec un lien type href="#" 'insuivable'! Les moteurs de toute façon n'interprètent pas le javascript ou très peu (Google ayant annoncé qu'il prenait en compte open.window ou window.location dans le lien via href="javascript:... ou via l'attribut onclick).
Vous parlez également de fiabilité du javascript (?) vous croyez que les grands éditeurs (Google, Yahoo,...) n'ont pas trouvé une façon fiable de s'en servir? Pas plus ou pas moins que le php, javascript n'est fiable. Ce sont les web développeurs incompétents qui ne sont pas fiables! D'ailleurs un web développeur parle de validation côté serveur vs côté client. Le second étant facultatif, améliorant l'expérience utilisateur mais bien souvent "inaccessible (sans ARIA)" rendant le premier de toute façon obligatoire.
Enfin en ce qui concerne les réglages de cache (? pas sûr d'avoir bien compris ce que vous vouliez dire) apache php offre toutes les possibilités pour optimiser selon vos besoins la mise en cache de la réponse d'un appel AJAX sur le serveur. Je n'y vois aucun problème...
La vieille école avait délaisse le javascript, le web 2.0, ses webservices via AJAX, les frameworks js (jQuery, Prototype, ...) lui ont redonné ses "lettres de noblesse" et c'est tant mieux! car on ne peut pas se passer désormais de javascript.
Reste à généraliser ARIA pour régler les problèmes d'accessibilité et reste à suivre de prêt (grâce à Olivier ;-) les propositions de Google pour optimiser encore le référencement des sites utilisant AJAX.
Bien sur Olivier , on est d'accord , mais M6 est suffisamment connu pour se permettre ce type de comportement.
Ce qui est plus grave , ce sont les gens qui connaissent peu les techniques du Web , et mal conseillées ,
se retrouvent avec un site irréférençable ou dur a référencer
Excès de javascript , site en Flash .
Tout est question de stratégie , mais il faut connaitre le terrain pour faire le bon choix .
Si on a un site en Flah , on réalise également une version html conforme et légère pour le référencement .
Mais on peut se moquer royalement du référencement comme certaines marques chics .
Hop , je laisse mon lien pour une backlink , ni vu ni connu (je plaisante ) :)|
Hum , c'est encore moi .
Le référencement dans le cas de M6 , est un choix stratégique , la plateforme peut se permettre de passer a la trappe certaines parties de son site au niveau référencement , et privilégier une navigation agréable a l'œil .
Bruno : on peut tout à fait concilier les 2 (un site bien référencé et agréable à naviguer)
Bonjour Olivier .
Si , effectivement , il y a un gros problème , le site est irréférençable , il est en Flash , si je ne me trompe .
Personnellement , je suis de la vieille école .
J'ai un système de cache bien conçu , donc Ajax ne m'est pas utile pour l'instant ,
tout ce que je réalise est relativement rapide .
Javascript me fait un peur peur , par rapport a Php , beaucoup de fonctions sont absentes ,
sur l'encodage , base64 , etc ... Moi qui aime la fiabilité , je ne suis pas vraiment a l'aise pour promouvoir ce type de technique . Par contre la validation de formulaire avec Js est très utile pour l'upload d'image , mais évidemment , on ne peut se passer de la validation Php qui , elle , doit être présente , puisqu'elle ne peut étre désactivée par le client .
Ajax , correctement utilisé , est une solution viable , bien que je préfère m'en passer ,
un exemple ici :
Bruno
Bonjour a tous .
Je ne voit aucun problème a l'élaboration d'un site en Ajax .
Si le site est construit de façon classique et que la couche Ajax est définie selon des fonctions js .
Les moteurs suivront les liens sans interpréter les fonctions js .
Je ne voit aucun ploblème de référencement .
@bruno : regarde le site m6replay.fr et dis-nous si tu ne vois "aucun problème de référencement" (si ce n'est pas de l'AJAX c'est une techno très similaire, dites-moi si je me trompe)
A priori je pencherais pour des paramêtres passés en url-rewriting après le # et séparés par /
Suis entré pour voir mais c'est du gros Flash qui pue... Pas moyen de savoir d'autant plus que mon Safari sous Mac y plante...
Je vais vérifier comment se comportent Safari et FF avec ce genre d'ancre (intégrant des /)
Si ces ancres sont "normales" alors elles permettent sans doute le bookmarking... perspective intéressante.
Mais NB tout type de séparateur de paramètres peut faire l'affaire, l'avantage du slash c'est qu'il ne se rencontre pratiquement jamais dans un nom ou une chaîne littérale qui pourrait être passé en paramètre.
Quand il n'y a pas ce # devant, le slash a 2 désavantages (Drupal par ex utilse le / comme séparateur en url-rewrinting) il "simule" une profondeur de dossier sur le serveur:
1/ interdisant les url relatives pour ttes références à une ressource dans la page, comme les images par ex
2/ on dit (vous les SEO dîtes-moi si je me trompe) que plus une page est profonde plus sont référencement est pénalisé
ex pour mieux comprendre:
avec un Drupal par ex, c'est en réalité appeler et le script php va comprendre $param1=tag et $param2=seo
avec un # devant ) j'imagine qu'on peut arriver au même résultat en ajax qui va actualiser un div contener cible au sein de la page chargée initialement via index.php, et sans la recharger donc, en faisant appel par ex à:
content.php?param1=tag¶m2=seo
Après viennent 2 questions:
-est-ce bien standard? à terme est-ce que les navigateurs se comporteront toujours ainsi, en effet l'attribut id (qui sert d'ancre) n'admet pas, je crois, le "/"
-est-ce bien accessible? à priori oui...
En tout cas tout ça est très intéressant ... d'autant plus que je suis en plein dedans en ce moment j'essaie de re-faire un google-reader (moins évolué qd même) à partir d'un fichier opml dans une page unique mais bookmarkable en fonction du fil RSS lu. Ça doit être accessible, standard, sémantique mais sera interdit aux robots (noindex,follow)
Pour info j'ai mis à jour l'article grâce à vos commentaires : j'espère que c'est mieux comme ça ?
Je vous soumets une petite étude de cas : le site m6replay génère des URL de ce genre :
Ma question : pourquoi la technique utilisée sur ce site (AJAX a priori) génère-t-elle des URL de ce type ? On est exactement dans le cas de cet article non ?
PtitLu, c'est exactement ça: "en même temps". Javascript ajoute une fonctionnalité au "déplacement" dans la page (scroll), le gestionnaire d'événement surveille par exemple tout click sur un lien avec ancre, et au besoin y ajoute un appel ajax dans une fenêtre modal comme dans l'ex de la timeline. On a des exemples similaires avec des systèmes d'onglets. Ça reste de la bidouille car bien souvent il faut ruser pour stocker plusieurs données: qu'elle sera la requête ajax et où l'afficher, certain utilise l'attribut rel pour ça en plus des class et des id. On peut préfixer ces id aussi pour repérer la cible. Pour en revenir au sujet, il faut ajouter que javascript doit aussi surveiller à l'ouverture de la page (événements onload ou domready) s'il y a ou non une ancre dans l'url pour pouvoir prendre en compte un bookmark avec ancre qui serait le reflet d'un "état". C'est la moins pire des solutions et comme en plus Google vient de déclarer qu'il allait prendre en compte dans les résultats de recherche les ancres dans les pages pour cibler les sections du contenu de la page, tout se tient!
Aaaaaaah, merci Hubert, j'ai compris le coup des ancres #, et du coup le reste de l'article.
Les appels en ajax n'ont jamais eu besoin de #, le navigateur fait un appel vers une URL invisible pour l'utilisateur du site.
Par contre, dans certains cas (c'est le cas du lien google timeline ci-dessus), l'application ajax gère les boutons précédent et suivant du navigateur. Et l'astuce utilisée pour cela est, en même temps que de faire la requête ajax, de simuler un clic vers une ancre inexistante dans la page. L'URL change, et pourtant la page n'est pas rafraichie.
Donc pour compléter cet article, il faudrait expliquer en quoi consiste cette astuce du #, qui est une utilisation très particulière de l'ajax.
Il serait donc bcp + juste de préciser qu'il ne s'agit que des cas d'utilisation d'AJAX où l'état figure dans l'URL ("Stateful AJAX pages")
Moi, je n'avais vu cette utilisation du # que sur les sites en flash qui veulent permettre l'utilisation du bouton retour, du signet profond, etc. Et la proposition de google pourrait s'adapter à ces cas de figures. C'est vrai que pour les sites en ajax, je n'avais pas encore vu, même si dans le même but d'accessibilité, on peut utiliser ce système d'ancre (et donc permettre à google de référencer des pages distinctes).
Merci Matthieu et Hubert pour vos commentaires !
Un très bel exemple de fonctionnalités ajax ancres permettant le bookmarking:
http://www.google.com/corporate/timeline/
Je pense que les web-développeurs bien informés ont déjà les armes pour permettre l'indexation de leur page utilisant Ajax/javascript.
1/ penser accessibilité (Google est notre premier utilisateur déficient)
2/ penser dégradation élégante
3/ balise noscript
4/ sitemap.xml généré dynamiquement
Bien-sûr google n'a pas besoin de tout indexer (ex: liste personalisée par l'utilisateur type panier).
le gestionnaire d'évènement de javascript permet de très bien s'en tirer surtout lorsqu'on utilise un framework bien écrit comme jQuery ou Prototype. C'est assez simple.
Un cas typique et simple à comprendre c'est celui des "modal window" qui affichent des photos (voir par exemple lightwindow). Les liens pointent bien sur les photos (elles sont donc indexables) mais le gestionnaire d'événement intercepte le click, récupère l'url de l'image et l'affiche dans une "modal-window".
Même principe pour rafraîchir le contenu de la page sans recharger le header, les menus, le footer etc... Si on a un template unique appelé par un script unique (index.php params passés via l'url, y compris en url-rewriting) et que seul change le contenu de par exemple div="content" où est affiché un script content.php auquel on re-passe les paramètres nécessaires, on procède de la même façon. Les liens pointent sur index.php?params, javascript intercepte les params et ajax rafraichi div="content" en appelant content.php?params. C'est accessible, c'est dégradé élégament. lol
Le seul problème qui demeure c'est le bookmarking des pages via la barre de navigation, via un bouton de bookmarking (type addthis) ça reste facile à bidouiller. Ce problème est plus le problème des développeurs de navigateurs que de google/webdeveloppeur qui devraient proposer une méthode pour ce réel problème. Apres ce que vient de proposer Google je ne comprend pas vraiment si il résout ce problème spécifique.
1. tout à fait d'accord avec Oscar-Paradi'SEO! il est encore trop tôt pour faire des portails intégralement orienté ajax.
2. ensuite, je vois pas le rapport entre vos token et ajax.
ajax, ce n'est rien de plus que faire un appel de fonction particulier dans le client web en fournissant une requête (adresse web) et en lui précisant le nom d'une méthode qui devra être appelée quand le client web aura traité la requête. quand la méthode est rappellée (callback), elle reçoit (en général) en param notamment du nouveau contenu que le dev va pouvoir utiliser pour raffrachir un autre contenu déjà chargé. Ajax, ce n'est rien de plus que ça. Après, vous trouverez toutes les incroyables innovations qu'on a pu faire en parant de cette pratique.
J'imagine que votre histoire de token est une proposition de google à mettre dans tout href pour les aider à matcher les liens "asynchrones" et pouvoir identifer une page qui correspond au contenu global.
Je me permet de citer le debut de l'article="Le problème avec AJAX, c'est que ce qui suit le signe # ne correspond pas à une ancre nommée mais à des paramètres qui définissent l'état (state)".
Cà c'est une assertion qu'elle est belle.
Heuu, soit j'ai loupé un épisode, soi on est en train de faire un généralité d'un cas spécifique qui est une convention de développement propre à un framework ou à un logiciel donné.
Si j'ai tort, je serais ravi d'être éclairé sur ce sujet, moi qui croyais faire de l'ajax depuis quelques années.
@Lo.J : avant cette "assertion" il y a une remarque, que je recopie ici : "je ne suis pas un développeur AJAX, merci donc de me signaler toute erreur ou approximation que vous pourriez relever dans cet article"
Je suis donc tout à fait ouvert à modifier l'article pour qu'il n'y ait pas d'erreur !
On va prendre les choses dans l'autre sens : dans quels cas trouve-t-on des paramètres passés derrière le # dans l'URL ? Sur un site utilisant AJAX, ne peut-on pas trouver ce genre d'URL ?
J'ai posé d'autres questions aux développeurs AJAX dans le forum, ce serait très sympathique d'y répondre (là-bas ou ici) : https://www.webrankinfo.com/forum/t/du-neuf-pour-le-referencement-de-pages-ajax.117525/#p1101881
Merci pour les infos, il me semble quand même qu'il est toujours très délicat de chercher à indexer des sites en flash ou en AJAX, même si des solutions existent.
Il suffit de penser en ajax dégradable tout simplement ... Kajax est un exemple de CMS full Ajax optimisé pour le référecement ;)
Pas hyper simple à gérer en pratique ! Me semble plus judicieux de limiter l'utilisation d'Ajax et la rapidité conférée par une requete asynchrone sans rechargement de la page, pour les parties du site et les pages avec traitement bdd ou back end lourd ... et qui n'ont pas forcément besoin d'être indexées (ex panier e-boutique). Les couches ajoutées de JS ou Ajax à des pages standard ne posent pas vraiment de pb, mais comme pour le flash vouloir développer un site full Ajax (certains développements n'ont de fait que très peu, voire même une seule URL !!) est-elle une bonne pratique ?
Ceci étant dit l'utilisation à bon escient de ces techniques plus modernes donnent certainement du dynamisme à un site, améliorant grandement "l'expérience utilisateur". Normal donc que Google recherche des solutions.
"Pourquoi Google demande aux serveurs de se charger de cette tâche alors que ses robots pourraient très bien interpréter eux-mêmes le code JavaScript ? Tout simplement parce que ça coûterait cher à Google en ressources machine ! Pourtant, la solution proposée par Google sera coûteuse pour les gestionnaires de sites qui devront supporter les coûts de développement et de maintenance de ces headless browsers…"
Google ne peut pas inventer les adresses des pages qu'il indexe. Sur l'ancienne version de deezer.com, quasiment toute les pages avaient la même adresse ou l'url par laquelle on accédait au site) on pouvait aussi accéder directement à un chanson via un permalink présent dans la page. Mais je ne crois pas que c'est viable pour un moteur de recherche de rechercher dans la page, l'adresse à indexer^^. Pour moi, ce n'est pas le rôle du moteur de recherche d'organiser les contenus mais celui du gestionnaire du site.
Je n'ai pas compris la remarque... désolé !
Dans les pages il y a des liens vers des URL du style
!etat. Google cherche à indexer le contenu de cette page, et il demande que la partie JavaScript soit prise en charge par le serveur alors qu'il pourrait le faire aussi.