michael kors cheap bags michael kors out

AJAX

Le gain d’un site Web full Ajax est clair d’après moi, tout le monde y gagne :

Ces points se vérifient si vous vous rendez sur mon site qui est basé sur l’idée d’une application à page unique ().

Méfiance

L’AJAX (Asynchronous JavaScript And Xml)?est pour beaucoup de personnes synonyme de mauvais référencement dans les moteurs de recherche, et elles n’ont pas tout à fait tort au premier abord même si le sujet de ce billet est justement de présenter des solutions de contournement (SEO).

Voici donc les deux principaux arguments contre une utilisation massive d’AJAX pour les sites web Internet?“grand public” :

Contournement

Le premier point soulevé dans les arguments contre est aujourd’hui assez facilement contournable mais reste néanmoins obligatoire à mettre en place pour résoudre le deuxième point sur le référencement des pages.

J’utilise personnellement une bibliothèque JavaScript, nommée ,?qui me permet d’ajouter une ancre au niveau de l’url de l’application (#nom_ancre) et de mapper cette ancre vers une fonction JavaScript qui se chargera de lancer une requête AJAX vers le serveur. Cette bibliothèque me permet donc de changer l’état d’une page (ou de mon unique page) sans la recharger entièrement.

Chaque page possède désormais une url dédiée (.../#page1, .../#page2, etc.) qui rend l’historisation fonctionnelle au niveau du navigateur et permet le partage de liens vers un contenu spécifique.

A noter qu’il existe beaucoup d’autres solutions pour contourner ce premier point qui font qu’il n’en est plus vraiment un : jQuery propose , GWT propose en interne, Flex , Vaadin , etc.

Référencement

Le second point évoqué dans les arguments contre est beaucoup plus complexe à appréhender et la solution proposée ci-dessous est?plus délicate à mettre en place.?En effet le nerf de la guerre reste le positionnement de son site dans les de Google principalement, un site mal référencé dans les moteurs de recherche est un site invisible ce qui?entra?ne?donc peu de trafic, peu de backlinks,?peu de ventes,?peu de revenus publicitaires, etc.

Google a donc mis au point ?destiné aux webmasters et aux développeurs qui va permettre à son robot de correctement indexer les urls AJAX d’un site, il n’y a plus qu’à comprendre ce qui est demandé et à le mettre en place.

Après résolution du premier point, nos URL AJAX présentent toutes à présent une ancre (ou fragment de hachage), tel que?état, où?#mon_état?correspond à l’ancre. Cependant le fragment de hachage est une particularité du navigateur et ne fait pas partie du protocole HTTP ce qui fait que ce paramètre n’est pas envoyé au serveur Web (Apache, Nginx, Lighttpd, etc.).

Ce qui implique que lorsque le robot va requêter des urls avec un #, l’état souhaité de la page ne pourra lui être retourné correctement, il faut donc que le robot interroge notre application sans fragment de hachage. C’est ce que propose Google en suffixant nos “ancres dynamiques” à l’aide du point d’exclamation (pour différencier les vraies “ancres statiques” des nouvelles) et en incluant dans son algorithme un mécanisme de transformation des urls contenant un tel paramètre (#!), sur le?schéma?“Pretty URL to Ugly URL” :

impact sur notre application

état devient alors?!mon_état

impact chez Googlebot

!mon_état sera transformé en état

Cette fois-ci l’état de la page est envoyé au serveur Web, car le paramètre _escaped_fragment_ est un paramètre comme un autre autorisé dans le protocole HTTP. Il ne nous reste plus qu’à intercepter cette url dans notre application et de lui renvoyer le contenu de la page souhaitée (?a a l’air simple dit comme ?a ? ^^).

Puisque les robots d’indexation ne peuvent exécuter de code JavaScript, il faut le faire à leur place, sous-entendu qu’il faut que notre serveur délivre un “snapshot” (un?instantané HTML)?de la page demandée lorsque le robot va requêter notre site. Ce snapshot doit correspondre à l’ensemble du contenu qui appara?t sur la page après l’exécution du JavaScript.

Pour cela nous avons donc besoin d’une servlet pour intercepter les url contenant _escaped_fragment_ et d’un headless browser qui va simuler pour nous le comportement du navigateur pour récupérer le contenu des pages demandées, l’outil HtmlUnit a été choisi pour réaliser cette t?che.

Google a mis à disposition un?exemple?de Servlet utilisée dans une démo GWT, le code est . Voici cependant ma version qui inclut quelques nouveautés avec entre autre le moyen d’éviter que ces requêtes, appelées par les robots, ne soient prises en compte dans les statistiques de Google Analytics par exemple.

Pour tester que tout fonctionne correctement, il vous suffit de tester une “Ugly URL” pointant sur une de vos pages pour voir le résultat, par exemple : , ou sinon vous pouvez aussi le faire en vous connectant au site .

A noter

- Le robot n’indexe que le contenu des pages (le source HTML) et non la présentation, c’est pourquoi j’ai volontairement fait en sorte que les fichiers css ne soient pas téléchargés avec HtmlUnit.

- Pour vérifier que Googlebot a correctement indexé vos urls AJAX, il suffit de taper site:votre_nom_de_domaine dans le moteur de recherche pour voir le nombre de lien qu’il en ressort, par exemple : affiche 19400 résultats.

- Toutes les urls dans le code de votre application et celles de votre sitemap si vous en avez un, ne doivent contenir que les “Pretty URL” avec les #!, le paramètre _escaped_fragment_ ne doit jamais être présent.

- La bonne nouvelle est qu’il semblerait que ce mécanisme ait été repris par Bing dans une??de son Webmaster tools.

Liens utiles