ディスカッションフォーラムスキーマの改善

rrlevering · 2024 年 1 月 3 日午後 3:11

URLはブロックされている場合でもそのまま残してください。フォーラムのユースケースとしてそれが理にかなっているかどうかは議論できますが、クロールがブロックされていても、曖昧さの解消に役立つ可能性があります。

Jagster · 2024 年 1 月 3 日午後 3:39

それはまだ丁寧な依頼にすぎず、Googleでさえ毎回尊重するわけではありません。たとえば、GmailのリンクはGooglebotをすぐにそこに誘導し、十分な訪問があればインデックス作成と検索結果につながります。

さらに…状況が将来どのように変化するかは、私たち/あなたにはわかりません。今修正されていれば、後で心配する必要はありません。確かに、それは作業時間を要求しますが、それについての投資や議論も同様です😏

rrit · 2024 年 1 月 4 日午後 3:32

現在、DiscussionForumPosting の datePublished 属性が first page では page=2+ の datePublished と異なっています！

first page:
2015-07-05T22:02:58Z
page=2+:
2015-07-05T22:02:57Z

Google はデータが異なることを信頼しない可能性があり、それゆえ、これら 2 つの URL が結合できない異なる DiscussionForumPosting を含んでいると判断するかもしれません。

first page と page=2+ で同じデータソースを使用する方が良いでしょう。
例えば、常にトピックから datePublished を使用し、最初の投稿からは絶対に使用しない、などです。

first page の search.google.com/test/rich-results
datePublished: 2015-07-05T22:02:58Z

grafik1276×854 61.4 KB

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

grafik1266×894 76.7 KB

PR:

常にトピックから datePublished を使用し、first_post からは絶対に使用しない。これにより、first page と page=2+ で datePublished が一貫するようになります。

page=2+ で text を繰り返す必要はありません。特に、text が要約に過ぎず、first page の text と 100% 一貫しない場合は、page=2+ で text を設定しないでください。
Google Search Console で予期しない結果が発生した場合: フォローアップページ page=2+ で text 属性を保持します。

rrit · 2024 年 1 月 5 日午前 12:01

クローラービューから「〇日前にクローズ」された投稿を非表示にする

トピックがクローズされると、トピックに特別な投稿が追加されます。
例：Google structured data for forums and profile pages - #15 を参照してください。

もちろん、この投稿にはない空の text 属性があります。validator.schema.org for …/t/-/286762 を参照してください – > 最後のコメント：

Google Search Consoleでのレポート

結論

したがって、この特別な種類のシステム/アナウンス投稿は、クローラービューから除外する必要があります。

PR

特別な種類のシステム/アナウンス投稿は、コンテンツがないため、クローラービューから除外されます。

空のコンテンツは、Google Search Consoleで「フィールド「text」（「comment」内）がありません」というクリティカルではない問題を引き起こします。

JonahAragon1 · 2024 年 1 月 6 日午前 8:20

プロフィールフィールドにフルネームが利用可能な場合に、著者名のメタデータを設定する方が理にかなっていますか？少なくとも prioritize username in ux が無効になっているフォーラムでは（ただし、どちらの場合でも URL フィールドで曖昧さが解消されるため、どちらでも良いと思います）。

digitaldominica · 2024 年 1 月 6 日午後 2:29

これを解決するために何かできることはありますか、それともDiscourseチームがコアを更新する必要がありますか？

rrit · 2024 年 1 月 7 日午後 3:38

Ryan Levering:

現在のサーチコンソールに表示されているチェックのために、擬似コードを記述させてください。[…]
    if not (IsDeletedContent() OR IsExternalContent())
       then if not ("text" OR "articleBody" OR "sharedContent" OR "image" or "video")
         then report(OneOfThreeRequired("text", "image", "video"))
   […]
[…]

DiscussionForumPosting が、マルチページコンテンツの元のページのように別のページ上のコンテンツを参照している場合、OPトピックタイトルなどの任意のものを保持するスタブを持ち、最初のページのURLを参照するだけで済みます。それが IsExternalContent() チェックであり、これは単に url != page URL であるかどうかを確認するものです。

@rrlevering この「フォローアップページでの text 属性は不要」/ IsExternalContent() チェックについて：

ライブドメインでこのテストケースがあります：

Discourse は以下のように DiscussionForumPosting を実装しています…

最初のページ - ページURL： https://example.org/t/-/12345
- 属性 url： https://example.org/t/-/12345
- 属性 text： – 設定済み –
- 属性 author： – 設定済み –
page=2 - ページURL： https://example.org/t/-/12345?page=2
- 属性 url： https://example.org/t/-/12345
- 属性 text： – 全く設定されていません –
- 属性 author： – 設定済み –

結果：Googleサーチコンソール（ライブテスト）

