web-dev-qa-db-fra.com

Utilisation de rel = prev / next / canonical avec la pagination du contenu fréquemment mis à jour

Je ne comprends pas ce qui serait le bon balisage pour une série paginée, même après avoir lu pas mal de conseils, notamment sur Google.

La sagesse commune semble être la suivante:

  • Utilisez rel="next" pour pointer sur chaque page suivante d'une série, rel="prev" pour revenir en arrière.

  • Soit rel="canonical" chaque page paginée à elle-même OR rel="canonical" dans une version "wiew all" OR ne le fait pas du tout.

Mon problème est que cette configuration semble supposer une configuration plutôt statique, telle que les magasins en ligne.

Mais qu'en est-il des blogs/publication?

Tout d'abord, les publications sont affichées les plus récentes en premier, donc rel = "next" pour les publications précédentes n'est pas trop intuitif, c'est le moins que l'on puisse dire. Wolud serait-il plus utile s'il était rel = "prev" pour les entrées plus anciennes?

Deuxièmement, le contenu étant constamment mis à jour, le contenu d'une URL paginée changera à chaque publication publiée jusqu'à ce que la page 2 devienne page 3, etc. Ces pages méritent-elles même un lien indexé?

Troisièmement, un "tout voir" n'est certainement pas une option avec des centaines de messages ou plus.

Alors, quel est le meilleur itinéraire à prendre?

  1. Suivez la sagesse commune.

  2. Inversez simplement la direction pour vous assurer que les anciens messages sont "prev" et les plus récents sont "prochains".

  3. Rel-canoniques pages à la page d'entrée sans prev/next.

  4. Rel-canonique à la page d'entrée, mais utilise aussi prev/next.

  5. Noindex et/ou nofollow toutes les pages suivantes et les oublie.

Ou autre chose?

Mise à jour - comportement attendu de l'utilisateur:

Les archives paginées ne constituent pas un contenu unique, mais plutôt une référence rapide pour ce qu’un site (ou un auteur, etc.) avait écrit dans le passé.

Ainsi, les lecteurs, par exemple Cliquez sur le nom d'un auteur pour voir ce qu'il a écrit d'autre et obtenir ainsi les dernières entrées. S'ils veulent voir encore plus, ils utiliseraient la pagination.

Si quelqu'un arrive à la liste via Google (après, disons, la recherche d '"articles par X"), c'est très bien aussi. Mais je vois peu d'intérêt chez les personnes qui atterrissent sur example.com/author-X/page/3 simplement parce qu'elles ont cherché "des articles de X sur les zèbres" et que c'est là que l'un des messages zébrés est actuellement indexé. Dans ce cas, je préférerais que Google amène le chercheur au poste de zèbre lui-même.

seometa-tagspaginationrel-canonical
4
Lucian Davidescu

Ok, donc ce que j’ai fait à la fin a été de prendre le long chemin. Pour celui-ci, j'utiliserai les archives datées pour la pagination et lierai la série à la page d'accueil comme point de départ. Donc, mon code qui va dans l'en-tête ressemble à ceci:

<? if(is_home()) { ?>
<link rel="prev" type="text/html" href="/<? echo date('Y-m-d'); ?>" /> 
<? } 
if(is_day()) { 
$date = isset($_GET['date']) ? $_GET['date'] : get_the_time('Y-m-d'); 
$today = date('Y-m-d');
$oldest = '[get the date of the first post somehow or just hardcode it as I did]'; 
if ($date != $oldest) { ?>
<link rel="prev" type="text/html" href="/<? echo date('Y-m-d', strtotime($date .' -1 day')); ?>" /> 
<? } if ($date != $today) { ?>
<link rel="next" type="text/html" href="/<? echo date('Y-m-d', strtotime($date .' +1 day')); ?>" /> 
<? } if ($date == $today) { ?>
<link rel="next" type="text/html" href="/" /> 
<? } } ?>

Cela fonctionne bien pour le concept actuel, car il n'y aura pas moins de 10 et pas plus de 20 messages par jour.

Avantages

  1. Maintenant, les choses ont beaucoup plus de sens, car "précédent" est toujours une date dans le passé.

  2. Le contenu reste en place, il est donc logique d’avoir un rel = canonique sur chaque page, tandis que rel = prev/next indique à Googlebot qu’il fait partie d’une série.

  3. Se débarrasser des liens de pagination classiques pour éviter les doublons. Habituellement, on garde ces archives et on supprime les archives pour atteindre le même objectif, mais je pense que c'est ainsi plus intuitif.

