Melhorias no esquema do fórum de discussão

Por favor, deixe a URL lá mesmo que ela esteja bloqueada. Você pode discutir se isso faz sentido ou não para os casos de uso do seu fórum, mas mesmo com o rastreamento bloqueado, isso pode ajudar na desambiguação.

6 curtidas

Isso ainda é apenas um pedido educado, e nem mesmo o Google o respeita o tempo todo. Por exemplo, links no Gmail permitem que o Googlebot vá direto para lá e visitas suficientes levam à indexação e aos resultados de pesquisa.

Além disso… nós/você não sabemos como as situações mudarão no futuro. Se estiver corrigido agora, não há necessidade de se preocupar com isso depois. Claro que exige tempo de trabalho, mas o mesmo vale para investir e discutir sobre isso :smirking_face:

1 curtida

Agora o atributo datePublished para DiscussionForumPosting na primeira página diverge do datePublished na página=2+!

  • primeira página:
    2015-07-05T22:02:58Z
  • página=2+:
    2015-07-05T22:02:57Z

Não acho que o Google confie em dados divergentes e, portanto, pode decidir que essas duas URLs contêm DiscussionForumPosting diferentes que não podem ser combinadas.

É melhor usar a mesma fonte de dados na primeira página e na página=2+.
Por exemplo, sempre usar o datePublished do tópico e nunca do primeiro post?

search.google.com/test/rich-results para a primeira página
datePublished: 2015-07-05T22:02:58Z

search.google.com/test/rich-results para a página=2
datePublished: 2015-07-05T22:02:57Z


PR:

Sempre usar datePublished do tópico e nunca de first_post. Isso garante que datePublished seja consistente na primeira página e na página=2+.

Não há necessidade de repetir text na página=2+. Especialmente não definir text na página=2+ se for apenas um resumo e, portanto, não 100% consistente com text na primeira página.
Resultados inesperados no Google Search Console: manter o atributo text nas páginas de acompanhamento página=2+.

3 curtidas

Ocultar postagem “Fechado há x dias” da visualização do rastreador

Se um tópico for fechado, uma postagem especial será adicionada a ele:
Exemplo: veja Google structured data for forums and profile pages - #15

Claro que esta postagem tem nenhum um atributo text vazio. Veja validator.schema.org para …/t/-/286762 –\u003e último comentário:

Relatório no Google Search Console

Conclusão

Portanto, este tipo especial de postagem de sistema/anúncio deve ser excluído da visualização do rastreador.

PR

\u003e Tipos especiais de postagens de sistema/anúncio são excluídos da visualização do rastreador, pois não possuem conteúdo.
\u003e
\u003e Conteúdo vazio aciona um problema não crítico ‘Campo “text” ausente (em “comment”)’ no Google Search Console.

Faria mais sentido o metadado do nome do autor ser definido para o campo de perfil de nome completo quando disponível? Pelo menos em fóruns com prioritize username in ux desabilitado (mas eu argumentaria de qualquer forma, o campo URL desambigua de qualquer maneira).

Há algo que possa ser feito para resolver isso ou a equipe do Discourse tem que atualizar o core?

@rrlevering Sobre esta “não há necessidade do atributo text em páginas de acompanhamento” / verificação IsExternalContent():

Tenho este caso de teste em um domínio ativo:

O Discourse implementa DiscussionForumPosting em…

  • primeira página - URL da página: https://example.org/t/-/12345
    • atributo url: https://example.org/t/-/12345
    • atributo text: – definido –
    • atributo author: – definido –
  • página=2 - URL da página: https://example.org/t/-/12345?page=2
    • atributo url: https://example.org/t/-/12345
    • atributo text: – não definido –
    • atributo author: – definido –

Resultado: Google Search Console (Teste em tempo real)

  • primeira página:
    DiscussionForumPosting válido
  • página=2:
    DiscussionForumPosting inválido
    • 1 problema críticoÉ necessário especificar \"text\", \"image\" ou \"video\"

