Résolu Autre que canonical pour éviter de référencer du contenu dupliqué.

[steph950]

Bonjour,

j'ai une petite question théorique... Quelle technique peut-on utiliser pour que des sections de page renvoient vers la page de contenu unique?

Je développe:

J'ai différentes lignes du temps, composées d'évènements. Chaque évènement existe sur une page avec une URL unique. Mais chaque évènement peut aussi se retrouver dans différentes timelines, par exemple en fonction d'un range d'années, ou si on consulte tous les évènements pour un personnage spécifique, ou pour un lieu précis, ou encore pour un ouvrage...

Donc en gros je souhaiterais dire aux moteurs de recherche que le contenu d'un évènement se trouve sur une page unique, et que les autres endroits où il se retrouve doivent renvoyer vers la page unique.

Mes explications sont certainement confuses, et je peux préciser si il y a des questions.

Merci d'avance pour votre aide.

 

[Marie-Aude]

Juste mentionner l'événement en faisant un lien vers la page détaillée.

 

[steph950]

Merci pour la réponse, qui est tout à fait juste.
Le problème c'est que le visiteur doit alors cliquer sur chaque lien pour en voir le contenu. Le but des timelines est justement de pouvoir présenter une succession d'évènements et d'en lire le flux de manière chronologique (avec les détails).

 

[emualliug]

Si je comprends bien, tu as une multitude de pages (les timelines) qui chacune affiche un contenu composé d'une succession d'éléments, ces éléments étant identiques d'une timeline à une autre, mais présentés dans un ordre différent suivant la timeline.

Si c'est bien ça, cela s'apparente à une navigation à facette.

 

[steph950]

Merci pour l'info. Etant relativement inculte j'ai dû chercher la définition de la navigation à facette, et c'est exactement ça.

Si j'ai bien compris ce que je viens de lire à propos de la navigation à facettes, ce que je souhaiterais donc c'est :

- éviter de trop diluer le budget crawl sur ces pages qui présentent beaucoup d'évènements (mais qui doivent être indexées car elles contiennent d'autres infos comme par exemple la fiche d'identité d'un personnage en plus des évènements qui le concernent);
- éviter de pénaliser le page rank par tous ces liens qui mènent vers d'autres évènements;
- éviter le duplicate content

