Référencer un site en AJAX

Olivier Duffez, Vendredi 9 octobre 2009

Le référencement d'un site en AJAX est en général aussi compliqué (voire plus) que celui d'un site en Flash… Bref, si AJAX sert à accéder au contenu du site, il vaut mieux éviter ces technologies si on veut qu'il soit vraiment bien référencé (ou alors tout est plus compliqué). Google vient de faire une proposition de solution technique permettant l'indexation de sites en AJAX. Nous verrons si d'autres moteurs suivent Google dans cette voie et si les développeurs apprécient l'idée de Google. Voici quelques premières explications…

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 : http://www.example.com/page-ajax#!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 http://www.example.com/page-ajax#!etat et 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 donne http://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

Quelle URL sera finalement indexée ?

Au final :

Les pages du site font des liens vers des URL du genre http://www.example.com/page-ajax#!etat
Les internautes consultent les URL comme http://www.example.com/page-ajax#!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…).

Vous pouvez également en discuter sur le forum officiel de Google pour les webmasters ou consulter les slides de Katharina Probs, qui a indiqué être en train de développer un prototype AJAX pour cela. J'ai aussi été interviewé à ce sujet par le magazine 01 Net Pro.

Formation référencement et webmarketing

Vous souhaitez sans doute améliorer votre référencement, avez-vous pensé à suivre une formation spécialisée sur le référencement naturel ? En 2008, plus de 700 entreprises ont assisté à nos différentes sessions, la plupart faisant financer ces journées par la formation professionnelle (OPCA). Orange Labs nous a décerné un taux de satisfaction des participants de 90% (octobre 2008).

Préparés et animés par Olivier Duffez (WebRankInfo) et Fabien Faceries (AgentWebRanking), 2 professionnels reconnus dans la profession, nos modules sur le référencement naturel sont très complets tout en laissant une grande place à l'interactivité pour répondre à toutes les questions des participants.

Pour connaître le plan détaillé de chaque module, le prix, les dates et les lieux, cliquez ici pour consulter le site de Ranking Metrics (organisme de formation agréé).

Lectures recommandées sur ce thème :

Consultez la description détaillée des produits ou services de Google suivants : Google Web Toolkit, Google API, OpenSocial, Google Browser Sync, Google Co-Op

27 commentaires sur “Référencement de l’AJAX : la solution Google”

tet dit :

10 octobre 2009 à 1:37

« 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 (http://www.deezer.com/ 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.
Olivier Duffez dit :

10 octobre 2009 à 6:17

Je n’ai pas compris la remarque… désolé !
Dans les pages il y a des liens vers des URL du style http://www.example.com/page-ajax#!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.
Oscar-Paradi'SEO dit :

10 octobre 2009 à 11:16

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.
Kolibot dit :

10 octobre 2009 à 15:26

Il suffit de penser en ajax dégradable tout simplement … Kajax est un exemple de CMS full Ajax optimisé pour le référecement ;)
Aden dit :

12 octobre 2009 à 10:23

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.
Lo.J dit :

13 octobre 2009 à 7:36

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.
Blaise dit :

13 octobre 2009 à 7:45

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.
Olivier Duffez dit :

13 octobre 2009 à 8:07

@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) : http://forum.webrankinfo.com/neuf-pour-referencement-pages-ajax-t117525.html#p1101881
Hubert Souchaud dit :

13 octobre 2009 à 12:58

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.
Matthieu Brunet dit :

13 octobre 2009 à 14:02

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).
Olivier Duffez dit :

13 octobre 2009 à 14:23

Merci Matthieu et Hubert pour vos commentaires !
Hubert Souchaud dit :

13 octobre 2009 à 14:38

Un très bel exemple de fonctionnalités ajax ancres permettant le bookmarking:
http://www.google.com/corporate/timeline/
PtitLu dit :

15 octobre 2009 à 19:05

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.
Olivier Duffez dit :

15 octobre 2009 à 21:22

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 »)
Hubert Souchaud dit :

15 octobre 2009 à 22:11

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!
Olivier Duffez dit :

19 octobre 2009 à 9:12

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 : http://www.m6replay.fr/#/series-fictions/prison-break/2810

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 ?
Hubert Souchaud dit :

19 octobre 2009 à 12:07

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:
http://domaine.com/tag/seo avec un Drupal par ex, c’est en réalité appeler http://domaine.com/index.php?q=tag/seo et le script php va comprendre $param1=tag et $param2=seo
avec un # devant (http://domaine.com/#tag/seo) 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&param2=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)
bruno dit :

29 octobre 2009 à 14:38

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 .
Olivier Duffez dit :

30 octobre 2009 à 9:46

@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)
bruno dit :

30 octobre 2009 à 10:10

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 : http://hydro.blogiwi.com/index-p-2.html

Bruno
bruno dit :

30 octobre 2009 à 10:13

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 .
Olivier Duffez dit :

30 octobre 2009 à 12:19

Bruno : on peut tout à fait concilier les 2 (un site bien référencé et agréable à naviguer)
bruno dit :

30 octobre 2009 à 12:33

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 ) :)|
Hubert Souchaud dit :

30 octobre 2009 à 14:41

@ 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.
bruno dit :

30 octobre 2009 à 17:53

no comment , je n’aime pas votre ton .
Hubert dit :

9 novembre 2009 à 19:10

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é!
bruno dit :

11 novembre 2009 à 19:35

Moi aussi Hubert .

Laisser une réponse

Hébergement web

Pour un bon référencement, il faut un bon hébergeur. Testez Sivit, l'hébergeur choisi par Olivier Duffez pour son site WebRankInfo (+ de 3 millions de visites/mois). Vous bénéficiez d'une garantie 30 jours satisfait ou remboursé.

A partir de 1,90 EUR HT/mois.

A la une sur WebRankInfo

Formation au référencement

Découvrez le programme de formation au référencement le plus complet : méthodologie d'optimisation du référencement Google, sites dynamiques, stratégies de liens, blogs, formation juridique Internet, Google Analytics, taux de transformation, ROI, etc.

Ce cycle de formation peut être pris en compte par votre budget formation... profitez-en !

Cette formation est assurée notamment par Olivier Duffez, créateur du site WebRankInfo et consultant indépendant en référencement.

Détails et inscription

WebRankInfo sur Twitter

Suivez-moi sur Twitter !

Logiciel de pro

Vous cherchez un bon logiciel pour effectuer le suivi du référencement ? Je vous conseille AgentWebRanking, le logiciel leader sur le marché, développé par une entreprise française et vendu dans le monde entier depuis 1998.
En tant que consultant en référencement, je l'utilise pour mes prestations de conseil en référencement professionnel.

Téléchargement

Derniers sites inscrits

Référencer son site