No index, rel=prev et rel=next sur la pagination

WRInaute discret
bonjour à tous,

je suis en pleine refonte de mon site web, et je me pose la question suivante.

Sur la version actuelle, je passais en noindex les pages 2, 3, 4 d'une liste de restaurants, afin qu'elles ne soient pas en concurrence sur la page 1 (par exemple Restaurant Paris)

Depuis de l'eau a coulé sous les ponts et on nous propose rel=prev et rel=next, est-ce que le fait d'utiliser cela permet d'éviter la mise en concurrence de la page 1 avec les autres pages ?

Dernière question, sommes-nous d'accord que je n'ai pas de canonical à utiliser puisque je ne fais pas de tri mais uniquement des filtres ? Par exemple, Restaurant Paris et Restaurant Paris avec terasse : tous les restaurants présents sur "avec terasse" existent dans l'une de pages de la pagination de Restaurant Paris, mais l'inverse est faux.

merci de vos éclaircissements à ce sujet
 
WRInaute discret
Bonjour !

L'utilisation des balises rel=prev/next est recommandée, et sert effectivement à résoudre ce genre de problématique (mise en avant de la page 1).

Les infos qui vont bien sur le sujet : https://support.google.com/webmasters/answer/1663744?hl=fr

Canonical sert à expliquer à Google quelle url doit être retenue pour une page donnée dans le cas où cette page est accessible par plusieurs urls. Exemple : votre produit est dans la catégorie 1 et 2. Il est accessible par monsite.com/cat1/produit.html ET monsite.com/cat2/produit.html. Un canonical expliquera aux moteurs de n'indexer que l'une des urls, pas les deux.
 
WRInaute accro
C'est marrant depuis que Google a mis en place le rel prev/next, tout le monde veux le mettre ... alors que c'est des attributs qui existent depuis des années pour l'accessibilité, je mettais déjà ça dans des sites en 2000.
 
Olivier Duffez (admin)
Membre du personnel
le mieux reste d'éviter la pagination (surtout que les internautes ne l'aiment pas), par exemple en augmentant le nb d'éléments affichés par page et en proposant des liens pour filtrer (pas trier)
 
WRInaute discret
Hello,

Il est plus intéressant de marquer sa pagination avec rel=prev et rel=next même si cela demande une vérification de l'implémentation. L'idée est de mettre le maximum de pages à disposition de Google (en espérant qu'il les indexe), avec ses balises il sait même comment les livrer (priorité de la page 1...). Donc bon point d'éviter la noindex !

Après, certains ont émis des doutes car leur référencement avait chuté sur certaines pages paginées justement. Donc comme le dit Olivier, le mieux est de délivrer le maximum d'infos (en respectant une bonne UX) pour éviter ces soucis.
 
Olivier Duffez (admin)
Membre du personnel
ckocher a dit:
L'idée est de mettre le maximum de pages à disposition de Google (en espérant qu'il les indexe)
ça, c'est ce qu'on faisait il y a déjà pas mal d'années, mais ce n'est vraiment plus la mode, en tout cas ce n'est pas ce que je conseille :roll:
 
