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

こんにちは。現在、Google Search Consoleでこのメッセージが表示されています。これが何を意味するのかよくわかりません。この問題について、もう少し詳しく教えていただけますか?解決策はありますか?また、プラットフォームで複数のテーマを試しましたが、同じエラーが引き続き発生していることも申し添えたいと思います。

「いいね!」 1

こんにちは、hiccupさん!

構造化データは、検索エンジンにより多くのコンテキストを提供するのに役立ちます。

Google検索では、そのトピックにオプションurlフィールドが見つかりません。
validator.schema.orgで、警告なしに完全に有効であることが確認できます。

心配する必要はありません。
とはいえ、Google検索がこのフィールドを強調表示する場合は、Discourseに追加する正当な理由となります。

「いいね!」 3

上記で @Arkshine が説明したように、これはバグではなく、スキーマにオプションフィールドを追加するという Google からの提案です。確認します。

「いいね!」 2

前のスレッドから:

ですから、「url」はオプションですが、実際にはここに実際の有効なエラーもあります。

itemprop="url" は、Google が同じトピックに属する複数の Comment ブロックを異なる URL で結合するのに役立ちます。

Google Rich Results Test でメタトピックをテストして、あなたが見ているエラーを再現しようとしましたが、エラーは見つかりませんでした。

Google でエラーが表示されているトピックへのリンクを提供していただけますか?

まず注意すべき点は、提示されたリンクが「Discussion Forum Schema」を持っておらず、「Breadcrumbs」スキーマのみを持っていることです。これは、リンクを「スマートフォン」モードではなく、「デスクトップ」モードでテストしているために起こっています。

https://search.google.com/test/rich-results/result?id=TlLcA6saLMo3BrxbQYnFuw

リンクをデスクトップテストに切り替えると、「Discussion Forum」スキーマが表示され、「missing field url」の問題が指摘されます。

クリティカルエラーを再現するには、次のような ?page=2 URLパラメータを持つ長いスレッドをテストする必要があります。

「いいね!」 1

指摘しておきたいのですが、Discourse の重要なバグだと思うのは、スキーマがスマートフォンモードで表示されないことです。Google はそれをフラグ付けする方法を知らないでしょう(Google は存在するスキーマのエラーのみをフラグ付けするため)が、Google にとってスマートフォンでのクロールとインデックス作成は、長年デフォルトとなっているため、スキーマがスマートフォンモードとデスクトップモードの両方に表示されることが重要です。

「いいね!」 2

最初の投稿で説明された問題とその他の問題が、このコミットで修正されました。

suggestions here@rrit さん、ありがとうございます! :+1:

これは、クローラービューで2ページ目以降に最初の投稿が含まれていないために発生しています。@sam さん、スキーマの問題を修正するために、クローラービューですべてのページに最初の投稿を含めるべきでしょうか? :thinking:

「いいね!」 1

いいえ、コンテンツの重複は決して良い結果をもたらさないと思います。他に選択肢はありますか?

「いいね!」 3

もう一つの選択肢は、microdata schemaJSON-LDGoogleが推奨)に置き換えることです。これにより、レンダリングされたデータと構造化データが分離され、Danが上記で指摘したように、モバイルでも機能するようになります。

すでにsolved pluginでJSON-LDスキーマを使用しています。

「いいね!」 3

はい、これははるかに正しい解決策のようですね。

「いいね!」 1

最初の投稿のデータ/テキストを後続のページに含めないでください。ただし、常に最初のページを指す itemprop="url" を追加してください。

Google structured data for forums and profile pages - #9 by rrit を参照してください。

「いいね!」 3

例外のないルールはありません。DiscussionForumPosting について、Googleは JSON-LD ではなく Microdata の使用を推奨しています。

Discussion Forum (DiscussionForumPosting, SocialMediaPosting) Schema Markup | Google Search Central  |  Documentation  |  Google for Developers を参照してください。

技術ガイドライン

  • 一般的な構造化データの設定とは異なり、DiscussionForumPosting マークアップは、可能な限り Microdata(または RDFa)で提供することをお勧めします。これにより、マークアップ内に大きなテキストブロックを重複して記述する必要がなくなります。ただし、これはあくまで推奨であり、JSON-LD も引き続き完全にサポートされています。
「いいね!」 4

Is this alread live on meta.discourse.org?

Please see my comment on github:

This whole link-tag should only be defined for post.is_first_post - no need to repeat it with the identical url for each Comment-item.

On meta.discourse.org the quotation marks are mangled right now:
<link itemprop='mainEntityOfPage' href="…">
See Schema Markup Validator

「いいね!」 3

はい、最近のコミットに従って現在それを行っていますが、それを追加した後でも、後続ページ(?page=2)に必要なフィールド(authordatePublishedtext)がいくつか欠落しています。

素晴らしい指摘です!このPRで修正しました。

ああ、そうです。これは @rrlevering さんによってもここで確認されています。

したがって、後続ページでコンテンツが重複しないようにしながら、Microdata スキーマを改善する必要があると思います。

「いいね!」 7

mainEntityOfPage-プロパティの修正、ありがとうございます。

