Qui n’a jamais été confronté aux problèmes de la pagination ? Du blog au gros site e-commerce, elle est quasi incontournable. Très vite, on ne se pose plus la question de savoir si il faut s’en affranchir ou pas, mais comment l’optimiser au mieux pour le référencement naturel. Comme beaucoup d’éléments qui ont trait à l’architecture d’un site, il ne faut pas considérer la pagination uniquement au travers du prisme SEO : l’expérience utilisateur et le web marketing sont également concernés, voir liés. Les solutions techniques existent, vous le savez sans doute, avec rel="prev", rel="next" et rel="canonical". Aucune n’est idéale, et il est important de savoir quelle technique et quelle stratégie adopter en fonction de son projet.
Pour certains d’entre vous, ce billet aura sans doute un arrière-goût très… « guideline » ; j’espère que vous ne m’en voudrez pas… en même temps difficile de ne pas faire autrement avec ce sujet. Beaucoup de webmasters et éditeurs n’ont pas encore réellement saisi toutes les subtilités de la pagination, ses avantages et surtout ses effets néfastes sur le référencement, préférant faire une confiance aveugle à leur CMS, hélas.
La pagination s’impose dès que le contenu devient trop important au sein d’une page, que ce soit en terme de taille, mais également de poids. Ce régime s’applique aussi bien aux visiteurs qu’aux robots d’indexation qui ont également une capacité de digestion limitée. Il faut également ménager les ressources : un site e-commerce qui afficherait des milliers de produits sur une page monolithique (par défaut) mettrait sans doute à genoux son serveur.
Exemple de pagination
Il faut d’abord distinguer plusieurs types de paginations dont voici les deux principales :
- La pagination de contenu, celle qui segmente un article de presse par exemple.
- La pagination de rubrique, celle que l’on connaît tous, qui affiche sous forme de listing paginé les articles d’une thématique. Tout le monde s’y retrouve confronté dès lors que l’on brasse un peu de contenu et que l’on dépasse la dizaine de pages par rubrique.
Cette fragmentation de pages se retrouve également dans la gestion des galeries d’images, résultats de recherches, forums, ou dans certains formulaires parfois longs à remplir, et où il est préférable de procéder par étape.
La pagination de contenu (article)
Les raisons qui motivent le découpage d’un article en plusieurs pages ne sont pas forcément les mêmes que pour les rubriques. L’approche est plus tournée vers le visiteur et le web marketing. On retrouve cette forme de pagination dans les gros articles/dossiers de fond (automobile, informatique, gadget, etc.) où le contenu se prête facilement à la segmentation : introduction, essai, fiche technique, conclusion, avis.
Moins pratiquée, cette pagination possède des avantages non négligeables, comme des inconvénients, et son utilisation (ou pas) génère parfois de longs débats.
Des avantages (parfois insoupçonnés)…
Augmenter le nombre d’impressions publicitaires : En fractionnant les articles en plusieurs pages, on augmente de facto le nombre de pages vues, et les affichages de bannières. Les possibilités de remarketing sont excellentes puisque le visiteur affichera plusieurs pages sur un sujet bien précis.
La possibilité d’aller à l’essentiel pour l’internaute : Un exemple typique, le test de hardware : pour bien réaliser un essai de carte graphique, le rédacteur devra effectuer des benchmarks avec différents jeux, différents logiciels, publier sa fiche technique, la comparer avec ses concurrentes, et faire une conclusion avec forces et faiblesses du produit. La nécessité de segmenter est ici importante pour offrir à l’internaute la possibilité de zapper les parties qui ne l’intéresse pas : si il cherche une carte graphique pour faire de l’infographie, il n’aura sans doute aucune envie de lire (et charger) la partie concernant les jeux.
Les pages en cluster : le bon plan SEO
Exemple de pagination sur le site journaldunet utilisant un « cluster » de plusieurs pages.
Dans l’exemple ci-contre, en plus d’être astucieuse, cette pagination est très bien réalisée car elle offre une triple lecture : une navigation par vignette, par numéro de pages (classique), et reprend les balises H1 des différentes pages en infobulle (JavaScript). En haut de page, une navigation simplifiée a été intégrée au cas où la principale descendrait en dessous de la ligne de flottaison sur les dispositifs mobiles.
Mais cette stratégie ne peut pas être adaptée à n’importe quel article. Ils doivent être calibrés (plutôt courts), et s’y prêter. Votre gestionnaire de contenu doit également être préparé pour gérer ce type de pagination.
Mais aussi des faiblesses en SEO
Découper un article en plusieurs parties présente inéluctablement des risques de dilution de PageRank et de « link juice », des backlinks et des likes éparpillés, etc.
Solutions techniques et stratégies
La mise en place d’un tel procédé ne doit pas se faire sans réflexion, et une stratégie éditorial + SEO doit être établie en amont.
La première page, celle qui introduit l’article devra contenir assez de texte pour résumer l’ensemble avec un choix de mots clés stratégiques. Les autres pages influenceront la longue traîne.
La découverte automatique par Google de ce genre de pagination est beaucoup moins évidente comparée à la pagination de rubrique. Il est vivement recommandé d’utiliser des attributs rel="next" et rel="prev" (ou "previous" ça marche aussi) pour guider le moteur et lui indiquer que tel ensemble de pages constitue un seul et même article. (voir plus bas pour l’intégration de cet attribut).
Dans ce contexte, je préfère ne pas utiliser le rel="canonical" (développé plus bas), et réserver cet attribut dans des scenarii qui présentent de la duplication de contenu.
Dans le cas d’une pagination de contenu, préférez les liens texte (titres des différentes sections) nettement plus parlants pour le visiteur, plutôt que des numéros de pages. Couplez-les avec des liens « précédent » & « suivant » qui indiquent clairement qu’il y a une suite. Tous ces liens doivent être évidemment bien visibles. Voir l’exemple ci-dessous.
La navigation, et la pagination des tests hardware chez presence-pc.com
Ancres internes VS pagination VS découpage en plusieurs pages distinctes
Le choix entre les différentes stratégies devrait être guidé par la nature de votre site, le volume et la nature de l’article et dans une moindre mesure les ressources de votre serveur. Quand un visiteur arrive sur un site d’essais automobile ou hardware, il s’attend (consciemment ou pas) à tomber sur ce type de pagination. Vous éviterez d’utiliser cette méthode sur des sites qui ne s’y prêtent pas, qui plus est de manière sporadique et inattendue. Préférez une navigation interne à l’article avec des ancres, comme je le fais avec cet article.
Toutefois, si votre article dépasse les 3000 mots, une très bonne stratégie SEO consiste à découper l’article en plusieurs pages distinctes (part I, part II, etc.), permettant ainsi de jouer sur les co-occurrences beaucoup plus efficacement que sur une seule et même page. Sur ce blog par exemple, où la tendance va plutôt au gros pavé, je suis très souvent à la limite de splitter mes articles en 2. C’est d’ailleurs le cas avec mon précédent billet sur l’exploration visuelle des réseaux de données. Ne perdons pas de vue qu’une fois passés les 500 premiers mots, les expressions clés perdent du poids.
Ce procédé diffère singulièrement des pages en cluster abordé plus haut. Il permet de ne pas tout publier d’un coup, de jouer sur le teasing, et de fractionner un article trop long pour tenir dans une seule page.
La pagination de rubrique
Les avantages
- Limiter la charge du serveur : tous ceux qui ont administré des sites à fort trafic gérés par des bases de données le savent, les grosses requêtes (SQL) mettent à mal les ressources, et génèrent parfois de gros ralentissements. C’est LE principal avantage.
- Faciliter la quête du visiteur : la pagination, si elle est accompagnée d’une bonne navigation permet également au visiteur d’arriver plus vite à ce qu’il cherche quand il y a beaucoup de résultats, avec notamment l’adjonction de filtres.
Les inconvénients
Pour le SEO, la pagination est une véritable plaie, et les scenarii sont nombreux. Si on devine les principaux, certains sont plus vicieux, et il n’est pas inutile de les rappeler.
- Problèmes de profondeur : certaines pages se retrouvent à des niveaux de profondeur difficilement atteignables par les visiteurs et les robots. Certes le sitemap.xml est là pour compenser, mais si une page tombe dans les profondeurs d’un site et qu’elle ne reçoit plus de trafic organique, elle tombera également dans les profondeurs des SERPs (résultats de recherche des moteurs).
Navigation typique des forums : la perforation de la pagination présente ici véritable frein pour le crawl et l’indexation.
- Problèmes liés à l’indexation des pages de rubrique : par nature, une page de rubrique a un contenu qui change régulièrement. Dès qu’une entrée est ajoutée, une autre s’éclipse pour passer en page 2 etc. Si Google (ou autre) propose cette page dans ses résultats de recherche, l’utilisateur risque de ne pas trouver ce qu’il cherche, la page indexée n’étant pas forcément à jour. Il en résulte alors un fort taux de retour, néfaste pour le référencement.
- Plus de clics pour l’utilisateur : inévitablement, les internautes devront effectuer plusieurs clics pour arriver à la page recherchée. Ce problème s’accentue sur les sites aux thématiques « fourre tout » mal segmentées.
La tendance qui s’inscrit dans la conception du web 2.0, va au scroll infini avec chargement des données en Ajax (jQuery). Mais ce n’est pas pour autant la solution salvatrice (d’un point de vue SEO), et cela peut générer quelques soucis d’un navigateur à l’autre. - Mise à mal de la stratégie de linking interne : comme je l’évoquais déjà dans mon article sur le linking interne, les paginations mal maîtrisées peuvent mettre à plat toute votre stratégie.
- Duplication de contenu : l’activation de la pagination induit très souvent du DC. Par exemple, la première url de votre pagination "/rubrique.php?id=4&page=1" sera certainement identique à "/rubrique.php?id=4".
Les bonnes pratiques de la pagination
Si l’objectif principal de la pagination est d’éviter les montées en charge du serveur, une mauvaise navigation de la pagination peut entraîner l’effet inverse. Imaginez une rubrique avec des milliers de produits triés par ordre chronologique de publication avec comme seuls éléments de navigation un bouton « précédent » et « suivant ». L’utilisateur devra cliquer frénétiquement sur suivant pour arriver sur le résultat recherché… quand il y arrive.
La pagination des essais du site turbo.fr ne permet pas d’aprécier le volume de pages à parcourir.
L’important est de raccourcir au maximum le parcours et le temps de latence que mettra un utilisateur pour trouver l’information qu’il cherche. Pour faciliter son cheminement, on l’a vu, les filtres sont très pratiques, mais il faut également qu’il ait des repères pour jauger de la quantité de pages à parcourir. Par exemple, en première page de navigation doit être indiqué clairement "page 1 à 10 sur 67". En plus des numéros de pages (facilement cliquables et identifiables) se trouveront de part et d’autre des boutons « précédent » et « suivant ».
Si le volume de pages est très important et qu’il n’est pas possible d’afficher l’intégralité des numéros de pages de la pagination, essayez de mettre un lien vers la dernière page. Certains sites ayant beaucoup de contenu affichent même une incrémentation par dizaines en plus de la dernière page.
La navigation d’amazon.fr permet à l’utilisateur d’apprécier le volume de pages.
La présentation de la navigation doit être claire, intuitive et aérée. Sur certaines paginations, on distingue à peine la page courante, et il n’y a parfois pas d’espace entre les numéros de page. J’en arrive même parfois à me repérer aux paramètres d’URLs ! C’est rédhibitoire.
Une navigation un peu trop minimaliste
Solutions techniques et optimisations SEO
En fonction de la structure de votre projet, de sa nature, et de son volume, la pagination doit être impérativement maîtrisée. Si la théorie veut que les robots sont assez intelligents pour la détecter, il vaut mieux les aider à comprendre comment sont structurés nos sites et prendre un minimum de risques.
La technique de la page monolithique avec rel="canonical"
C’est une solution hybride qui consiste à créer une page « voir tous » recensant tous les articles d’une rubrique. C’est l’utilisateur qui fera le choix d’afficher cette page, et forcément elle ne doit pas être affichée par défaut.
La page « voir tous » sera également désignée aux moteurs (Google) comme étant la page de référence. Autrement dit, on placera dans toutes les pages paginées de la rubrique un attribut rel="canonical" pointant vers la page « voir tous ». Techniquement, dans la partie <head> de votre document html vous devrez insérer la ligne suivante :
<link rel="canonical" href="http://www.mon-domaine.fr/rubrique/voir-tous.html" />
Hélas, cette technique ne peut s’adapter à tous les sites. Elle passe obligatoirement par la création d’une page unique parfois gourmande en ressources. Un site proposant des milliers de fiches produits par catégorie n’optera probablement pas pour ce type de stratégie, et le visiteur lui ne s’y retrouvera pas.
Gardez aussi à l’esprit qu’au-delà d’un certain nombre de liens par page, les robots d’indexation ont tendance à les bouder. On parle parfois de 100 liens par page maximum, mais la limite n’est pas franche, et il n’y a pas de communication claire sur le sujet de la part de Google… Cependant cela donne une idée du seuil à ne pas dépasser (dans ce contexte) pour ne pas trop perdre en performance. Au final, l’effet de profondeur, et de classement vertical se fera toujours sentir.
N’utilisez pas l’attribut canonical pour désigner la première page de votre pagination. Le risque étant que Google considère la première page comme exhaustive.
Si l’on met de côté l’aspect vertical et son incidence sur le SEO, plusieurs techniques peuvent se cumuler pour ne pas créer un requêtage trop bourrin :
- Mise en cache HTML. Une page de rubrique qui a déjà été calculée, n’a plus besoin de l’être tant que d’autres produits ou articles n’y ont pas été ajoutés.
- Remplacer une pagination classique, par une pagination Ajax : les utilisateurs qui voudront afficher tous les produits sur une page, chargeront le contenu de la liste (produits, pages, fiches, etc.) au fur et à mesure du scroll, de manière quasi transparente. Attention, cette solution n’est pas forcément « SEO friendly » ! Pour parfaire la technique, il faudra probablement faire un très léger cloacking, pour présenter aux robots une version de la page sans javascript pour qu’il puisse l’avaler entièrement… contrairement aux visiteurs. Ok Google sait interpréter le JavaScript, mais l’idée est de lui faciliter le travail, et d’optimiser le crawl.
- Autre piste que je n’ai pas expérimentée (et qui nécessite également un peu de cloacking), présenter à l’internaute une page « voir tous » en fonction de la charge du serveur. Si elle est > à 2 par exemple, alors on présente une version paginée. Mais dans tous les cas, non paginée pour les robots.
La technique avec les attributs rel="next" et rel="prev"
L’objectif de cette technique est d’indiquer aux robots le chaînage entre les pages de pagination. Quand le robot sera par exemple sur la page 3, il lui sera indiqué dans l’entête html de votre page quelle est la page précédente (2), tout comme la suivante (3). Le lien sera ainsi fait entre toutes les pages de pagination, et Google considérera cette ensemble de pages comme une seule entité, comme si c’était une page monolithique « voir tous ».
Exemple concret :
Supposons que ces 4 URLs soient celles de votre pagination de rubrique :
- http://www.mon-domaine.fr/rubrique.php?id=4&page=1
- http://www.mon-domaine.fr/rubrique.php?id=4&page=2
- http://www.mon-domaine.fr/rubrique.php?id=4&page=3
- http://www.mon-domaine.fr/rubrique.php?id=4&page=4
Pour la première page "rubrique.php?id=4&page=1" devra se trouver dans la partie <head> de votre source html :
<link rel="next" href="http://www.mon-domaine.fr/rubrique?id=4&page=2" />
pour la seconde (rubrique.php?id=4&page=2) :
<link rel="prev" href="http://www.mon-domaine.fr/rubrique?id=4&page=1" />
<link rel="next" href="http://www.mon-domaine.fr/rubrique?id=4&page=3" />
la troisième (rubrique.php?id=4&page=3) :
<link rel="prev" href="http://www.mon-domaine.fr/rubrique?id=4&page=2" />
<link rel="next" href="http://www.mon-domaine.fr/rubrique?id=4&page=4" />
et la quatrième (rubrique.php?id=4&page=4) :
<link rel="prev" href="http://www.mon-domaine.fr/rubrique?id=4&page=3" />
Vu comme ça, cette technique semble exploitable, mais en réalité, c’est souvent un véritable cauchemar. Mis à part quelques CMS orientés blog, les paginations sont très souvent accompagnées de filtres (tri par ordre alphabétique, pertinence, x produits par page, etc.) rendant très complexe l’intégration des attributs rel="next" et rel="prev". En outre, des problèmes de duplication de contenu peuvent apparaître surtout si vous utilisez des paramètres de session : vous devrez alors ajouter en surcouche un rel="canonical" pour désigner aux moteurs l’URL nettoyée de ses paramètres.
Pourtant certains sites s’en sortent plutôt très bien à l’image de jeuxvideo.fr qui combine adroitement une pagination simple avec rel="next" & "prev" sans abandonner pour autant les options de tri (grâce au plugin « tablesorter » de jQuery).
La pagination astucieuse de Jeuxvideo.fr qui combine l’utilisation des attributs next et prev avec le filtrage en JavaScript.
Regardez par exemple cette page : vous remarquerez que les 2 premières pages sont très graphiques favorisant le CTR sur les jeux récents, tandis que les pages plus profondes (> 3) présentent une version allégée sans image. Pour chaque page il est possible de trier les résultats pour chaque colonne, sans recharger la page, et sans générer d’autres URLs (donc pas de duplication de contenu).
Et pour ce qui est de la navigation, jeuxvideo.fr présente également un système très fonctionnel et sobre. C’est presque un « perfect » !
Recommandations et choix des stratégies
Il faut avant tout se poser les bonnes questions, puis adapter au cas par cas. Le choix de la pagination, et sa manière de la gérer dans une optique SEO est une affaire de dosage entre charge serveur, ergonomie, et SEO.
Ai-je réellement besoin de la pagination ? Si votre site est intelligemment structuré et segmenté, et que le nombre de pages par rubrique ne dépasse pas quelques dizaines, faites sauter la pagination !
Ai-je besoin d’indexer mes pages de rubrique (et donc de pagination) ? Souvent, les pages de rubrique ne sont alimentées que par du contenu repris (et donc dupliqué) dans les articles qu’elles contiennent, et n’offrent pas réellement de contenu pertinent. D’une manière générale, il est difficile d’en faire des pages de destination et il est préférable d’ajouter dans la partie <head> une balise meta noindex,follow. Mais cela ne vous dispense pas d’opter pour une bonne stratégie de pagination !
Dans la mesure où la pagination est incontournable, définissez un tri par défaut judicieux en terme de marketing et de SEO. Les articles les plus recherchés et concurrentiels seront mis en tête de liste. Au-dessus de votre liste paginée, vous ajouterez une sélection de produits « coup de coeur » qui enverront du « jus » permanent aux pages/produits que vous voulez pousser dans les SERPs.
Le principe est donc limpide : proposer un affichage par défaut qui présente les pages que l’on souhaite pousser, et laisser dans les profondeurs les pages de moindre intérêt.
Dans la majorité des cas, préférez le rel="canonical" pointant vers une page « affichez tout » à condition que votre serveur encaisse. C’est ce que préconise Google.
Rendez vos pages de rubrique pertinentes !
Si vous n’avez pas opté pour le noindex, ajoutez un texte de présentation de rubrique (unique, qualitatif, tout ça tout ça…). Environ 200 ou 300 mots devraient suffire, mais il ne faut pas que votre listing descende en-dessous de la ligne de flottaison. Si c’est le cas, utilisez un javascript type « accordion » qui masquera une partie du texte (avec bien sûr un bouton « voir plus » pour afficher l’intégralité).
Encore un super article de fond sur la pagination ! Pour ma part j’ai pas encore implémenté le rel= »next » et rel= »prev » sur mes sites mais comme tu le dis plus haut il vaut mieux structurer et catégoriser son contenu pour diminuer le nombre de pages 2/3/4… et avoir des pages « Catégories » ou « Tags » d’atterrissages.
Hello,
J’ai commencé à lire une bonne partie de l’article mais il aurait effectivement mérité une belle pagination.
Blague à part je n’ai pas finit de le lire, je viens de me l’envoyer pour ma lecture du soir dans les transports. Clairement, la pagination a toujours été un de mes points faibles. J’ai déjà rencontré certaines usines à gaz qui tournaient à grand renfort de rel=prev/next + du JS. Pas évident quand il y a un gros volume derrière. Mais ce qui est clair et comme cela à été très justement souligné, il n’y a pas ou peu de CMS qui intègre par défaut une pagination « à peu près » seo friendly.
Normal qu’il n’y ait pas vraiment de pagination « SEO friendly » car bien souvent elle doit s’adapter à la nature, ET au volume du contenu. A moins d’avoir un CMS qui propose tout une palette de paginations et systèmes de navigation…
>> rel= »canonical » pointant vers une page « affichez tout »
Merci pour cette information Aurélien,
Bertrand
Merci pour cet article.
Je trouve que la pagination de Jeuxvideo.fr est loin d’être proche du perfect : pas de canonique, du noindex,follow, des title, desc et hx dupliqués, aucune protection contre la génération de crawl parasite (bon après c’est en noindex mais tout de même, on peut générer du crawl).
Pour la page voir tout, même si la mettre en cache peut fonctionner, reste le problème des visuels produit. Si la page totale fini par faire plusieurs méga on a un souci. Alors il faudrait du lazy load mais sur un gros volume ça peut poser des soucis avec des navigateurs peu performants ou des machines anciennes.
Un autre vrai souci est de savoir comment transmettre un maximum de PR à toutes les pages. Pour ça il faut définir un algo sur les pages de pagination à présenter et surtout éviter le classique 1, 2, 3 … 400, Suivant >. Je crois qu’une vieille lettre abondance parlait de ça ;)
Une bonne vue d’ensemble des différentes techniques possibles et cette problématique se rapproche beaucoup de celle de la navigation par facette.
Personnellement j’utilise beaucoup les pages de catégories pour ranker sur un kw principal et les contenus internes sur la longue traine (En gros la même technique que tu évoques sur la pagination des articles).
Bien entendu la page est alors agrémentée d’un texte à haute valeur ajoutée.
Très bon récapitulatif!
Pour les gros volumes le no index follow me paraît une solution efficace et simple à implémenter, par contre il faut bien réfléchir au système de pagination à mettre en place : on peut vite se retrouver avec des pages de rubrique qui ne recevront (en liens internes) que des liens de page en no-index (sans jus) ce qui peut être problématique pour l’indexation et le positionnement des produits/articles qui y sont listés.
Merci pour ce super article. La pagination a toujours été et sera toujours un vrai casse-tête, surtout quand on part avec un des gros CMS du marché (et qu’on n’a pas envie de passer par un plugin de plus)
D’après ce que j’ai vu, l’encyclo universalis a mis en place un pagination de ces articles. Elle semble utilisée les attributs prev/next dans les métas
Encore un bel article qui pointe du doigt un sujet de fond pour beaucoup de webmasters et référenceurs.
Comme aucun CMS testé et utilisé à ce jour ne me donne entière satisfaction sur ce point, j’ajoute presque toujours un widget (souvent un simple bloc HTML) dans la page pour indiquer clairement et de manière « seo-ptimisée » les pages liées.
L’avantage c’est le contrôle sur les ancres et l’ergonomie, l’inconvénient consiste à avoir prévu cet emplacement au sein du gabarit de page, et qu’il y a risque de doublon selon le CMS (lien dans widget + lien pagination auto.). Mais vu que Google n’indexe que le premier URI qu’il rencontre, la plupart du temps tout se passe bien.
Je suis pas mal adepte du noindex, follow qui permet de limiter les risques. Après il me semble que Matt Cutts suggère fortement le canonical next, prev. Merci pour le dossier, un sujet à bookmarker ;)
Bonne synthèse qui touche du doigt un aspect peu développé mais essentiel qu’est l’architecture d’un site. J’ajouterai le problème de la disparition / réapparition des pages du fait du nombre fluctuant des produits d’une catégorie par exemple avec les conséquences sur le balisages (l’avant dernière page devient la dernière), les redirections à employer (301 vers la n-1, la page 1, ou une page synthétique, 404 si on pense qu’elle va revenir bientôt, ou autre).
Merci pour l’article, cela permet de se poser les bonnes questions et d’y trouver des solutions.
C’est tweeter !!
J aime tomber sur les articles de htiitipi, qui propose toujours des articles complets faisant bien souvent le tour de la question. Personnellement, la pagination sera toujours pour moi un problème récurrent en SEO malheureusement.
Après toutes les solutions proposées dans l articles, je passerais plutôt par des rel prev et next. Cela me semble encore le meilleur compromis.
Perso, je ne suis pas trop d accord avec les no index, enfin je ne me sens pas super motivé pour supprimer des milliers de pages de mes sites e commerce. Malgré le fait que ces pages soient en général handicapantes pour le SEO, les supprimer tout bonnement me semble un peu extrême.
Enfin, cela reste mon opinion.
Merci bcp pour ton retour ;-)
Supprimer en masse des URL avec entre autre la mise en place de noindex est effectivement une solution radicale qui peut supprimer plus de 90% des URLs d’un site e-commerce. Vu comme ça, ça peut faire trembler le SEO comme le client. Mais si toutes ces URL ne génèrent que du DC, DUST, et dilution de jus, quel intérêt de les garder ? A la limite, pour ne pas envoyer un signal trop brutal à Google, faire le ménage progressivement, palier par palier en observant les répercutions… Mais ça peut prendre un certain temps ;)
Hello,
Très bon guideline sur la pagination ! Perso je ne m’y ai pas pensé pour tous mes sites mais c’est vrai qu’avec mon blog qui commence à avoir un nombre important d’article je voulais m’y penché.
Je bookmark ;)
L’analyse est complète et permet aux détenteurs de blogs de voir les enjeux de la pagination surtout pour ne pas créer des pages trop profondes pas easy a crawler pour l’ami GG.
Mais sur un projet e-commerce, la logique de pagination pour les lourds sites avec de nombreuses références, est à prendre. Multiplier les rubriques ou les sous rubriques, et sous sous rubriques.
Je découvre le blog super complet pour améliorer un basic seo like me.
Article très complet sur une question passionnante et beaucoup plus technique qu’il n’y parait.
Je suis toujours frileux à utiliser la canonical, même si je sais que le résultat peut être bénéfique, étant donné que les pages paginées ne présentent pas le même contenu que la première page de la liste. « You’ll either misdirect the engines into thinking you have only a single page of results or convince them that your directives aren’t worth following (as they find clearly unique content on those pages) > http://www.seomoz.org/blog/pagination-best-practices-for-seo-user-experience »
En revanche, j’utilise volontiers les rel next et rel prev, ainsi que des title et meta différents sur chaque page.
Toute la question est ensuite de réfléchir à la distribution de PR, mais également à la consommation de crawl : et là ce sont d’autres optimisations…
C’est toujours un plaisir, autant sur le fond que sur la forme de lire tes articles.
Je suis étonné que tu parles à plusieurs reprises de charge serveur comme argument. Que tu fasses un limit 500 ou un limit 1000 sur ta requête, le temps d’exécution est quasiment identique pour moi. Apres si on compare l’affichage de 500 produits et 5000 là c’est certain qu’il y a une différence, mais de toute façon c’est le navigateur qui va te rappeler à l’ordre si les pages sont trop lourdes.
Tu as testé le comportement de googlebot sur un site où tu ajoutes / enlèves les rel next et rel prev?
Ciao
@Jerome : Merci pour ton message ;) La différence entre limit 500 et limit 1000 ne se fera pas sentir sur un site à faible trafic et qui plus est sur nu serveur mutualisé. Cette limitation de charge s’applique bien sur sur les site à fort trafic et sur serveur dédié ou il est impératif de « tuner » les requêtes. A ce niveau les résultats sont parfois énormes.
Quant aux résultats obtenus avec rel next et prev, oui je le vois régulièrement quand je l’implante sur les sites qui ne l’ont pas (et qui en on besoin).
Merci Aurélien pour cet article complet sur la question. Par rapport au point évoqué par @fred sur les paginations expirées, que penses-tu du fait d’avoir dans un premier temps une R302 au cas où la page viendrait à être recréée, puis dans un second temps une 404 afin d’éviter qu’il continue de crawler un contenu qui sera redirigé.
Merci Aurélien pour cet article.
J’ai tendance à penser qu’un no index sur l’ensemble des pages excepté la première peut être efficace, avec des link rel=prev et rel=next est ce qui se fait à l’heure actuelle de plus fonctionnel (je parle dans ce cas d’un tri via un formulaire envoyant de nombreux retours).
Qu’en pensez-vous ?
@Sébastien : Je n’en sais rien ;) Mais je préfère ne pas utiliser le noindex dans ce genre de contexte simplement pcq ça n’est pas dans les consignes de Google (si si des fois, faut les prendre en compte).
Super article très intéressant.
Une petite info que je n’ai pas réussi à trouver : que faire si notre pagination de produits est en ajax ? (l’url de ne change pas en passant en page 2, 3, ..). Selon moi pas besoin de rajouter de rel=next/prev ni de canonical sur les pages 2, 3 vers la page 1. Est ce correct ?
Merci
@Delaloupe : Merci pour ton commentaire. Ce que tu appelles pagination en ajax correspond t’il au scroll infini ?
Je te propose de consulter les best practices de Google à ce sujet : http://googlewebmastercentral.blogspot.fr/2014/02/infinite-scroll-search-friendly.html ;) Hope this helps!
Personnellement, j’ai une question à poser à l’auteur du blog : A partir de combien de commentaire faut-il prévoir une pagination dans les commentaires ? Certaines de mes pages sont à plus de 100 commentaires, j’hésite à les segmenter en pages de 10 commentaires avec la pagination qui va avec, mais j’ai l’impression que les commentaires renforcent également le référencement des pages et que donc mettre en place une pagination au niveau des commentaires diviserais la visibilité de cette même page… Le serpent qui se mort la queue ^^ !
Donc… Paginer les pages de commentaires ou non ? Cruel dilemme…
@SuzuKube : Relis bien l’article, et l’intérêt des attributs rel next/prev ;-)
Merci pour cet article. J’ai une question concernant ta remarque : « N’utilisez pas l’attribut canonical pour désigner la première page de votre pagination. Le risque étant que Google considère la première page comme exhaustive. »
En fait, je suis confronté à des sites qui traitent de l’actu chaude et donc il n’y pas vraiment d’intérêt SEO de faire indexer des centaines de pages de listing contenant les articles publiés chaque jour.
Dans ce cas, je pensais justement utiliser l’attribut rel=canonical pour désigner la première page comme page « maitre » et prioritaire pour Google, puisque je pense qu’il est pertinent de présenter à l’internaute que la page N°1.
Normalement Google devrait pouvoir continuer de crawler et d’indexer les articles grâce aux balises prev et next à l’intérieur des articles.
Qu’en penses-tu ? Ou les autres ? :)
Merci d’avance
@julien : Je ne ferai pas ça, car c’est un bricolage qui ne colle pas avec les consignes de Google (oui faut les suivre de temps en temps), et la fonction première de ces balises. Si tu ne veux pas indexer la ribambelle de pages de pagination, chose que je comprends tout à fait, tu colles un noindex. Jouer avec le canonical de la sorte est un risque inutile qui pourrait perturber le crawl rate du Googlebot, enfin à mon avis.
@aurélien, merci pour ta réponse, peut-être un noindex, follow comme ça Google continu de trouver les liens des articles sur ces pages de pagination, ça semble la bonne option non ?
@Julien : aucun intérêt. « follow » est la valeur par défaut, le noindex n’empêche en rien le crawl (contrairement au disallow dans le robot.txt). Donc juste noindex suffit.
Ok merci