Verbesserungen des Diskussionsforum-Schemas

Unterstützung
26

Bitte lassen Sie die URL dort, auch wenn sie blockiert ist. Sie können diskutieren, ob das für Ihre Forenanwendungsfälle sinnvoll ist oder nicht, aber auch wenn der Crawl blockiert ist, kann er zur Eindeutigkeit beitragen.

6 „Gefällt mir“
Applying Schema.org on the user profile page for improved author authority on Google
27

Das ist immer noch nur eine höfliche Bitte, und nicht einmal Google respektiert sie jedes Mal. Zum Beispiel lassen Links in Gmail Googlebot sofort dorthin und genügend Besuche führen zur Indizierung und zu Suchergebnissen.

Außerdem… wir/du wissen nicht, wie sich die Situationen in Zukunft ändern werden. Wenn es jetzt behoben ist, dann gibt es keinen Grund, sich danach Sorgen zu machen. Sicher, es erfordert Arbeitszeit, aber das gilt auch für Investitionen und Diskussionen darüber :smirking_face:

1 „Gefällt mir“
28

Jetzt weicht das Attribut datePublished für DiscussionForumPosting auf der ersten Seite von datePublished auf Seite=2+ ab!

  • erste Seite:
    2015-07-05T22:02:58Z
  • Seite=2+:
    2015-07-05T22:02:57Z

Ich glaube nicht, dass Google abweichende Daten vertraut und daher entscheiden könnte, dass diese beiden URLs unterschiedliche DiscussionForumPosting enthalten, die nicht kombiniert werden können.

Verwenden Sie besser dieselbe Datenquelle auf der ersten Seite und auf Seite=2+.
Verwenden Sie zum Beispiel immer das datePublished aus dem Thema und nie aus dem ersten Beitrag?

search.google.com/test/rich-results für die erste Seite
datePublished: 2015-07-05T22:02:58Z

grafik
grafik1276×854 61.4 KB

search.google.com/test/rich-results für Seite=2
datePublished: 2015-07-05T22:02:57Z

grafik
grafik1266×894 76.7 KB

PR:

Verwenden Sie immer datePublished aus dem Thema und nie aus first_post. Dies stellt sicher, dass datePublished auf der ersten Seite und auf Seite=2+ konsistent ist.

Es ist nicht nötig, text auf Seite=2+ zu wiederholen. Setzen Sie insbesondere text nicht auf Seite=2+, wenn es nur eine Zusammenfassung ist und daher nicht 100% mit text auf der ersten Seite übereinstimmt.
Unerwartete Ergebnisse in der Google Search Console: Behalten Sie das text-Attribut auf Folge-Seiten Seite=2+ bei.

3 „Gefällt mir“
29

Beitrag „Vor X Tagen geschlossen“ aus der Crawler-Ansicht ausblenden

Wenn ein Thema geschlossen ist, wird ein spezieller Beitrag zum Thema hinzugefügt:
Siehe z. B. Google structured data for forums and profile pages - #15

grafik
grafik444×144 6.19 KB

Natürlich hat dieser Beitrag kein ein leeres text-Attribut. Siehe validator.schema.org für …/t/-/286762 –\u003e letzter Kommentar:

grafik
grafik495×622 15.5 KB

Bericht in der Google Search Console

grafik
grafik1018×394 33.3 KB

Schlussfolgerung

Diese spezielle Art von System-/Ankündigungsbeiträgen sollte daher von der Crawler-Ansicht ausgeschlossen werden.

PR

\u003e Spezielle System-/Ankündigungsbeiträge werden von der Crawler-Ansicht ausgeschlossen, da sie keinen Inhalt haben.
\u003e
\u003e Leerer Inhalt löst in der Google Search Console ein nicht-kritisches Problem „Fehlendes Feld „text“ (in „comment“)“ aus.

30

Wäre es sinnvoller, Metadaten für den Autorennamen auf das Feld “Vollständiger Name” zu setzen, wenn dieses verfügbar ist? Zumindest in Foren, in denen prioritize username in ux deaktiviert ist (aber ich würde argumentieren, dass das URL-Feld sowieso zur Unterscheidung beiträgt).

31

Gibt es etwas, das getan werden kann, um dies zu lösen, oder muss das Discourse-Team den Kern aktualisieren?

32

@rrlevering Zu dieser „keine Notwendigkeit für das text-Attribut auf Folge-Seiten“ / IsExternalContent()-Prüfung:

Ich habe diesen Testfall auf einer Live-Domain:

Discourse implementiert DiscussionForumPosting auf …

  • erste Seite - Seiten-URL: https://example.org/t/-/12345
    • Attribut url: https://example.org/t/-/12345
    • Attribut text: – gesetzt –
    • Attribut author: – gesetzt –
  • page=2 - Seiten-URL: https://example.org/t/-/12345?page=2
    • Attribut url: https://example.org/t/-/12345
    • Attribut text: – überhaupt nicht gesetzt –
    • Attribut author: – gesetzt –

Ergebnis: Google Search Console (Live-Test)

  • erste Seite:
    DiscussionForumPosting gültig
  • page=2:
    DiscussionForumPosting ungültig
    • 1 kritisches Problem– Entweder "text", "image" oder "video" sollte angegeben werden