最初のページ：
DiscussionForumPosting 有効
page=2：
DiscussionForumPosting 無効
- 重大な問題が1件 – 「text」、「image」、「video」のいずれかを指定する必要があります

したがって、ここでは IsExternalContent() のチェックが行われていないか、またはチェックが以下に対して page URL と属性 url が等しいと想定しています。

ページURL：
https://example.org/t/-/12345?page=2
属性 url：
https://example.org/t/-/12345

そのため、現時点では、Googleサーチコンソールで 有効な DiscussionForumPosting を取得するために、フォローアップページで属性 text を繰り返す必要があります。

rrit · 2024 年 1 月 9 日午後 7:49

`DiscussionForumPosting` のスキーママークアップが無効です - 特定のトピック/投稿の URL のみ\n\n影響を受けるトピック: 合計 20 件を超える投稿があるトピック\n影響を受ける URL: `…/t/-/NNN/7` から `…/t/-/NNN/20`\n\n\n#### 「Google リッチ結果テスト」でのレポート\n[details="URL …/t/-/NNN/11: 合計投稿数が異なるトピック (クリックして開く)"]\n* 合計 18 件の投稿があるトピック: …/t/-/283678/11 の結果有効\n* 合計 19 件の投稿があるトピック: …/t/-/235984/11 の結果有効\n* 合計 20 件の投稿があるトピック: …/t/-/264899/11 の結果無効\n* 合計 21 件の投稿があるトピック: …/t/-/282382/11 の結果無効\n\n– すべてのサンプルトピックは、投稿の合計数が変更されないように「クローズ」されています。このバグは「オープン」なトピックにも影響します！ –\n[/details]\n\n[details="URL …/t/-/16968/1 から …/t/-/16968/38 まで: 現在 38 件の投稿がある 1 つのトピック (クリックして開く)"]\n有効なスキーママークアップ:\n– `DiscussionForumPosting` 自体に不要な属性 `position: 1` がまだあります。 –\n* …/t/-/16968 の結果: `Comment`-position 2 から 20\n* …/t/-/16968/1 の結果: `Comment`-position 2 から 20\n* …\n* …/t/-/16968/6 の結果 `Comment`-position 2 から 20。\n\n無効なスキーママークアップ: `author`/`datePublished` が欠落しています\n* …/t/-/16968/7 の結果 `Comment`-position 2 から 21。\n* …/t/-/16968/8 の結果 `Comment`-position 3 から 22。\n* …\n* …/t/-/16968/20 の結果 `Comment`-position 15 から 34。\n\n再び有効なスキーママークアップ: (ここでは: `@page > 1` が `true` です):\n* …/t/-/16968/21 の結果: `Comment`-position 16 から 35\n* …/t/-/16968/22 の結果: `Comment`-position 17 から 36\n* …\n\n* …/t/-/16968/24 の結果: `Comment`-position 19 から 38\n* …/t/-/16968/25 の結果: 現在含まれています `Comment`-position 19 から 38\n* …\n* …/t/-/16968/38 の結果 – 現在の最後の投稿: 現在含まれています `Comment`-position 19 から 38\n* …\n* …/t/-/16968/999 の結果 – 存在しない高い投稿: 現在含まれています `Comment`-position 19 から 38\n[/details]\n\n#### 技術的考慮事項\n\n[details="1. `@topic_view.prev_page` は、`author`/`datePublished` を表示するかどうかを決定するのに最適なソリューションではない可能性があります。"]\n\napp/views/topics/show.html.erb#L53-L60\n\nxml\n <% if @topic_view.prev_page %>\n <meta itemprop='datePublished' content='<%= @topic_view.topic.created_at.to_formatted_s(:iso8601) %>'>\n <span itemprop='author' itemscope itemtype=\"http://schema.org/Person\">\n <meta itemprop='name' content='<%= @topic_view.topic.user.username %>'>\n <link itemprop='url' href='<%= Discourse.base_url %>/u/<%= @topic_view.topic.user.username %>'>\n </span>\n <meta itemprop='text' content='<%= @topic_view.topic.excerpt %>'>\n <% end %>\n\n\n[/details]\n\n\n[details="2. `@topic_view.prev_page` の実装自体にバグがある可能性があります。"]\n\nlib/topic_view.rb#L113-L115\nlib/topic_view.rb#L128-L130\nlib/topic_view.rb#L193-L195\n\n`rb\n @post_number = [@post_number.to_i, 1].max\n# ---\n @page = @page.to_i > 1 ? @page.to_i : calculate_page\n# ---\n def prev_page\n @page > 1 && posts.size > 0 ? @page - 1 : nil\n end\n`\n\nここにバグはありますか？\nlib/topic_view.rb#L751-L755\n\n`rb\n def calculate_page\n posts_count =\n is_mega_topic? ? @post_number : unfiltered_posts.where(\"post_number <= ?\", @post_number).count\n ((posts_count - 1) / @limit) + 1\n end\n`\n* `calculate_page` は予期しない結果を返す可能性がありますか？それは現在の `@post_number` を使用し、値 7 から 20 までで何らかの理由で失敗しますか？\n* `((posts_count - 1) / @limit) + 1` は次のような結果になります:\n `((7 - 1) / 20) + 1 = 1.3 = 1`\n* 期待されるページ番号は何ですか？おそらく、非整数値で計算し、意図したとおりに `floor`/`ceil` で数値を丸めてから整数に型キャストします:\n `(((posts_count - 1.0) / (@limit + 0.0)) + 1.0).floor.to_i`\n* `@topic.posts` に意図したとおりに post_1 から始まるすべての投稿が含まれていない可能性があるため、`unfiltered_posts.where(\"post_number <= ?\", @post_number)` を確認してください。\n\nlib/topic_view.rb#L53-L55\nlib/topic_view.rb#L119-L127\nlib/topic_view.rb#L835-L841\nrb\n def self.chunk_size\n 20\n end\n# ---\n @chunk_size =\n case\n when @print\n TopicView.print_chunk_size\n else\n TopicView.chunk_size\n end\n\n @limit ||= @chunk_size\n# ---\n def unfiltered_posts\n result = filter_post_types(@topic.posts)\n result = result.with_deleted if @guardian.can_see_deleted_posts?(@topic.category)\n result = result.where(\"user_id IS NOT NULL\") if @exclude_deleted_users\n result = result.where(hidden: false) if @exclude_hidden\n result\n end\n\n\n[/details]\n\n#### 結論\n\nこのエッジケースでは…\n* 合計 20 件を超える投稿があるトピック\n* `…/t/-/NNN/7` から `…/t/-/NNN/20`\n\n…最初の投稿は現在のビューに含まれておらず、ビューがまだ最初のページにあったため `@topic_view.prev_page` がトリガーされませんでした。\n\nそのため、最初の投稿のコンテキスト内、または `@topic_view.prev_page == true` の場合にのみレンダリングされていた `DiscussionForumPosting` マイクロデータスキーマのすべての属性が欠落していました。\n\n#### PR\n\u003e `DiscussionForumPosting` マイクロデータスキーマの一部の属性は、最初の投稿のコンテキストでレンダリングされます。これらの属性が、最初の投稿が現在のビューに含まれていない場合にも設定されるようにしてください。\n\nFIX: set microdata schema for topic on missing first post by rr-it · Pull Request #25195 · discourse/discourse · GitHub

