Éliminer le contenu en double dans la navigation à facettes avec Ajax/JSON/JQuery

L’un des problèmes classiques du référencement est que si les schémas de navigation complexes peuvent être utiles aux utilisateurs, ils créent des problèmes de contenu en double pour les moteurs de recherche. De nombreux éditeurs s’appuient sur des balises telles que rel=canonical ou sur les paramètres des outils pour les webmasters pour essayer de résoudre ces types de problèmes. Cependant, chacune des solutions potentielles a ses limites. Dans l’article d’aujourd’hui, je vais expliquer comment vous pouvez utiliser les solutions JavaScript pour éliminer complètement le problème.

Notez que je ne vais pas fournir d’exemples de code dans cet article, mais je vais décrire comment cela fonctionne au niveau conceptuel. Si vous souhaitez en savoir plus sur Ajax/JSON/jQuery, voici quelques ressources que vous pouvez consulter :

1. Tutoriel Ajax
2. Apprendre Ajax/jQuery

Définir le problème avec la navigation à facettes

Avoir une page de produits et permettre aux utilisateurs de trier ces produits comme ils le souhaitent (triés du prix le plus élevé au prix le plus bas), ou d’utiliser un filtre pour sélectionner un sous-ensemble de produits (uniquement ceux de plus de 60 $) est logique pour les utilisateurs. Nous appelons généralement ces types d’options de navigation la “navigation à facettes”.

Cependant, la navigation à facettes peut poser des problèmes aux moteurs de recherche car ils ne veulent pas explorer et indexer tous vos différents ordres de tri ou toutes vos différentes versions filtrées de vos pages. Ils se retrouveraient avec de nombreuses variantes différentes de vos pages qui ne sont pas significativement différentes du point de vue de l’expérience utilisateur du moteur de recherche.

Les solutions telles que les balises rel=canonical et les paramètres des paramètres dans les outils pour les webmasters présentent certaines limites. Par exemple, les balises rel=canonical sont considérées comme des “indices” par les moteurs de recherche, et ils peuvent ne pas choisir de les accepter, et même si elles sont acceptées, elles n’empêchent pas nécessairement les moteurs de recherche de continuer à explorer ces pages.

Une meilleure solution pourrait être d’utiliser JSON et jQuery pour implémenter votre navigation à facettes afin qu’une nouvelle page ne soit pas créée lorsqu’un utilisateur sélectionne un filtre ou un ordre de tri. Voyons comment cela fonctionne.

Utiliser JSON et jQuery pour filtrer côté client

Le principal avantage de l’implémentation décrite ci-dessous est qu’une nouvelle URL n’est pas créée lorsqu’un utilisateur se trouve sur une de vos pages et applique un filtre ou un ordre de tri. Lorsque vous utilisez JSON et jQuery, l’ensemble du processus se déroule sur le périphérique client sans impliquer du tout votre serveur Web.

Lorsqu’un utilisateur demande initialement l’une des pages produit de votre site Web, l’interaction ressemble à ceci :

Cela transfère la page au navigateur que l’utilisateur a utilisé pour demander la page. Désormais, lorsqu’un utilisateur sélectionne un ordre de tri (ou un filtre) sur cette page, voici ce qui se passe :

Lorsque l’utilisateur sélectionne l’une de ces options, une requête jQuery est envoyée à l’objet de données JSON. Traduction : toute l’interaction se produit dans le navigateur du client et le tri ou le filtre y est appliqué. En termes simples, l’intelligence pour gérer ce tri ou ce filtre réside entièrement dans le code sur l’appareil client qui a été transféré avec la demande initiale de la page.

Par conséquent, aucune nouvelle page n’est créée et aucune nouvelle URL à explorer par Google ou Bing. Toutes les préoccupations concernant le budget de crawl ou l’utilisation inefficace du PageRank sont complètement éliminées. C’est super ! Cependant, des limites subsistent dans cette mise en œuvre.

Plus précisément, si votre liste de produits s’étend sur plusieurs pages de votre site, le tri et le filtrage ne seront appliqués qu’à l’ensemble de données déjà transféré au navigateur de l’utilisateur lors de la requête initiale. En bref, vous ne triez peut-être que la première page de produits, et non l’ensemble des produits. Il est possible que l’objet de données JSON initial contienne l’ensemble complet des pages, mais cela peut ne pas être une bonne idée si la taille de la page finit par être grande. Dans ce cas, nous devrons faire un peu plus.

Ce que l’Ajax fait pour vous

Nous allons maintenant creuser un peu plus profondément et décrire comment Ajax nous permettra de gérer le tri, le filtrage ET la pagination. Avertissement: Il y a des discussions techniques dans cette section, mais je vais essayer de faire suivre chaque explication technique par une explication profane sur ce qui se passe.

L’implémentation conceptuelle d’Ajax ressemble à ceci :

Dans cette structure, nous utilisons une couche Ajax pour gérer les communications avec le serveur Web. Imaginez que nous ayons un ensemble de 10 pages, l’utilisateur a obtenu la première page de ces 10 sur son appareil et demande ensuite une modification de l’ordre de tri. L’Ajax demande un nouvel ensemble de données au serveur Web pour votre site, similaire à une transaction HTML normale, sauf qu’il s’exécute de manière asynchrone dans un thread séparé.

Si vous ne savez pas ce que cela signifie, l’avantage est que le reste de la page peut se charger complètement pendant que le processus de capture des données que l’Ajax affichera s’exécute en parallèle. Ce seront des choses comme votre menu principal, vos liens de pied de page vers des produits connexes et d’autres éléments de page. Cela peut améliorer les performances perçues de la page.

