Du neuf pour le référencement de pages AJAX ?

[French Dread]

Je n'ai pas vu de topic sur l'annonce qu'a fait Google au SMX alors je l'ouvre Donc Google a proposé une méthode pour permettre d'indexer les sites en AJAX. La méthode est décrite sur le blog Google : http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making ... lable.html

Pour les anglophobes, j'en ai fait une description sommaire en français sur mon blog ( http://s.billard.free.fr/referencement/?2009/10/08/571-google-propose- ... sites-ajax ) que je reproduis ici :

Voici le principe de la méthode :

- Insertion d'un token pour distinguer les pages AJAX des simples URLs à ancres internes (les ancres internes étant ignorées par les moteurs). Google propose le point d'exclamation. l'URL http://example.com/stocks.html#GOOG deviendrait donc http://example.com/stocks.html#!GOOG

- Utilisation d'un navigateur coté serveur qui va produire un instantané HTML de la page AJAX. C'est cet instantané HTML qui sera indexé par les moteurs.

- Utilisation d'un schema d'URL spécifique pour accéder à l'instantané. Google propose d'échapper l'état et de l'inclure dans l'URL via le token "_escaped_fragment_". Google accédera donc à l'instantané via l'URL http://example.com/stocks.html?_escaped_fragment_=GOOG. Par contre, c'est l'URL originelle http://example.com/stocks.html#!GOOG qui sera affichée aux utilisateurs dans les pages de résultats.

[spout]

+1 reco

Mais je trouve pas ça cool de devoir développer exprès pour Google.
Autant faire un site qui fonctionne sans javascript (pour les robots) et si le client a JS activé, une version en JS/AJAX.

CakePHP avec le component RequestHandler permet de faire ça très simplement

[French Dread]

Je trouve la solution de Google plutôt intéressante. Car de toute façon ce n'est pas demain la veille que les moteurs interpreteront javascript (je parle bien d'interpréter au sens informatique et non d'extraire un bout d'information d'un morceau de javascript). Après je me pose la question du spam possible (vu que l'instantané est fait coté serveur on peut imaginer quelques manipulation).

Je déconseille de toute façon de faire un site en AJAX. AJAX amha c'est très bien pour de l'application, mais pas pour de l'information. En plus ça reste inaccessible en général.

[WebRankInfo]

Merci Sébastien, j'ai pas eu le temps de poster d'article sur WRI, il est en cours de rédaction

Comme toi je trouve ça globalement bien et je me demande à quels mécanismes les ingénieurs de Google ont pensé pour limiter les abus. Peut-être les mêmes méthodes que pour la détection du cloaking.

[WebRankInfo]

J'ai quelques questions aux développeurs :

- concrètement, qu'est-ce qu'on appelle un état ? est-ce simplement une façon de décrire un système, à l'aide de paramètres ? d'après ce qu'écrit Google, j'ai l'impression qu'une page en AJAX correspondant à un état a la caractéristique d'afficher toujours la même chose quand on y accède (donc en gros le contenu affiché ne dépend pas des actions passées de l'internaute)

- les URL avec un état représentent-elle un gros pourcentage des URL générées par les sites en AJAX ?

- est-ce qu'on peut dire que Flex présente exactement les mêmes problèmes qu'AJAX ? peut-on faire le parallèle entre javascript et actionscript ? avec un site en Flex, a-t-on le même genre d'URL qu'en AJAX, avec ce fameux signe # ? et donc la solution de Google conviendrait également pour Flex ?

pour une fois c'est moi qui pose plein de questions, alors merci à ceux qui accepteront d'y répondre !!!

[WebRankInfo]

j'espère que certains pourront répondre à mes précédentes questions !

en attendant, j'ai pu finir la rédaction de mon article sur le référencement de pages AJAX

[spout]

Article très intéressant mais je m'obstine à penser que la solution style CakePHP est mieux.

CakePHP fourni un component RequestHandler qui détecte comment est appelée la page.
En ajoutant le RequestHandler dans le controller:

Code: Tout sélectionner

<?php
class WidgetController extends AppController {
   
   var $components = array('RequestHandler');
   
   //rest of controller
}
?>


Cake va détecter que la page est appelée via AJAX et lui appliquer un layout (template) vide (ajax.ctp):

Code: Tout sélectionner

<?php echo $content_for_layout; ?>


Au lieu du layout html du site (default.ctp) (simplifié volontairement):

Code: Tout sélectionner

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
   <?php echo $html->charset(); ?>
   <title>
      <?php echo $title_for_layout; ?>
   </title>
   <?php
      echo $html->meta('icon');

      echo $html->css('cake.generic');

      echo $scripts_for_layout;
   ?>
</head>
<body>
   <div id="container">
      <div id="header">
         <h1><?php echo $title_for_layout; ?></h1>
      </div>
      <div id="content">
         <?php $session->flash(); ?>
         <?php echo $content_for_layout; ?>
      </div>
   </div>
</body>
</html>


Donc on peut facilement faire une "modal box", de la pagination, etc... qui ne recharge uniquement le contenu de $content_for_layout.
Tout ça sans programmer exprès pour Google qui fait des requêtes HTTP non-ajax et accessible aux navigateurs sans JS activé.