Portanto, ou não há verificação em IsExternalContent() aqui, ou a verificação assume que URL da página é igual ao atributo url para

  • URL da página:
    https://example.org/t/-/12345?page=2
  • atributo url:
    https://example.org/t/-/12345

Assim, por enquanto, temos que repetir o atributo text em páginas de acompanhamento para obter um DiscussionForumPosting válido no Google Search Console.

Marcação de esquema inválida para DiscussionForumPosting - apenas URLs específicas de tópicos/posts

Tópicos afetados: tópicos com um total de mais de 20 posts
URLs afetadas: …/t/-/NNN/7 a …/t/-/NNN/20

Relatório em ‘Google Rich Result Test’

URL …/t/-/NNN/11: tópicos diferentes com contagens totais de posts diferentes (clique para abrir)

– Todos os tópicos de exemplo estão ‘fechados’ para garantir que o total de posts não mude. O bug em si também afeta tópicos ‘abertos’! –

URLs …/t/-/16968/1 a …/t/-/16968/38: Um tópico com atualmente 38 posts (clique para abrir)

Marcação de esquema válida:
DiscussionForumPosting em si ainda tem um atributo desnecessário position: 1. –

Marcação de esquema inválida: author/datePublished ausente

Marcação de esquema válida novamente: (aqui: @page > 1 é true):

Considerações técnicas

1. `@topic_view.prev_page` pode não ser a melhor solução para decidir se exibe `author`/`datePublished` ou não.

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. A implementação de `@topic_view.prev_page` pode ser bugada por si só.

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

Existe um bug aqui?
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 pode dar resultados inesperados, pois usa o @post_number atual e, de alguma forma, falha para valores de 7 a 20?
  • ((posts_count - 1) / @limit) + 1 resulta em algo como:
    ((7 - 1) / 20) + 1 = 1.3 = 1
  • Qual é o número de página esperado? Talvez calcular com valores não inteiros, depois arredondar o número conforme pretendido via floor/ceil e converter para inteiro:
    (((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i
  • Talvez verificar unfiltered_posts.where("post_number <= ?", @post_number), pois @topic.posts pode não conter todos os posts começando com post_1 como pretendido.

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

Conclusão

Neste caso extremo …

  • tópicos com um total de mais de 20 posts
  • …/t/-/NNN/7 a …/t/-/NNN/20

… o primeiro post não fazia parte da visualização atual e @topic_view.prev_page não foi acionado, pois a visualização ainda estava na primeira página.

Portanto, todos os atributos do esquema de microdados DiscussionForumPosting que foram renderizados apenas no contexto do primeiro post ou em @topic_view.prev_page == true estavam ausentes.

PR

Alguns atributos do esquema de microdados DiscussionForumPosting são renderizados no contexto do primeiro post. Garanta que esses atributos também sejam definidos se o primeiro post não fizer parte da visualização atual.

3 curtidas

Hmmm… Isso é inesperado. Desculpe pelo transtorno, acho que a verificação de comparação de URL está descartando os parâmetros de consulta na comparação. Vou providenciar uma correção.

3 curtidas

Alguma atualização aqui sobre essa correção?

Acredito que a correção lançada esta semana para considerar parâmetros de consulta na verificação “este é um URL externo”. Assim, fóruns que se referem a OPs de um URL diferente por parâmetro de consulta (foo vs. foo?page=2) não terão erros relatados neles no GSC.

3 curtidas

Acredite que a correção lançada esta semana para considerar parâmetros de consulta na verificação “isso é uma URL externa”

@rrlevering em outra plataforma de fórum, você recomenda aninhar em comment - Schema.org Property schema para cada postagem em um thread. Não parece que o Discourse faz isso. Você ainda recomenda?

O Discourse aninha o esquema de Comentários para cada postagem no tópico. Confira Schema Markup Validator e abra o objeto DiscussionForumPosting e veja os comentários aninhados.

2 curtidas

Obrigado! Eu perdi isso aninhado no DiscussionForumPosting.