Lorsqu’un utilisateur sélectionne un ordre de tri différent, le code enregistre un gestionnaire d’événements pour un objet donné (par exemple, un élément HTML ou d’autres objets DOM) puis exécute une action. Le navigateur effectuera l’action dans un thread différent pour déclencher l’événement dans le thread principal, le cas échéant. Cela se produit sans avoir besoin d’exécuter une actualisation complète de la page, seul le contenu contrôlé par l’Ajax est actualisé.

Pour traduire cela pour le lecteur non technique, cela signifie simplement que nous pouvons mettre à jour l’ordre de tri de la page, sans avoir besoin de redessiner toute la page, ou de changer l’URL, même dans le cas d’une séquence de pages paginées. C’est un avantage car cela peut être plus rapide que de recharger la page entière, et cela devrait indiquer clairement aux moteurs de recherche que vous n’essayez pas d’obtenir une nouvelle page dans leur index.

En fait, il le fait dans le modèle d’objet de document (DOM) existant, que vous pouvez considérer comme la structure de base des documents et une spécification de la manière dont le document est accessible et manipulé.

Comment Google va-t-il gérer ce type de mise en œuvre ?

Pour ceux d’entre vous qui ont lu l’excellent article récent d’Adam Audette sur les tests effectués par son équipe sur la façon dont Google lit Javascript, vous vous demandez peut-être si Google chargera toujours toutes ces variantes de page sur la même URL de toute façon, et si cela ne leur plaira pas.

J’avais la même question, alors j’ai contacté Gary Illyes de Google pour obtenir une réponse. Voici la boîte de dialogue qui s’est déroulée :

Eric Engé: J’aimerais vous poser des questions sur l’utilisation de JSON et jQuery pour rendre différents ordres de tri et filtres au sein de la même URL. C’est-à-dire que l’utilisateur sélectionne un ordre de tri ou un filtre, et le contenu est réorganisé et redessiné sur la page du site client. Par conséquent, aucune nouvelle URL ne serait créée. C’est effectivement un moyen de canoniser le contenu, puisque chaque variante est un sous-ensemble strict.

Ensuite, il y a une considération de deuxième niveau avec cette approche, qui consiste à faire la même chose avec la pagination. C’est-à-dire que vous avez 10 pages de produits et que les utilisateurs disposent toujours d’options de tri et de filtrage. Afin de prendre en charge le tri et le filtrage sur l’ensemble des 10 pages, vous utilisez une solution Ajax, de sorte que tout cela s’affiche toujours sur une seule URL.

Donc, si vous êtes sur la page 1 et qu’un utilisateur exécute un tri, il récupère tout cela dans cette page. Cependant, pour faire cela correctement, aller à la page 2 s’afficherait également sur la même URL. En fait, vous prenez l’ensemble de 10 pages et vous le restituez dans une seule URL. Cela permet le tri, le filtrage et la pagination sans avoir besoin d’utiliser canonique, noindex, prev/next ou robots.txt.

Si cela n’a pas été problématique pour Google, le seul inconvénient est que cela rend la pagination non visible pour Google. Est-ce logique ou est-ce une mauvaise idée ?

Gary Illyes: Si vous n’avez qu’une seule URL et que les utilisateurs doivent cliquer sur des éléments pour afficher différents ordres de tri ou filtres pour exactement le même contenu sous cette URL, nous ne verrons généralement que le contenu par défaut.

Si vous n’avez pas d’informations de pagination, ce n’est pas un problème, sauf que nous ne verrons peut-être pas le contenu des autres pages qui ne sont pas contenues dans le code HTML lors du chargement initial de la page. La signification de rel-prev/next est de canaliser les signaux des pages enfants (page 2, 3, 4, etc.) vers le groupe de pages en tant que collection, ou vers la page de visualisation complète si vous en avez une. Si vous choisissez simplement de rendre ces versions paginées sur une seule URL, cela aura le même impact du point de vue des signaux, ce qui signifie que tous les signaux iront à une seule entité, plutôt que distribués à plusieurs URL.

Sommaire

Gardez à l’esprit que la raison pour laquelle Google a implémenté des balises telles que rel=canonical, NoIndex, rel=prev/next et d’autres est de réduire leur charge d’exploration et le gonflement global des pages et d’aider à concentrer les signaux sur les pages entrantes de la meilleure façon possible. L’utilisation d’Ajax/JSON/jQuery comme indiqué ci-dessus le fait simplement et élégamment.

Sur la plupart des sites de commerce électronique, il existe de nombreuses “facettes” différentes sur la façon dont un utilisateur peut souhaiter trier et filtrer une liste de produits. Avec l’implémentation de style Ajax, cela peut être fait sans créer de nouvelles pages. Les utilisateurs finaux obtiennent le contrôle qu’ils recherchent, les moteurs de recherche n’ont pas à gérer les pages excédentaires qu’ils ne veulent pas voir et les signaux vers le site (tels que les liens) se concentrent sur les pages principales où ils devrait être.

Le seul inconvénient est que Google peut ne pas voir tout le contenu lorsqu’il est paginé. Un site qui a beaucoup de produits très similaires dans une liste paginée n’a pas trop à s’inquiéter du fait que Google voit tout le contenu supplémentaire, donc ce n’est pas vraiment un problème si vos pages supplémentaires contiennent plus de ce qui se trouve sur la première page. Cependant, les sites dont le contenu est matériellement différent sur les pages supplémentaires ne voudront peut-être pas utiliser cette approche.

Ces solutions nécessitent une expertise en codage Javascript mais ne sont pas vraiment complexes. Si vous avez la capacité d’envisager un chemin comme celui-ci, vous pouvez vous libérer d’essayer de comprendre les différentes balises, leurs limites et si oui ou non elles accomplissent vraiment ce que vous recherchez.

Crédit : Merci à Clark Lefavour d’avoir fourni un examen de ce qui précède pour l’exactitude technique.