Questions fréquentes à propos d'AJAX

Cette rubrique répond aux questions les plus fréquentes concernant l'exploration AJAX.
Quand utiliser _escaped_fragment_ et #! dans les URL AJAX ?

Votre site doit utiliser la syntaxe #! dans toutes les URL conformes au processus d'exploration AJAX. Googlebot ne suit pas les liens hypertexte au format _escaped_fragment_.

Où puis-je voir ce processus en action ?

Vous pouvez voir des exemples d'applications AJAX à l'adresse http://gwt.google.com/samples/Showcase/Showcase.html. Lorsque vous cliquez sur un lien dans la partie gauche de la page, vous constatez que l'URL contient un fragment de hachage #! et que l'application accède à l'état correspondant à ce fragment. Si vous remplacez #! (par exemple, http://gwt.google.com/samples/Showcase/Showcase.html#!CwRadioButton) par ?_escaped_fragment_= (par exemple, http://gwt.google.com/samples/Showcase/Showcase.html?_escaped_fragment_=CwRadioButton), le site affiche un instantané HTML.

Que se passe-t-il si je décide de ne pas utiliser #! sur mon site AJAX ?

Il est possible que vos pages ne s'affichent pas correctement dans les résultats de recherche Google. Sachez cependant que nous travaillons sans cesse pour que le comportement de Googlebot se rapproche plus de celui d'un navigateur. Au fur et à mesure de la mise en œuvre des fonctionnalités requises par votre site, Googlebot va pouvoir commencer à indexer les pages correctement sans intervention particulière. Cependant, le processus d'exploration AJAX offre une solution pour les sites qui utilisent déjà AJAX et dont vous souhaitez que le contenu soit correctement indexé immédiatement. Il s'agit d'une solution adaptée pour les sites dont les pages contiennent déjà des instantanés HTML, ou pour les webmasters qui utilisent un navigateur sans interface pour créer les instantanés HTML.

Quel niveau d'actualisation mon contenu doit-il avoir ?

La réponse dépend de la fréquence de modification du contenu de vos applications. S'il change fréquemment, vous devez toujours construire un instantané HTML actualisé en réponse à une demande d'exploration. Pensez également à une bibliothèque archivée dont le répertoire ne change pas régulièrement. Pour éviter que le serveur n'ait à créer sans cesse les mêmes instantanés HTML, vous pouvez générer l'ensemble des instantanés HTML utiles une seule fois, éventuellement hors connexion, puis les enregistrer pour les réutiliser plus tard. Vous pouvez également répondre à Googlebot par un code d'état HTTP 304 (Non modifié).

Que se passe-t-il si mon application n'utilise pas de fragments de hachage ?

Peut-être devrait-elle en utiliser ! Les fragments de hachage accélèrent considérablement les applications, car ils sont gérés par le navigateur côté client, et n'entraînent pas l'actualisation de l'ensemble de la page. De plus, les fragments de hachage permettent de faire fonctionner l'historique, avec le bouton "Retour" du navigateur. Divers cadres AJAX sont compatibles avec les fragments de hachage. Consultez par exemple Really Simple History, le plug-in d'historique jQuery, le mécanisme d'historique du Google Web Toolkit et la gestion de l'historique par ASP.NET AJAX.

Si vous ne pouvez pas structurer votre application de manière à utiliser des fragments de hachage, placez un jeton spécial dans ces derniers (à savoir tout ce qui se trouve après le symbole # dans une URL). Les fragments de hachage correspondant à des états de page uniques doivent commencer par un point d'exclamation. Par exemple, si votre application AJAX contient une URL de type :

www.example.com/ajax.html#mon_état

cette URL doit prendre le format suivant :

www.example.com/ajax.html#!mon_état

Les sites qui adhèrent au processus font partie des "sites AJAX explorables". Autrement dit, le robot d'exploration voit le contenu de votre application lorsque votre site génère des instantanés HTML.

Cette approche peut-elle entraîner une prolifération des URL brutes _escaped_fragment_ ?

La syntaxe _escaped_fragment_ pour les URL est une URL temporaire qui ne doit jamais être vue par l'utilisateur final. Quel que soit le contexte, l'internaute doit voir l'URL vitrine contenant #! et non_escaped_fragment_ : dans les interactions d'applications normales, dans les sitemaps, dans les hyperliens, dans les renvois et dans toute autre situation dans laquelle l'utilisateur peut voir l'URL. Pour la même raison, les résultats de recherche sont des URL présentables plutôt que des URL disgracieuses.

Ce processus peut-il favoriser les techniques de dissimulation (cloaking) ?

Le cloaking vise à diffuser auprès des internautes des contenus différents de ceux qui s'affichent dans les moteurs de recherche. Cette technique a généralement pour objectif d'optimiser le classement d'un site dans les résultats de recherche. Le cloaking a toujours été (et sera toujours) un grand problème pour les moteurs de recherche. Sachez cependant que le fait de rendre les applications AJAX explorables ne constitue en aucun cas une incitation au cloaking. C'est pourquoi les instantanés HTML doivent avoir le même contenu que celui présenté à l'internaute dans le navigateur. Dans le cas contraire, la pratique peut être considérée comme du cloaking. Consultez cette réponse pour en savoir plus.

Puis-je utiliser ce processus pour faciliter l'exploration de mon contenu Flash ou d'autres fichiers rich media ?

Nous indexons de nombreux types de fichiers rich media et nous nous efforçons en permanence d'améliorer le système d'exploration et d'indexation. Toutefois, il est possible que Googlebot ne voie pas tout le contenu d'un élément Flash ou d'autres applications rich media (de même qu'il ne peut pas explorer tout le contenu dynamique sur votre site). Par conséquent, il peut être intéressant d'utiliser ce processus pour fournir un contenu supplémentaire à Googlebot. Encore une fois, les instantanés HTML doivent avoir le même contenu que celui présenté à l'internaute dans le navigateur. Nous nous réservons le droit d'exclure des sites de notre index s'ils utilisent des techniques de dissimulation.

