Référencement naturel pour les pages de liste de produits de commerce électronique

Chapitres “Ecommerce SEO”:

1 – L’architecture Du Site De Commerce Électronique
2 – La Recherche De Mots-Clés
3 – Référencement De L’exploration (Crawling)
4 – Référencement Des Liens Internes
5 – Référencement De La Page D’accueil
6 – Référencement Naturel Pour Les Pages De Liste De Produits
7 – Référencement Pour Les Pages Avec Des Détails Sur Les Produits (PDP)

Ceux qui sont impliqués en e-commerce, d’une manière ou d’une autre, appellent les pages avec des détails sur les produits (connues aussi comme product detail pages ou PDPs), les « pages d’argent » / money pages. Cela semble impliquer le fait qu’un grand nombre de personnes considèrent les PDPs comme les plus importantes pages pour e-commerce. A cause de cette mentalité, les PDPs bénéficient souvent de la plus grande attention, au détriment des pages listings, comme les pages listes de produits ou de catégories.

Quand même, les pages listings sont en effet de vrais noyaux pour les sites web d’e-commerce et peuvent recueillir et transférer la plus grande autorité aux niveaux supérieurs et inférieures dans la hiérarchie du site web. De même, le développement des liens pour e-commerce se concentre généralement sur les pages de catégories et sous-catégories ; par conséquent, les pages listings méritent plus d’attention.

Les pages listings affichent le contenu dans une grille ou une liste. Lorsque ces pages listent des produits, elles sont appelées des pages listes de produits (product listing pages ou PLPs). Lorsque les pages listent des catégories, sous-catégories, guides, villes, services etc., elles sont appelées pages d’atterrissage (landing pages) ou, plus simple, pages de catégories.

Deux types de listing

Les pages listings affichent généralement l’un des deux types d’éléments :

Produits – ce listing affiche des produits qui appartiennent à la catégorie visualisée à ce moment-là.
Sous-catégories – ce listing affichent des sous-catégories ou la catégorie ou département visualisé à ce moment-là.

Les listings de produits

Les listes (ou grilles) avec les produits affichent des thumbnail images pour tous les produits classés dans une certaine catégorie ou sous-catégorie. Cela signifie que tous les produits listés ici ont un parent commun dans la hiérarchie.

Cette capture d’écran montre une grille classique de produits. Tous les produits affichés dans la zone principale de contenu appartiennent à la catégories Guitares.

L’utilisation d’une liste de produits a l’avantage d’envoyer plus d’autorité directement aux produits dans la liste, particulièrement aux produits trouvés sur la première page de la liste. Pourtant, ces listings peuvent présenter trop d’optons pour les utilisateurs, qui peuvent être obligés à sélecter des centaines sinon des milliers de produits, comme vous pouvez voir dans l’image ci-dessous :

2,839 produits vestimentaires dans une seule catégorie imposeront la pagination.

Dans bien des cas, cela n’a aucun sens de montrer aux utilisateurs une liste entière de produits qui appartient à une catégorie de top. Ceux-ci ont besoin d’une guidance dans le choix d’une produit et le listing des milliers de produits est beaucoup trop et générique.

Voyons quelques recommandations pour optimiser les pages listings de produits.

Installez une fonction de Visualisation Rapide, conviviale du point de vue SEO

Utilisez cette caractéristique pour offrir plus de contenu et contexte pour les utilisateurs et les moteurs de recherche. Cette fonction est implémentée généralement par des fenêtres modales pour offrir rapidement des informations sommaires sur des produits, sans visiter la page avec les détails sur les produits eux-mêmes.

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML14cbb33.PNG$

Un clic sur le bouton QUICK LOOK ouvre la fenêtre modale à droite. Cette fonction peut assurer une expérience meilleure aux acheteurs.

Pour en profiter de cette fonction, implémentez-le avec JavaScript convivial du point de vue SEO, chaque fois que possible. Par exemple, vous pouvez livrer plus de contenu qui peut être exploré par les robots de recherche en chargeant la description statique du produit dans le code source, mais en l’affichant dans le navigateur seulement lorsqu’on clique sur Quick Look. Les informations dynamiques, tout comme la disponibilité du produit, les couleurs disponibles ou le prix peuvent être chargées à demande par AJAX.

Comme dans le cas de toute autre méthode qui affiche le contenu pour les utilisateurs seulement à la suite de certaines actions dans le navigateur, c’est une bonne idée de ne pas abuser de l’implémentation de la fonction Quick Look. Cela signifie que le contenu doit être super-pertinent et court. 50-150 mots, probablement, suffisent amplement pour la description du produit.

De même, le linking interne ne doit pas être exagéré ; deux – cinq liens sont assez pour la courte description du produit.

En outre, vous pouvez prendre en considération le nombre de produits que vous chargez dans la visualisation de base, respectivement ce qui est enregistré en cache par les moteurs de recherche. Si vous chargez 20 produits avec des descriptions de 100 mots chacune, vous avez un contenu de 2.000 mots sur cette page-là. Si vous chargez 50 produits, respectivement 5.000 mots, il peut s’avérer trop.

Créez et améliorez les algorithmes internes pour afficher optimalement les produits affichés dans la liste.

SEO signifie la croissance des profits à la suite du trafic organique par des mesures d’optimisation pour les utilisateurs qui arrivent sur le site à l’aide des moteurs de recherche. Si un utilisateur arrive sur une page de catégorie et les premiers produits sur la liste ou dans la grille ne génèrent des profits pour vous, vous gaspillez des chances importantes.

Vous devez créer et utiliser un algorithme qui attribue un classement au produit (product rank) à chaque article et organiser les produits sur la base de ce paramètre. L’algorithme ne doit pas être complexe. Vous pouvez prendre en considération quelques paramètres différents, par exemple le pourcentage de marge, les statistiques de ventes, la disponibilité du stock, la proximité de la location de l’utilisateur et même les produits choisis individuellement.

L’idée est de placer les produits qui génèrent le maximum de profit les premiers sur la liste.

La plupart des sites web ont les produits les plus vendus ou les plus populaires comme visualisation de base dans la liste de produits, ce qui est bénéficiel pour l’opérabilité, parce que la majorité des clients cherchent les produits les plus vendus.^[1] Pourtant, cela ne signifie pas que vous ne devez pas optimiser vos profits en expérimentant votre propre algorithme de classement.

Ajoutez du contenu spécifique à la catégorie

En ajoutant de contenu aux pages PLPs vous pouvez augmenter les chances d’avoir un rang plus élevé dans les pages de recherche. Cela s’applique aux catégories de tous niveaux de la hiérarchie.

Vous connaissez probablement le « contenu SEO » pour la description des catégories ; beaucoup de sites web d’e-commerce affichent ce contenu généralement dans la partie inférieure de la page. Jetons un coup d’œil sur l’image ci-dessous :

Le « contenu SEO » est affiché après la liste ou la grille de produits pour permettre l’affichage des produits au-dessus du pli. L’influence SEO de ce contenu peut être améliorée en ajoutant des liens vers plusieurs pages internes.

Vous demandez-vous si cela fonctionne pour Newegg?

Ils se classent #2 pour “moniteurs LCD”, au-dessus de Best Buy.

Bien sûr, d’autres facteurs ont contribué au classement sur la deuxième position, mais cette description de la catégorie aura une certaine influence. Notez, SEO signifie des modifications petites et incrémentales.

Certains sites web préfèrent placer ce type de contenu au-dessus de la liste, mais cette approche ne laisse pas beaucoup d’espace pour le texte et pousse la page en bas, comme vous pouvez voir dans l’image suivante :

La catégorie « texte SEO » dans la partie supérieure de la liste pousse les produits en bas de la page.

Dans l’exemple ci-dessus, la description de la catégorie n’est pas trop longue, mais la bannière de marketing pousse la grille de produits encore plus bas.

Il n’y a aucun doute qu’un contenu texte plus grand peut aider du point de vue SEO. Cependant, si vous ajoutez trop de contenu au-dessus de la liste de produits, vous poussez les produits au-delà du pli, ce qui peut créer de la confusion pour les utilisateurs et affecter les taux de conversion. D’une autre partie, l’affichage du contenu sous la grille de produits n’est pas aussi efficient et bénéficiel que l’affichage dans la partie supérieure de la page.

Il y a quelques techniques pour solutionner ce problème, par exemple l’extension/la compression (extend/collapse) d’un contenu supplémentaire à la suite d’un clic ou l’utilisation des carrousels JavaScript. Je crois que la navigation par des onglets et l’une des plus conviviales et élégantes solutions du point de vue SEO, parce qu’elle comprend beaucoup de contenu dans la partie supérieure de la page. Cette approche est bonne pour les utilisateurs, tout comme pour les robots de recherche et peut se faire dans un espace limité, sans faire du spam.

Une courte observation sur le contenu au-delà des onglets et clics d’extension : avant l’indexation pour les téléphones mobiles, un tel contenu était considéré moins important et recevait une autorité réduite. Quand même, cela s’est changé avec l’implémentation de l’indexation pour les mobiles.

Comparons les images avec la navigation par des onglets « avant et après ».

La capture d’écran ci-dessous nous montre à quoi ressemblait une page de catégories sur REI. Elle affichait peu de contenu dans la partie supérieure de la liste, mais n’utilisait pas la navigation par des onglets. Observez la manière dont le contenu de la partie supérieure pousse la liste en bas de la page.

Cette implémentation n’impose pas des onglets.

Voici la version de la navigation par des onglets :

Ce design nouvel utilise des onglets pour afficher plus de contenu au-dessus du pli.

Shop by Category est l’onglet de base, ce qui est fantastique pour les utilisateurs, parce qu’il liste les sous-catégories. Le dernier onglet, Expert Advice & Activities, a beaucoup de valeur SEO:

Le contenu ci-dessus est magnifique pour les utilisateurs et les moteurs de recherche.

Le contenu dans l’image ci-dessus n’est pas seulement très bon parce qu’il se concentre sur les utilisateurs et conversions plus que sur le SEO, mais il est aussi une « nourriture » géniale pour les moteurs de recherche. Ce type du contenu approche les utilisateurs dans de diverses étapes du processus d’achat et les poussera dans l’entonnoir de conversion, ce qui est fantastique. Il augmentera aussi les chances de cette catégorie-là de se classer mieux en SERP.

Une courte observation ici : REI pourrait facilement ajouter un ou deux liens texte contextuels vers les sous-catégories ou produits apparentés thématiquement pour y transférer du capital SEO.

La leçon à apprendre d’ici est que tout contenu placé dans la navigation par des onglets doit être utile pour les utilisateurs et non pas un texte passe-partout (boilerplate) quelconque.

J’ai mentionné déjà cet aspect et je veux répéter : les sites web de commerce électronique doivent publier du contenu s’ils souhaitent avoir du succès à long terme. Ce n’est pas une stratégie SEO mais plutôt une approche saine de marketing. Le contenu que vous placez sur chaque page devrait répondre à l’intention de l’utilisateur auquel cette page-là s’adresse. Si la recherche que vous visez avec une certaine page est générique, par exemple des noms de catégories, essayez de satisfaire des intentions multiples sur cette page. J’appelle cela contenu à intentions multiples (multi-intent content).

Outre le contenu de très bonne qualité dans cet onglet, REI a ajouté encore plus contenu dans la partie inférieure de la grille de sous-catégorie, en dehors de la navigation par des onglets :

Le contenu supplémentaire dans la partie inférieure de la page a le rôle d’augmenter la relevance de cette page de sous-catégorie.

Un bon modèle d’implémentation de contenu SEO dans la partie inférieure de la grille vous pouvez trouver sur le site Home Depot.

Ils ont placé des guides d’achats, des guides de projets et du contenu pour la communauté associé aux catégories, ce qui est fantastique pour les utilisateurs et les moteurs de recherche seront enchantés. Une seule observation : il serait intéressant à tester les effets sur les conversions si ce type du contenu était placé plus haut dans la présentation, au-dessus de la grille de produits.

La création d’un type du contenu similaire au contenu utilisé par Home Depot est une stratégie gagnante dans toute situation parce que :

Les utilisateurs obtiendront un contenu de très bonne qualité pour aider leurs besoins et répondre à leurs questions, ce qui amènera à des taux de conversions meilleurs.
Les moteurs de recherche aimeront ce type de contenu, ce qui amènera à un trafic organique plus élevé.

Une section très utile est présentée au final du listing des produits.

Une autre option pour ajouter plus de contenu sur les pages de catégories est d’introduite un lien ou un bouton vers du contenu supplémentaire, juste au-dessus des produits. Vous pouvez voir un tel exemple ci-dessous :

Lorsque les utilisateurs cliquent sur le bouton View Guide ils sont guidés vers une page nouvelle. Le guide de cette nouvelle page est long et de qualité, mais n’ajoute aucune valeur à la page listing en elle-même.

Au lieu d’ouvrir le guide dans une page nouvelle, une option SEO meilleure serait d’ouvrir une fenêtre modale qui contient un fragment du guide. Pre-chargez le fragment de texte en code HTML pour le faire accessible aux moteurs de recherche. Cette fenêtre modale comprendra un lien vers le guide HTML, donc les utilisateurs peuvent y cliquer pour lire le guide entier, s’ils souhaitent.

La création de contenu consume du temps et des ressources, donc vous devez identifier les catégories avec les meilleurs résultats et puis passer graduellement aux autres.

Profitez du contenu généré par l’utilisateur (user-generated content ou UGC)

Le contenu généré par les utilisateurs a une valeur SEO très élevée ; jetons alors un coup d’œil sur les deux types d’UGC que vous pouvez implémenter sur les pages listings : les critiques des produits et les commentaires sur les forums.

Les critiques des produits

En ajoutant quelques critiques pertinentes pour les produits, vous allez influencer les taux de conversions des moteurs de recherche :

Dans cette image vous pouvez voir la manière dont la section dédiée aux critiques est affichée en bas de la page listing. Les critiques de cette section devraient, idéalement, refléter les produits présentés.

Si le listing est paginé, les critiques devraient être listées sur la page d’indexation et ne devraient pas être répétées sur les pages numérotées. Si vous avez assez critiques pour remplir les pages 2-N de la série, vous pourriez être tentés de le faire, mais ce n’est pas une bonne idée.

Dans de tels cas, vous pouvez envisager une augmentation du nombre de critiques que vous listez sur la page d’indexation. Au lieu de trois critiques, augmentez le nombre à cinq ou dix.

Lorsque vous procédez ainsi, vous devez créer des règles pour éviter les problèmes liés au contenu en double entre les pages listings et les pages avec des détails sur les produits. De telles règles peuvent inclure :

N’affichez pas plus de deux critiques pour le même produit sur la même page.
Affichez seulement cinq critiques sur la même page listing.
Sur la page listing, n’affichez les mêmes critiques que vous avez affichées sur la page du produit.

Commentaires sur les forums

Le contenu adressé à la communauté, tout comme les commentaires des forums, peut être utile non seulement dans la section forum d’un site web (si vous en avez une, bien sûr), mais sur les pages de catégories :

$C:\Users\Traian\AppData\Local\Temp\SNAGHTMLc5d8e43.PNG$

Autre que les critiques des produits, quelques commentaires pertinents du forum sont listés sous la grille de produits.

Optimisez pour le SERP des snippets meilleurs

Les pages listings de produits peuvent obtenir des snippets dans les pages avec les résultats de la recherche en Google :

Snippet en SERP enrichi avec le nombre des produits dans la liste. Parfois, Google affiche seulement le nombre de produits de la liste ; parfois, il affiche aussi quelques noms de produits.

Quoique bien de sites web d’e-commerce soient intéressés à obtenir ces rich snippets, la recommandation officielle de Google n’offre pas trop de détails :^[2]

“Si le résultat d’une recherche est formé dans la plupart d’une liste structuré, comme un tableau pour une série de produits numérotée, nous montrerons une liste avec trois lignes ou des produits pertinents sous le résultat, dans un format numéroté. Le snippet montrera, aussi, une valeur approximative du nombre total de lignes ou produits sur cette page-là (par exemple, “40+ items” comme dans l’image ci-dessous)”.

Un code HTML propre peut aider à l’indication du nombre de produits dans le rich snippet.

Google peut utiliser le code HTML pour générer des rich snippets, ce qui signifie qu’il n’a pas besoin nécessairement d’un marquage (markup) sémantique, comme Schema.org. Voilà pourquoi il est important de garder le code propre et bien structuré.

Notez que si les pages listings comprennent des rich snippets qui incluent les noms de produits, alors la ligne de description du snippet en SERP sera plus court que d’habitude. Au lieu de deux ou trois lignes de texte, le snippet de description sera tronqué à une seul ligne de texte. C’est une bonne idée de vérifier l’impact sur le taux CTR en SERP dans ces cas-là.

Voici quelques conseils pour obtenir des rich snippets pour les listings de catégories :

Validez le code HTML pour votre liste

Si vous ouvrez un élément de la liste mais ne le fermez pas ou si vous incorporez des éléments d’une manière incorrecte, il sera plus difficile pour Google de comprendre la structure de la page.

Chaque produit de la grille est inclus dans un élément de la liste, qui est correctement fermée. De même, observez le nom de classe DIV et UL.

Ne séparez pas les tableaux HTML

Rich snippet affichera le nombre de produits de la page d’indexation (par ex., “40+ items”) si la grille contient 40+ produits dans un seul tableau, mais seulement si le marquage du tableau n’est pas séparé. Si quelque chose brise le tableau entre les lignes 10 et 11, Google affichera le message “10+ items”. Si vous listez les produits dans des tableaux multiples, Google choisira d’afficher le nombre d’un seul tableau.

Utilisez des nomes de classe suggestifs pour HTML

On affirme^[3] que l’utilisation du nom de classe « article » dans la DI de l’article aide à obtenir des rich snippets pour les pages de catégories :

“Seulement pour une confirmation, nous avons incorporé quelques produits dans le <div class=items> et le snippet a été actualisé. Il a fallu quatre jours pour apparaitre en SERP”.

Ce conseil semble fonctionner, au moins dans une certaine mesure, comme vous pouvez voir ci-dessous :

Observez le nom de classe LI.

DIV qui incorpore la grille de produits contient le terme « produits » et cela semble être commun parmi les sites web qui obtiennent des rich snippets sans utiliser un marquage sémantique. De même, le nom de la classe de produits contient le terme « article ».

Rich snippet pour la catégorie Running Shoes inclut le nombre de produits sur la page et le nombre total de produits de cette catégorie.

Un nombre total élevé de produits dans la liste peut attirer plus de clics, parce que les consommateurs cherchent une liste compréhensive lorsqu’ils choisissent où cliquer. Ainsi, nous arrivons à une autre idée d’optimisation.

Réanalysez le nombre de produits du listing

Si le nombre de produits dans la catégorie visualisée couramment est assez réduit et facile à parcourir (par ex., 50 produits dans une grille avec cinq lignes sur dix colonnes), alors chargez-les tous sur une seule page. En fonction du nombre de liens sur la page et l’autorité générale du domaine, vous pouvez hausser ce nombre à 100 ou même plus.

