Je vais vous présenter une technique que j'utilise depuis quelques temps sur plusieurs sites, pour rendre facilement indexable du contenu appelé en ajax, sous WordPress.
Cette méthode ne nécessite pas de déployer un "headless browser" comme dans l'article sur "Le référencement de l’Ajax avec un Headless Browser". De plus, elle est relativement simple à mettre en place.
Par contre, il faut que le site soit conçu de façon à ce que single.php ne soit pas utilisé dans le template, comme par exemple dans le tutoriel pour "Mettre en place une navigation Ajax dans WordPress".
Pour illustrer cet article, je vais prendre comme référence le site d'artplaTV (site hors ligne depuis), où tous les contenus du site sont chargés en ajax, sur la home.
Le référencement de l'Ajax et WP
Dans un thème WordPress en ajax normalement conçu, l'internaute n'a pas d'accès naturel aux pages d'article (générées via single.php). Les contenus en ajax sont chargés sur des pages de plus haut niveau telles que la home ou les pages de catégorie.
Par exemple ici, les pages de contenu et les articles s'affichent sur la home. Single.php n'est pas exploité pour la navigation de l'internaute.
Lorsque l'on veut que Google indexe un contenu en ajax, on le lui fait savoir en utilisant un hashbang (#!) dans l'URL. Le robot, pour accéder au contenu, va remplacer le hashbang dans l'URL par le "escaped_fragment".
Une url de la forme "http://www.artplatv.com/#!/vimeo/nuit-blanche" va devenir "http://www.artplatv.com/?_escaped_fragment_=/vimeo/nuit-blanche".
Le robot effectue ensuite une requête sur cette adresse. Ce paramètre est censé être intercepté, par exemple par un "headless browser" afin de servir au robot une capture HTML de la page.
Mais il est possible de se passer de ce système assez lourd. Nous allons demander à WordPress d'intercepter ce paramètre d'URL, qui annonce clairement qu'il s'agit d'un moteur de recherche, pour lui servir la page normale (single.php) de l'article.
Pour ce faire, il faut modifier une ligne de code dans une classe de WordPress. En cas de mise à jour, il faudra éventuellement réappliquer la modification.
Les modifications dans WordPress
Dans le fichier"wp-includes/class-wp.php", il faut modifier une ligne au début de la fonction parse(). Cette ligne est censée récupérer l'URL requise :
Remplacez là par :
Notre modification permet, si l'url demandée contient "?_escaped_fragment_=/", de le supprimer de l'URL
De cette manière, quand Google, Bing ou Yahoo voudront accéder au contenu de la page "http://www.artplatv.com/#!/vimeo/supakitch-koralie-euphorie", il accéderont en fait au contenu de la page "www.artplatv.com/vimeo/supakitch-koralie-euphorie" (merci de ne pas faire de lien direct vers cette page ^^).
Dans le thème, il faut donc concevoir une page single qui propose un contenu simple et accessible pour les moteurs de recherche.
Mais c'est du cloaking ?
Oui, cette technique peut s'apparenter à du cloaking. Il est tout à fait possible de servir à Google un contenu sur-optimisé pour le référencement. Ne serait-ce qu'en allégeant le poids de la page...
J'encourage ceux intéressés par ce hack à l'utiliser avec "respect" pour nos amis les moteurs, car Google pourra facilement s'en apercevoir.
Les limites de cette méthode
Selon les mise à jour, il faudra refaire la modification de la fonction parse, dans la classe-wp. Je n'ai pas trouvé de moyen efficace d'externaliser la chose dans le functions.php ou bien dans un plugin. Si quelqu'un a la solution, merci de partager...
De plus il reste certaines limitations propre à l'utilisation de l'ajax :
- Dans les SERPs de Google, l'aperçu des pages en ajax n'est pas disponible.
- Facebook, lorsque l'on voudra partager un lien, n'arrivera pas a parser l'URL correctement (il s’arrêtera au hashbang).
- Pour l'utilisation de google analytics, il faut penser à rajouter un tracker d'évènement lors du changement de contenu d'une page, sinon toutes les statistiques ne porteront que sur la page mère.
- Les logiciels dédiés à la SEO type "seeUrank falcon" et "myPoseo" ne comprennent pas les hashbangs. Pour l'instant...
Conclusion sur WordPress et le SEO de l'Ajax
La technique expliquée ici me parait beaucoup plus simple à utiliser que celle nécessitant un headless browser. De plus, elle permet une optimisation plus poussée.
Grâce à elle, vous pourrez facilement concevoir un site dynamique sans craindre pour l'indexation de vos contenus.
Cet article a été co-rédigé par Willy Bahuaud et Geoffroy Couprie.
19 Commentaires
C'est vraiment dommage que l'on ne puisse faire un hook dans le fichier functions.php pour modifier ce paramètre. Car sinon, il faut être très attentif aux mises à jour de ses blogs WordPress en Ajax...
En fait c'est possible, ça fonctionne, mais une erreur est générée à chaque appel...
Donc c'est pas vraiment très propre, et puis sur un gros site, le fichier de log d'erreurs va grossir très rapidement ^^
+ d'infos ici : le forum de grafikart, add_action sur fonction parse()
Et pas moyen de passer par le htaccess ?
Sinon la solution ultime et super propre c'est simplement la méthode HTML5 (via js) window.history.pushState qui change l'url de façon dynamique. Mais nécessite un browser pas trop vieux (fonction utilisé notamment sur flicker et sa lightbox)
Non, il n'y a pas vraiment moyen de passer par le htaccess. Toute modification passant par celui-ci passerait pour une redirection je crois, et serait intercepté par google.
En gros la page serait indexée sur une notification de redirection (c'est bof ^^)
Je ne suis pas sur que la solution HTML5 soit indexable par google en fait, elle sert uniquement à donner des informations/possibilités de navigation à l'internaute...
à moins que ça ai changé, je ne sais pas...
Ce serait presque possible de passer par du htaccess, mais assez bancal, car Apache ne connait rien au contenu WordPress. Et ça ne marcherait pas du tout dans le cas d'un site full AJAX(chargement de page vide, puis contenu arrivant par AJAX).
La modification de l'historique n'aidera pas au référencement: le googlebot n'est pas censé comprendre le javascript. Et ce n'est pas gênant de garder une URL avec hashbang dans l'historique du navigateur, car il saura interpréter correctement le JS et charger le contenu.
Ok pour l'htaccess
Par contre pour window.history.pushState je voudrais savoir ce qui pose problème exactement ? Car ...
1/ on ne touche pas aux url de wordpress, qui reste accessible même sans ajax donc (tu cliques sur l'url et sa t’amène sur la page visée, ni plus ni moins, comportement normal)
2/ ensuite tu rajoutes une couche de javascript qui va changer le comportement de tes liens (rien d'intrusif, tout se fait en parsant le dom via js)
3/ Via js donc, tu indiques que si l'utilisateur clique sur tel lien (le lien vers un article par exemple), et bien au lieu de l’amener sur la page en question, tu le laisses là où il est (un return false sur onclick), tu charges le contenu distant (là tu as multiples possibilités, facile) et tu modifies l'url/titre à la volée par l'url COMPLETE. Ni vu ni connu.
Et donc là je ne vois absolument pas comment google ne pourrait pas indexer le contenu puisque sans javascript activé, on se retrouve à naviguer normalement et avec des liens/url tout à fait classiques .... Ou alors j'ai raté un truc ?
Effectivement, cette technique peut marcher, mais elle pose encore quelques problèmes:
-il faut que ton code JS fasse la différence entre les liens WordPress et le reste (faisable, mais pas forcément simple)
-les utilisateurs posteront quand même des liens avec hashbang (par exemple par clic droit+ copy url) que Google ne comprendra pas sans utiliser _escaped_fragment_
A part ça, oui, ça marche.
La solution présentée ici permet d'adapter un thème AJAX existant en ne modifiant qu'une seule ligne, c'est un compromis satisfaisant, non?
Différencier les liens ça doit pouvoir se faire en utilisant des classes css pour le ciblage par exemple.
Par contre pourquoi dis-tu que les utilisateurs posteront quand même des liens avec hashbang ? Dans mon exemple a AUCUN moments il n'y a des hashbang présent dans les url ! Ni celle sur les liens, ni celles dans la barre d'adresse ! Même en ajoutant la page aux favoris on garde la bonne url !
Fait un test là: http://www.flickr.com/photos/k-simir/4574459068/ Cliques sur la photo, elle va s'afficher dans une lightbox via ajax mais avec la bonne url
Effectivement, il s'agit pas tout à fait de le même chose. Cependant je comprends ce que tu veux dire @ju.
La solution HTML5 pourrait convenir pour un site de ce type (mis à part la séparation de liens internes/externes, comme l'évoque @Géo, ainsi que le fait que ça ne marche que sur les navigateurs récents)
Par contre sur un site comme artplaTV, la chose devient plus complexe et moins adaptée, il me semble...
@Willy Bahuaud: pourquoi plus complexe sur artplaTV ? Avec la méthode html5 on pourrait ajaxifier n'importe quel site fonctionnant sur base de template avec juste un fichier javascript et 2 paramètres à fournir selon chaque site.
Dans le js tu code une fonction qui reçoit comme paramètres le nom de la classe css des liens a "ajaxiser" et l'id de la div qui contient le contenu AJAX. A partir de cette classe CSS, la fonction sait quelle page charger en ajax. Elle récupère la page et parse le contenu pour ressortir ce que contient la div ciblée (la fonction ajax de jquery permet de faire ça en une ligne très simplement par exemple) et le coller dans la même div sur la page courante. Ensuite on peut pousser un peu plus loin en parsant aussi le titre de la page distante pour l'afficher sur l'actuelle. Ensuite reste plus qu'a dire à ta fonction de changer l'url courante par la distante.
Ah oui, le hashbang n'apparaît pas. j'avais vu d'autres exemples
Donc, il reste le choix entre la solution idéale nécessitant un gros paquet de modifications sur le thème, et la solution simple qui règle le problème en une ligne :p
@Geoffroy Couprie
"nécessitant un gros paquet de modifications sur le thème" ? Ma soluce prend 2 lignes dans le functions.php (ajout du js dans le footer) ! ^^
@ju je dis que c'est plus difficile sur artplatv car je ne veux pas que les internautes aient accès au détail des pages. Et je ne veux pas que google crawl un contenu quasi identique à chaque fois. Perso sur artplaTV, le contenu est appelé en json par wp_ajax (ça change pas grand chose, mis à part le temps de chargement, me diras-tu :-P)
@Willy Bahuaud oui effectivement si tu ne veux pas que le contenu brut soit indexé ... d'ou l'utilité de partir sur un système de template pour lequel chaque page aurait le même design (et pas juste des données brutes) :)
@ju oui mais nan : qui dit même design dit charger quasiment le même contenu sur de nombreuses pages du site. J'avoue l'avantage de la méthode expliquée c'est le cloaking (Am I a bad guy ?)
@Willy Bahuaud
"qui dit même design dit charger quasiment le même contenu sur de nombreuses pages du site"
Ah oui mais bon c'est comme ça pour de très nombreux sites, surtout sous wordpress. Donc bon, de mon coté ça ne me gène pas et google n'est pas trop vilain avec moi pour ça. Après c'est sur que si tu veux optimiser .... ;)
@ju oui je veux optimiser, sinon je ferai rien de tout ça... ^^
Bonjour,
Je vous remercie pour toutes ces infos.
Pourriez-vous me donner plus d'informations sur :
"Dans le thème, il faut donc concevoir une page single qui propose un contenu simple et accessible pour les moteurs de recherche.",
Je ne comprends pas bien comment m'y prendre pour faire ça sur un site wordpress entièrement en Ajax...
Merci beaucoup !
Bonjour,
2 ans plus tard, ce tuto m'a bien aidé pour le site d'un client, qui avait ses pages de réalisations affiché via AJAX.
Après avoir pas mal galéré pour ne pas à avoir à modifier le fichier class WP, un dev de mon boulot m'a bien débloqué l'override du parse_request().
En gros :
- il faut remplacer les $this par $extra_query_vars
- il a supprimer 4-5 lignes au début qui servait pas à grand chose pour nous
- et pour finir, la dernière ligne do_action_ref_array('my_parse_request', &$extra_query_vars->extra_query_vars);
Et voilà le pastebin, qui fonctionne pour moi (sans warning) : http://pastebin.com/cdGiKXjJ
Enjoy ;)
Laisser un commentaire