Discourse répondra désormais avec un en-tête X-Robots-Tag: noindex lorsque la page demandée n’est pas la page canonique d’une ressource.
Bien que Discourse utilise une conception à défilement automatique pour les listes de sujets et les sujets, ce n’est pas ce que nous montrons aux robots d’exploration des moteurs de recherche, comme GoogleBot. Les moteurs de recherche voient des sujets paginés, avec 20 messages dans chaque page. Cependant, comme les utilisateurs peuvent lier des messages spécifiques dans leurs propres messages et le feront en utilisant le format d’URL /t/title/topic_id/post_id, ceux-ci seront capturés par les robots d’exploration et ajouteront du contenu dupliqué dans les résultats de recherche de votre site et gaspilleront le budget d’exploration précieux et limité que votre domaine possède.
Pour atténuer ce problème, notre communauté d’utilisateurs a suggéré d’ajouter le X-Robots-Tag: noindex aux URL telles que les URL spécifiques aux messages, que nous avons réussi à étendre à toutes les URL non canoniques dans Discourse. Ceci a été publié en tant que paramètre de site caché et désactivé par défaut il y a 3 mois, période pendant laquelle nous avons expérimenté l’activation de cet en-tête sur les sites communautaires ainsi que sur meta.discourse.org.
Étant donné que les résultats de cette période semblent bons jusqu’à présent, nous avons activé ce paramètre par défaut.
Si, pour une raison quelconque, vous ne souhaitez pas ce comportement sur votre instance, vous pouvez toujours activer l’indexation des pages non canoniques en exécutant docker exec -i app rails runner \"SiteSetting.allow_indexing_non_canonical_urls = true\" sur votre serveur.
Ne vous attendez pas à des changements drastiques sur le crawl et les résultats de recherche du jour au lendemain, mais au cours des prochains mois, vous devriez constater une diminution des crawls et des résultats de recherche sur les pages spécifiques aux messages, ce qui se traduira par plus de temps d’exploration consacré aux nouveaux sujets de votre site et au contenu qui n’a pas encore été indexé en raison des contraintes de budget d’exploration sur votre domaine.
TL;DR : Ne bloquez pas les pages non canoniques - pointez-les simplement vers une URL correcte via \u003clink rel=\"canonical\" … \u003e - c’est à cela qu’elle sert.
Cette fonctionnalité pourrait nuire au SEO et à la création de liens à long terme :
Tous les liens profonds vers les réponses à l’intérieur des sujets sont désormais sur des pages noindex ! Google apprécie-t-il cela ?
En fait, une balise canonical pointant toujours vers l’URL du sujet - même pour les pages de liens profonds vers une réponse - devrait parfaitement faire l’affaire - sans ajouter X-Robots-Tag: noindex :
Lors du premier parcours d’une page de réponse avec lien profond, Google reconnaît que l’URL de la page (réponse dans le sujet) ne correspond pas à l’URL canonique et décide alors de ne parcourir que l’URL canonique (sujet).
Pouvons-nous ajouter \u003ca rel=\"nofollow\" … \u003e à tous les liens effectuant ce lien profond sujet-réponse ? Edit : non, voir Search engines now blocked from indexing non-canonical pages - #9 by j127
Nous pourrions ainsi économiser davantage ce budget d’exploration précieux et limité des moteurs de recherche :
le moteur de recherche n’extrairait pas le lien en premier lieu, ni n’appellerait l’URL. L’appel à l’URL entraînant une réponse avec un en-tête http X-Robots-Tag: noindex provoquant le “rejet” de la réponse en ajoutant l’URL à la liste interne “noindex” des moteurs de recherche.
Quelques économies supplémentaires sur le budget d’exploration avec nofollow ajouté aux URL des flux RSS :
Je pense que la fonctionnalité ne devrait pas être activée par défaut. C’est dangereux du point de vue de la circulation, même si elle n’est activée que pendant une courte période, donc toute personne qui met à jour maintenant pourrait avoir une mauvaise surprise.\n\nLa balise canonical est la méthode que Google recommande pour résoudre ce problème, et elle semble déjà fonctionner. Faire des choses étranges avec les balises canoniques peut entraîner des problèmes étranges avec Google, et une erreur noindex pourrait être difficile à corriger.
Je suis d’accord avec la première partie de votre message, mais je ne pense pas que le nofollow interne soit idéal. Les liens internes aident à indiquer aux moteurs de recherche quelles pages du site sont importantes. Google ne suivra pas tous les liens qu’il voit, car il sait qu’il les a déjà vus. S’il voit une URL comme example.com/t/1234/5 mais qu’il l’a déjà explorée et sait que son URL canonique est example.com/t/1234, il ne gaspillera probablement pas ses ressources informatiques à visiter plusieurs fois la version non canonique.
Supprimer ‘noindex’ pour les URL liées par des sites Web externes
Désolé, par « réponses », j’entends « messages » dans un sujet :
Tous les liens profonds provenant de domaines externes vers des messages (par exemple, forum.example.com/t/example-topic/5/11) ont maintenant un en-tête http X-Robots-Tag: noindex ! Je suggère de supprimer à nouveau cet en-tête http.
Je suggère que rel="canonical" … n’utilise jamais d’URL avec une ancre de message (le dernier nombre dans …/t/example-topic/1234/5). Les URL canoniques doivent toujours pointer vers l’URL du sujet elle-même (…/t/example-topic/1234). Je pense que c’est déjà implémenté comme ça.
Réécrire les liens pour les moteurs de recherche si l’URL cible est « redirigée » par rel="canonical" …
Très bon point, il vaut mieux ne pas ajouter rel="nofollow" ici.
Discourse a une vue spéciale pour les robots d’exploration. Nouvelle suggestion pour la vue des robots d’exploration uniquement :
Convertir tous les liens internes pointant vers une URL de message (example.com/t/1234/5) pour qu’ils pointent plutôt vers l’URL du sujet correspondante (example.com/t/1234).
Intention : Ne pas annoncer d’URL supplémentaires aux moteurs de recherche lorsque ces URL supplémentaires sont de toute façon « redirigées » par rel="canonical" ….
Emplacements où de tels liens vers des messages sont trouvés :
liens ajoutés manuellement dans le contenu utilisateur
liens générés automatiquement dans
citations
premier message du sujet : « liens entrants suivis » d’autres sujets
premier message du sujet : « réponse sélectionnée »
premier message du sujet - carte du sujet ouverte : « liens de sujet »/« liens aimés »
Excursus : Où Google trouve-t-il toutes ces URL ?
« Liens entrants suivis » pour les moteurs de recherche
Pour cette raison exacte, les « liens entrants suivis d’autres sujets » générés automatiquement sur le premier message d’un sujet devraient également être visibles par les moteurs de recherche. Actuellement, ces « liens entrants suivis » sont manquants dans la vue des robots d’exploration. Édition : Ils sont déjà dans la vue des robots d’exploration.
Mais pointant vers l'URL du message au lieu de l'URL du sujet (voir source html)
<div class="crawler-linkback-list" itemscope="" itemtype="http://schema.org/ItemList">
<div itemprop="itemListElement" itemscope="" itemtype="http://schema.org/ListItem">
<a href="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26" itemscope="" itemtype="http://schema.org/DiscussionForumPosting" itemprop="item">
<meta itemprop="url" content="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26">
<span itemprop="name">Suppression des liens /2, /3, /4, etc. pour chaque réponse dans l'URL d'un sujet</span>
</a>
<meta itemprop="position" content="2">
</div>
</div>
C’est un point crucial. C’est une chose d’obtenir l’indexation de toutes vos pages et une autre d’obtenir un classement pertinent pour celles-ci. D’après mon expérience (avec de grands sites éditeurs), le maillage interne intelligent est la clé pour y parvenir.
Pour tous ceux qui mettront à jour leur site après la date de publication de l’OP.
Nous avons des données qui montrent que le nouvel en-tête réduit le temps d’exploration de ces pages, et qu’elles avaient toujours le canonique défini.
Mais ces pages ne sont de toute façon pas destinées à être explorées. Les métadonnées avec l’URL sont définies au niveau du sujet, nous ne voulons pas que Google explore le niveau du message car il s’agit d’un contenu dupliqué.
Génial, donc rien à changer ici.
Faire cela à l’exécution peut coûter trop cher en CPU, et sauvegarder deux versions de chaque message coûtera cher en disque.
Nos paramètres par défaut sont toujours ce que nous recommandons. Cependant, nous maintenons et annonçons les paramètres du site afin que les gens puissent choisir autrement s’ils estiment qu’un paramètre par défaut n’est pas idéal pour leur site.
Alors pourrait-il y avoir des problèmes avec sitemap_recent.xml qui contient de tels liens ? https://meta.discourse.org/t/category-moderator-improvements/158628?page=2
Je vois une énorme différence lorsqu’il y a un lien externe vers une URL de publication.
# A :
Domaine externe
|
|--(jus de lien)---> URL de la publication
|
|__/ exploration : \---> URL de la publication non indexée et
\ en-tête noindex / jus de lien majoritairement perdu
# B :
Domaine externe
|
|--(jus de lien)---> URL de la publication
|
|__/ exploration : \__|---> URL de la publication non indexée
\ réponse canonique / |---> URL du sujet indexée (de toute façon)
avec transfert de jus de lien
Pour les néophytes comme moi en matière de SEO, cela implique-t-il une amélioration du SEO qui pourrait potentiellement entraîner une légère augmentation/un bénéfice dans les résultats de recherche Google ?
Nous avons testé le changement dans une communauté d’actualités technologiques pendant quelques mois, et nous avons constaté une augmentation importante d’un pic à l’autre des pages vues anonymes. Notre objectif final est toujours de rendre toutes les communautés Discourse plus saines sur tous les fronts.
… Je suggère l’implémentation suivante pour obtenir le meilleur compromis :
N’ajoutez pas d’en-tête http X-Robots-Tag: noindex.
– en tenant compte de [E] –
Gardez les balises canonical pointant toujours vers l’URL du sujet.
– réduction des explorations [A] et prise en compte de [C] –
Uniquement pour la vue de l’explorateur : Convertissez les liens générés automatiquement pour qu’ils pointent toujours vers l’URL du sujet au lieu de l’URL de l’article – pour tous les liens dans le premier article du sujet « liens entrants suivis depuis d’autres sujets » et « carte du sujet ouverte : lien de sujet/liens aimés ».
– réduction des explorations [A] et prise en compte de [D], mais en ignorant délibérément [B] –
Concernant [B] : les dépenses CPU concernent uniquement les visites de l’explorateur et consistent à effectuer un remplacement d’expression régulière pour supprimer le dernier nombre des URL internes se terminant par deux chiffres, par exemple …/t/exemple-sujet/1234/5 → …/t/exemple-sujet/1234 dans les limites du premier article du sujet « liens entrants suivis depuis d’autres sujets » et « carte du sujet ouverte » uniquement.
Pour toutes les vues : ajoutez un nofollow interne aux citations et aux liens ajoutés manuellement dans le contenu utilisateur.
– réduction des explorations [A] et prise en compte de [B], mais en ignorant légèrement [D] –
Concernant [D] : les liens importants sont déjà dupliqués automatiquement vers le premier sujet dans la section « carte du sujet ouverte : lien de sujet/liens aimés » [voir 3.] et la plupart des citations restent de toute façon à l’intérieur du sujet lui-même.
Pour Google, le lien pointe directement vers l’URL canonique du sujet …/1234 – et Google ne connaîtra pas l’URL de l’article …/1234/5 à partir de cette syntaxe de lien.
Pour la navigation utilisateur, un JavaScript supplémentaire dans l’application Ember fera l’affaire :
par exemple, remplacez href par routerLink.
Important