mises en garde

  1. Vous devez publier au moins un message chaque jour, sinon la chaîne sera brisée. Cela peut être résolu avec plus de codage (seulement obtenir les dates avec les articles publiés), mais je n'ai pas besoin de ça moi-même.

  2. Le premier message de la journée devrait être publié exactement à minuit, sinon la page d'accueil indiquera une archive vide jusqu'à ce que vous publiez quelque chose. Encore une fois, plus de code résoudrait cela aussi.

  3. Le faire pour chaque terme de taxonomie est possible mais un peu plus compliqué (retour aux n ° 1 et n ° 2). Pour le moment, je préférerais que la limite de boucle soit fixée à 100 environ sur les archives et que je voie plus tard où cela se passe.

Conclusion

Fondamentalement, les pages archivées en incréments fixes ne sont pas optimales pour la publication - les archives basées sur la date sont un peu meilleures, mais pour le moment, vous êtes autonome.

0
Lucian Davidescu

Tout d'abord, les publications sont affichées les plus récentes en premier, donc rel = "next" pour les publications précédentes n'est pas trop intuitif, c'est le moins que l'on puisse dire. Wolud serait-il plus utile s'il était rel = "prev" pour les entrées plus anciennes?

rel="next" spécifie l'élément suivant d'une séquence logique, cela ne signifie pas "les nouveaux articles publiés", mais "la page suivante de cette série de pages", qui dans ce contexte est le page de publication précédente

Deuxièmement, le contenu étant constamment mis à jour, le contenu d'une URL paginée changera à chaque publication publiée jusqu'à ce que la page 2 devienne page 3, etc. Ces pages méritent-elles même un lien indexé?

Si avoir une liste de publications pour chaque auteur, de l’ancien au plus récent, est logique, leurs pages seront "corrigées" et vous n’auriez plus le problème du contenu changeant des pages.

Si l'ordre de vos listes de publication va du plus récent au plus récent au plus ancien , vos listes paginées contiendront une liste des publications qui modifieront souvent leurs URL, comme vous le dites. , Google le détectera et augmentera leur vitesse d'exploration, en leur rendant visite souvent.

D'après mon expérience personnelle, il est peu probable que vous consultiez une liste paginée de pages désynchronisée, ou même une page de cette liste provenant de Google. Il m'est arrivé dans les messages de forum que la page en cache dans Google ne contienne parfois pas le message I cherchais mais c'était sur des pages plus anciennes dans le fil.

Dans l’exemple que vous avez donné, recherchez les "articles de X sur les zèbres". Il serait donc plus logique que Google affiche directement le lien vers le message sur les zèbres dans SERP, qui aura également l’auteur dans la page, au lieu d’un lien. à la poste dans une liste de publications d’auteurs (mais cela dépend des titres et de la description de la liste/de la publication).

Troisièmement, un "tout voir" n'est certainement pas une option avec des centaines de messages ou plus.

Comme conseils pour les webmasters suggère:

Limitez le nombre de liens sur une page à un nombre raisonnable (quelques milliers au plus).

Ma suggestion est:

  • gardez la commande du plus récent au plus ancien, car c'est ce que les gens attendent des listes de messages dans les blogs (et non l'inverse)
  • implémentez rel="next" et rel="prev" liens pour indiquer la relation entre les URL et la confiance que Google continuera à analyser régulièrement.
  • Surveillez les requêtes de recherche et les pages de destination dans Search Console pour voir si vous recevez du trafic vers votre contenu paginé ou directement vers les publications.
3
marcanuy

Mais qu'en est-il des blogs/publication?

Vous semblez mal comprendre ce que rel next/prev est pour.

Chaque fois que vous divisez du contenu, vous pouvez suggérer à Google de créer une méta-publication volumineuse au lieu d'indexer chaque page en tant que contenu distinct. Sinon, la page 2 de votre guide sera fortement indexée pour le mot clé xxx, alors que les utilisateurs doivent le lire depuis le début pour obtenir le contexte.

Les articles de votre blog ne constituent pas un contenu volumineux. Ils sont beaucoup de pièces séparées. Ne tenez pas compte de la manière dont un utilisateur peut naviguer entre les contenus et concentrez-vous sur le fait d’atteindre ou non le contenu de plusieurs pages.

Voici un exemple où prev/next est nécessaire: un article publié sur 10 pages intitulé "Comment nettoyer votre code Javascript". Ou un répertoire statique de 3 000 liens populaires, qui a été divisé en 30 pages de 100 liens.

0
L Martin