Je ne sais donc pas s'il existe une bonne pratique pour que chaque section évènement d'une chronologie (donc au sein d'une même page) dise au moteur que le contenu qu'il contient possède sa propre page unique...

 

[WebRankInfo]

toutes ces pages ont-elles vraiment une bonne raison d'être indexées ? j'en doute, mais sans connaitre le site c'est difficile d'en dire plus

 

[steph950]

toutes ces pages ont-elles vraiment une bonne raison d'être indexées ? j'en doute, mais sans connaitre le site c'est difficile d'en dire plus

Je pense que oui pour certaines d'entre-elles (voir cas n°3 et 4).
Et en effet c'est peut-être plus facile avec un exemple...

1. Un évènement du 31 mai 1977. La page au contenu unique que le robot devrait indexer:
https://www.gaudry.be/bd/event-2337.html

2. Une page qui reprend les évènements de 1977 à 1978, dont celui cité ci-dessus: là je suis entièrement d'accord, je devrais placer une balise meta noindex sur cette page.
https://www.gaudry.be/bd/timeline-evt-1977-1978.html

3. Cet évènement se retrouve avec un grand nombre d'autres dans des pages relatives à un ouvrage (livre ou bd), comme ici la page sur le livre Terres Perdues:
https://www.gaudry.be/livre/la-tour-sombre/terres-perdues.html

4. ... ou encore dans la page d'un personnage qui est concerné par l'évènement, comme ici la page de Mr Bissette:
https://www.gaudry.be/livre/la-tour-sombre/personnages/len-bissette.html

5. Cet évènement se retrouve aussi sur les pages qui décrivent les lieux où se déroule l'action, comme ici la ville de Manhattan (à la rigueur, cette page peut elle-aussi avoir une noindex):
https://www.gaudry.be/bd/personnages/lieu/us/us-ny/93185/

Les pages qui sont les plus problématiques sont dans le 3è cas, et dans une moindre mesure dans le cas n°4.
Comment dire que la partie de l'évènement 2337 ne doit pas faire partie du contenu indexé de la page, mais doit pointer sur la page du cas n°1 ?

J'espère que ces exemples permettent de se faire une idée du problème.
Merci d'avance

 

[emualliug]

Si chaque page timeline a un contenu qui lui est propre, alors elle devrait être indexée.

Vu ton dernier message, je devine que tu as des pages liés à des personnages historiques avec une timeline des évènements de son époque. Ce n'est du coup pas juste une navigation à facette.

Le budget crawl, bien qu'il existe, n'est généralement pas un sujet.

Pour répondre à tes besoins, tout dépend du problème et de tes compétences. Je ne suis pas convaincu que l'évènement doive être intégralement décrit sur la timeline, et si tu estimes que ce serait pas mal pour fluidifier la lecture, permettre plutôt de charger plus de contenu en cours de lecture, par exemple en AJAX lorsque l'internaute "déplie" un élément de la timeline. Généralement, la page est indexée sans le contenu qui dépend d'une action de l'utilisateur, ça évite donc tout à fait le duplicate.

 

[Marie-Aude]

Je suis d'accord avec @emualliug , un résumé de l'événement sur la timeline, et un lien vers l'élément complet, en target= _blank (nouvelle fenêtre)

 

[steph950]

Merci à tous pour vos réponses.

@Marie-Aude, même si je souhaiterais optimiser le SEO, je préfère privilégier l'expérience utilisateur au détriment du SEO si nécessaire (mon site n'a aucune vocation commerciale et ne me rapporte rien; c'est juste un plaisir de partager des informations et le fruit de mes recherches). Donc pour moi, une fois que le visiteur est dans une timeline, je ne veux pas l'obliger à cliquer sur chaque évènement pour en afficher le détail. Ce serait un peu comme si je m'installait dans le divan pour lire un bon livre, mais que le livre ne contenait que des emplacements d'autres livres dans la bibliothèque et que je doive me lever à chaque page pour aller chercher la feuille qui correspond dans la bibliothèque.

@emualliug, si les robots ne prennent pas en compte le contenu qui est ajouté par la suite en ajax, alors c'est une situation qui peut me convenir... Je charge la page avec toutes les cases de la timeline et les dates, et je lance automatiquement en asynchrone le chargement de chaque évènement qui se trouve dans la partie visible du viewport. Ensuite, en scrollant, les autres évènements sont eux aussi chargés en ajax au fur et à mesure...
Je vais plancher sur le problème.

Si le fait de charger automatiquement les évènements en ajax ne change rien au niveau du duplicate content, je pense que je tenterai de déplacer les évènements qui se rapportent à un personnage, un ouvrage, ou un lieu à chaque fois dans une page annexe qui ne contient pas les informations qui doivent être indexées, et mettre un noindex sur cette timeline spécifique, puis je m'attaque au chargement asynchrone.

En tout cas merci à vous pour ces informations, et pour l'aide que vous apportez à tout le monde.

 

[emualliug]

Il faut toujours être prudent sur la manière dont les robots tiennent ou non compte du contenu généré avec JS. Les choses évoluent et sont variables d'un moteur de recherche à un autre, d'une situation à une autre. Il y a une époque, tout ce qui était généré par JS ne pouvait pas être lu par un robot, ce n'est plus le cas pour Google. On considère généralement que les robots peuvent indexer ce qui est chargé par JS sans interaction de l'utilisateur, typiquement au chargement de la page. Faudrait voir ce qu'il en est pour les éléments qui se chargent lors du défilement, je ne serais pas étonné que, dans une certaine mesure, certains éléments soient pris en compte, afin de tenir compte de la pratique du lazy loading. Bref faut voir au cas par cas avec la Search Console quelle est la page telle qu'indexée.

Pour le cœur du problème, il ne faut pas avoir trop peur du duplicate interne. Le risque essentiel c'est que Google ne retienne que la page A lorsqu'il estime que la page A et la page B ont un contenu identique. Finalement, que Google retienne A ou B, dans les deux cas, il retient une page de ton site. Le risque est finalement plutôt faible, alors que d'un autre côté, s'il n'estime pas que les pages sont similaires, il pourrait indexer la page A et la page B.

Il ne faut pas faire sciemment du duplicate, bien sûr, ça envoie un mauvais signal sitewide, le crawl prédictif pourrait être pénalisé, etc. Mais le risque de duplicate me semble parfois surévalué, et en duplicate interne le rapport bénéfice risque n'incite pas à des précautions superflues.

Et finalement, j'en viens à un autre principe général, une sorte de dent d'or de Fontenelle : avant de chercher comment régler un problème il faut s'assurer que ce soit un problème. Quand on est sur un nouveau projet, c'est bien d'anticiper et de se poser des questions dans des termes généraux et abstraits. Mais là ton site existe déjà, tu peux avoir des stats sur l'indexation et la consultation. Est-ce que les pages sont explorées ? sont-elles indexées ? si non, quelle en est la raison ? est-ce vraiment une question de duplicate ?

 

[steph950]

.../ avant de chercher comment régler un problème il faut s'assurer que ce soit un problème /...

J'adore ce genre de raisonnement

En fait c'est probablement une erreur de ma part dû à un manque de connaissance SEO... Je pensais que d'office c'était un problème, mais je vais me pencher sur les stats pour voir si c'est réellement un problème.

PS: je n'arrive pas à trouver le moyen de spécifier que le problème est résolu, en modifiant le titre ou en ajoutant une balise...

 

[Leuf]

[edit] oups dsl mal réveillé ;-)