Si vous considérez qu’il est nécessaire d’afficher un nombre réduit de produits de la perspective de l’expérience de l’utilisateur, vous pouvez charger 50, 100 ou 150 produits dans le code source d’une manière conviviale SEO et vous pouvez utiliser AJAX pour afficher seulement 10, 15 ou 20 produits dans le navigateur, pour éviter l’excès d’informations. Puis vous pouvez utiliser AJAX pour actualiser le contenu de la page sur la base des demandes des utilisateurs, tout comme navigation en bas de la page, triage, affichage de tous produits etc.

Si vous avez des milliers de produits sous la même catégorie, envisagez de les fragmenter dans des sous-catégories plus faciles à gestionner. Vous pouvez lister des sous-catégories au lieu de produits, après leur segmentation en lots plus petits.

Etiquetez les critiques des produits avec un marquage structuré

C’est une stratégie ouverte au débat, alors vous devez faire attention à la manière d’implémentation. Les moteurs de recherche ne supportent pas le marquage pour les critiques des produits sur les pages listings et peuvent considérer un tel marquage comme spam ; faites attention.

Le marquage Review peut être utilisé en toute sécurité seulement sur les pages PDP. Les pages PLP devraient limiter ce marquage.

Assurez-vous de ne pas utiliser l’entité AggregateOffer dans le marquage parce qu’il pourra être considéré spam. La plus sure entité à utiliser dans la PLP est Offer.

Pour en apprendre davantage sur le marquage des produits Schema.org lisez cet article.^[4]

Affichez les recherches liées à la catégorie sous le champ de recherche

La section Related searches (recherches similaires) a été traditionnellement utilisée pour faire des liens internes à d’autres pages et pour aplatir l’architecture du site web. Voici un exemple classique :

La section Related Searches aide le linking internes vers les autres pages.

Les recherches similaires existent pour aider les utilisateurs à découvrir et identifier les produits, en offrant des liens très similaires vers les autres pages d’un site web. Cela dit, pourquoi ne pas les placer plus près du lieu où les utilisateurs effectueraient une telle recherche, tout comme le champ de recherche ? Vous pouvez voir cela sur le site web Zappos:

Les liens Search by sont placés dans un endroit visible, pour transférer de l’autorité aux pages avec des liens et pour aider les utilisateurs.

Quand même, sur Zappos les liens sont les mêmes sur chaque page et n’ont aucune logique sur la section Bags du site web:

Zappos affiche les options de recherche comme des liens HTML simples immédiatement sous le champ de recherche.

Size, Narrow Shoes et Wide Shoes ne sont pas des détails utiles pour quelqu’un qui cherche des sacs, n’est-ce pas ? Au lieu, vous pouvez modifier dynamiquement ces liens vers quelque chose similaire aux sacs, peut être en faisant un lien vers une page qui filtre les sacs selon Style ou d’autres attributs qui sont apparentés à la catégorie sacs (Bags).

Si vous ne souhaitez pas utiliser trop d’espace pour lister 10 ou plus recherches similaires, vous pouvez implémenter une fenêtre modale qui s’ouvre au clic sur « Recherches populaires ». Assurez-vous que le contenu de cette fenêtre est disponible aux moteurs de recherche lorsqu’ils chargent la page. Vous pouvez lister autant mots-clés similaires populaires que vous souhaitez pour chaque catégorie.

L’image ci-dessus décrit une possible implémentation des recherches populaires en utilisant une fenêtre modale.

Comme nous l’avons mentionné dans la section Pages d’accueil (Home pages), vous pouvez utiliser l’une des sources suivantes pour découvrir les recherches utiles pour les utilisateurs :

Trouvez quelles sont les recherches de top effectuées sur chaque page de catégories.
Identifiez les produits ou les sous-catégories les plus visitées après la visualisation de la page de catégories.
Obtenez les principaux mots-clés de référence. Notez que Google et d’autres moteurs de recherche commerciaux cachent les recherches sous l’étiquette « indisponible » (not provided).

Retardez le chargement des images thumbnail pour les produits

Lorsque vous chargez des dizaines de produits sur une page listing, il est possible que beaucoup de ces pages se trouvent sous la ligne médiane (below the fold).^[5] Le chargement simultané de toutes les images thumbnail n’est pas ni nécessaire, ni recommandé. Chargez l’image seulement si l’utilisateurs naviguent en bas de la page pour visualiser plus de produits.

Bien que le retard dans l’affichage des images n’ait pas un impact majeur sur les classements, il améliora l’expérience des utilisateurs, en diminuant le temps de chargement de la page.

Observez que le curseur scroll latéral (le carré rouge) est très petit ; cette dimension nous indique que la page est très longue. Les produits dans l’image sont à quelques milliers pixels « sous la ligne médiane ».

Un petit avertissement sur la signification du terme « médian ». Il a une signifiance très claire en typographie (c’est-à-dire le pli des journaux au milieu) mais, en ce qui concerne les sites web, la signifiance n’est pas aussi claire. Vous devrez identifier et définir la ligne médiane de votre site web, en prenant en considération la résolution du navigateur et les systèmes les plus utilisés par la majorité de vos utilisateurs.

Evidemment, la ligne médiane sera différente sur le mobile que sur le desktop.

Enlevez ou consolidez les liens inutiles

Les listes de produits posent souvent le problème des liens en double. Par exemple, dans l’image ci-dessous il y a un lien sur l’image thumbnail du produit et un autre sur le nom du produit. Les deux indiquent vers la même URL.

Les liens sur l’image thumbnail du produit et le nom du produit indiquent vers la même URL.

Il y a plusieurs façons de solutionner ce problème, que nous avons discuté antérieurement. Voir la section Position du lien de la section Linking interne.

Un autre problème très similaire à la redondance thumbnail-nom du produit apparaît aussi lorsque vous placez un lien sur les étoiles de la critique et lorsque le lien texte affiche le nombre de critiques pour le même produit :

Le lien image sur les étoiles et le lien du texte sur nombre “6” renvoient vers la même URL.

Dans l’exemple ci-dessus, aucun des liens ne peut pas offrir trop de relevance aux moteurs de recherche à la cause de l’absence du texte d’ancre ; donc, gardez un seul lien. Je garderai les liens sur les images étoiles, parce que vous pouvez ajouter un contexte SEO supplémentaire en utilisant alt texte et parce que la zone pour le lien sur ces images est plus grande que les nombres texte. Le lien sur le nombre de critiques pourrait être écrit par JavaScript éventuellement.

L’enlèvement des liens inutiles ou d’autres éléments de la page peut décongestionner le design, en offrant d’espace entre les produits et peut réduire le nombre de liens qui ont des fuites d’autorité vers les mauvaises pages.

Il est inutile d’afficher le lien avec Special Offers pour chaque produit. Au lieu, utilisez des tooltips ou affichez des petits symboles pour mettre en évidence de telles offres.

Un autre élément listé fréquemment dans la liste de produits est le bouton « ajouter au panier ». Je ne dis pas que vous devriez l’éliminer sans une analyse rigoureuse, mais vous pouvez faire un test A/B pour voir la manière dont il influence le taux de conversion.

Je vous recommande de surveiller les événements du type « ajouter au panier » et d’analyser si les utilisateurs ajoutent les produits au panier directement des pages de listings de produits. Si oui, allez un pas en avant et identifiez le type des utilisateurs qui font cela (par exemple, des clients antérieurs, visiteurs pour la première fois etc.). Dans beaucoup de cas, ceux qui ajoutent des produits directement de la page de listing de produits sont des clients antérieurs qui connaissent très bien la marque, les produits et votre site web ; généralement, ils savent exactement ce qu’ils veulent de vous. Si vous décidez d’éliminer les boutons « ajouter au panier », ces utilisateurs savent qu’ils peuvent ajouter les produits au panier des pages avec des détails sur les produits.

L’utilité des boutons « ajouter au panier » sur les pages listings de produits doit être testée. Testez la en la remplaçant par d’autres boutons CTS, en ajoutant des détails supplémentaires aux produits ou par l’élimination complète de cette fonction.

Faites la visualisation de listing la visualisation de base

Généralement, la visualisation du type liste permet le plus d’espace pour le contenu lié aux produits, ce qui est utile pour les utilisateurs et les moteurs de recherche.

Celle-ci est la visualisation grille. Il n’y a pas trop d’espace pour présenter des informations sur un produit d’une grille (seulement le nom et le prix).

Dans une visualisation du type liste, il y a assez d’espace pour afficher plusieurs informations sur les produits.

Dans l’exemple ci-dessus, la visualisation du type liste est de base pour les utilisateurs et les moteurs de recherche, mais les utilisateurs ont l’option de choisir la visualisation du type grille dans l’interface.

Au commencement de cette section j’ai mentionné qu’il y a deux types de listing. Jusqu’à ce moment, nous avons discuté sur les listings de produits. Il est le temps de parler du deuxième type

Les listings de catégories

Le listing des catégories signifie qu’au lieu d’afficher des produits, vous affichez les sous-catégories disponibles qu’une catégorie contient, chacune affichée par une image thumbnail représentative. Les listings de catégories sont implémentés dans les premiers deux ou trois niveaux de la hiérarchie d’un site web, en fonction de la dimension du catalogue de produits. Parce que le nombre de sous-catégories à afficher est réduit, dans la plupart des cas les pages listings de catégories utilisent la visualisation du type grille et non pas la visualisation du type liste.

Voyons comment Home Depot a implémenté la grille avec des sous-catégories d’une manière conviviale pour l’utilisateur et les moteurs de recherche.

C’est le premier niveau de la hiérarchie.

Le premier niveau dans la hiérarchie (Appliances), liste plusieurs images de sous-catégories (Refrigerators, Ranges, Washers etc.), tout comme des liens de sous-catégories (par ex., sous Refrigerators ils présentent des liens vers French Door Refrigerators, Top Freezer Refrigerators, Side By Side Refrigerators etc.)

Lorsque vous cliquez sur Refrigerators, un listing de catégories se charge. Cette fois-ci, le listing affiche les plus importantes sous-catégories pour la sous-catégorie Refrigerators.

C’est le troisième niveau de la hiérarchie.

Le troisième niveau de la hiérarchie (Appliances > Refrigeration > Refrigerators) liste encore des catégories au lieu de produits. Cela encourage les utilisateurs à choisir une route de sélection plus précise avant que la page affiche des dizaines ou des milliers de produits.

L’implémentation de sous-catégories dans les premiers deux niveaux de la hiérarchie e-commerce a l’avantage d’envoyer plus de PageRank aux pages de sous-catégories. Il est mieux ainsi que le transfert de PageRank seulement vers quelques produits, parce que vos efforts de linking devraient faire référence vers les pages de catégories et sous-catégories. Il n’est pas faisable du point de vue économique de viser les pages de produits avec la construction des liens à moins que vous n’ayez un budget très grand ou très peu produits dans le catalogue. Le développement des liens retours construit du capital pour les pages de catégories et sous-catégories, qui se transfère puis aux pages PDP.

L’implémentation de deux premiers niveaux de la hiérarchie e-commerce comme listing des sous-catégories permet, aussi, une expérience meilleure des utilisateurs. Les tests d’opérabilité ont démontré^[6] que les utilisateurs peuvent être encouragés à naviguer plus en profondeur dans les niveaux de la hiérarchie et à faire des choix meilleurs concernant la gamme de produits.

Le choix entre le listing des produits et des sous-catégories dépend des particularités de chaque site web. Généralement, le listing des sous-catégories est un choix meilleur, particulièrement pour les sites web avec des stocks grands de produits. La décision liée aux sous-catégories qui doivent être présentées au chaque niveau de la hiérarchie devrait se baser sur des règles d’affaire (par ex., les premières cinq catégories avec la marge la plus grande de profit ou les premiers cinq produits les plus vendus).

Voici quelques recommandations pour construire des pages listings de sous-catégories meilleures :

Pour transférer de l’autorité SEO directement aux produits, ajoutez une liste des produits présentés/de top en bas de la page, comme vous pouvez voir ci-dessous :

Ne listez pas trop de produits ; 5-10 sont suffisants.

Gardez la navigation latérale gauche disponible aux utilisateurs ici, parce qu’ils ont été formés d’y chercher pour la navigation secondaire ; ce type de navigation influence les conversions^[7]. De même, il est plus facile de scanner et choisir des liens de navigation secondaire.
La navigation secondaire ne comprendra pas de filtres jusqu’à ce que l’utilisateur n’arrive pas dans un point où vous listez des produits au lieu des sous-catégories.
Affichez des images thumbnail professionnelles pour les sous-catégories, comme indiqué ci-dessous :

Les images de haute qualité assurent les utilisateurs qu’il s’agit d’une entreprise digne de confiance.

Ajoutez une courte description de la catégorie chaque fois qu’il est possible et éventuellement faites un lien vers des guides d’achats ou des instruments interactifs d’identification des produits pour aider les utilisateurs à décider lequel produit est le mieux pour eux. Cela est d’autant plus important si votre marché cible ne connait très bien les produits que vous vendez ou si vous vendez de produits de très grande valeur.

Une courte description pour chaque catégorie peut aider les utilisateurs qui achètent pour la première fois à comprendre la terminologie et peut offrir plus de contexte aux moteurs de recherche.

En offrant des guides et du contenu éducatif vous augmentez le taux de conversion.

Dans l’exemple ci-dessus, le design originel n’incluait pas des boutons comme « Trouvez le réfrigérateur approprié », « Trouvez le lave-linge approprié » ou « Trouvez le séchoir approprié ». Quand même, ces liens peuvent s’avérer d’une grande valeur pour les utilisateurs et pour SEO aussi. Si les utilisateurs cliquent sur ces boutons après ils sont arrivé sur une page à la suite d’une recherche générique (par ex, « les meilleurs appareils ménagers »), les clics aideront à la diminution du taux « bounce » et conduiront aux temps meilleurs de visitation du site.

Utilisez une fonction SEO de visualisation rapide (Quick View) pour ajouter plusieurs détails sur chaque catégorie.

Compte tenu qu’une telle fonction marche bien sur les pages listings de produits, une approche similaire peut être implémentée pour les listings de catégories.

Dans cette image j’ai ajouté le bouton More Info au design originel à titre illustratif.

Un clic sur More Info ouvrera une fenêtre modale. Dans cette fenêtre vous pouvez inclure des détails comme une courte description de la catégorie, ce que les utilisateurs peuvent y trouver, des liens à d’autres catégories de la hiérarchie, même si questions et réponses fréquentes.

Breadcrumbs

Breadcrumbs sont une forme d’éléments de navigation et sont affichés généralement entre le titre et le contenu principal :

Breadcrumbs offre un sentiment de “localisation” pour les utilisateurs.

Par exemple, un breadcrumb sur un site web qui vend des produits de bricolage pourrait ressembler à ceci : Home > Appliances > Cooking

Dans la structure d’un breadcrumb, Home, Appliances, et Cooking sont appelés éléments, et le signe > est appelé séparateur.

Breadcrumbs sont souvent négligés comme facteur SEO, mais il y a quelques bonnes raisons pour les accorder plus d’attention :

Les liens par des breadcrumbs sont des éléments de navigation très importants qui communiquent la location d’une page dans la hiérarchie du site web pour les utilisateurs et les aident à naviguer plus facilement à l’intérieur du site.^[8],^[9]
Breadcrumbs sont l’une des meilleures façons de créer des catégories (silos), permettant aux robots des moteurs de recherche d’explorer verticalement vers les niveaux supérieurs de la taxonomie.
La navigation par breadcrumbs aide les moteurs de recherche à analyser et comprendre l’architecture de votre site.
Breadcrumbs sont l’un des plus sûrs endroits où vous pouvez utiliser des mots-clés exacts pour le texte d’ancre.

Malgré la bonne opérabilité et les bénéfices SEO, beaucoup de sites web ne réussissent pas à implémenter correctement les breadcrumbs pour les utilisateurs et les moteurs de recherche.

Devinez quelle page est ça!

Jetez un regard rapide sur l’image ci-dessus. Quelle page pensez-vous qu’elle est ? Peut-être la page Gifts? Ou Designer Sale? Ou est-elle la page Shop by Designer page? Aucune de ces pages. C’est la page listing de la catégorie Shoes & Handbags. Est-ce que vous avez trouvé l’étiquette, jusqu’à ce moment ? Elle est dans le drop-down dans la navigation à gauche.

L’utilisation d’un breadcrumb sur ce site web aiderait les utilisateurs à comprendre où ils se trouvent dans la hiérarchie.

Si seulement l’opérabilité n’est pas assez pour vous convaincre d’accorder une plus grande attention aux breadcrumbs, alors peut-être il est le moment de vous rappeler que certains breadcrumbs correctement implémentés apparaissent directement dans les résultats de la recherche en Bing^[10] et Google:^[11]

SERP snippets qui comprennent breadcrumbs.

Dans cette image vous voyez comment les sites web BestBuy, NewEgg et Dell ont une structure breadcrumb dans le snippet des résultats, mais Walmart n’en a aucune. Probablement leur code HTML n’est pas marqué correctement.

En ce qui concerne l’inclusion des breadcrumbs dans les rich snippets de SERP, un brevet Google^[12] discute de la taxonomie du site web, du linking interne, navigation primaire et secondaire et des URLs structurés parmi d’autres choses qu’ils prennent en considération lorsqu’ils décident d’afficher les breadcrumbs en SERP. Pour augmenter les chances que breadcrumbs apparaissent dans les pages de résultats des moteurs de recherche, implémentez-les constamment sur le site entier et respectez les recommandations officielles de Google en utilisant le marquage structuré Breadcrumbs avec des micro-données ou RDFa.^[13]

Dans le passé, les listings des breadcrumbs dans les résultats de la recherche permettaient aux utilisateurs non seulement cliquer sur le titre bleu en SERP, mais sur les breadcrumbs, aussi. Quand même, Google a décidé de ne pas faire un hyperlien pour ces liens dans les breadcrumbs. Je crois que les utilisateurs cliquaient sur des liens des catégories intermédiaires et arrivaient sur des pages qui ne correspondaient pas à leur intention, donc Google a décidé d’arrêter cette option.

Si un produit appartient à des catégories multiples, il est OK de lister des breadcrumbs multiples sur la même page,^[14] tant que le produit n’est pas classé dans trop de catégories différentes. Cependant, le premier breadcrumb sur la page doit être la route canonique vers ce produit-là, parce que Google choisit le premier breadcrumb qu’il trouve sur la page.

Breadcrumbs déclenchés seulement à un certain niveau de profondeur

Certains sites web implémentent des breadcrumbs seulement à une certaine profondeur dans la hiérarchie du site web, mais ce n’est pas le meilleur choix pour les utilisateurs et les moteurs de recherche.

Lorsque les utilisateurs se trouvent sur la page de la catégorie de top Furniture, il n’y a pas de breadcrumbs.

Lorsque les utilisateurs naviguent vers une sous-catégorie de Furniture (par ex. Bedroom Furniture), breadcrumbs commencent à être affichés. Toutes les sous-catégories qui se trouvent sous Bedroom Furniture seront affichées.