そして、meta-タグとlink-タグの発見も素晴らしいです :+1:
\u003clink itemprop='url' content='\u003c%= @topic_view.absolute_url %\u003e'\u003e

さらに良いのはこちらです:
\u003clink itemprop='url' href='\u003c%= @topic_view.absolute_url %\u003e'\u003e

参照:
– このリンクは古いですが、YouTubeは今日でも\u003clink itemprop='url' href='…'\u003eを使用しています。–

HTML5でURLを提供するには、[ link タグの場合] href 属性を使用します。
meta 要素の content 属性の値としてURLを使用すると、URLではなく文字列(URLのように見えるもの)を表します。


Googleが提供するDiscussionForumPosting: プロパティのドキュメントを再確認しました。

必須プロパティ:

  • author
  • author.name
  • datePublished
  • text または image または video のいずれか

text または image または video のいずれか」に関する特別な注意

フォーラムの後のページやフォーラムカテゴリページなど、外部のurlを持つ別のページで投稿を表している場合は、これは必須ではありません

推奨プロパティ

  • url
  • […]

url」に関する特別な注意

  • ディスカッションの正規URL。複数ページのスレッドでは、このプロパティを最初のページURLに設定してください。単一のディスカッションでは、通常は現在のURLです。

したがって、以下の結論に至りました。

  • page=2+text を再度追加する必要はありません(完了)。
  • オプションのプロパティ url を追加する必要があります。特に page=2+ に(完了)。

さらなる調査が必要な事項:

  • これらの「必須プロパティ」である authorauthor.namedatePublished は、本当に page=2+ で必須なのでしょうか、それとも省略しても問題ないのでしょうか?
    validator.schema.orgpage=2+ でプロパティが欠落していても文句を言いません。(完了)
    → しばらくこれらの修正が適用された後、「Google Search Console → レポート:拡張機能 → ディスカッションフォーラム」で新しいライブデータを確認します。(TODO)

構造化データ:ツールとリソース

スキーマ

schema.org

developers.google.com

バリデーター

schema.org

  • 一般的なバリデーター:
    https://validator.schema.org/
    これは、スキーマ定義に対する構造化データの準拠性と、マークアップがHTML/XMLに準拠しているかを確認します。
    → チェックされる要件は Standard™ に従っており、かなり広範で具体的ではありません。
    → 検出されたすべてのバグを修正することをお勧めします。

Google Search Console

  • レポート:拡張機能 → ディスカッションフォーラム:
    https://search.google.com/search-console/r/discussion-forum?hl=en
    これは、Googleクローラーによって処理された情報に関する直接的なフィードバックを提供します。
    これらのレポートは、Google SEOに関するある種の拘束力のある事実です。Googleが何かを間違っていると発表した場合、それが間違っていなくても、Googleは間違っていると考えます。
    → 「無効」または「改善が必要」とフラグが付けられた場合、まず修正について考えることをお勧めします。そして、既知の副作用がない場合は、常に修正を実装してください。

Google: Rich Results Test

  • https://search.google.com/test/rich-results?hl=en
    これはシミュレートされたフィードバックのみを提供し、Googleクローラーではありません
    私の意見:Googleのマーケティングツールであり、サイト所有者に「構造化データについて何かしてください!」と伝えるためのものです。
    → このツールはGoogleによってある程度無視されており、Google自体が提供する最新の技術推奨事項と常に一致しているわけではありません。
    Rich Results TestGoogle Search Console と常に同じ結果を提供するとは限りません。疑わしい場合は、Google Search Console を信頼する方が良いです。
「いいね!」 5

Search Console に表示されている現在のチェックの擬似コードを記述させてください。これらのスレッドで非常に役立つと思います。ShEx または SHACL をお送りすることもできますが、それらは人間が読みにくいものです。

    if not (IsDeletedContent() OR IsExternalContent())
       then if not ("text" OR "articleBody" OR "sharedContent" OR "image" or "video")
         then report(OneOfThreeRequired("text", "image", "video"))
    if not ("author")
       then Report(Required("author"))
    if not("datePublished")
       then Report(Required("datePublished")

アイデアは、DiscussionForumPosting/OP が現在のページにコンテンツを持っている場合、何らかのコンテンツフィールドが必要であるということです。

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

ドキュメントの 2 番目の例は、このケース (14 ページ目が最初のページのスタブ投稿を参照する) を正確にモデル化することを目的としていました。

author および date は、現在のところ、検証ルールで常に必須です。これは主に、このデータを見つけるための追加のホップを防ぐためです。OP の日付を知ることが、コメントがどれだけ古いかを理解するのに役立つことがわかります。そのデータを含むメタ要素をそこに追加できますか? 重複データでページを肥大化させることに関しては、それらのフィールドほど心配していませんでした。

「いいね!」 7

Ryan、コンテキストとヒントをありがとう!

これは完了しました。後続のページ(ページ2以降)のメタデータは、これで良くなりました

「いいね!」 3

author URL を、デフォルトの robots.txt によってパスがブロックされている状態で追加しても、まだ意味がありますか?これらの URL を宣伝しているので、robots.txt からブロックを削除すべきでしょうか?

「いいね!」 2