Miglioramenti dello schema del forum di discussione

Supporto
26

Si prega di lasciare l’URL lì anche se è bloccato. È possibile discutere se ciò abbia senso o meno per i casi d’uso del proprio forum, ma anche se il crawl è bloccato può aiutare con la disambiguazione.

6 Mi Piace
Applying Schema.org on the user profile page for improved author authority on Google
27

Quella è ancora solo una richiesta cortese, e nemmeno Google la rispetta sempre. Ad esempio, i link in Gmail consentono a Googlebot di accedervi subito e visite sufficienti portano all’indicizzazione e ai risultati di ricerca.

Inoltre… noi/tu non sappiamo come cambieranno le cose in futuro. Se è risolto ora, allora non c’è bisogno di preoccuparsene in seguito. Certo, richiede tempo di lavoro, ma lo stesso vale per l’investimento e la discussione al riguardo :smirking_face:

1 Mi Piace
28

Ora l’attributo datePublished per DiscussionForumPosting sulla prima pagina devia da datePublished sulla pagina=2+!

  • prima pagina:
    2015-07-05T22:02:58Z
  • pagina=2+:
    2015-07-05T22:02:57Z

Non credo che Google si fidi di dati divergenti e quindi potrebbe decidere che quei due URL contengono DiscussionForumPosting diversi che non possono essere combinati.

Meglio usare la stessa origine dati sulla prima pagina e sulla pagina=2+.
Ad esempio, usare sempre datePublished dal topic e mai dal primo post?

search.google.com/test/rich-results per la prima pagina
datePublished: 2015-07-05T22:02:58Z

grafik
grafik1276×854 61.4 KB

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

grafik
grafik1266×894 76.7 KB

PR:

Usa sempre datePublished dal topic e mai da first_post. Questo garantisce la coerenza di datePublished sulla prima pagina e sulla pagina=2+.

Non è necessario ripetere text sulla pagina=2+. Soprattutto non impostare text sulla pagina=2+ se è solo un abstract e quindi non coerente al 100% con text sulla prima pagina.
Risultati imprevisti in Google Search Console: mantieni l’attributo text sulle pagine successive pagina=2+.

3 Mi Piace
29

Nascondi post “Chiuso x giorni fa” dalla vista del crawler

Se un argomento è chiuso, viene aggiunto un post speciale all’argomento:
Ad esempio, vedi Google structured data for forums and profile pages - #15

grafik
grafik444×144 6.19 KB

Naturalmente questo post ha nessun un attributo text vuoto. Vedi validator.schema.org per …/t/-/286762 –\u003e ultimo commento:

grafik
grafik495×622 15.5 KB

Segnalazione in Google Search Console

grafik
grafik1018×394 33.3 KB

Conclusione

Quindi questo tipo speciale di post di sistema/annuncio dovrebbe essere escluso dalla vista del crawler.

PR

\u003e I post speciali di sistema/annuncio sono esclusi dalla vista del crawler poiché non hanno alcun contenuto.
\u003e
\u003e Il contenuto vuoto attiva un problema non critico ‘Campo mancante “text” (in “comment”)’ in Google Search Console.

30

Avrebbe più senso impostare i metadati del nome dell’autore sul campo del profilo del nome completo quando disponibile? Almeno sui forum con prioritize username in ux disabilitato (ma sostengo che in entrambi i casi, il campo URL disambigua comunque).

31

C’è qualcosa che si può fare per risolvere questo problema o il team di discourse deve aggiornare il core?

32

@rrlevering Su questo “non è necessario l’attributo text nelle pagine successive” / controllo IsExternalContent():

Ho questo caso di test su un dominio live:

Discourse implementa DiscussionForumPosting su…

  • prima pagina - URL della pagina: https://example.org/t/-/12345
    • attributo url: https://example.org/t/-/12345
    • attributo text: – impostato –
    • attributo author: – impostato –
  • pagina=2 - URL della pagina: https://example.org/t/-/12345?page=2
    • attributo url: https://example.org/t/-/12345
    • attributo text: – non impostato affatto –
    • attributo author: – impostato –

Risultato: Google Search Console (Test live)

  • prima pagina:
    DiscussionForumPosting valido
  • pagina=2:
    DiscussionForumPosting non valido
    • 1 problema critico– Deve essere specificato \"text\", \"image\" o \"video\"