Cette solution est tout à fait faisable avec d'autres systèmes de template où l'on défini un layout.
(Par ex. le système de template de Brian Lozier: http://www.massassi.com/php/articles/template_engines/ )

[fandecine]

Olivier, on peut faire une analogie entre les parametres passés en GET dans l'url pour un langage de script coté serveur avec les parametres passés aprés le # pour javascript coté client.

En effet, javascript permet de récupérer ce qui est passé dans l'url après le # et donc d'adopter un comportement en fonction de ce paramètre.

$_SERVER['REQUEST_URI'] en php retourne l'url de la page avant le #

document.location.href en javascript retourne l'url completede la page, y compris après le #

Je n'aime pas beaucoup le terme AJAx derriere lequel on met un peu de tout et n'importe quoi, mais pour donner un exemple, imagine une page de blog avec:
la section 1 contenant la news,
la section 2 contenant les commentaire,
la section 3 contenant le formulaire de dépot de commentaire.

Avec du javascript et/ou du css tu masque les section 2 et 3 à l'internaute. (elles restent visble pour les moteurs de recherche)

Tu rajoute 2 liens en javascript (invisible pour les moteurs) avec comme url de destination mapage.html#section1, mapage.html#section2

Tu interprete l'url avec document.location.href et si tu detecte une valeur après le # tu affiche a l'aide de javascript la section correspondante soit betement en modifiant le css, soit à l'aide de routine du type jquery.

Cela permet d'améliorer le confort de l'internaute en affichant du contenu à la demande sans alourdir la page et sa lisibilité.

Mais tu peux bien sur charger du contenu de façon asynchrone

Pour ce qui est de la proposition de Google je suis d'accord avec toi lorsque tu dis que google déporte la charge de développement vers les webmasters (masi ils sont libre de le faire ou pas, à eux de voir ), je suis également d'accord lorsque tu dis que c'est une avancée en matière de référencement.

Par contre, pour ce qui concerne tes crainte en matière de cloaking, cela ne changera rien. Il ne sera pas plus facile ou plus dur de faire du cloaking et ce ne sera pas plus facile ou plus dur pour google de le détecter car seule une vision humaine (tant que google n'interprétera pas le javascript) sera en mesure de le faire.

Maintenant, je te propose un sujet de réflexion : Google affirme que son robot n'interpréte pas le javascript, oui, il ne le fait pas systématiquement (pour les raisons que tu invoques). Mais qui dit qu'il ne le fait pas ponctuellement ? par exemple lorsqu'il y a un doute de cloaking (moi, c'est ce que je ferais en tout cas à la place de google) C'est surement moins couteux et plus rapide que de le faire faire par un humain non !? (ce qui n'empèche pas les vérifications humaines soit dit en passant)

[blman]

Un très vieux post : http://forum.webrankinfo.com/moteur-t46667.html
Je pense toujours la même chose La technique proposée par Google, c'est un peu du bricolage à mon sens, en tout cas, je ne conseillerais jamais ces pratiques à un développeur. Le maitre mot reste l'accessibilité au contenu.

[nervusdm]

Moi ce qui me fait peur avec les pages AJAX, c'est justement.. lé référencement.

Imaginons, on a une page qui parle de Toto à la piscine. ( Ô combien important que ceci ).

Cela fait un truc du genre -http://www.toto.fr#!piscine.
Les personnes, s'ils aiment cette histoire, vont mettre un lien dans les forums & autres de ce genre.
Mais que Google va croire ?

Va til créditer la page principale, d'accueil, ( donc toto.fr ), ou va t'il savoir qu'il faut créditer la page piscine ?

Je parle bien de "créditer" ( donc donner de la valeur ), pas de mettre dans Google. Pour Intégrer une page ajax, on va simplement mettre des liens à suivre pour ceux n'ayant pas javascript, et le onclick viendra s'occuper de l'ajax.

Truc dans le genre : <a href='oui.html' onclick='ajax(this.href); return false'>Oui</a>

PS : Notez que je parle de Google avec "Il", comme s'il s'agissait d'un humain, mais vous m'aurez compris je pense

[WebRankInfo]

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 ?

[spout]

On peut générer des URLs de ce type avec ce plugin jQuery:
http://www.asual.com/jquery/address/

Ou en Flash/Flex/Ajax avec:
http://www.asual.com/swfaddress/

[WebRankInfo]

je me suis mal exprimé sans doute
dans la 1ère version de mon article sur le référencement d'un site en AJAX, j'avais titré "le pb de l'AJAX c'est les URL générées qui contiennent #"
on m'avait expliqué que ce n'était pas du tout le cas de tous les sites en AJAX
ce WE en regardant M6 Replay j'ai trouvé cet exemple et j'aimerais savoir dans quels cas on se retrouve avec un site qui a des URL de ce genre, et qui pose donc de gros problèmes de référencement (cet exemple est le vide intersidéral d'un point de vue référencement d'ailleurs)
question inverse : m6replay.fr aurait-il pu avoir des URL + SEO friendly ? je suppose que la solution classique aurait été de créer plein de pages HTML affichant le Flash "au bon endroit" (c'est ce que j'ai fait pour quelques clients)