Discourse カレンダー/イベントの「今後のイベント」ルートは、初期のサーバーレンダリングHTMLレスポンスからOpen GraphおよびTwitterカードのメタデータをすべて省略しているようです。
これは、通常のページが正しくソーシャルメタデータを出力し、有効なサイトのOpenGraph画像が設定されているホスティングされたDiscourseサイトでも再現可能です。
影響を受けるルートの例:
https://www.mbacommons.com/upcoming-events/month/2026/8/1
再現手順
- 有効なサイトのOpenGraph画像を設定します。
- ホームページまたは通常のトピックが、生のHTMLで通常のOpen Graphメタデータを出力していることを確認します。
/upcoming-events/month/2026/8/1を開きます。- JavaScript実行後のDOMではなく、
view-source:または初期のサーバーレスポンスの生のHTMLを検査します。
実際の結果
「今後のイベント」ルートはHTTP 200を返しますが、生のHTMLには以下の要素が含まれていません:
og:imageog:titleog:descriptionog:urltwitter:cardtwitter:image
LinkedInBot/1.0 を使用してテストしましたが、結果は同じでした。
同じサイトで行われた生のHTMLの本番環境監査では、以下の数値が記録されました:
- ホームページ: 11個のソーシャルメタデータタグ
- 通常のトピック: 14個
- 今後のイベント: 0個
ホームページと通常のトピックは、設定されたサイトのOpenGraph画像を正しく使用しているため、サイトレベルのブランディング設定自体は正常に動作しています。
期待される結果
「今後のイベント」ルートは、クローラーが検知できるサーバーレンダリングのソーシャルメタデータを出力する必要があります。少なくとも以下を含める必要があります:
og:titleog:descriptionog:urlog:image(設定されたサイトのOpenGraph画像にフォールバック)- 対応するTwitterカードメタデータ
LinkedInや同様のソーシャルクローラーはクライアントサイドのテーマJavaScriptに依存できないため、これらのメタデータは初期HTMLに含まれている必要があります。
LinkedIn Post Inspectorは現在、以下を報告しています:
LinkedIn上のコンテンツの画像を制御するには、ページにog:imageタグを追加してください。
グローバルなテーマの head_tag インジェクションは適切ではないようです。通常のページにはすでに正しいメタデータがあり、重複または競合するタグを作成する可能性があるためです。これは、「今後のイベント」に対するルート認識型のサーバーサイド処理、またはDiscourseの通常のソーシャルメタデータレンダリングパスの使用が必要であるように見えます。