Que se passe-t-il si mon site affiche des URL à fragments de hachage qui ne doivent pas être explorées ?

Si votre site adhère au processus d'exploration AJAX, notre robot d'exploration explore chaque URL à fragments de hachage qu'il trouve sur son passage. Si votre site contient des URL à fragments de hachage à ne pas explorer, nous vous conseillons d'ajouter une instruction à expression régulière dans votre fichier robots.txt. Par exemple, vous pouvez utiliser une convention dans les fragments de hachage à ne pas explorer, puis exclure toutes les URL correspondantes dans le fichier robots.txt. Supposons que tous vos états non indexables se présentent au format #DONOTCRAWLmyfragment. Pour empêcher Googlebot d'explorer ces pages, ajoutez l'élément suivant dans votre fichier robots.txt :

Disallow: /*_escaped_fragment_=DONOTCRAWL
Qu'en est-il des utilisations existantes de #!dans les fragments de hachage ?

#! n'est pas un jeton fréquemment utilisé dans les fragments de hachage. Cependant, il n'est pas interdit par la spécification URL. Que faire si mon application utilise #! et que je ne souhaite pas adhérer au nouveau processus d'exploration AJAX ? Vous pouvez ajouter une instruction dans votre fichier robots.txt afin d'en informer le robot d'exploration.

Disallow: /*_escaped_fragment_

Veuillez noter que cela signifie que si votre application contient seulement cette URL, www.example.com/index.html#!mystate, alors cette URL ne sera pas explorée. Si l'application contient également l'URL www.example.com/ajax.html, cette URL sera explorée.

Qu'en est-il de l'accessibilité ?

La pratique actuelle, qui consiste à fournir du contenu statique aux moteurs de recherche, incite les webmasters à rendre leurs applications davantage accessibles aux internautes handicapés. L'accessibilité a fortement évolué : sans intervention manuelle, les webmasters peuvent, à partir d'un navigateur sans interface, créer des instantanés HTML englobant l'intégralité du contenu pertinent et pouvant être exploités par les lecteurs d'écran. Il est donc aujourd'hui plus simple de maintenir le contenu statique à jour, car moins d'interventions manuelles sont nécessaires. En d'autres termes, les webmasters disposent désormais d'un plus grand facteur de stimulation pour rendre leurs applications accessibles aux personnes handicapées.

Comment dois-je utiliser rel="canonical" ?

Utilisez <link rel="canonical" href="http://example.com/ajax.html#!foo=123" /> et pas <link rel="canonical" href="http://example.com/ajax.html?_escaped_fragment_=foo=123" />.

Quelle URL dois-je intégrer dans mon sitemap ?

Le sitemap doit contenir la version que vous souhaitez voir figurer dans les résultats de recherche : http://example.com/ajax.html#!foo=123.

Quel est l'impact des URL #!sur les flux de produits ?

Généralement, les webmasters souhaitent avoir la même URL pour Google Recherche de Produits et pour la Recherche sur le Web Google. En général, la version de l'URL avec #! doit être considérée comme la version "canonique" à utiliser quel que soit le contexte. L'URL _escaped_fragment_ est considérée comme une URL provisoire que les utilisateurs finaux ne doivent jamais voir.

J'utilise le navigateur sans interface HtmlUnit, mais il ne fonctionne pas. Pourquoi ?

Si la question sous-entend que HtmlUnit n'affiche pas l'instantané que vous attendiez, vous n'avez sans doute pas accordé assez de temps à l'exécution des requêtes JavaScript ou XHR. Pour y remédier, essayez l'une des solutions suivantes :

  • Utilisez NicelyResynchronizingAJAXController pour demander à HtmlUnit d'attendre les appels XHR en suspens.
  • Augmentez le délai d'attente de waitForBackgroundJavaScript ou de waitForBackgroundJavaScriptStartingBefore.
Ces opérations permettront très probablement de résoudre le problème. Dans le cas contraire, vous pouvez également consulter les questions fréquentes sur HtmlUnit ici : http://htmlunit.sourceforge.net/faq.html. HtmlUnit dispose également d'un forum d'aide.

 

Ces informations vous-ont elles été utiles ?
Comment pouvons-nous l'améliorer ?