Discourse Events

Discourse カレンダー/イベントの「今後のイベント」ルートは、初期のサーバーレンダリングHTMLレスポンスからOpen GraphおよびTwitterカードのメタデータをすべて省略しているようです。

これは、通常のページが正しくソーシャルメタデータを出力し、有効なサイトのOpenGraph画像が設定されているホスティングされたDiscourseサイトでも再現可能です。

影響を受けるルートの例:

https://www.mbacommons.com/upcoming-events/month/2026/8/1

再現手順

  1. 有効なサイトのOpenGraph画像を設定します。
  2. ホームページまたは通常のトピックが、生のHTMLで通常のOpen Graphメタデータを出力していることを確認します。
  3. /upcoming-events/month/2026/8/1 を開きます。
  4. JavaScript実行後のDOMではなく、view-source: または初期のサーバーレスポンスの生のHTMLを検査します。

実際の結果

「今後のイベント」ルートはHTTP 200を返しますが、生のHTMLには以下の要素が含まれていません:

  • og:image
  • og:title
  • og:description
  • og:url
  • twitter:card
  • twitter:image

LinkedInBot/1.0 を使用してテストしましたが、結果は同じでした。

同じサイトで行われた生のHTMLの本番環境監査では、以下の数値が記録されました:

  • ホームページ: 11個のソーシャルメタデータタグ
  • 通常のトピック: 14個
  • 今後のイベント: 0個

ホームページと通常のトピックは、設定されたサイトのOpenGraph画像を正しく使用しているため、サイトレベルのブランディング設定自体は正常に動作しています。

期待される結果

「今後のイベント」ルートは、クローラーが検知できるサーバーレンダリングのソーシャルメタデータを出力する必要があります。少なくとも以下を含める必要があります:

  • og:title
  • og:description
  • og:url
  • og:image(設定されたサイトのOpenGraph画像にフォールバック)
  • 対応するTwitterカードメタデータ

LinkedInや同様のソーシャルクローラーはクライアントサイドのテーマJavaScriptに依存できないため、これらのメタデータは初期HTMLに含まれている必要があります。

LinkedIn Post Inspectorは現在、以下を報告しています:

LinkedIn上のコンテンツの画像を制御するには、ページにog:imageタグを追加してください。

グローバルなテーマの head_tag インジェクションは適切ではないようです。通常のページにはすでに正しいメタデータがあり、重複または競合するタグを作成する可能性があるためです。これは、「今後のイベント」に対するルート認識型のサーバーサイド処理、またはDiscourseの通常のソーシャルメタデータレンダリングパスの使用が必要であるように見えます。

「いいね!」 2