Entweder gibt es hier keine Prüfung auf IsExternalContent(), oder die Prüfung geht davon aus, dass page URL gleich Attribut url ist für

  • Seiten-URL:
    https://example.org/t/-/12345?page=2
  • Attribut url:
    https://example.org/t/-/12345

Daher müssen wir vorerst das Attribut text auf Folge-Seiten wiederholen, um ein gültiges DiscussionForumPosting in der Google Search Console zu erhalten.

34

Ungültiges Schema-Markup für DiscussionForumPosting – nur spezifische Themen-/Post-URLs

Betroffene Themen: Themen mit insgesamt mehr als 20 Beiträgen
Betroffene URLs: …/t/-/NNN/7 bis …/t/-/NNN/20

Bericht im ‘Google Rich Results Test’

URL …/t/-/NNN/11: Unterschiedliche Themen mit unterschiedlicher Anzahl von Beiträgen (zum Öffnen klicken)

– Alle Beispielthemen sind ‘geschlossen’, um sicherzustellen, dass die Anzahl der Beiträge nicht geändert wird. Der Fehler selbst betrifft auch ‘offene’ Themen! –

URLs …/t/-/16968/1 bis …/t/-/16968/38: Ein Thema mit derzeit 38 Beiträgen (zum Öffnen klicken)

Gültiges Schema-Markup:
– DiscussionForumPosting selbst hat immer noch ein unnötiges Attribut position: 1. –

Ungültiges Schema-Markup: author/datePublished fehlt

Gültiges Schema-Markup wieder: (hier: @page > 1 ist true):

Technische Überlegungen

1. `@topic_view.prev_page` ist möglicherweise nicht die beste Lösung, um zu entscheiden, ob `author`/`datePublished` angezeigt werden soll oder nicht.

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. Die Implementierung von `@topic_view.prev_page` könnte selbst fehlerhaft sein.

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

Gibt es hier einen Fehler?
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
  • Könnte calculate_page unerwartete Ergebnisse liefern, da es die aktuelle @post_number verwendet und für Werte von 7 bis 20 fehlschlägt?
  • ((posts_count - 1) / @limit) + 1 ergibt etwas wie:
    ((7 - 1) / 20) + 1 = 1.3 = 1
  • Was ist die erwartete Seitenzahl? Vielleicht mit nicht-ganzzahligen Werten berechnen und dann die Zahl wie beabsichtigt über floor/ceil runden und in Integer umwandeln:
    (((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i
  • Vielleicht unfiltered_posts.where("post_number <= ?", @post_number) überprüfen, da @topic.posts möglicherweise nicht alle Beiträge ab Post_1 enthält, wie beabsichtigt.

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

Schlussfolgerung

In diesem Sonderfall …

  • Themen mit insgesamt mehr als 20 Beiträgen
  • …/t/-/NNN/7 bis …/t/-/NNN/20

… war der erste Beitrag nicht Teil der aktuellen Ansicht und @topic_view.prev_page wurde nicht ausgelöst, da die Ansicht noch auf der ersten Seite war.

Daher fehlten alle Attribute des Microdata-Schemas DiscussionForumPosting, die entweder im Kontext des ersten Beitrags oder bei @topic_view.prev_page == true gerendert wurden.

PR

Einige Attribute des Microdata-Schemas DiscussionForumPosting werden im Kontext des ersten Beitrags gerendert. Stellen Sie sicher, dass diese Attribute auch gesetzt werden, wenn der erste Beitrag nicht Teil der aktuellen Ansicht ist.

3 „Gefällt mir“
36

Hmmm… Das ist unerwartet. Es tut mir leid für die Umstände. Ich glaube, die URL-Vergleichsprüfung verwirft die Abfrageparameter beim Vergleich. Ich werde eine Korrektur einführen.

3 „Gefällt mir“
37

Gibt es hierzu ein Update zu dieser Korrektur?

38

Ich glaube, die diese Woche ausgerollte Korrektur berücksichtigt Query-Parameter bei der Prüfung „Ist dies eine externe URL“. Foren, die sich über einen Query-Parameter auf OPs von einer anderen URL beziehen (foo vs. foo?page=2), melden daher keine Fehler mehr im GSC.

3 „Gefällt mir“
39

Ich glaube, die diese Woche ausgerollte Korrektur berücksichtigt Query-Parameter bei der Prüfung „Ist dies eine externe URL“.

41

@rrlevering auf einer anderen Forenplattform empfehlen Sie, für jeden Beitrag in einem Thread in comment - Schema.org Property zu verschachteln. Das sieht nicht so aus, als ob Discourse das tut. Empfehlen Sie das immer noch?

42

Discourse verschachtelt das Comment-Schema für jeden Beitrag im Thread. Schauen Sie sich Schema Markup Validator an und öffnen Sie das DiscussionForumPosting-Objekt, um die verschachtelten Kommentare zu sehen.

2 „Gefällt mir“
43

Danke! Ich habe es im DiscussionForumPosting übersehen.