Améliorations du schéma du forum de discussion

Soutien
26

Veuillez laisser l’URL là même si elle est bloquée. Vous pouvez discuter si cela a du sens ou non pour vos cas d’utilisation de forum, mais même si le crawl est bloqué, cela peut aider à la désambiguïsation.

6 « J'aime »
Applying Schema.org on the user profile page for improved author authority on Google
27

Ce n’est toujours qu’une demande polie, et même Google ne la respecte pas toujours. Par exemple, les liens dans Gmail y amènent Googlebot immédiatement et suffisamment de visites entraînent l’indexation et les résultats de recherche.

De plus… nous/vous ne savez pas comment les situations changeront à l’avenir. Si c’est résolu maintenant, il n’y a pas besoin de s’en soucier par la suite. Bien sûr, cela demande du temps de travail, mais il en va de même pour l’investissement et la discussion à ce sujet :smirking_face:

1 « J'aime »
28

Maintenant, l’attribut datePublished pour DiscussionForumPosting sur la première page diverge de datePublished sur la page=2+ !

  • première page :
    2015-07-05T22:02:58Z
  • page=2+ :
    2015-07-05T22:02:57Z

Je ne pense pas que Google fasse confiance aux données divergentes et pourrait donc décider que ces deux URL contiennent des DiscussionForumPosting différents qui ne peuvent pas être combinés.

Mieux vaut utiliser la même source de données sur la première page et la page=2+.
Par exemple, toujours utiliser le datePublished du sujet et jamais du premier message ?

search.google.com/test/rich-results pour la première page
datePublished : 2015-07-05T22:02:58Z

grafik
grafik1276×854 61.4 KB

search.google.com/test/rich-results pour la page=2
datePublished : 2015-07-05T22:02:57Z

grafik
grafik1266×894 76.7 KB

PR :

Toujours utiliser datePublished du sujet et jamais de first_post. Cela garantit que datePublished est cohérent sur la première page et la page=2+.

Pas besoin de répéter text sur la page=2+. Surtout ne pas définir text sur la page=2+ si ce n’est qu’un résumé et donc pas 100% cohérent avec text sur la première page.
Résultats inattendus dans la Google Search Console : conserver l’attribut text sur les pages suivantes page=2+.

3 « J'aime »
29

Masquer le message « Fermé il y a x jours » de la vue du robot d’exploration

Si un sujet est fermé, un message spécial y est ajouté :
Par exemple, voir Google structured data for forums and profile pages - #15

grafik
grafik444×144 6.19 KB

Bien sûr, ce message a aucun un attribut text vide. Voir validator.schema.org pour …/t/-/286762 –\u003e dernier commentaire :

grafik
grafik495×622 15.5 KB

Rapport dans la Google Search Console

grafik
grafik1018×394 33.3 KB

Conclusion

Ainsi, ce type spécial de messages système/d’annonce devrait être exclu de la vue du robot d’exploration.

PR

\u003e Les messages système/d’annonce de type spécial sont exclus de la vue du robot d’exploration car ils n’ont aucun contenu.
\u003e
\u003e Un contenu vide déclenche un problème non critique « Champ "text" manquant (dans "comment") » dans la Google Search Console.

30

Serait-il plus judicieux de définir les métadonnées du nom d’auteur sur le champ de profil du nom complet lorsqu’il est disponible ? Au moins sur les forums où prioritize username in ux est désactivé (mais je dirais que de toute façon, le champ URL désambiguïse).

31

Y a-t-il quelque chose qui puisse être fait pour résoudre ce problème ou l’équipe de Discourse doit-elle mettre à jour le cœur du logiciel ?

32

@rrlevering Concernant cette « pas besoin d’attribut text sur les pages suivantes » / vérification IsExternalContent() :

J’ai ce cas de test sur un domaine live :

Discourse implémente DiscussionForumPosting sur…

  • première page - URL de la page : https://example.org/t/-/12345
    • attribut url : https://example.org/t/-/12345
    • attribut text : – défini –
    • attribut author : – défini –
  • page=2 - URL de la page : https://example.org/t/-/12345?page=2
    • attribut url : https://example.org/t/-/12345
    • attribut text : – pas défini du tout –
    • attribut author : – défini –

Résultat : Google Search Console (Test live)

  • première page :
    DiscussionForumPosting valide
  • page=2 :
    DiscussionForumPosting invalide
    • 1 problème critique – Il faut spécifier \"text\", \"image\", ou \"video\"

Il n’y a donc soit aucune vérification sur IsExternalContent() ici, soit la vérification suppose que URL de la page est égal à l’attribut url pour

  • URL de la page :
    https://example.org/t/-/12345?page=2
  • attribut url :
    https://example.org/t/-/12345

Donc pour l’instant, nous devons répéter l’attribut text sur les pages suivantes pour obtenir un DiscussionForumPosting valide sur Google Search Console.

34

Balisage de schéma invalide pour DiscussionForumPosting - uniquement les URL spécifiques de sujet/publication

Sujets concernés : sujets avec plus de 20 publications au total
URL concernées : …/t/-/NNN/7 à …/t/-/NNN/20

Rapport dans ‘Google Rich Result Test’

URL …/t/-/NNN/11 : sujets différents avec des nombres de publications totaux différents (cliquez pour ouvrir)

– Tous les sujets exemples sont ‘fermés’ pour garantir que le nombre total de publications ne change pas. Le bug lui-même affecte également les sujets ‘ouverts’ ! –