WRInaute accro
ckocher a dit:
Il est plus intéressant de marquer sa pagination avec rel=prev et rel=next même si cela demande une vérification de l'implémentation. L'idée est de mettre le maximum de pages à disposition de Google (en espérant qu'il les indexe), avec ses balises il sait même comment les livrer (priorité de la page 1...). Donc bon point d'éviter la noindex !

En référencement, il n'y a pas d'idée générale. Selon le type de site, ce genre de chose peut être utile ou pas.

Exemple 1 : un blog, les articles passent d'abord en page d'accueil, sont indexés, catégorisés. Si l'article n'a pas été crawlé quand il est en page d'accueil, il ne le sera certainement pas quand il sera dans une x° page d'archives. La multiplication du contenu "faible" n'a aucun intérêt

Exemple 2 : un site de petites annonces, avec un fort trafic, et surtout de très nombreuses annonces postées quotidiennement. Les annonces peuvent ne pas rester suffisamment longtemps en page d'accueil / N° 1 de la catégorie pour être crawlées, il peut être utile de laisser les pages suivantes

Je ne vois pas l'intérêt dans l'absolu de donner le maximum de pages à Google. Au contraire... ça risque de diluer son intérêt pour les pages les plus importantes.
 
WRInaute discret
Je suis un peu perdu du coup, avec ou sans ? No Index ? plutôt que de longues explications, voici la fameuse page :

http://tinyurl.com/lcbkwyh

J'ai déjà une longue page de résultat, et les restaurants sont classés dans un ordre du plus important au moins important (afin de donner plus de poids à la tête de liste), mais sur des villes comme les arrondissements parisiens je monte à 15 pages dans la pagination.
 
WRInaute discret
WebRankInfo a dit:
le mieux reste d'éviter à tout prix d'avoir à gérer de la pagination (surtout que les internautes ne l'aiment pas), par exemple en augmentant le nb d'éléments affichés par page et en proposant des liens pour filtrer (pas trier)
Faut il avoir recours à un loading Ajax (infinite scroll) quand on scroll et supprimer définitivement la pagination ?
 
WRInaute discret
WRInaute passionné
La meilleure technique est celle utilisée par Facebook : https://www.facebook.com/find-friends

Il y a des dizaines ou centaines de millions de profils et/ou de pages et on en trouve une en .... 4 clics ! qui dit mieux :D

avec 27 liens sur la première page (recherche alphabétique de A à Z + @), 100 liens sur les pages filles et 100 liens sur les pages filles des pages filles on peut accéder à 270000 pages en 3 clics :mrgreen:
 
WRInaute discret
fandecine a dit:
La meilleure technique est celle utilisée par Facebook : https://www.facebook.com/find-friends

Il y a des dizaines ou centaines de millions de profils et/ou de pages et on en trouve une en .... 4 clics ! qui dit mieux :D

avec 27 liens sur la première page (recherche alphabétique de A à Z + @), 100 liens sur les pages filles et 100 liens sur les pages filles des pages filles on peut accéder à 270000 pages en 3 clics :mrgreen:
je crois que je vais donc partir là dessus, j'avais hésité au début, et puis finalement non ...
 
Nouveau WRInaute
Pour éviter le contenu dupliqué et l’indexation des pages inutiles, il est recommandé d’attribuer "noindex , follow" au page d'archives
 
WRInaute discret
fandecine a dit:
La meilleure technique est celle utilisée par Facebook : https://www.facebook.com/find-friends

Il y a des dizaines ou centaines de millions de profils et/ou de pages et on en trouve une en .... 4 clics ! qui dit mieux :D

avec 27 liens sur la première page (recherche alphabétique de A à Z + @), 100 liens sur les pages filles et 100 liens sur les pages filles des pages filles on peut accéder à 270000 pages en 3 clics :mrgreen:
Je reviens avec mes grands sabots, mais : le fait que le contenu soit chargé dynamiquement va gêner le référencement de la page ? Google (entre autre) va voir une page avec 20 restaurants alors que certaines pages en ont plus de 400
 
WRInaute passionné
J'ai supprimé ces balises, n'ayant pas envies de donner a google de faire des calculs non maitrisés ou qui pourraient faire l'objet d'une retenue dans un filtre. Peut être je me trompe et que le gain est sensible.
Il faudrait pour cela avoir un même type de site en référence (annuaire), qui n'aurait fait que ce changement, pour être certain.
 
WRInaute discret
longo600 a dit:
J'ai supprimé ces balises, n'ayant pas envies de donner a google de faire des calculs non maitrisés ou qui pourraient faire l'objet d'une retenue dans un filtre. Peut être je me trompe et que le gain est sensible.
Il faudrait pour cela avoir un même type de site en référence (annuaire), qui n'aurait fait que ce changement, pour être certain.
Tu as donc passé en noindex les autres pages de la pagination ?
 
WRInaute passionné
non, j'ai 100% de mes pages indexables. Dans mon cas, c'est un annuaire, avec une structure modifiée en sous domaines par catégorie (1000). Je laisse google faire à sa guise de ce côté là, choisir les pages les plus pertinente. Mais en général, c'est la première page de chaque sous domaine, même sans ces balises là.
 
WRInaute discret
longo600 a dit:
non, j'ai 100% de mes pages indexables. Dans mon cas, c'est un annuaire, avec une structure modifiée en sous domaines par catégorie (1000). Je laisse google faire à sa guise de ce côté là, choisir les pages les plus pertinente. Mais en général, c'est la première page de chaque sous domaine, même sans ces balises là.
Je pense que rel=prev et rel=next sont quand même mieux que rien surtout si tu indexes tout

Je crois qu'au final, je vais rester sur du rel=prev et rel=next car je vois pas comment se fera l'indexation des restaurants qui ne sont pas là lorsque l'on arrive sur la page et qui est chargé via Ajax avec le scroll
 
WRInaute accro
En gérant la pagination avec (infinite scroll) et sans AJAX. Il suffit de détecter si le request est fait en AJAX et appliquer un layout différent.
 
WRInaute discret
spout a dit:
En gérant la pagination avec (infinite scroll) et sans AJAX. Il suffit de détecter si le request est fait en AJAX et appliquer un layout différent.
Ce qui implique de devoir charger 450 restaurants pour certaines villes (donc 450 images) le temps de chargement sera trop long

Je pensais, pourquoi ne pas mettre la pagination en dessous de la ligne de flottaison avant que le scroll l'atteigne ?

Donc on aura :
- une pagination pour les moteurs
- un infinite scroll pour l'utilisateur
 
WRInaute accro
Infinite scroll ne vx pas dire tout charger d'un coup, exactement comme pour la pagination par lots de 10 par ex.
 
WRInaute discret
C'est pas tant le code qui me pose problème, c'est de comprendre la logique.

Mise en situation :

Un internaute arrive sur la page "restaurant à Paris"

Il scroll la liste et arrive après 15 restaurants (les seuls affichés sur la page)

=>Comment on affiche la suite ?


Google arrive sur la page "Restaurant à Paris"

Il crawl la page avec les 15 restaurants pour cette page, et repart

=>Comment le faire crawler l'intégralité des restaurants de cette page ?
 
WRInaute accro
david_WRI a dit:
Un internaute arrive sur la page "restaurant à Paris"

Il scroll la liste et arrive après 15 restaurants (les seuls affichés sur la page)

=>Comment on affiche la suite ?
Listener JS sur le scroll.

david_WRI a dit:
Google arrive sur la page "Restaurant à Paris"

Il crawl la page avec les 15 restaurants pour cette page, et repart

=>Comment le faire crawler l'intégralité des restaurants de cette page ?
Liens de pagination
 
WRInaute discret
spout a dit:
david_WRI a dit:
Un internaute arrive sur la page "restaurant à Paris"

Il scroll la liste et arrive après 15 restaurants (les seuls affichés sur la page)

=>Comment on affiche la suite ?
Listener JS sur le scroll.

david_WRI a dit:
Google arrive sur la page "Restaurant à Paris"

Il crawl la page avec les 15 restaurants pour cette page, et repart

=>Comment le faire crawler l'intégralité des restaurants de cette page ?
Liens de pagination
C'est donc ce que je proposais : je laisse la pagination sous le niveau du listener JS ?
(et pour le coup je dois gérer les deux : rel=prev et rel=next + infinite scroll)
merci !
 
Olivier Duffez (admin)
Membre du personnel
sauf qu'à mon avis lister les restaurants par paquets de 15 est mauvais pour le SEO... en tout cas les pages 2 et suivantes n'ont que très peu d'intérêt SEO.
 
WRInaute discret
WebRankInfo a dit:
sauf qu'à mon avis lister les restaurants par paquets de 15 est mauvais pour le SEO... en tout cas les pages 2 et suivantes n'ont que très peu d'intérêt SEO.
En fait je dis 15, mais j'en affiche 40. Y a-t-il un nombre optimal ? Ou cela dépends plutôt de la vitesse de chargement de la page ? (puisque Google digère maintenant les pages avec volume important de liens)
edit : on parle bien du linkjuice trop peu important pour arroser les liens des restaurants sur ces pages là ? (et non pour la page elle-même ?)
 
WRInaute passionné
Avec Panda 4.0, le texte a pris plus d'importance. Qu'en est-il des listes de type "annuaire" restaurant ou autre, le poids total de la page est-il devenu un facteur majeur, et donc, faut-il augmenter le nombre de résultats des pages?

Je me pose la question, je vais peut-être tenter l'expérience, passer de 15 a 20 … je ne sais pas. J'ai un peu envie de laisser de côté le SEO interne pour d'autres projets.

Des retours ou autres avis sur le seul effet (positif ou négatif) d'utiliser ou non rel=prev et rel=next sur la pagination?
 
WRInaute discret
longo600 a dit:
Avec Panda 4.0, le texte a pris plus d'importance. Qu'en est-il des listes de type "annuaire" restaurant ou autre, le poids total de la page est-il devenu un facteur majeur, et donc, faut-il augmenter le nombre de résultats des pages?

Juste sur ce point : augmenter le nombre de pages avec un contenu "fin" ("shallow content") n'est pas une bonne solution. Google met la pression sur les annuaires, comparateurs et autres s'ils n'offrent pas une valeur ajoutée (avis, contenus...)
 
WRInaute passionné
Je note que quelques annuaires d'entreprises ont considérablement augmenté le poids de leurs pages, passant d'une vingtaine de résultats par page a 30, 40 ou 50 adresses/page même pour cylex France. Chez ce dernier, on retrouve la pagination prev next.

J'ai du mal a comprendre la logique d'indiquer le next et prev et à la fois devoir alourdir chaque page, la première option (next prev) étant censée englober le volume total du texte de toutes les pages …

Bien d'autres annuaire pro ont augmenté aussi leur volume de texte par page en affichant plus de résultats. J'ai du mal a comprendre l'avantage pour Google.
 
Discussions similaires
Haut