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.
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 ![]()
Agora o atributo datePublished para DiscussionForumPosting na primeira página diverge do datePublished na página=2+!
primeira página:
2015-07-05T22:02:58Zpá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
datePublisheddo tópico e nunca defirst_post. Isso garante quedatePublishedseja consistente naprimeira páginae napágina=2+.
Não há necessidade de repetirtextnapágina=2+. Especialmente não definirtextnapágina=2+se for apenas um resumo e, portanto, não 100% consistente comtextnaprimeira página.
Resultados inesperados no Google Search Console: manter o atributotextnas páginas de acompanhamentopágina=2+.
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 –
- atributo
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 –
- atributo
Resultado: Google Search Console (Teste em tempo real)
primeira página:
DiscussionForumPostingválidopágina=2:
DiscussionForumPostinginválido1 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)
- Tópico com total de 18 posts: resultado para …/t/-/283678/11 válido
- Tópico com total de 19 posts: resultado para …/t/-/235984/11 válido
- Tópico com total de 20 posts: resultado para …/t/-/264899/11 inválido
- Tópico com total de 21 posts: resultado para …/t/-/282382/11 inválido
– 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. –
- resultado para …/t/-/16968:
Comment-posições 2 a 20 - resultado para …/t/-/16968/1:
Comment-posições 2 a 20 - …
- resultado para …/t/-/16968/6
Comment-posições 2 a 20.
Marcação de esquema inválida: author/datePublished ausente
- resultado para …/t/-/16968/7
Comment-posições 2 a 21. - resultado para …/t/-/16968/8
Comment-posições 3 a 22. - …
- resultado para …/t/-/16968/20
Comment-posições 15 a 34.
Marcação de esquema válida novamente: (aqui: @page > 1 é true):
- resultado para …/t/-/16968/21:
Comment-posições 16 a 35 - resultado para …/t/-/16968/22:
Comment-posições 17 a 36 - …
- resultado para …/t/-/16968/24:
Comment-posições 19 a 38 - resultado para …/t/-/16968/25: atualmente inclui
Comment-posições 19 a 38 - …
- resultado para …/t/-/16968/38 – último post atual: atualmente inclui
Comment-posições 19 a 38 - …
- resultado para …/t/-/16968/999 – post inexistente alto: atualmente inclui
Comment-posições 19 a 38
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_pagepode dar resultados inesperados, pois usa o@post_numberatual e, de alguma forma, falha para valores de 7 a 20?((posts_count - 1) / @limit) + 1resulta 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/ceile 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.postspode 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/7a…/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
DiscussionForumPostingsã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.
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.
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.
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.
Obrigado! Eu perdi isso aninhado no DiscussionForumPosting.




