Comment baliser correctement différentes versions d'un même document qui ne sont pas canoniques

Le cas d'utilisation est un document qui a plusieurs versions qui sont toutes disponibles simultanément. Par exemple, la documentation sur un produit pour chaque version de ce logiciel:

• /v1/install-guide
• /v2/install-guide
• /v3/install-guide

Ce n'est pas le même contenu dans le sens où il serait incorrect de spécifier dans les pages v1 et v2 que l'URL canonique est v3. Si je recherchais dans Google le «guide d'installation du produit v2», je m'attendrais à pouvoir trouver la v2. Chaque version du document serait légèrement différente, mais elles auraient beaucoup de points communs.

La question est donc: puis-je baliser ces pages d'une manière ou d'une autre pour signaler à Google et à ses amis que la dernière version (v3) est préférée, donc une simple recherche de 'guide d'installation du produit' est plus susceptible d'afficher la page v3 au lieu de la page v1 ou v2?

compte tenu de votre question, je dois faire les hypothèses suivantes:

1. votre site Web propose une section pour les guides d'installation d'un produit
2. les guides diffèrent de la version du produit mais restent pertinents pour les clients utilisant des versions de produit plus anciennes
3. vos clients le savent et savent exactement de quelle version ils peuvent avoir besoin

Premièrement: ce n'est en effet pas le cas d'utilisation pour a rel="canonical".

Une approche pour gérer des situations comme la vôtre est la structure: vous pouvez implémenter une page de guide statique pour votre produit qui contient toujours le guide le plus récent. Cette page est liée à la page produit ou catégorie, elle gagne donc beaucoup d'importance.

Schème:

exapmle.com/product/guide/
exapmle.com/product/guide/guide-v1
exapmle.com/product/guide/guide-v2
exapmle.com/product/guide/guide-v3

Chaque fois qu'un nouveau guide est publié, il est publié sur la page statique et l'ancien descend vers une nouvelle URL plus en profondeur dans la structure d'URL. Ces URL "ancien guide" sont liées à partir de la page statique, mais pas à partir des pages de catégorie. Ils seront donc considérés comme "moins importants"

Assurez-vous que les v1, 2, 3, … nversions ne sont liées qu'à partir de la page principale des guides et chacune à chacune. La page principale doit être bien reliée à l'ensemble de votre site.

Par rapport à votre structure d'URL existante, cela donne plus de pertinence au guide publié sur exapmle.com/product/guide/.

• /v1/install-guide
• /v2/install-guide
• /v3/install-guide

Dans cette structure, chaque URL "vaut" la même chose et Google doit s'appuyer sur d'autres signaux pour décider quelle URL est la plus pertinente.

L'étape suivante consiste à optimiser les pages de guide de manière à ce que les moteurs de recherche comprennent rapidement la différence entre les versions individuelles:

• individualiser le titre de la page, par exemple: <title>Version 1.0 install Guide for Product XY</title>
• individualiser l'en-tête principal de la page, par exemple: <h1>How to Install Version 1.0 of Product XY</h1>
• individualiser la description de la page, par exemple: <meta name="description" content"Here you can find your guide to install version 1.0 of Product XY […]" />
• utiliser les textes d'ancrage pour indiquer différentes versions lors de la liaison aux guides <a href="http://example.com/product/guide/guide-v2" >Install guide for V 2.0</a>

Chacun pour indiquer la version pour laquelle il a été conçu et peut-être l'année / le mois / la date.

Astuce: il peut être utile de souligner les différences en haut des pages individuelles. Ainsi, les clients peuvent facilement comprendre pourquoi ils ont besoin de guides différents et les moteurs de recherche obtiennent des informations supplémentaires et un contenu unique pour chaque page, ce qui réduit le risque de problèmes de «contenu presque dupliqué».

De cette façon, vous vous assurez que le guide le plus récent est toujours présent example.com/product/guide/et servira de résultat pour les recherches génériques comme " installer le produit du guide ". Les moteurs de recherche reconnaîtront que le contenu de cette page est mis à jour fréquemment et reconnaîtront également que des sous-éléments de ces pages existent et les serviront pour des termes de recherche plus spécifiques tels que " guide d'installation du produit V 2.0 ". En optimisant les pages pour les versions spécifiques qu'elles représentent, vous vous assurez que les clients trouvent leur version en la recherchant.

Je n'ai vu aucun moyen technique éprouvé qui indiquerait à un moteur de recherche qu'une certaine version d'un guide ou d'une page est plus récente que la date mentionnée par norcal johnny.

Cependant, j'ai remarqué que dans de nombreux cas, la version plus ancienne inclura un avertissement en haut disant, allez là-bas pour la version plus récente. Un peu compliqué si vous utilisez la version que vous regardez maintenant, mais excellent si vous essayez d'évaluer un produit et que vous voulez vous assurer que vous regardez la dernière.

Le premier site Web où j'ai vu cette pratique se produire clairement était le W3C. Par exemple, ce document a une "dernière version" en haut: https://www.w3.org/TR/html401/