Breadcrumbs qui sont affichés à une certaine profondeur peuvent fonctionner bien pour les utilisateurs qui commencent la navigation de la page d’accueil, mais à ce moment n’importe qu’elle page du site web pourrait servir comme point d’entrée pour les utilisateurs et les moteurs de recherche. Par conséquent, il est important d’inclure des breadcrumbs du premier niveau de la taxonomie du site web. En outre, l’utilisation des breadcrumbs seulement sur quelques pages pourrait désorienter les utilisateurs.

Dans beaucoup de cas, le nom de la catégorie est présenté, aussi, dans les breadcrumbs.

Il est OK de répéter le nom de la catégorie dans le breadcrumb et dans le titre. Pourtant, le dernier élément du breadcrumb ne devrait pas avoir un lien, parce que cet élément-là comprendre un lien d’auto-référence à la page active, ce qui est très déroutant pour les utilisateurs.

Selon la manière d’implémentation, il y a trois types de breadcrumbs:^[15] basés sur la route (path-based), basés sur la location (location-based) et basés sur des attributs (attribute-based).

Breadcrumbs basés sur la route

Ce type de breadcrumbs montre la route suivie par les utilisateurs dans le cadre du site web pour arriver à la page courante. Il agit de la manière d’un indice « vous êtes ici » pour les utilisateurs. Les breadcrumbs seront actualisés dynamiquement pour refléter la route de navigation historique de l’utilisateur. L’histoire de la visualisation des pages se fait soir par l’étiquetage URL, soit par des cookies basés sur des sessions.

Ce n’est pas une bonne idée d’implémenter ce type de breadcrumb n’importe où, à l’exception des pages de recherche interne sur le site. Les utilisateurs qui arrivent sur la page des moteurs de recherche peuvent arriver à des sections plus profondes dans le cadre d’un site web sans devoir naviguer dans le site. Dans ce cas, un breadcrumb basé sur la route choisie devient inutile pour les utilisateurs. La même chose s’applique aux robots des moteurs de recherche, qui peuvent arriver aux pages en bas de la hiérarchie de sources de référence externes.

Breadcrumbs basés sur la location

C’est le plus populaire type de breadcrumb et indique la position de la page courante dans la hiérarchie du site web. C’est l’indice du type « vous êtes ici » pour les utilisateurs. Ce type de breadcrumbs garde les utilisateurs sur une route fixe de navigation, sur la base de la taxonomie du site web, indépendamment des pages antérieures visitées pendant la navigation. C’est le type de breadcrumb recommandé par les taxonomistes^[16] et les experts en opérabilité.^[17]

Sur les pages des catégories de niveau de top, le breadcrumb sera seulement un lien vers la page d’accueil, lorsque le nom de la catégorie sera un texte simple (non pas un hyperlien).

Le nom de la catégorie n’a pas un hyperlien, parce que c’est la page active. Ce le comportement correct.

Le premier élément dans le breadcrumb devrait être toujours un lien vers la page d’accueil, mais vous ne devez pas utiliser obligatoirement le texte d’ancre « page d’accueil » ou « accueil ». Vous pouvez utiliser à la place le nom de l’entreprise ou un petit symbole du type maisonnette avec le nom de l’entreprise en alt texte.

Les niveaux suivants dans les breadcrumbs sont les noms des catégories et sous-catégories utilisées dans votre taxonomie. Encore, ne faites pas un lien sur la page courante, parce qu’il déroutera les utilisateurs.

Il y a des situations quand l’utilisation d’un mot-clé dans le lien du texte d’ancre qui fait référence à la page d’accueil a du sens (par exemple, si le nom de votre entreprise est The Furniture Store). Mais, même dans cette situation, utilisez-le avec attention.

Breadcrumbs basés sur des attributs

Beadcrumbs basés sur des attributs, comme le nom nous suggère, utilisent des attributs des produits ou des valeurs des filtres (comme style, couleur ou marque) pour créer une navigation qui est présentée dans la manière d’un breadcrumb. Ce type du breadcrumb est un indice similaire au « c’est ainsi que vous avez filtré les produits » pour les utilisateurs :

Cette page présente des breadcrumbs comme filtres.

Si vous cliqueriez sur Bed &Bath et puis sur Comforter Sets, vous verrez les breadcrumbs listés dans la partie supérieure de la page. Dans l’exemple ci-dessus, les éléments de breadcrumb ne sont pas des liens (les signes « X » sont des liens).

Du point de vue technique, ceux-ci ne sont pas des breadcrumbs, mais plutôt des valeurs des filtres. Cependant, cette implémentation copie l’utilisation traditionnelle des breadcrumbs, et les utilisateurs s’attendent que les filtres puissent être accédés, tout comme ils s’attendent que les breadcrumbs soient affichés horizontalement et non pas verticalement.

Je ne recommande pas généralement le remplacement des catégories par des filtres pour les catégories de niveau de top et pour les premiers niveaux de sous-catégories. Le choix entre une catégorie et un filtre se résume au moment où il n’a pas de sens de créer des catégories séparées pour des attributs spécifiques des produits. Par exemple, des catégories séparées pour la pointure des chaussures n’ont pas de sens. La pointure est plutôt un attribut du produit qui sera marqué par un filtre de navigation sur la gauche.

Séparateur

Vous devez séparer clairement chaque élément de la chaîne breadcrumb; vous pouvez séparer les éléments à l’aide des séparateurs. Le plus commun séparateur des éléments d’un breadcrumb est le signe « plus grand que » (>). D’autres bonnes options incluent les signes (»), (/) ou les flèches (→). N’oubliez pas de marquer les séparateurs avec des entités HTML correctes.^[18]

Pagination

SEO pour les pages de catégories commence à se compliquer lorsque les pages listings ont besoin de pagination. La pagination apparaît sur les sites web d’e-commerce à cause du grand nombre de produits qui doivent être segmentés en plusieurs pages (appelées aussi pages composantes). Généralement, la pagination apparaît sur les pages listings de produits et sur les pages de recherche interne sur le site.

La pagination dans l’exemple ci-dessus s’étend sur 113 pages, ce qui est trop pour les utilisateurs et difficile à optimiser pour les robots de recherche.

Si la pagination apparaît sur les pages qui listent d’autres sous-catégories à la place de produits, il est le temps de revoir la structure, en faisant les sous-catégories disponibles aux utilisateurs sans pagination. Vous pouvez faire cela en augmentant le nombre de sous-catégories que vous présentez sur une page ou en divisant les sous-catégories dans des sous sous-catégories.

La pagination est l’un des plus anciens problèmes des sites web avec des grands sets de produits et le résoudre ressemble au tir à cible mobile. Au moment présent, l’approche la plus recommandée est avec rel=“prev” et rel=“next”.

Quand même, il existait quelques stratégies d’approche de la pagination même avant que Google ait introduit ces relations à la fin de l’année 2011. De telles stratégies incluaient la non-indexation de toutes les pages, à l’exception de la première page ou l’utilisation d’une page du type view-all (visualiser toutes les images).

Pour faire la pagination encoure plus déroutante, Google dit que l’une des options de management de la pagination est de les laisser « telles comme elles sont »,^[19] en suggérant qu’ils peuvent identifier une page canonique et qu’ils peuvent gestionner bien la pagination.

Pourtant, tout ce que vous pouvez faire pour aider les moteurs de recherche à comprendre mieux ou plus efficacement votre site web est dans votre avantage. Le problème n’est pas de faire quelque chose avec la pagination, mais comment procéder.

D’une perspective SEO, une fonction « simple » comme la pagination peut poser des problèmes graves à la capacité des moteurs de recherche d’explorer et d’indexer votre contenu. Jetons un coup d’œil sur certains problèmes liés à la pagination.

Problèmes d’exploration

Un listing avec des milliers de produits aura besoin de pagination parce qu’une présentation telle quelle de ces produits n’aiderait ni les utilisateurs, ni les moteurs de recherche. Quand même, la pagination peut affecter une structure plate d’un site web plus que toute autre chose.

Pour illustrer, dans cet exemple ci-dessous il est possible que les moteurs de recherche aient besoin de 15 pas pour arriver à la page 50 d’une série. Si la seule manière d’arriver aux produits listés sur la 50^ème page est de passer par la pagination page par page, ces produits auront une chance très faible d’être découverts. Probablement, ces pages-là seront explorées moins fréquemment, ce que n’est pas idéal.

Nous sommes sur la page 7 d’une série et cette page liste trois URLs supplémentaires de pagination (8, 9 et 10) en comparaison avec page 1.

Dans notre exemple de pagination il y a des pages composantes qui manquent de la série (les pages 2 et 3), ce que signifie que les robots de recherche peuvent sauter directement de page 1 à page 4. Grâce à ces URLs qui manquent, les robots peuvent arriver à page 50 en environ 15 pas au lieu de 43 (les robots auront besoin de 43 pas pour arriver à page 50 parce qu’ils peuvent aller de page 1 directement à page 7, parce que page 7 est listée sur la page d’indexation. De page 7 ils seront nécessaires 43 pas supplémentaires/clics sur Next pour arriver à page 50).

Les chances que Google « saute » le contenu paginé pour explorer les pages finales baissent avec chaque page de la série et plus significativement à page 5.

Le graphique ci-dessus est un essai sur la pagination. Comme vous pouvez voir, Google explore les pages composantes 6-N beaucoup plus rarement.^[20]

L’essai a démontré que:

“Plus le numéro de la page est grand, plus la probabilité que cette page soit indexée est faible…En moyenne, la chance que le robot explore la page suivante des résultats de recherche baisse par 1,2 – 1,3% par page”.

Si vous avez un grand nombre de pages composantes, trouvez une manière d’ajouter des liens aux pages intermédiaires d’une série. Au lieu de faire un lien vers les pages 1, 2, 3 et 4 et puis sauter à la dernière page, ajoutez des liens vers des pages intermédiaires multiples. Dans notre exemple ci-dessus, nous pouvons rompre la série en quatre parts, en faisant un lien vers toutes les 28^èmes pages de la série. Pourquoi est-ce que j’ai choisi de faire un lien toutes les 28^èmes pages composantes ? Parce que j’ai voulu rompre la pagination en quatre (112 divisé par quatre est égal à 28).

Moins de pages composantes vous avez dans la pagination, moins des lots vous allez utiliser. Par exemple, si vous avez 10 pages composantes, vous allez lister de liens vers toutes les pages. Si vous avez 50, vous allez les diviser à 2 ; 100 seront divisées à 4, 200 à 8 et ainsi de suite.

Par conséquent, la pagination peut maintenant ressembler à l’image ci-dessous :

Assurez-vous que la navigation sur chaque page de la série a du sens pour les utilisateurs.

Dès que vous avez fait des modifications à la pagination, vous pouvez évaluer l’impact après une semaine ou deux. En plus, vous pouvez utiliser les rapports sur le navigateur pour déterminer le comportement de Googlebot avant et après les modifications faites concernant la pagination.

Des métadonnées en double

Quoique les produits listés sur les pages 1 à N soient différents, très souvent chaque page composante a le même titre et description méta tout au long de la série. Parfois, même la copie du contenu SEO est en double au long de la série de pagination, ce que signifie que la page d’indexation sera en concurrence avec les pages composantes. Dans beaucoup de cas, cette duplication est attribuable à la configuration CMS de base.

Envisagez les aspects suivants pour améliorer ou éviter cette situation :

Créez des titres et descriptions personnalisées, uniques pour les pages d’indexation (page 1 de chaque série).
Ecrivez des titres et descriptions du type boilerplate pour les pages 2-N. Par exemple, vous pouvez utiliser le titre de la page 1 avec un texte boilerplate annexé au final “{Title Page One} – Page X/Y”.
Ne répétez pas la copie SEO (si vous en avez une) de la page d’indexation sur les pages composantes.

Il est possible que l’attribution de ce caractère unique aux titres, descriptions et à la copie pour toute la série n’ait pas un impact significatif sur les classements pour les pages 2 à N, mais elle aide Google à consolider la relevance pour la page d’indexation. En plus, les pages composantes enverront des signaux internes de qualité et ne seront pas en concurrence avec la page d’indexation.

Un autre problème de contenu en double spécifique à la pagination peut apparaitre lorsque vous faites référence à la première page d’une série (c-est-à dire la page d’indexation) des pages composantes :

mysite.com/category/
mysite.com/category?page=1

Des URLs qui font référence vers la page d’indexation (la page 1 de la série) ne devraient pas inclure les paramètres de pagination. Au lieu, ces liens devraient faire référence à l’URL de la catégorie d’indexation, mysite.com/category/.

La dispersion des signaux de classement

Parfois, parce que les pages composantes de la série de pagination reçoivent des liens internes (ou des sites externes), elles peuvent arriver sur les pages SERP. Dans de tels cas, les signes de classement sont dispersés vers des URLs multiples au lieu d’être canalisés vers une seule page consolidée.

Si nous regardons la manière dont PageRank est transféré, selon la première étude sur ce sujet (publié en 1998^[21], qui affirme que PageRank se transfère également par chaque lien et a un facteur de décomposition de 10-15%), alors les pages composantes ressemblent à de vrais trous noirs pour PageRank – particulièrement ceux qui n’ont pas un lien de la première page de la série).

Voyons comment PageRank se transfère d’une page view-all et sur quelques séries paginées. Dans le but de notre démonstration, nous allons diviser PageRank seulement entre les pages composantes. Ainsi, nous supposions que tous les autres liens sont similaires sur toutes les pages.

Dans le scénario de pagination ci-dessus, les produits listés sur page 2 recevront environ trois fois moins PageRank que les produits listés sur une page view-all.

Notre scénario est pour un listing de 100 produits, sur une page PageRank 4. A cause du facteur de décomposition, cette page de listing enverra seulement 3,4 points PageRank vers les autres pages, 4 x (1-0.15). Chacun des 100 produits listés sur la page view-all recevra 0,034 points PageRank.

Nous diviserons le même listing en dix pages d’une série paginée, avec dix produits sur page. Nous aurons des liens vers les pages 1, 2, 3, 4, 5…10.

Pour la première page de la série nous aurons les paramètres suivants :

Son PageRank est 4, le même que pour la page view-all, et la valeur qui peut être transférée vers les autres liens est de 3,4 points PageRank.
Le nombre total de liens est 16 (10 liens pour les produits, plus six liens pour les URLs de pagination).
Chaque URL de l’article et de la pagination reçoit 0.213 points PageRank.

Les dix produits sur la première page de la pagination reçoivent environ six fois plus PageRank que les produits de la page view-all.

La deuxième page a les paramètres suivants :

Sa valeur PageRank est 0.213, et la valeur qui peut se transférer plus loin vers les autres liens est 0.181.
Le nombre total de liens est encore 16 (10 liens pour les produits plus six liens pour les URLs de pagination).
Chaque URL d’article et pagination reçoit 0.011 points PageRank.

Les dix produits de la deuxième page reçoivent trois fois moins PageRank que les produits listés sur la page view-all.

Page 6 de la série n’a pas un lien de la page d’indexation dans la pagination ci-dessus.

Si une URL composante n’est pas présente sur la première page de la série (par exemple, page 6 apparaît seulement lorsque les utilisateurs cliquent sur la page 2 de la série, comme dans l’image ci-dessus), alors la valeur PageRank qui se transfère aux produits qui ont un lien de page 6 est incroyablement réduite.

PageRank pour cette page est 0.011 (de page 2), et la valeur qui peut être transférée plus loin est 0.0096.
Le nombre total de liens est 16 (10 liens pour chaque article plus six liens pour les URLs de pagination).
Chaque URL d’article ou de pagination reçoit 0.0006 points PageRank.

Cela signifie que les produits de ces pages recevront environ 56 moins PageRank que les produits listés sur la page view-all.