rrlevering · 2024 年 1 月 17 日午後 1:33

うーん、予期せぬ事態です。ご迷惑をおかけして申し訳ありません。URL比較チェックでクエリパラメータが失われているようです。修正を展開します。

Soenneker · 2024 年 2 月 1 日午前 11:48

この修正に関するアップデートはありますか？

rrlevering · 2024 年 2 月 1 日午後 3:58

今週リリースされた修正により、「これは外部URLか」チェックでクエリパラメータが考慮されるようになったと考えています。そのため、クエリパラメータ（foo vs. foo?page=2）によってOPを異なるURLから参照するフォーラムでは、GSCでエラーが報告されなくなります。

Akshiya · 2024 年 7 月 26 日午前 8:56

今週リリースされた、URL の「外部 URL かどうか」のチェックでクエリパラメータを考慮する修正について

gbernhardt · 2025 年 1 月 21 日午後 2:54

@rrlevering 別のフォーラムプラットフォームでは、スレッド内の各投稿を comment - Schema.org Property スキーマにネストすることを推奨していました。Discourse はそうしていないようです。それでも推奨しますか？

rrlevering · 2025 年 1 月 23 日午後 5:41

Discourse は、スレッド内の各投稿に対して Comment スキーマをネストします。Schema Markup Validator を確認し、DiscussionForumPosting オブジェクトを開いて、ネストされたコメントを確認してください。

gbernhardt · 2025 年 1 月 23 日午後 5:52

ありがとうございます！DiscussionForumPostingの中にネストされていたのを見落としていました。

トピック		返信	表示
Google Structured Data -- Invalid Article Schema Support	44	8733	2018 年 11 月 9 日
Different schema type for Topics and Posts Feature	16	3806	2024 年 1 月 1 日
Google structured data for forums and profile pages Feature seo	14	1626	2024 年 1 月 1 日
Removing the /2, /3, /4, etc links for each reply within a topic URL Dev seo	33	4107	2024 年 10 月 13 日
Search console "author" field missing: (+1,000% increase Bug	7	497	2024 年 4 月 3 日

ディスカッションフォーラム スキーマの改善

クローラービューから「〇日前にクローズ」された投稿を非表示にする

Google Search Consoleでのレポート

結論

PR

ライブドメインでこのテストケースがあります：

結果：Googleサーチコンソール（ライブテスト）

関連トピック

ディスカッションフォーラムスキーマの改善