manuboss
À ce jour, vous avez probablement entendu dire que Google est ne plus soutenir rel = prev / next balisage. En fait, Google ne le supporte pas depuis des années.
C’est regrettable, car Google a oublié de le dire à personne. De nombreux stratèges numériques mettaient en œuvre rel = prev / next Code pensant qu'il offrirait un avantage de référencement.
Cela s'est fait à un moment donné. Ce n’est plus le cas.
Alors, qu'est-ce-qu'il s'est passé? Et que devriez-vous faire maintenant?
Dans cet article, je reviens sur la récente annonce de Google concernant ce changement. Je vais aussi expliquer ce que l’élimination de rel = prev / next des moyens pour le référencement.
Comment nous sommes arrivés ici
Retour en 2011, Google a présenté le rel = prev / next balisage. C'était un moyen d'informer Googlebot que la page Web faisait partie d'une série.
Par exemple, si vous avez écrit plusieurs articles de blog sur toutes les bases du référencement, vous pouvez inclure un article sur la recherche par mot clé, un autre article sur le référencement sur site, un autre article sur le backlinking, etc.
Dans ce cas, vous utiliseriez le rel = prev / next balisage pour identifier les articles suivants et précédents de la série.
Ce n’était pas simplement une bonne idée pour les articles de blog. Les sites de commerce électronique ont utilisé le balisage pour identifier les produits qui appartenaient tous à la même catégorie.
Jusque récemment, Google incluait dans sa page d’aide Webmasters une documentation dans laquelle il était expressément indiqué aux propriétaires de sites Web rel = prev / next balisage. Il se lit comme suit:
Utilisation rel = "next" et rel = "prev" liens ou en-têtes pour indiquer la relation entre les URL des composants. Ce balisage indique clairement à Google que vous souhaitez que ces pages soient traitées comme une séquence logique, consolidant ainsi leurs propriétés de liaison et envoyant généralement les chercheurs à la première page.
Maintenant, toute cette page a disparu. Pire encore: Google l'a supprimé sans le dire à personne Pourquoi.
Finalement, le compte Twitter officiel de Google Webmasters a publié la déclaration suivante:
"Nettoyage de printemps! Après avoir évalué nos signaux d’indexation, nous avons décidé de prendre notre retraite rel = prev / next. Des études montrent que les utilisateurs aiment le contenu d'une seule page; visez-le lorsque cela est possible, mais plusieurs parties sont également acceptables pour la recherche Google. Connaissez et faites ce qui est le mieux pour * vos * utilisateurs! "
Avez-vous besoin de supprimer le code de votre site?
Non, vous n’avez absolument pas besoin de retirer le rel = prev / next balise de votre site si vous l'avez.
Pourquoi? Parce que tout simplement, il ne faut pas blesser de le laisser là.
De plus, Google n'est pas le seul moteur de recherche en ville. Et Frédéric Dubut de Bing est enregistré en disant que son moteur de recherche utilise toujours rel = prev / next balisage "pour la découverte de la page et la compréhension de la structure du site."
La bonne nouvelle est donc que vous n’avez pas besoin de revenir en arrière et de mettre à jour toutes vos anciennes pages qui utilisent le balisage depuis 2011.
Ouf.
Mais vous devriez? C'est une question différente qui devient un peu délicate. J'ai déjà envisagé cela et fait une étude à ce sujet.
Qu'est-ce que ce changement signifie pour le référencement?
Avant de répondre à cette question, permettez-moi de préciser une chose: il ne semble qu'aucun professionnel du référencement n'ait remarqué que Google avait cessé de soutenir la rel = prev / next balisage d'un point de vue d'indexation.
Ce n’est que lorsque quelqu'un a vu que le Big G avait tiré la page de documentation que les gens ont commencé à poser des questions.
Alors peut-être devrions-nous poser la question philosophique: "Si Google supprimait une fonctionnalité et que personne ne la remarquait, était-elle vraiment présente?"
Mais cela signifie que Google indexera la page de catégorie au lieu de la pagination.
Ce n’est pas un problème, cependant. Selon Ilya Grigorik, ingénieur en performance Web chez Google, Googlebot est suffisamment intelligent pour trouver vos pages suivantes / précédentes avec un signal clair.
Rappelez-vous: le bot est déjà évaluer tous les liens sur votre site. Si vous avez structuré votre site Web de manière à ce qu’il soit convivial et pratique en ce qui concerne les liens internes, Google trouvera le contenu associé et le classera.
Quelques conseils sur l'optimisation des catégories
Maintenant que rel = prev / next est parti, que pouvez-vous faire pour optimiser vos pages de catégorie? Voici quelques indications.
Premier, assurez-vous que vous avez la plupart de votre contenu sur la première page de la catégorie. Cela va aider à l’indexation. Par contenu, je veux dire du texte, des images et des vidéos.
Non seulement cela, mais cela aidera avec l'indexation pour les bons termes de recherche. Une fois que les personnes accèdent à votre page de catégorie, elles peuvent trouver d'autres pages.
Suivant, optimiser votre image sélectionnée sur votre page de catégorie principale. Oui, je vous recommande d’avoir une vignette optimisée avec un mot-clé dans le nom du fichier et le texte alternatif. Cela donne à Google des informations supplémentaires sur la nature de vos pages.
En outre, les images optimisées généreront du trafic depuis Google Image Search.
Après cela, vous devriez aussi ajoutez autant d'articles que possible à votre page de catégorie sans trop la ralentir.
Celui-ci peut être délicat dans certains cas. Et si vous avez 10 000 articles dans une seule catégorie?
Voyez si vous pouvez les diviser en sous-catégories. Ensuite, incluez un représentant de chaque sous-catégorie sur la page de catégorie.
En ce qui concerne le commerce électronique, récemment, j'aime bien avoir entre 30 et 60 produits dans une catégorie. De plus, je ne créerai pas de sous-catégorie à moins d’avoir cinq produits uniques.
La question à un million de dollars, vous débarrassez-vous de rel next rel prev?
Eh bien, puisqu'il existe déjà un canonique, Google attribuera simplement toute la valeur à la première page. Donc, vous avez la possibilité de.
- Gardez-le en place et faites-le fonctionner comme un vrai canonique.
- Se débarrasser de rel next rel prev et le traiter de la même manière, mais ne vous inquiétez pas du code hérité.
- Mettez en place un non index sur toutes les pages sauf la catégorie. Cela plaît à certaines personnes, car si vous utilisez le bloc no index ou un bloc robots.txt, vous économiserez un certain budget d'analyse, ce qui signifie que Google n'explorera pas autant la pagination.
Personnellement, j'aime bien l'option 2.
Envelopper
Je pourrais vous donner 20 astuces supplémentaires sur l'optimisation des catégories dans cet article. Des choses comme l’ajout de dates aux titres, le test de numéros dans divers éléments du modèle, l’ajout de schéma et le contenu unique. Mais je vais garder ça pour un autre post.
Ce que vous devez savoir aujourd’hui, c’est que Google a tout gâché et a oublié de vous dire qu’il ne prend plus en charge rel = prev / next balisage. Ce n’est pas la fin du monde.
N'hésitez pas à laisser le code de marquage sur votre site ou sélectionnez une autre option ci-dessus. Le choix vous appartient. Mais une chose est sûre, assurez-vous d'indiquer clairement à Google quelle page correspond à Page un. Cela aidera votre classement.
Les opinions exprimées dans cet article sont celles de l'auteur invité et pas nécessairement celles du moteur de recherche. Les auteurs sont répertoriés ici.
A propos de l'auteur
John Lincoln est PDG de Ignite Visibility, professeur de marketing numérique à l'Université de Californie à San Diego et auteur du livre Digital Influencer, Guide pour atteindre le statut d'influenceur en ligne. Tout au long de sa carrière, Lincoln a travaillé avec des centaines de sites Web, allant des start-ups aux noms de famille, et a remporté des prix en référencement, en CRO, en analyse et en médias sociaux. Dans les médias, Lincoln a été présenté sur des sites tels que Forbes, le magazine Entrepreneur, le magazine Inc., le magazine CIO, etc.
