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

Sébastien Billard · 8 Octobre 2009

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 · 8 Octobre 2009

+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

Sébastien Billard · 8 Octobre 2009

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 · 8 Octobre 2009

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 · 8 Octobre 2009

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 · 9 Octobre 2009

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 · 9 Octobre 2009

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:

<?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:

<?php echo $content_for_layout; ?>

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

Code:

<!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 · 10 Octobre 2009

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 :wink:

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 :mrgreen: ), 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 :mrgreen: (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 · 10 Octobre 2009

Un très vieux post : https://www.webrankinfo.com/forum/t/moteur-2-0.46667/
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 · 12 Octobre 2009

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 · 19 Octobre 2009

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 · 19 Octobre 2009

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 · 19 Octobre 2009

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)

tonguide · 10 Octobre 2010

Comme à priori, tu n'as peut-être pas trouvé la/les réponses que tu cherchais, je vais essayer de t'éclairer un petit peu.

Déjà pourquoi le signe # pour ajax/flash.
Pour la simple est bonne raison que c'est la seul solution qui permet 2 choses :
1 - ne pas recharger la page tout en changeant l'url dans la barre de tache
2 - avoir une URL unique permettant d'avoir une page en favoris (qui donne bien le résultat après exécution AJAX) mais SURTOUT de gérer le côté précédent/suivant du navigateur. Tout le monde a probablement déjà du rencontrer ce soucis d'avoir parcouru de nombreuses pages, et de faire "précédent" et de se retrouver 15 pages en arrières car le développeur ne l'a pas prévu en Ajax.

En bref, ça permet déjà de résoudre ces 2 soucis non négligeable pour le but principal des sites full Ajax, améliorer l'expérience utilisateur.

Et évidemment, si on utilise pas cette méthode, on change l'url par un autre moyen, et à ce moment là inutile d'avoir de l'Ajax pour changer le contenu de la page, et autant dire que la musique/vidéo est coupé (d'où le fait que Deezer utilise ce signe ou encore M6 replay). Et si on ne change pas l'url, le précédent/suivant affiche la dernière page statique et non le dernier lien ajax sur lequel on aurait cliqué.

Maintenant sur le contenu après le dièse, à la sauce deezer (et à priori m6 replay aussi), c'est un simple paramètre qu'il faut traiter ensuite (comme vous le voulez). Pour les 2 exemples, il s'agit de l'url classique (c'est à dire que si vous retirez le # vous arrivez sur la même page que si vous le mettez).

On retrouve d'ailleurs le code suivant sur Deezer

Code:

if (location.hash != '') {
	var loc = location.hash.substr(1, location.hash.length - 1);
	var tab = loc.split('?');

	if (tab.length == 2) document.location.href = 'http://' + SETTING_HOST + '/' + SETTING_LANG + '/' + tab[0] + '?' + hex2bin(tab[1]);
	else document.location.href = 'http://' + SETTING_HOST + '/' + SETTING_LANG + '/' + loc;
}

Où, en gros, il remplace automatiquement le # par la même url sans le dièse (ceci se produisant si on tape directement l'url et non si on fait suivant/précédent ou lorsque l'on clique sur un lien sur le site).

location.hash permettant de récupérer "#ancre_qui_suit" (loc = "ancre_qui_suit" sans le dièse)

Vous pouvez d'ailleurs essayer avec deezer, vous allez sur une url en cliquant sur plusieurs liens dans le site deezer (je ne sais pas si il faut écouter de la musique ou si c'est le comportement par défaut), vous verrez que les liens sont tous avec un dièse, vous supprimez ce dièse sans rien changer (et tout ce qu'on trouve avant jusqu'à /fr/ si vous n'êtes pas parti de l'accueil), et vous aurez un lien statique de la page en question auquel il vous rajoutera immédiatement un nouveau dièse avec le même contenu que la page où vous vous trouverez. Les prochains cliques, seul ce qui suit le dièse va alors changer.

En bref, c'est à vous de savoir ce que vous voulez en faire de ce paramètre

Donc pour finir, mon analyse sur l'ajax (à référencer) et le référencement est que :
1 - Sans ajax vos URL doivent être "classique" monsite.com/machin
2 - Avec ajax vos URL ont peu d'importance : monsite.com/#!cequevousvoulez (affiche le même contenu que 1)
3 - vous rendez accessible monsite.com/?_escaped_fragment_=cequevousvoulez (affiche le même contenu que 1 et 2)
4 - la page 3 étant la copie de 1, on utilise rel="canonical" pour référencer la page 1 et non la page 2

De cette manière, GG connait l'url 1 en le parcourant avec son bot classique, et si un de vos visiteurs placent un lien vers une de vos pages ajax, GG a le bon contenu et vous pouvez lui signaler qu'une page statique (sans #! + ajax) est disponible et comporte le même contenu qu'il est donc préférable qu'ils placent dans les résultats de recherche. Et bien entendu, pour le visiteur lambda, il aura une URL unique pour un contenu ajax.

Vous aurez compris qu'il est nécessaire de traiter ce qui arrive du hash (changement du hash = une action JS qui change le contenu de la page via Ajax) ce qui est d'ailleurs un avantage de mettre un signe après le # puisqu'il vous permet de ne traiter que les hash nécessaire (dans le cas présent, qui ont un "!" en premier caractère) afin que les autres hash classique (#top) ne soit pas analysé par le JS.

Voilà, j'espère avoir été complet et surtout compréhensible (évidemment, sur le côté référencement, c'est mon avis perso, il faudrait faire des tests pour voir si il n'y a pas mieux à faire).