Mejoras en el esquema del foro de discusión

Soporte
26

Por favor, deja la URL ahí incluso si está bloqueada. Puedes discutir si eso tiene sentido o no para los casos de uso de tu foro, pero incluso si el rastreo está bloqueado, puede ayudar a la desambiguación.

6 Me gusta
27

Esa sigue siendo solo una petición educada, y ni siquiera Google la respeta siempre. Por ejemplo, los enlaces en Gmail permiten que Googlebot acceda de inmediato y suficientes visitas conducen a la indexación y a los resultados de búsqueda.

Además… nosotros/tú no sabemos cómo cambiarán las situaciones en el futuro. Si se soluciona ahora, entonces no hay necesidad de preocuparse por ello después. Claro que exige tiempo de trabajo, pero también lo hace invertir y discutir sobre ello :smirking_face:

1 me gusta
28

Ahora el atributo datePublished para DiscussionForumPosting en la primera página se desvía de datePublished en página=2+!

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

No creo que Google confíe en datos que se desvían y, por lo tanto, podría decidir que esas dos URL contienen DiscussionForumPosting diferentes que no se pueden combinar.

Es mejor usar la misma fuente de datos en la primera página y en la página=2+.
Por ejemplo, ¿usar siempre datePublished del tema y nunca de la primera publicación?

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

grafik
grafik1276×854 61.4 KB

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

grafik
grafik1266×894 76.7 KB

PR:

Usar siempre datePublished del tema y nunca de first_post. Esto asegura que datePublished sea consistente en la primera página y en la página=2+.

No es necesario repetir text en la página=2+. Especialmente no establecer text en la página=2+ si es solo un resumen y, por lo tanto, no es 100% consistente con text en la primera página.
Resultados inesperados en Google Search Console: mantener el atributo text en las páginas de seguimiento página=2+.

3 Me gusta
29

Ocultar publicación “Cerrado hace x días” de la vista del rastreador

Si un tema está cerrado, se añade una publicación especial al tema:
Por ejemplo, véase Google structured data for forums and profile pages - #15

grafik
grafik444×144 6.19 KB

Por supuesto, esta publicación tiene ningún un atributo text vacío. Véase validator.schema.org para …/t/-/286762 –\u003e último comentario:

grafik
grafik495×622 15.5 KB

Informe en Google Search Console

grafik
grafik1018×394 33.3 KB

Conclusión

Por lo tanto, este tipo especial de publicaciones del sistema/anuncios debe excluirse de la vista del rastreador.

PR

\u003e Las publicaciones especiales del sistema/anuncios se excluyen de la vista del rastreador ya que no tienen ningún contenido.
\u003e
\u003e El contenido vacío activa un problema no crítico ‘Campo “text” faltante (en “comment”)’ en Google Search Console.

30

¿Tendría más sentido que los metadatos del nombre del autor se establecieran en el campo de perfil de nombre completo cuando esté disponible? Al menos en foros con prioritize username in ux desactivado (pero argumentaría de cualquier manera, el campo de URL desambigua de todos modos).

31

¿Hay algo que se pueda hacer para solucionar esto o el equipo de Discourse tiene que actualizar el núcleo?

32

@rrlevering Sobre esta “no necesidad del atributo text en páginas de seguimiento” / verificación IsExternalContent():

Tengo este caso de prueba en un dominio en vivo:

Discourse implementa DiscussionForumPosting en…

  • primera página - URL de la página: https://example.org/t/-/12345
    • atributo url: https://example.org/t/-/12345
    • atributo text: – establecido –
    • atributo author: – establecido –
  • página=2 - URL de la página: https://example.org/t/-/12345?page=2
    • atributo url: https://example.org/t/-/12345
    • atributo text: – no establecido en absoluto –
    • atributo author: – establecido –

Resultado: Consola de Búsqueda de Google (Prueba en vivo)

  • primera página:
    DiscussionForumPosting válido
  • página=2:
    DiscussionForumPosting inválido
    • 1 problema crítico– Se debe especificar \"text\", \"image\" o \"video\"