Quindi o non c’è un controllo su IsExternalContent() qui o il controllo presuppone che URL della pagina sia uguale all’attributo url per

  • URL della pagina:
    https://example.org/t/-/12345?page=2
  • attributo url:
    https://example.org/t/-/12345

Quindi per ora dobbiamo ripetere l’attributo text nelle pagine successive per ottenere un DiscussionForumPosting valido su Google Search Console.

34

Schema markup non valido per DiscussionForumPosting - solo URL specifici di argomenti/post

Argomenti interessati: argomenti con un totale di oltre 20 post
URL interessati: …/t/-/NNN/7 a …/t/-/NNN/20

Report in ‘Google Rich Result Test’

URL …/t/-/NNN/11: argomenti diversi con conteggi post totali diversi (clicca per aprire)

– Tutti gli argomenti di esempio sono ‘chiusi’ per garantire che il numero totale di post non cambi. Il bug stesso influisce anche sugli argomenti ‘aperti’! –

URL …/t/-/16968/1 a …/t/-/16968/38: Un argomento con attualmente 38 post (clicca per aprire)

Schema markup valido:
– DiscussionForumPosting stesso ha ancora un attributo non necessario position: 1. –

Schema markup non valido: author/datePublished mancante

Schema markup valido di nuovo: (qui: @page > 1 è true):

Considerazioni tecniche

1. `@topic_view.prev_page` potrebbe non essere la soluzione migliore per decidere se visualizzare `author`/`datePublished` o meno.

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'implementazione di `@topic_view.prev_page` potrebbe essere di per sé problematica.

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

C’è un bug qui?
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 potrebbe dare risultati inaspettati poiché utilizza l’attuale @post_number e in qualche modo fallisce per i valori da 7 a 20?
  • ((posts_count - 1) / @limit) + 1 risulta in qualcosa come:
    ((7 - 1) / 20) + 1 = 1.3 = 1
  • Qual è il numero di pagina previsto? Forse calcolare con valori non interi, quindi arrotondare il numero come previsto tramite floor/ceil e convertire in intero:
    (((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i
  • Forse controllare unfiltered_posts.where("post_number <= ?", @post_number) poiché @topic.posts potrebbe non contenere tutti i post a partire da post_1 come previsto.

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

Conclusione

In questo caso limite …

  • argomenti con un totale di oltre 20 post
  • …/t/-/NNN/7 a …/t/-/NNN/20

… il primo post non faceva parte della vista corrente e @topic_view.prev_page non si è attivato poiché la vista era ancora sulla prima pagina.

Quindi tutti gli attributi dello schema microdati DiscussionForumPosting che venivano renderizzati solo nel contesto del primo post o su @topic_view.prev_page == true erano mancanti.

PR

Alcuni attributi dello schema microdati DiscussionForumPosting vengono renderizzati nel contesto del primo post. Assicurarsi che questi attributi siano impostati anche se il primo post non fa parte della vista corrente.

3 Mi Piace
36

Hmmm… Questo è inaspettato. Mi scuso per l’inconveniente, penso che il controllo del confronto dell’URL stia ignorando i parametri di query nel confronto. Provvederò a rilasciare una correzione.

3 Mi Piace
37

Ci sono aggiornamenti su questa correzione?

38

Credo che la correzione distribuita questa settimana per considerare i parametri di query nel controllo “questo è un URL esterno”. Pertanto, i forum che fanno riferimento agli OP da un URL diverso tramite parametro di query (foo vs. foo?page=2) non segnaleranno errori in GSC.

3 Mi Piace
39

Credi che la correzione distribuita questa settimana consideri i parametri di query nel controllo “è un URL esterno”

41

@rrlevering su un’altra piattaforma di forum consiglia di nidificare nello schema https://schema.org/comment per ogni post in un thread. Discourse non sembra farlo. Lo consiglia ancora?

42

Discourse annida lo schema Comment per ogni post nel thread. Dai un’occhiata a Schema Markup Validator e apri l’oggetto DiscussionForumPosting e vedi i commenti annidati.

2 Mi Piace
43

Grazie! L’avevo perso annidato nel DiscussionForumPosting.