Maintenant, je l'ai remarqué sur MSDN, où ils ont un lien nommé "Version recommandée". https://msdn.microsoft.com/en-us/library/78zh94ax%28v=vs.71%29.aspx

De toute façon, je n'ai vu aucun type de HTTP ou HTML technique qui pourrait être utilisé pour l'indiquer. Il y a une balise de lien avec le rel = "alternative" qui peut fonctionner, mais d'après ce que je comprends, cela ne fonctionne vraiment que pour les langues ou d'autres versions différentes du même document, pas diverses versions différentes.

Il y a une autre technologie avec laquelle Google a essayé et je suis sûr qu'ils l'utilisent toujours, c'est http://schema.org qui se trouve avoir une balise https://schema.org/softwareVersion . En supposant que Google ait implémenté cette balise spécifique, il devrait comprendre votre schéma de version. En suivant la perspicacité de Seb, ayant une page / guide, vous pourriez alors avoir des liens vers chaque version. Le lien serait étiqueté avec un schéma pour inclure ces softwareVersioninformations. Cependant, cette version n'accepte que du texte me faisant penser que c'est une description ("Meilleure version jamais!") Du logiciel et non une version réelle (1.0, 2.3, 3.7.1 ...) Mais que je pense que ce serait probablement le meilleur tu peux faire.

J'ai vu des cas comme le vôtre lors de la navigation dans la documentation technique comme les documents Django .

Il n'y a pas de balise spécifique à ajouter dans ce cas, mais vous pouvez utiliser les stratégies suivantes pour indiquer à Google que vous préférez le lien v3 (la dernière version):

Liens sans versions

• Lorsque vous faites référence à ce contenu en dehors de la portée de la v3, utilisez des liens sans versions qui redirigent automatiquement vers la page de la dernière version, par exemple:

  example.com/install-guide - redirige vers la dernière -> example.com/v3/install-guide

Lorsque vous avez une version plus récente (v4), elle sera redirigée vers example.com/v4/install-guide.

Alertes avec liens vers la dernière version

• toujours afficher la version disponible de votre documentation afin que l'utilisateur puisse facilement décider laquelle utiliser et s'il visite une ancienne version, vous pouvez afficher une alerte indiquant qu'il n'est pas sur la dernière version et ajouter un lien vers le lien sans la version dans le url, Google saura que ces anciennes pages de version font référence à la dernière, ce qui leur donne implicitement plus de poids pour décider laquelle sélectionner. Dans ce cas, la dernière version sera toujours référencée par les autres.

Lorsque Django déprécie une version, il la montre clairement à l'utilisateur, dans votre cas, vous pouvez également ajouter le dernier lien de version dans l'alerte.

Nouveaux liens

• les nouveaux liens (contenu plus récent ou versions plus récentes dans votre cas) obtiendront naturellement plus de traction que les anciens.

Chaque fois que je recherche des informations sur l'API FB, cela me renvoie les dernières informations avec la dernière URL de l'API, et ils n'utilisent aucune redirection ni balise de lien canonique qui pointe vers les dernières informations, ce qu'ils font simplement, ils commencent à pointer vers les dernières informations partout, donc Google explorera cela plus souvent et transmettra plus de juicyrank, c'est le seul signal que vous pouvez également utiliser pour votre site Web. Vous avez le contrôle sur vos liens, alors utilisez-le.

N'utilisez pas noindex, redirection 301 et balise de lien canonique sur les anciennes pages qui pointent vers la dernière URL, cela rendra votre page Web morte aux yeux du moteur de recherche Google, je veux dire que Google supprimera tous les avantages initiaux qui sont accordés à cette page Web. J'ai demandé récemment sur le hangout officiel de Google et ils ont dit qu'ils ne donnent aucune valeur PR initiale pour la balise noindex, donc je pense que cela s'appliquera également à la balise de lien canonique. et lorsque vous effectuez une redirection 301, tous les RP passeront à la nouvelle URL, et tout PR initial donné à cette ancienne page Web sera supprimé car il n'est plus disponible. Google donne une certaine valeur aux pages Web en ligne.

Vous n'avez pas vraiment besoin de modifier votre balisage. Les sites de commerce électronique affichent le même type de page Web sur deux URL différentes pour cibler deux pays, et ce qu'ils changent n'est que le prix actuel. Par exemple, pour les États-Unis, c'est le dollar et pour l'Inde, c'est le roupie, et tout le reste est le même, et ce genre de site Web n'a pas été sanctionné par Panda.

Vous pouvez utiliser les dates de page pour le tri.

Google estime une date de page en fonction des fonctionnalités de la page telles que les dates dans le titre et l'URL.

La recherche personnalisée vous permet d'utiliser cette date pour trier, biaiser et restreindre les résultats en utilisant une clé de métadonnées spéciale de date. Cette date estimée peut être utilisée dans tous les opérateurs qui utilisent le &sort=paramètre URL, y compris "Trier par attribut", "Biais par attribut", "Limiter à la plage".

Par exemple:

Pour obtenir la liste des codes actuels, consultez la documentation de Google Custom Search .