Entonces, o no hay una verificación en IsExternalContent() aquí, o la verificación asume que URL de la página es igual a url del atributo para

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

Así que, por ahora, tenemos que repetir el atributo text en las páginas de seguimiento para obtener un DiscussionForumPosting válido en la Consola de Búsqueda de Google.

34

Esquema de marcado no válido para DiscussionForumPosting: solo URLs específicas de temas/publicaciones

Temas afectados: temas con un total de más de 20 publicaciones
URLs afectadas: …/t/-/NNN/7 a …/t/-/NNN/20

Informe en ‘Google Rich Result Test’

URL …/t/-/NNN/11: temas diferentes con recuentos de publicaciones totales diferentes (haz clic para abrir)

– Todos los temas de ejemplo están ‘cerrados’ para garantizar que el número total de publicaciones no cambie. ¡El error en sí también afecta a los temas ‘abiertos’! –

URLs …/t/-/16968/1 a …/t/-/16968/38: Un tema con actualmente 38 publicaciones (haz clic para abrir)

Esquema de marcado válido:
– DiscussionForumPosting en sí mismo todavía tiene un atributo innecesario position: 1. –

Esquema de marcado no válido: falta author/datePublished

Esquema de marcado válido de nuevo: (aquí: @page > 1 es true):

Consideraciones técnicas

1. `@topic_view.prev_page` podría no ser la mejor solución para decidir si mostrar `author`/`datePublished` o no.

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. La implementación de `@topic_view.prev_page` podría ser defectuosa en sí misma.

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

¿Hay un error aquí?
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
  • ¿Puede calculate_page dar resultados inesperados ya que utiliza el @post_number actual y falla de alguna manera para los valores del 7 al 20?
  • ((posts_count - 1) / @limit) + 1 da como resultado algo como:
    ((7 - 1) / 20) + 1 = 1.3 = 1
  • ¿Cuál es el número de página esperado? Quizás calcular con valores no enteros, luego redondear el número según lo previsto mediante floor/ceil y convertir a entero:
    (((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i
  • Quizás comprobar unfiltered_posts.where("post_number <= ?", @post_number) ya que @topic.posts podría no contener todas las publicaciones empezando por la publicación_1 como se esperaba.

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

Conclusión

En este caso extremo …

  • temas con un total de más de 20 publicaciones
  • …/t/-/NNN/7 a …/t/-/NNN/20

… la primera publicación no formaba parte de la vista actual y @topic_view.prev_page no se activó ya que la vista todavía estaba en la primera página.

Por lo tanto, faltaban todos los atributos del esquema de microdatos DiscussionForumPosting que solo se renderizaban en el contexto de la primera publicación o cuando @topic_view.prev_page == true.

PR

Algunos atributos del esquema de microdatos DiscussionForumPosting se renderizan en el contexto de la primera publicación. Asegúrate de que estos atributos también se establezcan si la primera publicación no forma parte de la vista actual.

3 Me gusta
36

Hmmm… Eso es inesperado. Lamento el problema, creo que la comprobación de comparación de URL está omitiendo los parámetros de consulta en la comparación. Voy a implementar una solución.

3 Me gusta
37

¿Alguna novedad aquí sobre esta corrección?

38

Creo que la corrección implementada esta semana considera los parámetros de consulta en la verificación “es esta una URL externa”. Por lo tanto, los foros que hacen referencia a los OP desde una URL diferente mediante un parámetro de consulta (foo vs. foo?page=2) no informarán errores en GSC.

3 Me gusta
39

Cree que la corrección implementada esta semana considera los parámetros de consulta en la verificación “es esta una URL externa”.

41

@rrlevering en otra plataforma de foros recomiendas anidar en el esquema comment - Schema.org Property para cada publicación en un hilo. No parece que Discourse haga esto. ¿Todavía lo recomiendas?

42

Discourse anida el esquema de comentarios para cada publicación en el hilo. Consulte Schema Markup Validator y abra el objeto DiscussionForumPosting y vea los comentarios anidados.

2 Me gusta
43

¡Gracias! Me lo perdí anidado en el DiscussionForumPosting.