Cette capture d’écran décrit la manière dont PageRank se change lorsque vous modifiez le nombre de produits sur chaque page composante (par ex., lister 10, 20 ou 25 produits sur page.

Ce modèle du flux PageRank suggère que :

Les produits listés sur la première page d’une série de pagination reçoivent une valeur PageRank significativement plus grande que ceux listés sur les pages composantes.
Moins de liens vous avez sur la première page, moins ils sont importants et plus de PageRank ils reçoivent – pas de surprise ici.
Si le lien vers une page paginée n’est pas listé sur la page d’indexation de la série, cette page-là reçoit une valeur PageRank significativement réduite.
Les produits listés sur les pages 2-N reçoivent moins PageRank que s’ils auraient été listés sur une page view-all. Sauf les cas lorsqu’ils reçoivent plus de liens externes.

Quand même, dans la pratique PageRank est un paramètre qui se transfère dans des façons plus complexes. Par exemple, PageRank court en avant et en arrière entre les pages et plus PageRank est transféré des liens contextuels que des liens de pagination. La valeur PageRank qui arrive sur les pages de pagination est impossible de calculer, sauf pour Google.

Cependant, ce modèle supra-simplifié nous montre que vous pouvez transférer une valeur significative de PageRank vers un nombre réduit de produits de la première page de pagination (et considérablement plus faible aux produits des pages composantes) ou vous pouvez transférer une valeur moyenne de PageRank vers tous les produits, par l’intermédiaire d’une page view-all.

Dans les deux cas, si vous utilisez la pagination il est essentiel de placer vos produits les plus importants dans la partie supérieure de la liste, sur la première page.

Contenu thin (de faible qualité)

Les pages listings ont généralement un contenu réduit ou pas de contenu, ou en tout cas pas assez pour que les moteurs de recherche le considèrent digne d’indexation. A l’exception des noms des produits et quelques informations de base, il n’y a pas trop de texte ici. Donc, Panda a filtré plusieurs pages listings de l’index de Google.

Utilité douteuse

Est-ce que vos utilisateurs utilisent la pagination ? Jetez un coup d’œil sur vos données analytiques pour apprendre. Les pages composantes servent comme points d’entrée, soit des moteurs de recherche, soit d’autres références ? Sinon, les avantages SEO et les avantages pour les utilisateurs offerts par une page view-all pourraient être plus grands que dans le cas de la pagination.

Il est possible que la pagination soit un mal nécessaire si l’architecture du site a été déjà implémentée et il est difficile de faire des actualisations, ou si un grand nombre de produits ne peuvent pas être divisés et groupés dans des sous-catégories multiples.

Si vous voulez minimaliser les problèmes liés à la pagination, il est probablement mieux de commencer avec l’architecture du site web. Vous pouvez éviter certains problèmes compliqués liés à l’expérience des utilisateurs, IT et SEO en faisant cette chose. Vous devriez envisager les aspects suivants:

Remplacez les listings de produits avec des listings de sous-catégories

Par exemple, sur la page de catégories Men’s Clothing dans l’image ci-dessus, au lieu de lister 2,037 produits, vous pouvez lister des sous-catégories, comme Athletic Wear, Belts & Suspenders, Casual Shirts, et ainsi de suite. Vous auriez des listings de produits seulement dans les niveaux plus profonds de la hiérarchie du site web.

La page de catégories Men’s Clothing liste des produits, mais elle devrait mieux lister des sous-catégories, comme dans l’image ci-dessous.

Cette-ci n’est qu’une simulation que j’ai faite pour démontrer le remplacement des listings de produits par des listings de sous-catégories.

Le listing de catégories au lieu de produits aidera aussi les utilisateurs à faire des choix mieux.^[22]

Faites des sous-catégories plus petites

Si vous avez une catégorie avec des centaines ou milliers de produits, peut-être il est possible de la diviser dans des plus petits segments. Cela déterminera une réduction ou même éliminerait le nombre des pages de la série.

La sous-catégorie Jeans & Pants peut être divisée en deux sous-catégories séparées.

La segmentation dans des catégories multiples peut enlever complètement la nécessité de pagination si vous listez un nombre raisonnable de produits. Toutefois, il est recommandé d’éviter un trop grand nombre de sous-catégories.

Augmentez le nombre de produits dans le listing

L’idée de cette approche est simple : plus vous affichez des produits sur une page listing, moins de pages composantes vous auriez dans la série. Par exemple, si vous listez 50 produits en utilisant une grille 5×10 et vous avez 259 produits à lister, vous auriez besoin de six pages dans la série de pagination. Si vous augmentez le nombre à 100, vous auriez besoin de seulement trois pages pour lister tous les produits.

Le nombre de produits que vous listez sur chaque page dépend de nombre d’autres liens sur la page, de la capacité du serveur web de charger rapidement les pages et du type de produits dans la liste. Par exemple, les listings avec des cartes de vœux peuvent être scannés plus lentement que les listings des ampoules. Généralement, 100 – 150 produits sont un bon choix.

Faites des liens aux plusieurs URLs de pagination

Au lieu de sauter les pages dans la série de pagination, faites autant de liens de pagination que possible.

Ce type de pagination présente de grands problèmes d’opérabilité.

La pagination dans l’image ci-dessus demande aux moteurs de recherche et aux utilisateurs à cliquer sept fois sur la flèche de la droite pour arriver à la dernière page. Cela est une chose négative pour les utilisateurs et SEO.

Au lieu, vous devriez faire un lien pour toutes les URLs de pagination, et la pagination ressemblera à ceci :

Avec cette approche il est plus facile pour les utilisateurs d’aller à n’importe quelles pages composantes.

En ajoutant des liens pour un nombre décent des URLs de pagination, vous aiderez les robots de recherche à arriver à ces pages-là avec les moins pas que possible.

Si vous pouvez, faites des interliens entre toutes les pages composantes. Par exemple, si le listing a comme résultat un nombre inférieur à 10 liens composants, vous pouvez lister tous les liens et non seulement 1, 2, 3…10. Si le listing génère un nombre des URLs composantes impossible à gestionner, listez autant de liens possibles sans créer une expérience négative pour les utilisateurs.

Les idées mentionnées ci-dessus peuvent vous aider à minimaliser l’impact de la pagination sur SEO. Pourtant, dans beaucoup de cas la pagination est nécessaire encore – et vous devrez la gérer.

La manière dont vous abordez la pagination est situationnelle, ce que signifie qu’elle dépend de plusieurs facteurs, tout comme l’implémentation courante, la saturation de l’indexation (le nombre des pages indexées par les moteurs de recherche), la moyenne du nombre de produits des catégories ou sous-catégories et d’autres facteurs. Il n’y a pas une approche générale.

En laissant de côté l’approche du type « ne faites rien », il y a plusieurs méthodes SEO de gérer la pagination :

La méthode “noindex, follow”.
La méthode view-all.
La méthode des attributs de la pagination, c’est-à-dire rel=“prev”, rel=“next”.
La méthode AJAX.

Une approche incorrecte de la pagination est d’utiliser rel=“canonical” pour lier toutes les pages composantes d’une série de la première page. Google affirme que :

“Le réglage canonique vers la première page d’une séquence sans paramètre est considérée utilisation impropre”.^[23]

La méthode “noindex, follow”

Cette méthode implique l’inclusion de méta-robots “noindex, follow” dans le titre (<head>) des pages 2 – N de la série, lorsque la première page sera indexable. En outre, les pages 2-N peuvent comprendre un attribut d’auto-référencement rel=“canonical”.

Des trois méthodes, celle-ci est la moins compliquée à implémenter, mais elle enlève effectivement les pages 2-N des indices des moteurs de recherche. Notez que cette méthode ne transfère aucun signal d’indexation des pages composantes à la première page, canonique.

Les pages 2 – N sont non-indexées avec l’étiquette méta “noindex, follow”.

Si votre objectif est d’éliminer les pages de l’indexation – parce que vous avez été affecté par un filtre lié au contenu thin – alors c’est la meilleure approche. De même, une bonne application de la méthode de non-indexation est sur les pages internes de recherche dans le site, parce que Google et d’autres moteurs de recherche de top ne veulent pas afficher des résultats pour la « recherche en recherche ».^[24]

Le blocage de l’accès des robots de recherche aux pages composantes peut se faire par robots.txt et dans vos comptes webmaster. Ces deux options n’élimineront pas les pages des indices ; elles seulement empêcheront l’action d’exploration ultérieure. De plus, même si vous pouvez utiliser Google Search Console pour empêcher l’action d’exploration sur les pages composantes, il est plus facile à gestionner la pagination si vous les bloquez dans un seul endroit, soit par robots.txt, soit par GSC. Lorsque vous faites un audit sur des problèmes d’exploration et d’indexation, n’oubliez pas où vous avez bloqué le contenu.

La page “view-all”

Cette méthode semble être la méthode préférée par Google pour le management de la page, parce que

“les utilisateurs préfèrent généralement l’option view-all dans les résultats de la recherche”

Et parce que,

“[Google] fera un effort plus grand pour détecter correctement et offrir cette version aux utilisateurs”.^[25]

Cette approche semble être soutenue par les tests effectués par les experts en opérabilité, comme Jakob Nielsen, qui a trouvé que:

“L’option View-all [a été] utile pour certains utilisateurs. Plus important, l’option View-all n’a pas dérangé les utilisateurs qui ne l’ont pas utilisé ; lorsque l’option manquait, pourtant, certains utilisateurs se sont plaints de cela”.^[26]

La méthode view-all implique deux pas:

1. La création d’une page view-all qui liste tous les produits d’une catégorie, comme dans l’image ci-dessous :

Le lien view-all liste tous les produits.

2. Faites la page view-all l’URL canonique de la série paginée en ajoutant l’attribut rel=“canonical” qui fait référence à l’URL view-all, sur chaque page composante:

Chaque URL composante renvoie à la page view-all.

L’objectif de rel= “canonical” est de consolider tous les signaux des liens sur la page view-all. Avec l’approche view-all, toutes les pages composantes perdent leur capacité de se classer en SERP.

Cependant, même si la page view-all peut être différente de la page d’indexation du listing, la transformation de la page view-all dans une page d’indexation est aussi possible.

La méthode view-all a certains avantages, tout comme une opérabilité meilleure, la consolidation du signal d’indexation et l’implémentation relativement facile.

Quand même, il y a quelques provocations que vous devez envisager avant de créer une page view-all:

La consolidation de centaines ou milliers de produits sur une seule page peut augmenter dramatiquement le temps de chargement, particulièrement les pages listings de produits. Un temps rapide de chargement est considéré sous quatre secondes, mais vous devriez vous proposez un temps de sous 2 secondes. Utilisez le chargement progressif pour permettre cela.
Une page view-all implique des centaines ou milliers de liens sur une seule page, parce que la page view-all doit afficher tous les produits des pages composantes. Même si une compensation peut être la consolidation des signaux d’indexation, nous n’avons pas aucune déclaration officielle regardant la manière dont les moteurs de recherche évalueront un si grand nombre de liens sur la page view-all.
Parfois vous ne souhaitez pas enlever toutes les autres pages composantes et forcez la page view-all être listée en SERP. Si vous voulez promouvoir quelques pages de la série de pagination, vous devez utiliser rel=“next” și rel=“prev”.
L’implémentation est moins complexe que dans le cas de la méthode “noindex”. Cependant, elle n’est pas aussi complexe que l’utilisation des attributs de pagination.

Il y a des situations lorsque vous souhaitez implémenter la page view-all seulement pour des motifs liés à l’expérience des utilisateurs et vous ne souhaitez pas que les moteurs de recherche la listent en SERP. Dans de telles situations, assurez-vous que les pages composantes de la série n’ont pas l’attribut rel=“canonical” qui fait référence à la page view-all, mais vers la première page de l’indexation. De plus, vous pouvez faire le lien view-all disponible seulement aux utilisateurs, en utilisant AJAX ou un contenu sur la base de cookies ou d’autres méthodes.

Si vous vous inquiétez des temps de chargement de la page, il y a des façons de livrer une version simple de la page view-all aux moteurs de recherche, en présentant en même temps la page complètement rendue aux utilisateurs, à demande et sans augmenter les temps de chargement. Ces implémentations doivent prendre en considération l’amélioration progressive (progressive enhancement)^[27] et l’expérience des utilisateurs sur les téléphones mobiles.

Quand même, de nos jours vous devriez construire des applications web progressives et des applications d’accélération mobile pour permettre un chargement super-rapide et ne pas compliquer les choses en livrant de différentes ressources aux robots de recherche versus utilisateurs humains.

Quoique la dé-pagination puisse fonctionner pour les sites web qui ont un nombre raisonnablement petit de produits dans leurs listings, pour les sites webs avec de grands stocks il peut être plus facile de maintenir la pagination conviviale avec l’utilisateur, qui limite le nombre de produits. Du point de vue de l’opérabilité,

“typiquement, cette limite supérieure devrait se situer à environ 100 produits, mais elle pourrait être plus élevée ou plus réduite, en fonction de l’effort des utilisateurs de scanner les produits et de l’affectation du temps de réponse pour une page longue”.^{^[28]}

Les attributs de pagination (ou la méthode rel=”prev” et rel=”next”)

Une autre méthode de management de la pagination est l’utilisation des attributs de pagination (connue aussi comma la méthode rel=“prev” et rel=“next”). Cette méthode est, probablement, l’approche qui s’applique le mieux aux sites web d’e-commerce d’aujourd’hui, parce qu’elle semble générer de bons résultats, sans enlever complètement la capacité des pages de se classer dans les résultats de recherche.

Dans la section de titre (<head>) de chaque page composante de la série, utilisez l’attribut rel=“prev” ou rel=“next” (ou les deux) pour définir une « chaîne » de composantes paginées.

Les attributs de relation prev et next ont été longtemps des standards HTML,^[29] mais ils ont captivé l’attention seulement quand ils ont été promus par Google. Rel=“prev” et rel=”next” sont seulement quelques indices pour suggérer la pagination ; ils ne sont pas des directives.

Disons que vous avez des listings de produits paginés dans la série suivante :

http://www.website.com/duvet-covers/
http://www.website.com/duvet-covers?page=2
http://www.website.com/duvet-covers?page=3
http://www.website.com/duvet-covers?page=4

Sur la première page (la page d’index de la catégorie), vous incluriez cette ligne dans la section <head>:

<link rel=“next” href=“http://www.website.com/duvet-covers?page=2” />

La première page contient le marquage rel=“next” mais non pas rel=“prev”. Normalement, c’est la page de la série qui devient hub et est listée en SERP.

Sur la deuxième page, vous incluriez ces deux lignes dans la section <head>:

<link rel=“prev” href=“http://www.website.com/duvet-covers/” />
<link rel=“next” href=“http://www.website.com/duvet-covers?page=3” />

Les pages de 2 – avant-dernière devraient avoir le marquage rel=“next” tout comme rel=“prev”.

Notez que page 2 fait référence en arrière vers la première page de la pagination comme /duvet-covers/ au lieu de /duvet-covers?page=1. C’est la manière correcte de faire référence à la première page de la série et cela ne rompt pas la chaîne, parce que:

/duvet-covers/ enverra vers /duvet-covers?page=2 comme page suivante et
/duvet-covers?page=2 enverra vers /duvet-covers/ comme page précédente.

Sur la troisième page (http://www.website.com/duvet-covers?page=3) – vous incluriez le marquage suivant dans la section <head> :

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=2” />
<link rel=“next” href=“http://www.website.com/duvet-covers?page=4” />

Sur la dernière page (http://www.website.com/duvet-covers?page=4), vous incluriez l’attribut suivant de lien:

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=3” />

Observez que la dernière page de la série ne comprend que le marquage rel=“prev”.

La méthode rel=”prev” rel=”next” a certains avantages, comme :

Les pages composantes gardent et distribuent une quote-part d’autorité avec les autres pages de la série.
Résolve le problème de la pagination sans ajouter l’attribut “noindex” aux pages composantes.
Consolide les propriétés de consolidation, tout comme le texte d’ancre et PageeRank, tout comme dans le cas de l’implémentation view-all. Cela signifie que dans la plupart des cas, la page d’indexation de la série apparaîtra dans les résultats de recherche en Google.
Les facteurs SEO sur la page, comme les titres, les métas-descriptions et les URLs peuvent être gardés pour les pages composantes individuelles, en comparaison avec la consolidation dans une seule page view-all.
Si le listing peut être trié dans des façons multiples en utilisant des paramètres URL, alors ces visualisations multiples « ordonnée selon » sont éligibles pour être listées en SERP. Cela n’est pas possible avec l’approche view-all.

Ce n’est pas une bonne idée de mélanger les attributs de pagination avec une page du type view-all. Si vous avez une page view-all, indiquez l’attribut rel=“canonical” sur toutes les pages composantes vers la page view-all et n’utilisez pas des attributs de pagination. Vous pouvez faire aussi une auto-référencement sur les pages de contenu pour éviter le contenu en double à la suite d’IDs de session et les paramètres de surveillance.

L’utilisation de l’attribut rel=“canonical” en même temps avec rel=“prev” et rel=“next”

Les attributs de pagination et rel=“canonical” sont des concepts indépendants et les deux peuvent être utilisés pour prévenir les problèmes de contenu en double.

Par exemple, page 2 d’une série pourrait comprendre un attribut rel=”canonical”, un attribut rel=“prev” et un autre rel=“next”:

<link rel=“canonical” href=“http://www.website.com/duvet-covers?page=2” />
<link rel=“prev” href=“http://www.website.com/duvet-covers?sessionid=1235sfsd” />
<link rel=“next” href=“http://www.website.com/duvet-covers?page=3&sessionid=1235sfsd”/>

Ce réglage informe Google que page 2 est part d’une série de pagination et que la version canonique de page 2 est l’URL sans le paramètre de sessions ID. L’URL canonique devrait faire référence à la page courante sans aucun triage, filtre, visualisation ou d’autres paramètres, mais rel=“prev” et rel=“next” devraient inclure les paramètres.

Notez que l’attribut rel=“canonical” devrait être utilisé seulement pour le contenu en double ou presque en double. Utilisez-le pour :

Des URLs avec des IDs de session.
Des URLs avec des paramètres internes de surveillance ou référence.
Le triage change l’affichage, mais non pas le contenu (par ex., le triage qui se produit d’une page à l’autre).
Des sous-sets d’une page canonique (par ex., une page view-all).

Vous pouvez utiliser aussi rel=”canonical” pour les variations de produits (respectivement, des pages PDP presque en double, qui ont la même description de produit, la seule différence étant un attribut général du produit (par ex., les mêmes chaussures mais des pointures différentes). Vous devez comprendre le marché cible avant d’appliquer l’attribut canonique et vous devez être aussi capables de sélecter le produit canonique de la collection de SKUs.

rel=“prev”, rel=“next” et les paramètres dans URLs

Même si la méthode rel=“prev” et rel=“next” semble plus avantageuse que la méthode view-all du point de vue SEO, elle présente quelques problèmes d’implémentation.

En ce qui concerne les paramètres URL, la règle sur les pages paginées est que les attributs de pagination peuvent faire un lien commun seulement pour des URLs avec des paramètres similaires. La seule exception est lorsque vous enlevez le paramètre de pagination pour la première page de la série.

Pour faire les attributs de pagination fonctionner correctement, vous devez vous assurer que toutes les pages dans le cadre d’une séquence paginée rel=“prev” et rel=“next” utilisent les mêmes paramètres.

La pagination et les paramètres de surveillance

Les URLs suivantes ne sont pas considérées une partie de la même série, parce que l’URL pour page 3 a des paramètres différents et cela rompt la chaîne:

http://www.website.com/duvet-covers?page=2
http://www.website.com/duvet-covers?page=3&referrer=twitter
http://www.website.com/duvet-covers?page=4

Dans ce cas, vous devez introduire dynamiquement les paires à valeur clé sur la base de l’URL sollicitée (fetched URL).

Si l’URL sollicitée contient le paramètre referrer=twitter (http://www.website.com/duvet-covers?page=3&referrer=twitter) alors les URLs de pagination devraient inclure dynamiquement le paramètre referrer aussi:

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=2&referrer=twitter”>
<link rel=“next” href=“http://www.website.com/duvet-covers?page=4&referrer=twitter”>

Supplémentairement, vous pouvez utiliser Google Search Console pour informer Google que ce paramètre ne change pas le contenu de la page et de faire explorer seulement les URLs représentatives (URLs sans le paramètre referrer).

La pagination et les paramètres de visualisation ou triage

Un autre scénario fréquent dans le cas de la pagination est le triage et la visualisation des listings qui couvrent plusieurs pages. Parce que chaque option de visualisation génère des paramètres URL uniques, vous devriez créer un set de pagination pour chaque visualisation.

Disons que les lignes ci-dessous sont les URLs pour « trier selon le plus nouveau », en affichant 20 produits sur page :

http://www.website.com/duvet-covers?sort=newest&view=20
http://www.website.com/duvet-covers?sort=newest&view=20&page=2
http://www.website.com/duvet-covers?sort=newest&view=20&page=3

Sur page 1 vous auriez seulement l’attribut de pagination rel=“next” qui indique vers les URLs avec les paramètres de triage et visualisation :

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=2”>

Sur page 2 vous auriez rel=“prev” et rel=”next” qui indiquent aussi vers les URLs avec les paramètres de triage et visualisation :

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=20”>
<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=3”>

Sur page 3 vous auriez seulement un attribut rel=”prev” qui renvoie aussi vers les URLs avec les paramètres de triage et visualisation :

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=2”>

Le marquage ci-dessus définit une série de pagination.

Quand même, si les utilisateurs peuvent afficher 100 produits par page, celle-ci est une nouvelle option de visualisation et créera une nouvelle série de pagination. Les nouvelles URLs ressembleront à ceci ; le paramètre view est égal maintenant à 100.

http://www.website.com/duvet-covers?sort=newest&view=100
http://www.website.com/duvet-covers?sort=newest&view=100&page=2
http://www.website.com/duvet-covers?sort=newest&view=100&page=3

Sur page 1 vous auriez seulement l’attribut de pagination rel=“next” qui renvoie vers les URLs avec les paramètres de triage et visualisation :

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=2”>

Sur page 2 vous auriez rel=“prev” et rel=”next” qui renvoient, aussi, vers les URLs avec les paramètres de triage et visualisation :

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=100”>
<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=3”>

Sur page 3 vous auriez seulement un attribut rel=”prev”, qui renvoie vers les URLs avec les paramètres de triage et visualisation:

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=2”>

Lorsque vous travaillez avec des URLs de triage, vous devez empêcher les moteurs de recherche d’indexer les options de triage bidirectionnelles, parce que le triage selon le plus nouveau est le même avec le triage selon le plus ancien, mais dans un ordre différent. Gardez un mode de base pour faire le triage accessible, par exemple « le plus nouveau » et bloquez l’autre, « le plus ancien ».

De même, en ajoutant une logique aux paramètres URL, vous ne prévenez pas seulement les problèmes liés au contenu en double, mais il aide aussi:

“à l’expérience de l’utilisateur, en maintenant un ordre constant du paramètre, sur la base des paramètres les plus importants pour les utilisateurs, listés les premiers (comme l’URL peut être visible dans les résultats de la recherche) et des paramètres les moins importants, listés les derniers (par ex., ID session). Evitez example.com/category.php?session-id=123&tracking-id=456&category=gummy-candies&taste=sour”^[30]

Assurez-vous que les paramètres ne changent pas le contenu de la page (comme les ID de session), qu’ils sont implémentés comme des paires standard de valeur clé, non pas comme répertoires. Cela est nécessaire pour que les moteurs de recherche comprennent lesquels paramètres sont utiles et lesquelles paramètres sont inutiles.

Voici quelques bonnes pratiques dans le domaine des attributs de pagination :

Même si théoriquement vous pourriez utiliser des URLs relatives pour faire référence aux attributs de pagination, vous devez utiliser des URLs absolues pour éviter les cas lorsque les URLs sont dupliquées accidentellement au long des répertoires ou sous-domaines.
Ne rompez pas la chaîne. Cela veut dire que la page N devrait envoyer vers N-1 comme page antérieure et N+1 comme page suivante (sauf la première page, qui n’aura pas l’attribut “prev” et la dernière page, qui n’aura pas l’attribut “next”).
Une page ne peut pas contenir des attributs multiples rel=“next” ou rel=“prev”.^[31]
Des pages différentes ne peuvent pas avoir les mêmes attributs rel=“next” ou rel=“prev”.

Probablement le plus grand désavantage des attributs rel=“prev” et rel=“next” est qu’ils sont difficiles à implémenter, particulièrement sur les URLs avec des paramètres multiples. De même, notez que Bing ne traite pas les relations next et prev de la même manière que Google. Même si Bing utilise le marquage pour comprendre la structure de votre site web, il ne consolidera pas les signaux d’indexation vers une seule page. Si la pagination est un problème en Bing, envisagez le blocage des pages excessives avec une directive robots.txt spécifique aux Bingbots ou une étiquette méta noindex.

La méthode des liens AJAX ou JavaScript

Avec cette méthode vous créez des liens de pagination qui ne sont pas accessibles aux moteurs de recherche, mais sont disponibles aux utilisateurs, dans le navigateur. Le compromis est que les utilisateurs qui n’ont pas JavaScript n’auront pas accès aux pages composantes. Quand même, les utilisateurs peuvent accéder une page view-all.

Les liens de pagination ne sont pas des liens HTML simples.

Dans cette image vous pouvez voir que l’interface (1) permet aux utilisateurs à trier, tout comme choisir entre la visualisation du type grille et liste. Elle permet aussi l’accès à la pagination. Quand même, le code source (2) nous révèle une implémentation JavaScript pour la pagination. Si les ressources JavaScript nécessaires pour générer ces liens sont bloquées par robots.txt, Google n’aura pas accès à ces URLs-là de pagination (3).

Cette approche a le potentiel d’éviter beaucoup de complications liées au contenu en double associées à la pagination, au triage et aux options de visualisation. Cependant, elle peut introduire des problèmes causés par l’identification des URLs.

Si vous préférez cette approche, assurez-vous que les moteurs de recherche ont au moins un autre façon d’accès à chaque produit de la liste — en utilisant, par exemple :

Une classification plus détaillée qui n’exige pas plus de 100-150 produits dans chaque liste.
Un linking interne contrôlé, qui lie tous les produits aux autres pages, d’une manière conviviale SEO.
Sitemaps HTML bien structurés, à côté de XML Sitemaps.
D’autres types de liens internes.

Scrolling infini

Une alternative fréquente de design pour l’interface de l’utilisateur en ce qui concerne la pagination est le scrolling infini (infinite scrolling).^[32] Connu aussi sous le nom de scrolling continuel (continuous scrolling), la méthode permet aux utilisateurs de visualiser le contenu à mesure qu’ils scrollent vers le bas de la page, sans qu’ils doivent cliquer sur les liens de pagination. Visuellement, cette alternative semble similaire à l’affichage de tous les produits sur une seule page. Quand même, la différence entre le scrolling infini et une page view-all est que dans le cas du scrolling infini le contenu est chargé à demande (par exemple, en cliquant sur le bouton « charger plus de produits » ou lorsque le contenu devient visible au-dessus de la ligne médiane), tandis que sur une page du type view-all le contenu est chargé complètement une seule fois.

Les sites web mobiles utilisent le scrolling infini plus, parce qu’il est plus facile de glisser sur l’écran que de cliquer. Cependant, le scrolling infini est basé sur le chargement progressif par AJAX,^[33] ce que signifie que vous devrez quand même assurer des liens aux ULRs composantes pour les moteurs de recherche ou pour les utilisateurs sans JavaScript actif. Vous pouvez faire cela à l’aide d’amélioration progressive (progressive enhancement).

En ce qui concerne le SEO, le scrolling infini ne résout pas les problèmes de pagination pour les grands stocks de produits et cela est l’une des raisons pourquoi Google suggère la pagination des scrolls infinis.^[34]

Le conseil de Google est OK, mais je ne suis d’avis que le scrolling continuel a besoin de pagination si vous n’avez pas trop de produits sur un listing ; une page du type view-all avec 200 produits est préférable dans beaucoup de cas. Pourtant, les pages qui listent plus de 200 produits et utilisent le scrolling infini devraient rétrograder à des liens de pagination HTML simples pour les utilisateurs non-JavaScript et cela n’inclut pas les robots des moteurs de recherche.

La rétrogradation aux liens HTML signifie que les moteurs de recherche peuvent encore rencontrer des problèmes à la pagination, donc vous devrez gestionner la pagination en utilisant l’une des méthodes décrites ci-dessus.

Cette image décrit la version cache d’une page de sous-catégorie qui utilise le scrolling infini et rétrograde aux liens HTML pour la pagination lorsque les utilisateurs n’ont pas activé JavaScript.

Sur la page des captures d’écran antérieures il y a des liens pour les pages Previous et Next pour les utilisateurs sans JavaScript actif (ou pour les moteurs de recherche).

Celle-ci est une image de la même page, mais cette fois le JavaScript est actif. Les liens Previous et Next n’apparaissent pas. Cela a été possible en masquant la section de pagination par CSS et JavaScript. Les utilisateurs peuvent presser continuellement sur le scroll pour voir tous les montres.^[35]

Le scrolling continuel a plusieurs avantages, tout comme une expérience meilleure pour les utilisateurs sur les dispositifs tactiles, une navigation plus rapide en éliminant le rechargement des pages, une identification meilleure des produits et la consolidation des liens externes.

Quand même, il y a aussi des désavantages,^[36] et le scrolling infini ne fonctionne bien sur tous les sites web.

Par exemple, sur Etsy – un site d’e-commerce pour des produits d’époque et artisanaux – le scrolling infini n’a pas eu le résultat économique souhaité, donc ils sont revenus à la pagination classique.^[37] Le scrolling infini a conduit à un nombre plus faible de clics de la part des utilisateurs, parce qu’ils se sentaient perdus dans un océan de produits et il était difficile pour eux de trier les produits selon leur relevance.

Cependant, sur d’autres sites web, le scrolling infini peut fonctionner bien, comme cette étude l’a démontré.^[38]

Tout comme il est valable pour la majorité des idées pour un site web, un test A/B peut vous indiquer si l’élimination de la pagination est utile ou non pour les utilisateurs.

Si vous planifiez à tester le scrolling infini, voici quelques idées :

Affichez des indices visuels lorsque plus de contenu est chargé.

Non pas toutes les connexions sont assez rapides pour charger le contenu en un clin d’œil. Si votre serveur ne peut pas faire face au scrolling rapide des utilisateurs ou si les navigateurs sont lents, informez l’utilisateur que plus de contenu vient d’être affiché.

Observez le message Loading More Results en bas de la liste. Il informe les utilisateurs que plus de contenu est chargé.

Envisagez une solution hybride

Une solution hybride combine le scrolling et la pagination. Avec cette approche, vous afficheriez un bouton « montrer plus de résultats » au final d’une liste préchargée. Sur le mobile, ce bouton doit être plus grand, pour combattre le syndrome des doigts gros^[39]. Lorsque le bouton est pressé, une autre série de produits est chargée :

Dans cet exemple, on charge plusieurs paires de chaussures avec AJAX seulement lorsque les utilisateurs cliquent sur le bouton « montrer plus de résultats ».

Ajoutez des repères pour scrolling

Amazon utilise une pagination horizontale dans ce widget pour les produits, pour aider les utilisateurs se faire une idée sur le nombre de pages dans ce carrousel:

Vous pouvez voir la pagination horizontale pour ce carrousel en haut à droite de l’image.

Pour le scrolling vertical, l’addition de repères, tout comme des numéros virtuels sur la page, peut offrir aux utilisateurs une idée sur la distance parcourue et peut aider à la création de références mentales (par ex., « J’ai vu un produit qui m’a plu quelque part sur page 6 »).

Cette capture d’écran a été modifié pour exemplifier un repère de navigation (la règle horizontale et le texte “Page 2”).

Actualisez l’URL lorsque les utilisateurs défilent vers le bas de la page

Ceci est un concept intéressant qui mérite être investigué. Vous pouvez ajouter automatiquement un paramètre de pagination à l’URL lorsque les utilisateurs défilent au-delà d’un certain nombre de lignes.

Ce concept est expliqué le meilleur à l’aide d’un matériel vidéo, donc j’ai fait une courte capture d’écran pour l’illustrer si la page originale^[40] devient indisponible.

Si vous avez généralement 200 produits ou moins dans vos listings, il vaut mieux charger tous les produits une seule fois. Ainsi vous exposerez tout aux moteurs de recherche, comme une seule page du type view-all. C’est l’implémentation préférée par Google pour éviter la pagination.

Bien sûr, les utilisateurs verront 10 10 ou 20 produits une fois et vous pouvez retarder le chargement des autres produits dans l’interface. Quand même, vous utiliseriez des données du code HTML chargé déjà. Ainsi vous pouvez éviter beaucoup de problèmes avec la pagination. En fonction de l’autorité de votre site web, vous pouvez avoir même plus de 200 produits par listing.

Si la liste est immense, probablement vous devrez la paginer. Mais, même alors, vous pouvez envisager une page view-all.

Ajoutez la navigation filtrée

Les grandes séries devraient être accompagnées par la navigation filtrée pour permettre aux utilisateurs de réduire les produits de la liste à la base des attributs des produits. De même, utilisez la navigation par des sous-catégories pour permettre aux utilisateurs un accès plus profond dans la hiérarchie du site web.

Les filtres peuvent réduire les produits d’une liste de quelques centaines à quelques dizaines ou moins.

La page listing antérieure a 116 produits, mais si vous les filtrez par marque (Brand=Samsung), la liste se réduit à 52 produits. Si vous filtrez par Color ou Finish Family, la liste se réduit à 9 produits.

Si le scrolling infini produit des résultats meilleurs pour vos utilisateurs et revenus, c’est probablement une bonne idée de l’implémenter. Mais faites-le fonctionner pour les utilisateurs sans JavaScript, enlevez la pagination de la part du client et implémentez le scrolling infini pour les utilisateurs avec JavaScript actif.

La navigation secondaire

Sur les pages listings, la navigation primaire est toujours supplémentée par une sorte de navigation auxiliaire. On l’appelle navigation secondaire.

Je vais faire référence à la navigation secondaire comme cette navigation-là qui assure l’accès aux catégories, sous-catégories et produits localisés plus profondément dans la taxonomie. Sur les sites web d’e-commerce, ce type de navigation est affiché, généralement, sur la barre latérale gauche.

La navigation secondaire peut apparaitre très près de la navigation primaire (soit en haut de la page soit sur la barre latérale gauche).

Dans beaucoup de cas, la navigation secondaire liste des sous-catégories, attributs des produits ou des filtres pour les produits.

L’entière section de la gauche est considérée navigation secondaire ; elle inclut des sous-catégories comme des filtres, noms de filtres et valeurs des filtres.

Contrairement à la navigation primaire, les étiquettes de la navigation secondaire peuvent se changer d’une page à l’autre pour aider les utilisateurs à naviguer plus en profondeur dans la taxonomie du site web. Ce changement de liens dans le menu de navigation est probablement la distinction la plus importante entre la navigation primaire et la navigation secondaire.

Du point de vue SEO, il est important de créer une navigation en fonction de catégories. Ainsi, vous offrez aux utilisateurs des informations plus pertinentes, vous assurez des routes d’exploration pour les catégories et vous donnez aux moteurs de recherche des indices meilleurs regardant la taxonomie.

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML1571d101.PNG$

Prenons Amazon, pour exemple. Lorsque vous vous trouvez dans le département Books du site web, toute la navigation est liée aux livres.

La navigation facettée (appelée aussi navigation filtrée)

Les sites d’e-commerce sont souvent remplis en excès, en affichant trop d’informations à retenir et trop de produits dont les utilisateurs doivent choisir. Cela conduit à un excès d’informations et induit la paralysie du choix (choice paralysis).^[41] Il est essentiel, alors, que vous offriez aux utilisateurs une manière plus facile de naviguer à travers des grands catalogues de produits. C’est ici que la navigation facettée (ou ce que Google appelle filtration supplémentaire ou additive filtering) joue un rôle important.

Indépendamment du fait que les utilisateurs cherchent quelque chose très spécifique ou seulement visitent le site web, les filtres peuvent être extrêmement utiles. Ils aideront les utilisateurs à localiser les produits sans utiliser la recherche interne du site ou la navigation primaire qui, dans la plupart des cas, ne montre qu’un nombre limité d’options pour les utilisateurs.

La navigation facettée permet aux utilisateurs de trouver plus facilement ce qu’ils cherchent, en réduisant les listings de produits sur la base des filtres prédéfinis, sous la forme des liens cliquables. Les experts en opérabilité décrivent la navigation facettée comme :

“probablement l’innovation la plus significative dans le domaine de la recherche dans la dernière décennie”.^[42]

La navigation facettée a presque toujours un impact positif sur l’expérience des utilisateurs et sur les paramètres de l’affaire. Un commerçant a observé :

“une augmentation de 76,1% des revenus, une augmentation de 26% des conversons et une augmentation de 19,76% des visites de la page avec le panier d’achat à la suite d’un test A/B après l’implémentation de la filtration sur ses pages listings”.^[43]

Cette capture d’écran montre un design habituel pour la navigation facettée:

$C:\Users\traiann\AppData\Local\Temp\SNAGHTML29552d11.PNG$

Un exemple d’interface pour la navigation facettée.

On remarque fréquemment que la navigation facettée est présente dans la barre latérale gauche, mais elle peut être affichée aussi en haut des listings de produits, en fonction du nombre de filtres de chaque catégorie. Dans plusieurs cas, les sous-catégories sont incluses aussi dans la navigation facettée.

Les filtres, les valeurs des filtres et les facettes ont une signification différente.

Les filtres représentent un groupe d’attributs des produits. Dans cette image, Styles, Women’s Size, Women’s Width sont les filtres.
Les valeurs des filtres sont les options sous chaque filtre. Pour le filtre Styles, les valeurs des filtres sont Comfort, Pumps, Athletic, et ainsi de suite.
Les facettes sont des visualisations générées par la sélection d’un filtre ou une combinaison de valeurs des filtres. Le choix d’une valeur du filtre Women’s size et d’une valeur du filtre Women’s width crée ce qu’on appelle une « facette ».

Le choix d’une valeur ou de plusieurs valeurs génère ce qu’on appelle une facette.

La navigation facettée est une bénédiction pour les utilisateurs et les taux de conversion, mais peut générer un labyrinthe immense pour les robots de recherche. Les principaux problèmes posés par la navigation facettée sont :

Contenu en double ou presque en double
Des pièges d’exploration.
Contenu non-essentiel, thin.

Si vous avez reçu un message sur Google Search Console comme le message ci-dessus, la navigation facettée est l’une des causes possibles.

Il n’y a pas un meilleur exemple pour la manière dont la filtration peut créer des problèmes que celui offert même par Google. La navigation facettée sur googlestore.com – à côté d’autres types de navigation, tout comme les options de triage et visualisation – a généré 380.000 URLs.^[44] Notez de plus qu’il s’agit d’un site web qui ne vend que 158 produits.

Si vous êtes curieux d’apprendre combien d’URLS peut générer la navigation facettée pour une page listing de produits, vous pouvez utiliser la formule suivante pour calculer les permutations possibles (sans la répétition permise) :

P = n!/r!(n-r)!

Dans cette formule, n est le nombre total de valeurs des filtres qui peuvent être appliquées, et r est le nombre total de filtres. Par exemple, disons que vous avez deux filtres :

Le filtre Styles, avec cinq options de filtration
Le filtre Materials, avec neuf options de filtration

Dans ce cas, n sera 14, ce que signifie le nombre total d’options de filtrations et r sera 2, parce que nous avons deux filtres. Ce réglage pourrait générer théoriquement 91 URLs.^[45]

Si vous ajoutez un autre filtre (par ex., le filtre Color), et ce filtre a 15 options de filtration, n devient 29 et r est égal à 3. Ce réglage va générer 3.654 URLs uniques.

Comme nous avons mentionné déjà, la formule ci-dessus ne permet pas des URLs répétitives. Cela signifie que si les utilisateurs choisissent (style = comfort ET material = suede) ils reçoivent les mêmes résultats que pour (material = suede ET style = comfort), pour la même URL. Si vous n’implémentez pas un ordre pour les paramètres URL, alors la navigation facettée générera 182 liens pour l’exemple avec 2 filtres et 21.924 URLs pour les exemples avec trois filtres appliqués.

La différence immense entre le nombre total de pages indexées et le nombre de pages explorées à n’importe quel moment indique un possible problème d’exploration ou un problème grave de qualité du contenu.

Voyez-vous combien d’URLs génère le paramètre price?!

Dans l’image antérieure, le problème a été identifié et confirmé par la vérification du rapport de paramètres URL de Google Search Console. Le grand nombre d’URLs a été créé par le filtre Price, qui a généré 5,2 millions URLs.

Vous pouvez résoudre partiellement les problèmes liés au contenu en double généré par la navigation facettée en forçant un ordre strict pour les paramètres URL, indépendamment de l’ordre de sélection des filtres. Par exemple, Category pourrait être le premier filtre choisi et Price le deuxième. Si un utilisateur (ou un robot) choisit le filtre Price pour la première fois et puis le filtre Category, procédez de telle manière que le filtre apparaisse le premier en URL, suivi par Price.

Dans l’URL ci-dessus, même si la valeur du filtre cherry a été choisie après double door, sa position en URL est basée sur un ordre prédéfini.

Le même ordre est reflété dans les breadcrumbs:

Si vous avez besoin d’un breadcrumb qui reflète l’ordre de la sélection de l’utilisateur, vous pouvez stocker l’ordre dans un cookie de session et non pas dans une URL.

Un autre problème de contenu presque en double apparait lorsque l’une des options de filtration présente presque les mêmes produits que la visualisation sans filtration. Par exemple, la visualisation pour Ski & Snowboard Racks comprend un nombre total de 15 produits et vous pouvez réduire les résultats en utilisant deux sous-catégories : Hitch Mount et Rooftops.

L’image ci-dessus est la page listing pour les produits Ski & Snowboard Racks.

Quand même, la sous-catégorie Rooftop Ski Racks & Snowboard Racks inclut 13 résultats sur la page non filtrée. Cela signifie qu’à l’exception de deux produits, la page filtrée et la page non-filtrée sont presque en double.

Rooftop Ski Racks & Snowboard Racks.

La navigation facettée présente un avantage significatif contre la navigation hiérarchique : les combinaisons de filtres généreront des pages qui ne pourraient pas exister dans une hiérarchie du type arbre, parce que celles-ci sont rigides et ne peuvent pas couvrir toutes les combinaisons possibles générées par la navigation facettée. La structure hiérarchique est bonne, pourtant, pour les décisions à un niveau plus haut.

Disons que vous vendez des bijoux et vous souhaitez un meilleur classement pour la recherche « pendentifs carrés en platine » (“square platinum pendants”). La hiérarchie de votre site web sépare les bijoux seulement selon leur type, comme pendentifs, bracelets etc. et puis permet la filtration basée sur le filtre Material, avec des valeurs comme platine, or etc. Si vous n’avez pas le filtre de forme (Shape) pour lister l’option « carré », le site web n’aura pas une navigation facettée pour “square platinum pendants”.

Pourtant, si vous introduisiez le filtre Shape sur la page listing de Platinum Pendants, cela vous permettra de générer la facette Square Platinum Pendants, qui réduit l’inventaire sur la base de la valeur « carré » du filtre. Cette page est pertinente pour les utilisateurs et les moteurs de recherche. Vous pouvez optimiser davantage cette page avec du contenu personnalisé et des aspects visuels, pour la faire plus attractive pour les robots de recherche et les utilisateurs.

Un filtre supplémentaire – Shape – permettra de cibler plusieurs mots-clés du type torso et long-tail.

S’il n’y a pas un filtre Shape pour générer la facette Square Platinum Pendants et s’il n’y existe aucune navigation hiérarchique pour conduire vers une telle page, vous devrez créer manuellement une page qui cible la recherche “square platinum pendants”. Puis vous devrez faire un lien interne et externe vers cette page pour que les moteurs de recherche puissent la découvrir. Selon la dimension de votre catalogue de produits, il serait pratiquement impossible de créer manuellement des milliers ou même millions de telles pages.

Filtres essentiaux, importants et overhead

Avant de discuter la manière d’approche de la navigation facettée d’une perspective SEO, il est important de classifier les filtres et les facettes en trois types : essentiaux, importants et overhead (en excès).

Facettes/filtres essentiaux

Les filtres essentiaux généreront des pages de destination qui ciblent des mots-clés compétitifs, avec des grands volumes de recherche, qui sont généralement des termes du type « head » ou « torso ». Si votre navigation facettée liste des sous-catégories, ces facettes sont essentielles et s’appellent des sous-catégories facettées.

Dans cet exemple, Bags, Wallets, et les autres sous-catégories sont des filtres essentiaux. Vous devez toujours permettre aux moteurs de recherche d’explorer et indexer ces filtres.

Les facettes essentielles peuvent être aussi générées par une combinaison de valeurs des filtres sous Brand + Category—par exemple, en utilisant la valeur de filtre “Nokia” pour Brand et la valeur de filtre “Cameras” pour Category.

Category, tout comme Brand, peuvent être considérées des facettes, parce qu’elles fonctionnent comme filtres pour des sets plus grands de données.

Vous pouvez choisir manuellement les combinaisons de top des filtres essentiaux qui précieuses pour les utilisateurs et votre affaire. Transformez-les dans des pages indépendantes, en ajoutant du contenu et en les optimisant comme vous le feriez avec chaque page importante. C’est un procès largement manuel, parce qu’il impose la création de contenu, donc il est réalisable seulement pour un nombre limité de pages.

Quand même, si vous faites cela régulièrement et si vous allouez des ressources pour la création de contenu, vous auriez un avantage contre la concurrence. Commencez avec les plusieurs importantes 1%s des facettes et avancez graduellement. Si vous faites quelques pages par jour (vous n’avez pas besoin que de 100 – 150 mots bien choisis), après un an vous auriez optimisé de centaines de pages filtrées.

Toutes les pages facettes essentielles devraient avoir des titres et descriptions uniques. Idéalement, les titres devraient être personnalisés, lorsque les descriptions peuvent être du type boilerplate.

Assurez-vous que les moteurs de recherche peuvent découvrir les liens vers les filtres et facettes essentielles. De fait, les filtres essentiaux doivent avoir des liens des vos pages riches en contenu, tout comme les articles de blog ou les guides d’utilisation. Pour un transfert maximal d’autorité, faites un lien de la zone du contenu principal de telles pages.

La structure URL pour les facettes essentielles devrait être propre. Idéalement, elle devrait refléter, soit partiellement, soit exactement, la hiérarchie du site web dans une structure du type répertoire ou une convention des noms des fichiers :

L’URL pour la facette de la sous-catégorie Bathroom Accessories est sans des paramètres et reflète la hiérarchie du site web.

Facettes/filtres importants

Ces améliorations conduiront les utilisateurs et les moteurs de recherche vers les pages de destination qui peuvent entrainer du trafic pour les mots-clés du type „torso” et „long-tail”.

Par exemple, si vos données analytiques montrent que le marché cible cherche des « chaussures confort rouges », cela signifie que les URLs générées par la sélection Color + Style sont des facettes importantes pour votre affaire. Les moteurs de recherche devraient avoir accès aux URLs des facettes importantes.

Vous devriez vous décider laquelle facette et importante ou non, préférablement à partir d’une catégorie ou sous-catégorie. Par exemple, le filtre Color peut être pertinent pour la sous-catégorie Shoes, mais il sera un filtre overhead pour la sous-catégorie Fragrances.

Un cas particulier que vous devez prendre en considération est le filtre Sales ou Clearance. Dans l’exemple ci-dessous, le commerçant liste toutes les facettes pour tous les produits en liquidation totale.

Les filtres de navigation de gauche ci-dessus n’aident pas trop les utilisateurs parce que les Tapis (Rugs) n’ont pas des manches (sleeves), Les raquettes (snowshoes) n’ont pas un style chemise (shirt style), et les Pulls (Pullovers) n’ont pas comme style des bâtons de ski (ski pole style).

Au lieu de lister des produits, ce commerçant devrait lister seulement les sous-catégories dans la navigation à la gauche et la zone du contenu principal. Ainsi, les utilisateurs vont gestionner mieux la nature ambiguë de la page Liquidation des stocks (Clearance) en choisissant d’abord une catégorie qui les intéresse. One fois la catégorie désirée est choisie, le commerçant devrait afficher les filtres qui s’appliquent à cette catégorie-là.

Selon la manière dont votre marché cible fait les recherches en ligne, il est recommandé d’empêcher les moteurs de recherche d’accéder les URLs générées lorsque plus de deux valeurs de filtration ont été appliquées. Si l’un des filtres appliqués est un filtre essentiel, vous allez les bloquer lorsque trois filtres ont été appliqués.

Cela fonctionne le mieux avec des sélections multiples sur le même filtre (par ex., Brand = Acorn ET Brand = Aerosoles) parce qu’il est moins probable que les utilisateurs cherchent des modèles comme “{brand1} {brand2} {category}” (par ex., “Acorn Aerosoles shoes”).

La capacité de sélecter des valeurs multiples du filtre est utile pour les utilisateurs qui pourraient choisir Red ET Blue Shirts, mais elle n’est pas utile pour les moteurs de recherche. Donc, de telles sélections peuvent être bloquées pour les robots.

Un exemple de sélections multiples sur le filtre Brand.

Notez que le blocage de l’accès aux URLs de la navigation facettée comme réglage de base chaque fois qu’on applique des filtres multiples empêchera les robots de découvrir les pages créées par les sélections d’une seule valeur aux filtres différents (par ex., Color = red ET Style = comfort). Vous perdrez du trafic pour un grand nombre de combinaisons de filtres (si vous ne créez et optimisez pas manuellement les pages de destination pour tous les filtres et facettes importantes et si vous ne permettez aux robots d’explorer et indexer ces pages-là).

Laissez les données décider lorsque vous choisissez lesquelles facettes vous devrez laisser ouvertes pour les moteurs de recherche. Recueillez des données des sources différentes et puis remplacez à l’aide d’un logiciel les mots-clés avec les valeurs de leurs filtres, quand il est nécessaire. C’est un processus très similaire à la technique d’Etiquetage et Classification décrite dans la section Architecture du site web. Vous devez identifier des modèles et voir quelles facettes sont utilisées plus souvent par vos utilisateurs. Sur votre plateforme d’e-commerce, marquez les filtres importants et permettez leur indexation.

La structure URL pour les facettes importantes doit être aussi propre que possible. Il est OK de garder les valeurs du filtre dans un répertoire ou dans la structure file path. Il est OK, aussi, de les garder dans des paramètres URL, aussi longtemps que vous n’utilisez plus de deux ou trois paramètres.

Lorsqu’on applique un filtre important, sa valeur est attachée à l’URL, sous la forme d’un répertoire. Dans cette URL, la valeur du filtre est kohler, sous le filtre Brand.

Dans la mesure du possible, évitez la codification URL non-standard – tout comme les virgules ou parenthèses – pour les paramètres URL.^[46]

Souvent, les moteurs de recherche traitent les pages créées par les filtres comme des sous-ensembles de la page non-filtrée. Pour éviter être poussés dans l’indice supplémentaire, vous devez créer des titres, descriptions, breadcrumbs, entêtes uniques et du contenu personnalisé sur ces pages filtrées. Les titres et descriptions du type boilerplate peuvent être acceptables, mais ne répétez pas le titre de la visualisation non-filtrée sur les pages facette. La visualisation non-filtrée peut être sur la page view-all ou la page d’indexation, si vous avez implémenté la pagination avec l’attribut rel=“prev”/next.

En outre, les breadcrumbs, tout comme les entêtes, doivent s’actualiser pour refléter la sélection de l’utilisateur. Il peut sembler évident, mais il est incroyable de voir le nombre de sites web d’e-commerce qui ne font pas cela.

Une technique qui peut être utile pour augmenter la relevance de chaque page filtrée et pour diminuer les problèmes liés au contenu en double est d’écrire des descriptions du produit qui incluent les valeurs du filtre utilisées pour générer la page. Lorsqu’un utilisateur choisit une valeur sous le filtre Material, le snippet avec la description du produit comprendrait la valeur du filtre.

La page PLP ci-dessus filtre les SKUs selon material = white gold. La description du produit quick view pour le deuxième article inclue intelligemment les mots “white” et “gold”.

Ce snippet quick view diffère de la description du produit sur la page avec des détails sur les produits :

La section (1) est le snippet quick view, la section (2) la description complète du produit.

La section (1) de l’image ci-dessus nous montre le snippet avec la description quick view du produit sur la page listing de produits. Comme vous pouvez voir, le snippet a été créé attentivement pour inclure toutes les valeurs importantes du filtre. La section (2) présente la description du produit sur la page avec des détails sur les produits. Ces deux descriptions de produits sont différentes.

Ecrire des snippets pour des produits personnalisés sur les pages listing est une tactique SEO très efficace lorsque vous ne présentez que 20-25 mots pour chaque produit. Pourtant, il est difficile d’écrire de tels snippets lorsque vous avez des milliers de produits. Une alternative serait d’écrire les descriptions détaillées des produits pour inclure les valeurs des filtres les plus importants au commencement ou à la fin de la description détaillée du produit et puis d’extraire automatiquement et afficher la première/dernière proposition sur la page listing de produits.

Une autre méthode d’augmenter la relevance des pages listing générées par les facettes importantes est d’ajouter les valeurs du filtre sélecté sur le listing du produit, à la volée. Cependant, vous pouvez faire du spam facilement si vous n’êtes pas attentifs. Si vous choisissez cette approche, assurez-vous que vous avez des règles d’implémentation pour éviter l’utilisation en excès des mots-clés (keyword stuffing).

Les filtres overhead

Ces filtres génèrent des pages avec un volume de recherche minimal ou égal à zéro. Tout ce qu’ils font est de gaspiller le budget d’exploration sur des URLs non-pertinentes. Un exemple classique de filtre overhead est Price; dans beaucoup de cas, le filtre Size aussi. Quand même, notez qu’un filtre peut être overhead pour une affaire mais important ou même essentiel pour une autre.

Vous devriez empêcher les moteurs de recherche d’explorer les URLs générées sur la base des filtres overhead et marquer les filtres comme overhead dans chaque catégorie. Chaque fois qu’une combinaison de filtres inclue une valeur overhead, ajoutez le méta-tag “noindex, follow” à la page générée et attachez le paramètre crawler=no à son URL. Bloquez puis le paramètre crawler avec robots.txt.

La directive de robots.txt empêchera le gaspillage du budget d’exploration, lorsque le méta-tag noindex empêchera l’apparition des snippets vides en SERP. Si vous avez des pages dans l’index que vous devez enlever, implémentez d’abord “noindex, follow” et attendez que les pages soient éliminées de l’index. Une fois éliminées, attachez le paramètre de contrôle de l’exploration des URLs.

Faites attention à la combinaison de robots.txt et le méta tag noindex , parce que robots.txt ne permettra l’accès des robots à la directive au niveau de page et noindex est une directive au niveau de page. Si le site web n’a pas un problème d’indexation ou d’exploration, vous pouvez envisager l’implémentation de rel=“canonical” au lieu de robots.txt.

De même, vous pouvez utiliser AJAX pour générer du contenu pour les facettes overhead d’une manière qui ne change pas les URLs, donc les moteurs de recherche ne solliciteront inutilement de contenu. Dans ce cas, vous devez bloquer les scripts (et toutes les autres ressources nécessaires pour les appels AJAX) avec robots.txt. Cela empêchera les moteurs de recherche de rendre les liens AJAX.

Si vous voulez dégrader le code pour les utilisateurs avec JavaScript désactivé, vous pouvez utiliser des paramètres URL qui peuvent être placés soit après le signe (#) soit dans une chaîne URL bloquée avec robots.txt. Quand même, les plus strictes restrictions d’exploration viennent du processus de rendu des URLs overhead indisponibles pour les robots.

Observez comment l’URL ci-dessus comprend la chaîne NCNI-5 au final.

La chaîne NCNI-5 est utilisée pour le contrôle des robots, parce que toutes les URLs qui comprennent la chaîne NCNI-5 sont bloquées avec robots.txt:

Disallow: /*NCNI-5*

Pour synthétiser, voilà comment Home Depot définit les URLs filtrées pour tous les trois types de facettes :

Chaque filtre/facette est traité différemment, en fonction de son importance.

L’URL pour la facette essentielle comprend un nom propre de catégorie. L’URL pour la facette importante inclut le nom de la catégorie et la valeur du filtre, kohler. L’URL pour la facette overhead – bien qu’elle englobe le nom de la catégorie et la valeur du filtre, comprend aussi la chaîne de contrôle d’exploration, NCNI-5.

Ce n’est pas une bonne idée de réécrire les URLs pour faire les filtres overhead similaires aux URLs statiques. L’exemple suivant d’URL inclut le filtre overhead Price, avec les valeurs 50 – 100.

http://www.homedepot.com/b/Bath-Bathroom-Accessories-Hardware-Bathroom-Accessories/KOHLER/N-5yc1vZbz99Z1qh/Price/50-100

L’URL n’existe pas sur le site web Home Depot; nous avons ajouté la part avec /Price/50-100 seulement pour exemplifier. La génération des URLs conviviales avec les moteurs de recherche ne change pas le fait qu’il existeront de millions de pages non-pertinentes sur le site web.

En ce qui concerne la capacité de l’URL d’être découverte, les moteurs de recherche ne doivent pas trouver les liens qui font référence aux filtres ou facettes overhead. En fait, vous devez empêcher les moteurs de recherche de découvrir les facettes overhead.

Si vous devez permettre aux moteurs de recherche d’explorer les facettes overhead, gardez les filtres dans des paramètres en utilisant la codification HTML standard et des paires key=value au lieu de répertoires. Cela aidera les moteurs de recherche à faire la différence entre des valeurs utiles et valeurs inutiles.

La navigation facettée : étude de cas

J’ai cherché sur Google “Canon digital cameras” et Overstock est apparu sur la première page, OfficeMax sur la cinquième et Target sur la septième.

L’approche d’Overstock regardant la navigation filtrée

L’image ci-dessus est la page de sous-sous-catégories Digital Cameras filtrée selon Brand = Canon. Elle a un titre unique, des breadcrumbs personnalisés et un entête H1 pertinent. De même, cette page utilise une bonne méta description. Ces éléments transmettent des signaux de qualité aux moteurs de recherche.

Lorsque les utilisateurs filtrent les SKUs selon une autre marque (par ex., Sony), les éléments de la page s’actualisent. S’ils n’étaient pas actualisés, la page Canon Digital Cameras aurait eu le même H1, la même description et les mêmes breadcrumbs, ce qui n’est pas désirable.

En outre, Overstock permet l’exploration pour les filtres essentiaux et importants et ne crée pas des liens pour les filtres gray-end (filtres qui génèrent des résultats zéro).

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML1ae667cc.PNG$

La valeur du filtre “10 Megapixels” génère zéro résultats. Donc, il n’a pas un hyperlien.

L’implémentation de la navigation facettée par Overstock est conviviale du point de vue SEO, parce qu’elle permet aux robots d’accéder de différentes pages filtrées et actualise les éléments de la page sur la base de la sélection de l’utilisateur ou robot de recherche.

Une courte observation sur les valeurs des filtres gray-end. Quoique vous choisissiez de faire avec ces valeurs des filtres dans l’interface (par ex., de ne les montrer pas, de les montrer à la fin de la liste de filtration ou de les cacher derrière le lien « voir plus »), les filtres gray ends de devraient pas avoir un hyperlien. Si vous devez faire un hyperlien pour n’importe quelle raison, le code de réponse pour des résultats zéro devrait être 404. Si une réponse 404 n’est pas possible, marquez les pages avec “noindex, follow”. Alternativement, vous pouvez utiliser robots.txt pour bloquer les URLs qui génèrent des résultats zéro.

L’approche d’OfficeMax vers la navigation facettée

L’image ci-dessus décrit la page PLP Digital Cameras d’OfficeMax.

Le titre, la description et les breadcrumbs ne s’actualisent pas lorsque l’utilisateur choisit une valeur de filtre sous le filtre Brand. Cela signifie que de milliers de pages filtrées auront des éléments SEO sur la page très similaires à la page non-filtrée. Même si les produits sur chaque page filtrée changeront, les moteurs de recherche obtiendront plusieurs signaux méta-tag presque en double.

Cette « impasse » pourrait faire Google n’indexer pas la page facettée qui résulte à la suite de la filtration Canon. La page qui se classifie pour “Canon digital cameras” sur le site d’OfficeMax est la page de catégories Digital Cameras. Celle-ci n’est pas la page idéale de classifier, parce qu’elle ne correspond pas à l’intention de l’utilisateur derrière la recherche. La filtration selon Brand=Canon signifie que les utilisateurs doivent faire un pas supplémentaire, inutile.

Sur la version cache de la page Digital Cameras nous observons que la navigation facettée n’existe pas. Cela arrive parce que la navigation facettée n’est pas accessible aux moteurs de recherche.

La navigation facettée n’est pas accessible aux moteurs de recherche.

Une courte observation ici : si les liens manquent de la version cache, Google pourrait encore les trouver lorsqu’il rende la page comme il le faisait dans le navigateur.

Peut-être OfficeMax a essayé de réparer certains problèmes de supra-indexation ou un possible filtre Panda pour les pages avec contenu faible (thin). Quand même, cette implémentation de la navigation facettée n’est pas optimale, parce qu’elle bloque complètement l’accès à toutes les pages filtrées. Si OfficeMax ne crée pas manuellement des pages de destination pour toutes les pages filtrées importantes, ils ont fermé la porte aux moteurs de recherche et au trafic que ces pages pourraient apporter.

L’approche Target vers la navigation facettée

Tout comme OfficeMax, Target ne crée pas des signaux de relevance pour les pages filtrées.

Sur le site web Target, le titre de la page, breadcrumbs, l’entête et la description pour leur page Canon Digital Cameras sont les mêmes comme sur la page non-filtrée, Digital Cameras. De fait, les éléments ci-dessus mentionnés seront les mêmes sur des dizaines ou milliers d’autres possibles pages filtrées.

De plus, parce que la page a une référence canonique vers la page non-filtrée, sa capacité de se classifier est (théoriquement), zéro. A cause de cette approche, j’ai cru qu’ils auraient une page Canon Digital Cameras qui puisse être accédée de la navigation ou d’une autre page. S’ils en avaient une, Google n’a pas réussi à l’identifier.

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML1b5e8417.PNG$

Google n’a pas pu trouver une page de catégories (ou au moins une URL facette) pertinente pour Canon Digital Cameras. Tous les résultats pertinents étaient des PDPs.

La version Google cache de la page nous montre que la navigation facettée ne crée pas des liens :

Parce que Brand est un filtre important et parce que dans notre exemple nous avons utilisé une seule valeur de filtre, sous Brand il faudrait être des liens HTML simples.

Les catégories dans la navigation facettée

La navigation hiérarchique, basée sur des catégories, est utile assez longtemps qu’il est facile pour les utilisateurs de choisir entre les catégories. Par exemple, il serait plus utile pour les utilisateurs si certaines sous-catégories pour lesquelles une décision pourrait être prise facilement seraient listées dans la zone principale de contenu, contre l’affichage comme sous-catégories facette dans la barre latérale. On devrait utiliser des pages listing des sous-catégories :

“chaque fois que la navigation ultérieure est nécessaire, ou la définition de la sphère en avant, c’est une bonne idée d’afficher une liste avec les produits pour les utilisateurs. Généralement, les pages de sous-catégorie ont la plus grande logique dans le premier ou dans les premières couches de la hiérarchie, où la sphère est trop grande pour produite une liste utile de produits”.^[47]

Cette catégorie affiche le niveau suivant de catégories de la hiérarchie dans la zone principale de contenu.

Dans l’image antérieure, la navigation facettée (présente généralement dans la navigation à la gauche comme des options de filtration) n’est pas introduite encore à ce niveau de la hiérarchie (le niveau des catégories), même pas au niveau des sous-sous-catégories.

Dans l’exemple suivant, vous pouvez voir la manière dont la navigation sur la base de catégories finit au troisième niveau de la hiérarchie ; le premier niveau est la catégorie Décor, le deuxième niveau est Blinds & Window Treatments, et le troisième niveau est Blinds & Shades.

La navigation facettée n’est pas affichée qu’au troisième niveau de la hiérarchie.

Vous pouvez voir la navigation facettée affichée dans la barre latérale gauche, pour aider au processus de prendre les décisions. Vous pouvez observer, aussi, que le listing des sous-catégories a été remplacé avec le listing des produits.

Il est important de garder les hiérarchies relativement superficielles, pour que les utilisateurs ne soient pas forcés de cliquer plus de quatre niveaux pour arriver à la liste des produits. Les moteurs de recherche auront les mêmes provocations et ils peuvent considérer que les produits enterrés en profondeur ne sont pas importants.

Parce que la navigation facettée est une fonction de segmentation granulaire du stock de produits, elle génère du contenu en excès dans la plupart des implémentations. Elle va générer aussi du contenu en double – par exemple, si vous n’implémentez pas un ordre strict pour les filtres des paramètres des URLs.

Par conséquent, quelles sont les options pour contrôler la navigation facettée ?

L’option rel=”canonical”

Même si rel=“canonical” doit être utilisé théoriquement pour le contenu identique ou presque identique, il peut être une bonne idée d’expérimenter avec des attributs canoniques pour optimiser le contenu au long des URLs de navigation facettée.

Vanessa Fox, qui a travaillé pour Google Webmaster Central, a suggéré l’approche suivante dans certains cas :

“Si la visualisation filtrée est un sous-ensemble d’une seule page non-filtrée (peut-être l’option visualisation=100), alors vous pouvez utiliser l’attribut canonique pour indiquer la page filtrée vers la page non-filtrée. Quand même, si la visualisation filtrée a comme résultat du contenu paginé, cela pourrait ne pas fonctionner (parce qu’il est possible que chaque page ne soit pas un sous-ensemble de ce que vous souhaitez indiquer comme canonique)”.^[48]

Rel=“canonical” va consolider les signaux d’indexation vers la page canonique et résoudra certains problèmes de contenu en double, mais les moteurs de recherche peuvent encore tomber dans le piège d’explorer les URLs non-pertinentes.

Rel=“canonical” est une bonne option pour les sites web nouveaux ou pour ajouter des options de filtration des sites web existants. Pourtant, cet attribut n’aide pas si vous essayez d’enlever les URLs existantes filtrées des indices des moteurs de recherche. Si vous n’avez pas des problèmes d’indexation et d’exploration, vous pouvez utiliser rel=“canonical”, comme Vanessa a suggéré.

L’option robots.txt

Robots.txt est la mesure de contrôle suprême pour l’exploration. Notez que si vous utilisez robots.txt pour bloquer des URLs, vous allez affecter le transfert de PageRank de et vers milliers de pages. Et cela parce que les URLs listées en robots.txt peuvent recevoir du PageRank, mais ne peuvent pas le transférer.^[49] De même, notez que robots.txt n’empêche pas l’indexation des pages.

Cependant, dans certains cas, cette approche est nécessaire – par ex., lorsque vous avez un site web nouveau, sans autorité et avec un grand nombre de produits qui doivent être découverts ou lorsque vous avez des problèmes d’indexation ou lié au contenu faible.

Si vous utilisez des paramètres dans les URLs et vous souhaiteriez arrêter l’exploration de toutes URLs générées par la sélection des valeurs sous le filtre Price, vous ajouteriez dans votre fichier robots.txt quelques chose similaire à ceci :

User-agent: *
Disallow: *price=

Cette directive signifie que toute URL qui contient la chaîne price= ne sera pas explorée.

Paramètre/répertoire URL bloqué par robots.txt

Cette méthode vous demande d’ajouter sélectivement un paramètre URL pour contrôler quelles pages filtrées peuvent être explorées. Nous avons décrit cela dans la section Optimisation de l’exploration (crawling), mais je veux répéter ici :

D’abord, décidez-vous sur les URLs que vous souhaitez bloquer.

Disons que vous souhaitez bloquer l’exploration de la navigation facettée en ne permettant pas aux moteurs de recherche d’explorer les URLs générées lorsqu’on applique plus d’une valeur de filtration dans le même filtre (connu aussi comme multi-sélection). Dans ce cas, vous allez ajouter le paramètre crawler=no pour toutes les URLs générées après la sélection d’une deuxième valeur de filtration sur le même filtre.

Si vous voulez bloquer les robots lorsqu’ils essaient d’explorer une URL générée par l’application de plus de deux valeurs de filtration sur des filtres différents, vous ajouterez le paramètre crawler=no à toutes les URLs générées par la sélection d’une troisième valeur, indépendamment des options faites ou l’ordre du choix. Voici un scénario comme exemple :

Le robot d’exploration se trouve sur la page de sous-catégorie Battery Chargers.

La hiérarchie est: Home > Accessories > Battery Chargers

L’URL de la page est: mysite.com/accessories/motorcycle-battery-chargers/

Puis, le robot « vérifie » l’une des valeurs de filtration Brands, c’est-à-dire Noco. Celle-ci est la première valeur de filtration et, par conséquent, vous allez permettre au robot d’explorer cette page.

L’URL pour cette sélection ne contient pas le paramètre d’exclusion :

mysite.com/accessories/motorcycle-battery-chargers?brand=noco

Le robot vérifie maintenant l’une des valeur de filtration Style, cables. Parce que c’est la deuxième valeur de filtration appliquée, vous allez encore permettre au robot d’explorer l’URL.

L’URL ne contient encore pas le paramètre d’exclusion. Il ne comprend que les paramètres brand et style:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables

Maintenant, le robot « choisit » l’une des valeurs de filtration Pricing, numéro 1. Parce que c’est la troisième valeur de filtration, vous allez attacher crawler=no à l’URL. L’URL devient :

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables&pricing=1&crawler=no

Si vous voulez bloquer l’URL ci-dessus, le fichier robots.txt comprendra:

User-agent: *
Disallow: /*crawler=no

La méthode décrite ci-dessus empêche l’exploration des URLs facette lorsque deux ou plusieurs valeurs de filtration ont été appliquées, mais elle ne permet pas un contrôle spécifique sur les filtres exacts qui seront explorés ou non. Par exemple, si le robot « vérifie » d’abord les options de Pricing, l’URL qui comprendra le paramètre de prix sera exploré.

Notez qu’il existe des risques si vous bloquez les pages filtrées seulement sur la base du nombre de valeurs de filtrations appliquées. Par exemple, si une valeur de filtration Price est appliquée d’abord, les pages générées seront encore indexées, parce qu’une seule valeur de filtration a été sélectée. Vous devriez avoir des règles plus solides de contrôle de l’exploration – par ex., si une valeur de filtration du type overhead a été appliquée, bloquez toujours les pages générées.

C’est aussi une bonne idée de limiter le nombre de sélections que le robot d’un moteur de recherche puisse découvrir. Nous allons discuter cela un peu plus tard dans le cadre de cette section, comme option de contrôle de l’exploration par JavaScript/AJAX.

Les filtres ou les facettes importantes doivent être des liens HTML simples. Vous pouvez présenter les filtres du type overhead comme texte simple aux moteurs de recherche (non pas des hyperliens), mais comme HTML fonctionnel pour les utilisateurs (hyperliens).

L’approche du répertoire bloqué demande le placement des URLs indésirables dans un répertoire et puis le blocage de ce répertoire par robots.txt.

Dans notre exemple ci-dessus, lorsque le robot vérifie l’une des options Pricing, placez l’URL dans le répertoire /filtered/. Si l’URL normale ressemble à ceci :

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables&pricing=1
lorsque vous contrôlez les robots, l’URL inclura le répertoire /filtered/:
mysite.com/filtered/accessories/motorcycle-battery-chargers?brand=noco&style=cables&pricing=1

Si vous voulez bloquer l’URL, le fichier robots.txt comprendra:

User-agent: *
Disallow: /filtered/

L’option nofollow

Certains sites web préfèrent l’attribut nofollow pour les filtres ou facettes inutiles. De façon surprenante et contre la recommandation officielle de ne pas faire nofollow sur tout lien interne, nofollow est l’une des recommandations de Google pour gestionner la navigation facettée^[50]. Quand même, nofollow ne garantit pas que les moteurs de recherche n’exploreront pas les URLs inutiles ou que ces pages-là ne seront pas indexées. De plus, l’attribut nofollow ajouté aux liens internes pourrait envoyer aux moteurs de recherche des signaux erronés, parce que nofollow se traduit par « ne faites pas de la confiance à ces liens ».

Ainsi, nofollow ne résout pas les problèmes courants d’indexations. L’option marche le mieux dans le cas des sites web nouveaux.

Il peut être une bonne idée soit de « supplémenter » l’option nofollow avec une autre méthode qui empêche l’indexation des URLs (par ex., le blocage des URLs par robots.txt) ou de canonicaliser le lien dans un super-ensemble.

L’option JavaScript/AJAX

Nous avons décidé que les filtres et les facettes essentielles et importantes devraient toujours être accessibles aux moteurs de recherche sous la forme de liens. Préférablement, sous la forme de liens HTML simples. Les URLs pour les filtres et les facettes du type overhead, de l’autre côté, peuvent être bloquées sans problème pour les robots des moteurs de recherche.

Théoriquement, vous pouvez cacher toute la navigation facettée aux moteurs de recherche, en la chargeant avec JavaScript ou AJAX, qui « ne sont pas conviviales » avec les moteurs de recherche. Nous avons vu qu’OfficeMax a procédé ainsi. Quand même, il n’est pas une bonne idée d’exclure toute la navigation facettée et vous ne devriez pas faire cela lorsqu’il existe des manières alternatives pour que les moteurs de recherche puissent arriver aux pages créées pour toutes les facettes essentielles et importantes. Dans la pratique, cette chose n’est ni faisable, ni recommandée.

Une option est de permettre aux moteurs de recherche seulement l’accès aux liens des facettes essentielles et importantes, sans générer des liens overhead. Par exemple, chargez seulement les facettes et filtres importants comme HTML simple, lorsque les filtres ou les facettes overhead sont chargés par JavaScript ou AJAX. Les utilisateurs pourront cliquer sur n’importe quel lien, parce qu’ils seront générés dans le navigateur (par ex., en utilisant les liens « voir plusieurs options »).

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML1c152e6b.PNG$

Certaines valeurs de filtration de la navigation facettée n’ont pas des hyperliens.

Dans cet exemple, les utilisateurs peuvent voir seulement deux valeurs de filtration pour Review Rating, avec un lien vers Show All Review Rating (colonne 1). Lorsque je clique sur ce lien-là, je vois toutes les valeurs de filtration (colonne 2). Pourtant, Show All Review Rating n’est pas un lien pour les moteurs de recherche (colonne 3).

Cette option limitera d’une manière efficace le nombre d’URLs que les moteurs de recherche peuvent découvrir, ce que peut être une chose positive ou négative, selon votre situation. Si votre marché cible cherche « critiques 3-étoiles planchers laminés », alors vous devez faire le lien correspondant accessible aux moteurs de recherche.

Similairement, vous pouvez cacher des filtres entiers ou seulement certaines valeurs de filtration.

Par exemple, eBay présente initialement aux utilisateurs seulement un nombre limité de filtres et valeurs de filtration mais, après un clic sur « voir tout » ou « raffiner davantage », tous les filtres s’ouvrent dans une fenêtre modale :

Cette fenêtre modale comprend tous les liens nécessaires aux utilisateurs pour détailler la liste de produits.

Quand même, le contenu de la fenêtre modale n’est pas accessible aux moteurs de recherche, comme vous pouvez voir dans cette image, ou « raffiner davantage » n’a pas un hyperlien :

L’élément “More refinements” (raffiner davantage » ressemble à un lien et fonctionne comme un lien, mais il n’est pas un href normal

Un avantage du chargement sélectif de filtres et facettes avec AJAX et JavaScript caché aux robots de recherche est que cela peut aider au transfert d’un plus d’autorité (PageRank) vers les autres pages, plus importantes. C’est un concept très similaire à l’ancien concept de modelage de PageRank. Pourtant, notez que ce « modelage » a lieu seulement si les moteurs de recherche ne peuvent pas exécuter AJAX sur de telles pages. Et les moteurs de recherche deviennent encore meilleurs dans l’exécution de JavaScript et AJAX. Pour vous assurer que les liens ne sont pas accessibles pour Googlebot, bloquez les ressources nécessaires pour les appels JavaScript ou AJAX par robots.txt et puis effectuez une opération du type « fetch and render » dans Google Search Console.

Si vous savez que certaines pages ne présentent pas aucune valeur pour les moteurs de recherche et vous ne souhaitez pas que ces pages inutiles soient indexées, pourquoi permettre l’accès des robots en premier lieu ?

Un autre avantage du chargement sélectif des URLs est qu’en procédant ainsi vous allez empêcher le processus d’exploration des liens inutiles.

Le signe dièse (#)

Vous pouvez ajouter des paramètres après le signe (#) pour éviter l’indexation des URLs facettées. Cela signifie que vous pouvez permettre à la navigation facettée de créer des URLs pour toute combinaison possible de filtres. Comme observation, notez que le contenu AJAX est signalé avec le signe (#!). Quand même, ce schéma n’est pas recommandé par Google.

Si vous effectuez une recherche “info:” pour une page qui inclut le signe dièse dans l’URL, vous verrez que Google présente la page qui exclut tout ce qui est mentionné après le signe dièse.

Pour les moteurs de recherche, cette page:

http://www.modcloth.com/shop/books#?price=28,70&sort=newest&page=1

fait référence au contenu de cette page:

http://www.modcloth.com/shop/books

Google mémorise en cache le contenu de la page générée avant l’utilisation des signes dièse.

Le signe dièse peut consolider, théoriquement, les signaux de linking vers modcloth.com/shop/books, mais toutes les pages générées en utilisant le signe dièse ne seront pas indexées ; alors, elles ne peuvent pas se classifier.

Quand même, vous pouvez placer seulement les filtres overhead après le signe dièse. Chaque fois qu’une facette essentielle ou importante est sélectée, incluez-la dans une URL propre, avant du signe dièse. On peut ajouter aussi des filtres de sélections multiples après le signe dièse.

Vous pouvez contrôler aussi les robots en utilisant les instruments de management des paramètres URL offerts par Bing et Google.

Ce réglage informe Google que le paramètre mid est utilisé pour la réduction du contenu. Je préfère à informer Google sur l’effet que chaque paramètre a sur le contenu de la page mais, finalement, je lui laisse décider quelles URLs il explorera.

Ce réglage présente un seul indice pour Google, alors vous devez encore résoudre le problème lié à l’exploration et au contenu en double, en utilisant une autre méthode (par ex., le blocage des facettes overhead par texte sélectif robots.txt), ou en utilisant une combinaison de méthodes.

L’option noindex, follow

En ajoutant le méta-tag “noindex, follow” aux pages générées par les filtres overhead vous pouvez résoudre les problèmes d’indexation excessive (“index bloat”) mais vous n’empêcherez pas les robots de tomber dans les pièges de la filtration.

Une courte observation sur l’utilisation de la directive noindex en même temps avec robots.txt. Théoriquement, “noindex,follow” peut être utilisé en combinaison avec robots.txt pour empêcher l’exploration et l’indexation des sites web nouveaux. Cependant, si quelques URLs indésirables ont été déjà explorées et indexées, vous devez d’abord ajouter l’attribut “noindex, follow” à ces pages-là et permettre aux robots de recherche de les explorer. Cela signifie que vous ne bloquerez pas encore les URLS avec robots.txt. Bloquez les URLs indésirables par robots.txt seulement après l’enlèvement des URLs de l’index.

Eléments de triage

Vous devez permettre aux utilisateurs de trier les listings sur la base de plusieurs options. Quelques options de triage populaires incluent : les plus vendus, produits nouveaux, le meilleur classement, le prix (du bas vers le haut ou vice-versa), le nom des produits et même le discount appliqué.

Quelques options populaires de triage.

Le triage change tout simplement l’ordre du contenu et non pas le contenu en soi. Cela va créer des problèmes de contenu en double ou presque en double, particulièrement lorsque le triage peut être bidirectionnel (par ex., triage selon le prix—du bas en haut et du haut vers le bas) ou quand le listing entier se présente sur une seule page (view-all).

Google nous dit que si les paramètres de triage n’existent pas dès le commencement dans les URLs, ils ne souhaitent pas même explorer ces URLs-là.

Cette capture d’écran est prise de la présentation officielle de Google, « Les paramètres URL en Webmaster Tools ».^[51]

La meilleure approche du triage est situationnelle et dépend de la manière dont vos listings sont réglés.

Utilisez rel=“canonical”

Souvent, les paramètres de triage sont gardés en URL. Lorsque les utilisateurs changent l’ordre de triage, les paramètres de triage sont ajutés à l’URL et la page se recharge. Dans ce cas, vous pouvez utiliser rel=“canonical” sur les pages triées pour faire référence à une page de base (par ex., triée selon les produits les plus vendus).

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML2b1f2b5.PNG$

Dans cette image, vous pouvez voir que même si le triage génère des URLs uniques pour les options de triage ascendantes et descendantes, les deux URL font référence à la même URL canonique.

L’utilisation de rel=“canonical” est très recommandée si le triage se fait sur une seule page, parce que le triage du contenu changera seulement la manière d’affichage et non pas le contenu. Cela signifie que le contenu de chaque page, même s’il peut être trié, ne sera pas différent et la page générée sera un duplicate exact. Par exemple, lorsque le triage réordonne le contenu sur une page view-all, vous générez des duplicates exacts (étant donné le fait qu’une page view-all liste tous les produits en stock). Pourtant, même quand le contenu est trié page par page et non pas en utilisant l’entier listing paginé, vous pouvez créer de contenu en double ou presque en double.

Enlever ou bloquer les URLs de l’ordre de triage

Cela impose que l’attribut rel=“noindex, follow” soit ajouté aux URLs de triage ou que l’accès vers elles soit bloqué complètement en utilisant robots.txt ou dans le cadre de Google Search Console.

Dans cet exemple, le listing Ski Boots peut être trié dans deux directions (prix « du haut vers le bas » et prix « du bas vers le haut »).

Lorsque les produits sont triés dans deux directions, le premier produit de la page triée « du haut vers le bas » devient le dernier produit de la page trié « du bas vers le haut ». Le deuxième produit de la première page devient l’avant-dernier et ainsi de suite. En fonction du nombre de produits que vous listez normalement et du nombre de produits listés, vous pouvez arriver à des duplicates exacts ou presque duplicates. Par exemple, disons que vous listez 12 produits sur page et qu’il y a 48 produits en total. Cela signifie que la dernière page de la série de pagination affichera exactement 12 produits. Lorsque vous listez selon le prix « du haut vers le bas », les produits sur la première page de la pagination seront identiques avec les produits sur la dernière page lorsque vous triez « du bas vers le haut ».

Un autre façon de gestionner le triage bidirectionnel est de permettre aux moteurs de recherche d’indexer seulement une direction de triage et d’enlever ou bloquer l’accès à l’autre. Par exemple, permettez l’exploration et l’indexation des URLs de triage « les plus anciens » et bloquez « le plus nouveaux ».

L’enlèvement ou le blocage des URLs de l’ordre de triage est la méthode d’implémentation la plus facile et peut assurer une solution rapide aux problèmes de pagination, jusqu’à ce que vous êtes prêts d’avancer avec une solution plus complexe.

Utilisez AJAX pour trier

Avec cette approche, triez le contenu en utilisant AJAX et les URLs ne changent pas lorsque les utilisateurs choisissent une nouvelle option de triage. Tous les liens externes sont consolidés naturellement dans une seule URL, parce qu’il serait une seule URL pour faire le lien.

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML2851cfc.PNG$

Le triage par AJAX ne change pas, généralement, l’URL.

Observez la manière dont l’URL de l’image précédente ne change pas lorsque la liste est triée de nouveau selon Les plus vendus, dans l’image ci-dessous :

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML28dad6e.PNG$

Même si le contenu s’actualise lorsque les utilisateurs choisissent de différentes options de triage, l’URL reste la même.

Parce que l’URL ne s’actualise pas au triage, cette méthode rend impossible l’utilisation, la distribution ou l’enregistrement d’un lien pour les listings triés. Mais est-ce les utilisateurs font cela ? Même s’ils le font, quelle sera la relevance de la pagination ou du triage une semaine ou un mois après le moment le lien a été copié ou distribué ? Les produits sont ajoutés ou éliminés constamment des listes, en changeant fréquemment l’ordre des produits. Il est possible que les produits listés sur n’importe quelle page de triage soient partiellement ou totalement différents des produits listés sur la même page la semaine ou le mois prochain.

Par conséquent, la capacité de distribuer (shareability) et de copier le lien (linkability) ne devrait vous préoccuper lorsque vous décidez d’implémenter AJAX pour le triage. S’il est mieux pour les utilisateurs, faites-le.

Utilisez des URLs avec le signe dièse

L’utilisation des signes dièse dans les URLs permet la distribution, le marquage et le linking vers les URLs individuelles. Un attribut rel=“canonical” qui fait référence à l’URL de base (sans #) consolidera les liens possibles vers une seule URL.

Dans cette image, la visualisation de base liste les produits triés selon les SKUs Les plus pertinents.

L’URL ci-dessus sera la page canonique. Dans l’image ci-dessous, vous pouvez observer comment l’URL change lorsque la liste est filtrée selon Prix, du bas vers le haut :

L’URL inclut le signe dièse et la valeur de filtration ~priceLowToHigh.

Pour le moment, les moteurs de recherche ignorent d’habitude tout ce qui se trouve après le signe dièse, à moins que vous n’utilisiez le signe (#!) pour signaler un contenu AJAX (ce qui est démodé, aussi). Les moteurs de recherche ignore tout ce que se trouve après le signe dièse parce que son utilisation dans les URLs ne permet pas l’extraction des informations supplémentaires du serveur web.

L’implémentation du signe dièse est une solution élégante qui prend en considération l’expérience de l’utilisateur et les possibles problèmes de contenu en double.

Les options de visualisation

Tout comme les utilisateurs préfèrent de différentes options de triage, certains utilisateurs veulent changer la manière d’affichage des listes. Les options les plus populaires de visualisation sont : voir N résultats sur page ou voir comme liste/tableau. Même si elles sont utiles pour les utilisateurs, les options de visualisation peuvent poser des problèmes aux moteurs de recherche.

Dans l’exemple ci-dessus, les utilisateurs peuvent choisir de visualiser la page comme tableau compact ou liste détaillée ; ils peuvent, aussi, choisir le nombre de produits affichés sur la page.

La visualisation du type tableau et liste

$C:\Users\Traian\AppData\Local\Temp\SNAGHTML6a6bbd7.PNG$

Visualisation tableau (à gauche) et liste (à droite).

Généralement, la visualisation dans un tableau ou sous la forme d’une liste présente le même SKU, mais la visualisation en liste peut utiliser plus d’espace blanc.

Cet espace peut être complété avec des informations supplémentaires sur le produit et représente une opportunité SEO exceptionnelle, parce qu’il peut être utilisé non seulement pour augmenter la quantité de contenu sur la page, mais pour créer aussi des liens contextuels internes pertinents vers les produits ou les catégories parents.

L’approche optimale pour les options de visualisation est de charger le contenu visualisation-liste dans le code source d’une manière accessible aux moteurs de recherche et puis d’utiliser JavaScript pour faire le transfert entre les visualisations dans le navigateur.

Il n’est pas nécessaire de générer des URLs séparées pour chaque visualisation. Si vous générez des URLs séparées, ces pages auront du contenu en double, et la manière de gestionner cette situation est d’utiliser l’attribut rel=“canonical” pour la visualisation de base. La visualisation de base doit être la page qui charge le contenu pour la visualisation du type liste.

Par exemple, ces deux URLs indique l’attribut rel=“canonical” pour /French-Door-Refrigerators/products:

/French-Door-Refrigerators/products?style=List
/French-Door-Refrigerators/products?style=Grid

Voir – N – produits

Beaucoup de sites web de commerce électronique ont la fonction Voir – N – produits par page pour choisir le nombre de produits dans la liste :

Ci-dessus vous avez un menu vertical (drop-down) typique pour l’option « visualisation N produits » sur page.

S’il est possible, le listing des produits de base sera la page view-all. Si view-all n’est pas une option, affichez un nombre de base dans la liste (disons 20) et permettez aux utilisateurs de cliquer sur un lien view-all.

L’option view-all de Nike est affichée dans le menu même.

Si l’option view-all génère une liste impossible de gestionner, avec des milliers de produits, permettez aux utilisateurs de choisir entre deux nombres, ou le deuxième nombre est substantiellement plus grand que le nombre de base (par ex., 60 et 180). Gardez les préférences des utilisateurs dans une session ou un cookie persistent^[52], et non pas dans des paramètres URL.

La deuxième option de visualisation est substantiellement plus grande que la première.

D’une perspective SEO, les URLs du type voir-N-produits par page sont gestionnées généralement avec l’attribut rel=“canonical” qui renvoie vers les pages listing de base (qui sont généralement les pages d’indexation pour les pages de département, catégorie ou sous-catégorie).

Par exemple, sur une page listing avec 464 produits, l’option de visualisation de 180 produits per page peut être gardée dans la paire key=value itemsPerPage=180, et l’URL peut ressembler à ceci :

mywebsite.com/seat-covers/10A522.aspx?itemsPerPage=180

L’URL ci-dessus liste 180 produits par page et comprendra un attribut rel=“canonical” dans l’entête <head> qui renvoie vers l’URL de base de la catégorie :

mywebsite.com/seat-covers/10A522.aspx

Cependant, l’URL canonique ne liste que 60 produits par page comme réglage de base et c’est ce que les moteurs de recherche indexeront.

Cela signifie qu’un sous-ensemble plus grand (celui qui liste 180 SKU) est canonicalisé dans un sous-ensemble plus réduit (celui qui liste 60 SKU). Cette approche va créer quelques problèmes, parce que Google indexera le contenu de la page canonique (60 produits), ignorant le contenu sur le reste des pages voir-N-produits. Dans ce cas, vous devez vous assurer que les moteurs de recherche peuvent accéder d’une manière ou autre à chaque produit de l’ensemble entier (464 produits). Par exemple, vous pouvez faire cela avec contenu paginé qui est gestionné par rel=“prev” et rel=“next”, pour que Google consolide toutes les pages composantes dans l’URL canonique.

L’utilisation d’un attribut rel=“canonical” sur une page voir-N-produits est correcte si l’attribut canonique fait référence soit à une page du type view-all soit au plus grand ensemble de produits. La première option n’est pas idéale si vous souhaitez afficher une autre page dans les résultats de la recherche (par ex., la première page d’une série paginée avec 20 produits listés comme réglage de base).

Les approches pour le contrôle des pages voir-N-produits sont similaires aux approches pour le management du triage : une page view-all combinée avec AJAX/JavaScript pour changer l’affichage dans le navigateur, des liens AJAX/JavaScript qui ne sont pas explorables, des URLs marquées avec le signe dièse ou l’utilisation du méta-tag « noindex ». J’ai mentionné ces approches selon mes préférences, mais notez que même si une approche peut sembler meilleure dans certaines conditions sur un site web, il est possible qu’elle ne fonctionne pas sur un autre.

Prioritize: Good Content Bubbles to the Top, http://www.nngroup.com/articles/prioritize-good-content-bubbles-to-the-top/ ↑
New snippets for list pages, http://insidesearch.blogspot.fr/2011/08/new-snippets-for-list-pages.html ↑
More rich snippets on their way: G Testing Real Estate Rich Snippets, https://plus.google.com/+MarkNunney/posts/RqzNcKE9NSc ↑
Product – schema.org, http://schema.org/Product ↑
Below the fold, http://en.wikipedia.org/wiki/Above_the_fold#Below_the_fold ↑
Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
Usability is not dead: how left navigation menu increased conversions by 34% for an eCommerce website, https://vwo.com/blog/usability-left-navigation-menu-bar-conversions-ecommerce-website/ ↑
User Mental Models of Breadcrumbs, http://www.angelacolter.com/breadcrumbs/ ↑
Breadcrumb Navigation Increasingly Useful, http://www.nngroup.com/articles/breadcrumb-navigation-useful/ ↑
Breadcrumbs, http://www.bing.com/webmaster/help/markup-breadcrumbs-72419f3f ↑
New site hierarchies display in search results, http://googleblog.blogspot.fr/2009/11/new-site-hierarchies-display-in-search.html ↑
Visualizing Site Structure And Enabling Site Navigation For A Search Result Or Linked Page, http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220110276562%22.PGNR.&OS=DN/20110276562&RS=DN/20110276562 ↑
Rich snippets – Breadcrumbs, https://support.google.com/webmasters/answer/185417?hl=en ↑
Can I place multiple breadcrumbs on a page? https://www.youtube.com/watch?v=HXEYryd3eAY ↑
Location, Path & Attribute Breadcrumbs, http://instone.org/files/KEI-Breadcrumbs-IAS.pdf ↑
Taxonomies for E-Commerce, Best practices and design challenges -http://www.hedden-information.com/Taxonomies_for_E-Commerce.pdf ↑
Breadcrumb Navigation Increasingly Useful, http://www.nngroup.com/articles/breadcrumb-navigation-useful/ ↑
HTML Entity List, http://www.freeformatter.com/html-entities.html ↑
Pagination and SEO, https://www.youtube.com/watch?v=njn8uXTWiGg&feature=youtu.be&t=11m ↑
Pagination and Googlebot Visit Efficiency, http://moz.com/ugc/pagination-and-googlebot-visit-efficiency ↑
The Anatomy of a Large-Scale Hypertextual, Web Search Engine, http://infolab.stanford.edu/pub/papers/google.pdf ↑
Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
Five common SEO mistakes (and six good ideas!), http://googlewebmastercentral.blogspot.ca/2012_03_01_archive.html ↑
Search results in search results, http://www.mattcutts.com/blog/search-results-in-search-results/ ↑
View-all in search results, http://googlewebmastercentral.blogspot.ca/2011/09/view-all-in-search-results.html ↑
Users’ Pagination Preferences and ‘View-all’, http://www.nngroup.com/articles/item-list-view-all/ ↑
Progressive enhancement, http://en.wikipedia.org/wiki/Progressive_enhancement ↑
Users’ Pagination Preferences and ‘View-all’, http://www.nngroup.com/articles/item-list-view-all/ ↑
HTML <link> rel Attribute, http://www.w3schools.com/tags/att_link_rel.asp ↑
Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.ca/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
Implementing Markup For Paginated And Sequenced Content, https://web.archive.org/web/20140527145918/http://www.bing.com/blogs/site_blogs/b/webmaster/archive/2012/04/13/implementing-markup-for-paginated-and-sequenced-content.aspx ↑
Infinite Scrolling: Let’s Get To The Bottom Of This, http://www.smashingmagazine.com/2013/05/03/infinite-scrolling-lets-get-to-the-bottom-of-this/ ↑
Web application/Progressive loading, http://docforge.com/wiki/Web_application/Progressive_loading ↑
Infinite scroll search-friendly recommendations, http://googlewebmastercentral.blogspot.ca/2014/02/infinite-scroll-search-friendly.html ↑
Infinite Scrolling: Let’s Get To The Bottom Of This, http://www.smashingmagazine.com/2013/05/03/infinite-scrolling-lets-get-to-the-bottom-of-this/ ↑
Infinite Scroll On Ecommerce Websites: The Pros And Cons, http://www.lyonscg.com/insights/infinite-scroll-on-ecommerce-websites-the-pros-and-cons/ ↑
Why did infinite scroll fail at Etsy?, http://danwin.com/2013/01/infinite-scroll-fail-etsy/ ↑
Brazillian Virtual Mall MuccaShop Increases Revenue by 25% with Installment of Infinite Scroll Browsing Feature, https://web.archive.org/web/20131106172124/http://www.ereleases.com/pr/brazillian-virtual-mall-muccashop-increases-revenue-25-installment-infinite-scroll-browsing-feature-135237 ↑
Typographical error, http://en.wikipedia.org/wiki/Typographical_error ↑
Better infinite scrolling, http://scrollsample.appspot.com/items ↑
The Paradox of Choice, http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less ↑
Search Patterns: Design for Discovery, [page 95] ↑
Adding product filter on eCommerce website boosts revenues by 76%, https://vwo.com/blog/product-filter-ecommerce-ab-testing-revenue/ ↑
Configuring URL Parameters in Webmaster Tools, https://www.youtube.com/watch?v=DiEYcBZ36po&feature=youtu.be&t=1m37s ↑
Permutation, Combination – Calculator, http://easycalculation.com/statistics/permutation-combination.php ↑
Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.ca/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
Implementing Pagination Attributes Correctly For Google, http://searchengineland.com/implementing-pagination-attributes-correctly-for-google-114970 ↑
Do URLs in robots.txt pass PageRank? https://productforums.google.com/forum/#!category-topic/webmasters/crawling-indexing–ranking/OTeGqIhJmjo ↑
Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.fr/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
URL Parameters in Webmaster Tools, https://docs.google.com/presentation/d/1xWy5TOkB4rwoUHXFPgwVMgl2Op9PayZOWa5wdW7ZB-o/present?pli=1&ueb=true#slide=id.g6205f11_0_28, page 18 ↑
Persistent cookie, http://en.wikipedia.org/wiki/HTTP_cookie#Persistent_cookie ↑