URL …/t/-/16968/1 à …/t/-/16968/38 : un sujet avec actuellement 38 publications (cliquez pour ouvrir)

Balisage de schéma valide :
– DiscussionForumPosting lui-même a toujours un attribut inutile position: 1. –

Balisage de schéma invalide : author/datePublished manquant

Balisage de schéma à nouveau valide : (ici : @page > 1 est true) :

Considérations techniques

1. `@topic_view.prev_page` n'est peut-être pas la meilleure solution pour décider d'afficher ou non `author`/`datePublished`.

app/views/topics/show.html.erb#L53-L60

      <% if @topic_view.prev_page %>
        <meta itemprop='datePublished' content='<%= @topic_view.topic.created_at.to_formatted_s(:iso8601) %>'>
        <span itemprop='author' itemscope itemtype="http://schema.org/Person">
          <meta itemprop='name' content='<%= @topic_view.topic.user.username %>'>
          <link itemprop='url' href='<%= Discourse.base_url %>/u/<%= @topic_view.topic.user.username %>'>
        </span>
        <meta itemprop='text' content='<%= @topic_view.topic.excerpt %>'>
      <% end %>
2. L'implémentation de `@topic_view.prev_page` pourrait être buggée en soi.

lib/topic_view.rb#L113-L115
lib/topic_view.rb#L128-L130
lib/topic_view.rb#L193-L195

    @post_number = [@post_number.to_i, 1].max
# ---
    @page = @page.to_i > 1 ? @page.to_i : calculate_page
# ---
  def prev_page
    @page > 1 && posts.size > 0 ? @page - 1 : nil
  end

Y a-t-il un bug ici ?
lib/topic_view.rb#L751-L755

  def calculate_page
    posts_count =
      is_mega_topic? ? @post_number : unfiltered_posts.where("post_number <= ?", @post_number).count
    ((posts_count - 1) / @limit) + 1
  end
  • calculate_page peut-il donner des résultats inattendus car il utilise le @post_number actuel et échoue d’une manière ou d’une autre pour les valeurs 7 à 20 ?
  • ((posts_count - 1) / @limit) + 1 donne quelque chose comme :
    ((7 - 1) / 20) + 1 = 1.3 = 1
  • Quel est le numéro de page attendu ? Peut-être calculer avec des valeurs non entières, puis arrondir le nombre comme prévu via floor/ceil et convertir en entier :
    (((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i
  • Peut-être vérifier unfiltered_posts.where("post_number <= ?", @post_number) car @topic.posts pourrait ne pas contenir toutes les publications à partir de post_1 comme prévu.

lib/topic_view.rb#L53-L55
lib/topic_view.rb#L119-L127
lib/topic_view.rb#L835-L841

  def self.chunk_size
    20
  end
# ---
    @chunk_size =
      case
      when @print
        TopicView.print_chunk_size
      else
        TopicView.chunk_size
      end

    @limit ||= @chunk_size
# ---
  def unfiltered_posts
    result = filter_post_types(@topic.posts)
    result = result.with_deleted if @guardian.can_see_deleted_posts?(@topic.category)
    result = result.where("user_id IS NOT NULL") if @exclude_deleted_users
    result = result.where(hidden: false) if @exclude_hidden
    result
  end

Conclusion

Dans ce cas particulier…

  • sujets avec plus de 20 publications au total
  • …/t/-/NNN/7 à …/t/-/NNN/20

… la première publication ne faisait pas partie de la vue actuelle et @topic_view.prev_page ne s’est pas déclenché car la vue était toujours sur la première page.

Ainsi, tous les attributs du schéma de microdonnées DiscussionForumPosting qui n’étaient rendus que dans le contexte de la première publication ou lorsque @topic_view.prev_page == true étaient manquants.

PR

Certains attributs du schéma de microdonnées DiscussionForumPosting sont rendus dans le contexte de la première publication. Assurez-vous que ces attributs sont également définis si la première publication ne fait pas partie de la vue actuelle.

3 « J'aime »
36

Hmm… C’est inattendu. Je suis désolé pour le désagrément, je pense que cette vérification de comparaison d’URL supprime les paramètres de requête lors de la comparaison. Je vais déployer un correctif.

3 « J'aime »
37

Une mise à jour concernant cette correction ?

38

Je pense que le correctif déployé cette semaine prend en compte les paramètres de requête dans la vérification « s’agit-il d’une URL externe ». Ainsi, les forums qui font référence aux OP à partir d’une URL différente par paramètre de requête (foo vs. foo?page=2) n’auront pas d’erreurs signalées dans GSC.

3 « J'aime »
39

Croyez que le correctif déployé cette semaine pour prendre en compte les paramètres de requête dans la vérification « s’agit-il d’une URL externe »

41

@rrlevering sur une autre plateforme de forum, vous recommandez l’imbrication dans le schéma comment - Schema.org Property pour chaque publication dans un fil de discussion. Il ne semble pas que Discourse fasse cela. Le recommandez-vous toujours ?

42

Discourse imbrique le schéma Comment pour chaque publication dans le fil. Consultez Schema Markup Validator et ouvrez l’objet DiscussionForumPosting pour voir les commentaires imbriqués.

2 « J'aime »
43

Merci ! Je l’avais manqué imbriqué dans le DiscussionForumPosting.