個人ウェブサイトのためのJSON-LD解説

 (hawksley.dev)
2 ポイント 投稿者 GN⁺ 8 시간 전 | 1件のコメント | WhatsAppで共有
  • 個人ウェブサイトでも構造化データを入れることで、クローラーがページ・人物・記事の関係をよりよく理解でき、リンクプレビューや検索での露出品質を改善できる
  • 実装は <head> 内の <script type="application/ld+json"> で @context を Schema.org に指定し、@graph に WebSite、Person、BlogPosting などのノードを配置する方式
  • 同じ @id を使うとウェブクローラーは複数ページにまたがるノード属性をマージできるが、1ページしか読まないスクレイパーや LLM はマージしないという違いがある
  • ルートページには WebSite、ProfilePage、Person を基本として置き、ブログ・プロジェクト・一覧ページには Blog、BlogPosting、SoftwareApplication、CollectionPage、BreadcrumbList を性格に応じて追加する
  • Person の sameAs、ページの breadcrumb、記事の image・license・日付フィールドは、人物識別、検索結果での経路表示、記事プレビュー、利用条件、鮮度判断に直接使われる

JSON-LDの役割と基本構造

  • JSON-LD は JSON Linked Data の略で、ウェブページに構造化データを追加する形式
  • クローラーがサイトの意味構造を理解するのを助け、より豊かなリンクプレビューや検索順位の改善につながる可能性がある
  • ページに追加する際は、<head> セクション内に次の形式のスクリプトを入れる
    • <script type="application/ld+json"> は MIME タイプを application/ld+json として宣言する
    • このタイプが指定されると、ブラウザの JavaScript エンジンは実行しない
    • Googlebot のような特殊なクローラーがその要素を見つけて内容を解析する

@context、@graph、ノード ID

  • @context は JSON-LD データが従う文脈を指定し、ウェブクローラーは Schema.org を標準として使う
  • Schema.org は JSON で使える有効なキーと値の組み合わせを定義する
  • JSON-LD 文書はラベル付き有向グラフとして見ることができ、データは @graph の下に格納される
  • グラフには複数のノードが入り、ノード同士は有向の接続で結ばれる
  • 各ノードは次の要素で構成される
    • @type: ノードが何であるかを示す。例: WebSite, SoftwareApplication
    • @id: 通常は URL の末尾に一意のハッシュ値を付けたノード識別子
    • 属性: ノードの特性を表すキーと値の組み合わせ
  • ウェブクローラーは同じ @id を共有するノードの属性を複数ページにわたってマージできる
  • ただし、単一ページだけを読むスクレイパーや LLM は属性をマージしないため、複数ページで JSON-LD を再利用する際はこの違いを考慮する必要がある
  • @id は #website のように、ノードを一意に識別するハッシュを URL の後ろに付ける方式が推奨される

サイトとページを説明するノード

  • WebSite

    • WebSite はサイトのメタデータを保持し、クローラーがサイトをどう表示するか判断するためのヒントを与える
    • ルートページには url、name、alternateName、description、inLanguage、publisher、image などの属性を含む詳細版を置ける
    • すべてのページに完全な WebSite ノードを入れる必要はない
    • ドメインのルートページは詳しく記述し、他のページでは @type、@id、url、name だけを含む簡略版でも十分
    • 簡略版は、単一ページしか読まないクローラーがサイト名を正しく把握するために必要な文脈を提供する

  • WebPage

    • WebPage は現在のページそのもの、つまりHTML の物理ページを表す
    • BlogPosting のようなコンテンツタイプとは区別すべきで、WebPage はそのコンテンツを載せているページを指す
    • 例となる属性には url、isPartOf、name、inLanguage、breadcrumb が含まれる
    • ProfilePage、CollectionPage は WebPage のより具体的なサブタイプ
    • あまり一般的でないサブタイプは Schema.org の WebPage 定義 で確認できる

個人識別とプロフィールページ

  • Person

    • 個人ウェブサイトのすべてのページには Person ノードを入れることが推奨される
    • Person はサイトの所有者が誰かを示し、Google のコンテンツ品質指標の一部として使われる
    • LLM クローラーも、回答で誰を引用するか判断する際に Person 情報をますます利用している
    • WebSite と異なり、Person はすべてのページに含めるだけの価値がある重要な文脈
    • 重要な属性は次のとおり
      • url: ルートページを指してノードを固定する
      • name, givenName, familyName: 名前を明確に示す
      • image: 可能なら本人写真や関連ロゴを使って正式な画像を結び付ける
      • sameAs: 他のプロフィールをクローラーに知らせ、人物識別を助ける
    • sameAs は特に同姓同名が多い場合の別人との区別に有用で、複数ページにまたがるナレッジグラフ表現を作るのに使われる
    • そのほかの Person 属性は詳細を加えるのに有用だが必須ではなく、省略しても影響は小さい

  • ProfilePage

    • ProfilePage はサイト内で特定の人物に関するページを表す
    • ホームページで自分を紹介しているならホームページに使えるし、別の about ページがあるならそちらに置くほうが適切な場合もある
    • isPartOf でより大きな WebSite ノードと結び付けることが重要
    • mainEntity は、そのページが誰についてのものかをクローラーに伝える
    • dateCreated、dateModified はクローラーに対する鮮度シグナルとして有用だが、サイトで簡単に提供できないならそれほど気にする必要はない

プロジェクトと経路表示

  • SoftwareApplication

    • ページでソフトウェアを紹介するなら、SoftwareApplication ノードでそのソフトウェアのメタデータを持たせるのがよい
    • より具体的な型として MobileApplication、WebApplication、VideoGame を使える
    • url 属性はプロジェクトが配布されている場所を指すべき
    • 例として crates.io のような配布ページが該当する
    • sameAs はソースコードリポジトリのような、プロジェクトに関連する他のページに使う
    • applicationCategory の有効な値は Google の SoftwareApplication 定義 で確認できる
    • FOSS プロジェクトであっても offers を含め、価格を 0 に設定すべき

  • BreadcrumbList

    • BreadcrumbList はルートページを除くすべてのページで広く有用
    • ページの分類経路を表し、実際の URL パスと必ずしも同じである必要はない
    • 検索エンジンが特定ページの経路をどう表示するかを制御するために使える
    • サイトのパスがすでに短いなら、このノードの利点は小さく省略できる
    • パスが長いサイトでは BreadcrumbList が検索結果の経路を短くするのに役立つ

一覧、ブログ、記事ページ

  • CollectionPage

    • CollectionPage は主に一覧を含むページに使う WebPage のサブタイプ
    • 他のプロフィールをまとめた /elsewhere/ ページや、ブログ記事一覧の /blog/ ページが例
    • about で関連する Person ノードを結び付けられる
    • breadcrumb は必ず現在ページに対応する正しい BreadcrumbList と結び付ける必要がある

  • Blog

    • Blog ノードはブログのインデックスまたはホームページに追加する
    • WebSite と個々の BlogPosting の間をつなぐ中間ノードの役割を果たす
    • dateModified は鮮度シグナルとして有用だが、簡単に提供できないなら省略してよい
    • license はクローラーに記事をどの条件で利用できるかを伝える
    • 個人ウェブサイトでは publisher を Organization ではなく Person に設定してもよい
    • Google のドキュメントは以前と異なり Person も有効に許容しており、個人ウェブサイトにはより正確な場合がある

  • BlogPosting

    • BlogPosting は公開されたすべてのブログ記事に含めるべき
    • クローラーが記事をより正確に表現できるよう追加情報を提供する
    • 検索結果でより正確な配置と豊富な詳細情報を提供するために使われる場合がある
    • 個人サイトでは author と publisher が同じ Person ノードを指していても問題ない
    • image 属性は、記事のリンクプレビューにすでに使っているOG 画像に合わせるのがよい
    • license は記事の利用条件を示すために使える

最小実装と適用基準

  • 個人サイトに必要な JSON-LD は、ページの性格に応じて選択的に構成できる
  • ビルド工程のない静的サイトでも、ルートページに最低限次のノードを追加することで効果を得られる
    • WebSite
    • ProfilePage
    • Person
  • ブログがあるなら Blog と BlogPosting を追加し、記事一覧や外部プロフィール一覧ページには CollectionPage を使える
  • プロジェクト紹介ページには SoftwareApplication、ルート以外のページには BreadcrumbList を検討できる

関連記事

1件のコメント

 
GN⁺ 8 시간 전
Hacker Newsのコメント

  • たとえて言えば、前の戦争をもう一度戦っているような感じだ
    私の WWW サイトの立場からすると、Google は今や人々を実際の私の文章へ送るより、誤りの混じった長い LLM 生成要約を上に表示している
    「パンくず」やドメインの代わりに見栄えのよい表示名を得ても、Google がそうした要素をきれいに整えるかどうかより優先順位を下げているという現実は解決しない
    実際のサイトに直接来る人は絶対に見ず、Google を使う人にとっては Google 自体の LLM 化されたバージョンの下に押し込まれて見つけにくいものに、あまりにも多くの努力を費やしていることになる

    • こういうデータに意味がある世界を望むなら、まず 種をまかなければならない
      Google が使わなくても、インターネット全体がこうしたメタデータを適用すれば、LLM スクレイピングではない競合が代替手段を提供しやすい土壌になる
      Google に屈すれば支配力を強めるだけで、競合の参入障壁が高まり、彼らも同じ技術を使うよう追い込まれる
    • 本当にその通りだ。うちの会社も今では Google 検索でこう表示される:
      $STATE を拠点とする IT 企業で、中西部の企業向けに実用的な AI ワークフローと情報管理ソリューションの構築を専門としている。俊敏な固定価格契約モデルで運営され、エンタープライズ的な肥大化を避けつつ、具体的な成果を提供することに注力している
      うちが 実用的な AI ワークフローを提供していたとは知らなかった
      そのうえ、似てはいるが明らかに別の名前の競合他社名を混ぜ込み、私を役員として載せている。せめてもの救いは、その競合は連絡先を「相談予約」フォームの後ろに隠しているので、こちらの連絡先だけが表示されることだ
    • もう Google に私のサイトを クロールしてインデックス化することすら許可していない
    • Google も今では「ボットがサイトに来たら 10GB zipbomb を受け取る」対象に含めている
      今では何の価値も加えず、問題を増やすだけだ
    • その通り。何年ものあいだ、トラフィックを持ってきてくれることを期待して、ウェブサイトに microdata タグや属性を山ほど入れてきた
      結局のところ、人々が Google を離れないようにする Google の AI を訓練していただけだった

  • 実務的な志向なら、ウェブサイト向け Google ドキュメントで JSON-LD を読んでみることを勧める
    https://developers.google.com/search/docs/appearance/structu...
    多くの情報が一部のサイトにしか関係しないこともわかるはずだ。Rotten Tomatoes は JSON-LD で映画評論家の評価を公開できるが、私が映画レビューを書くとしても、それは自分にはあまり関係がない
    JSON-LD は簡単で、実際に検索エンジンが使っているので悪くない。ウェブページ内の情報を重複させることにはなるが、情報が文書内に正確に一度だけ現れるよう完全に注釈付けするという夢は、球形の牛や質量のないロープのような理想化に近いと思う
    ウェブページを作るには人の手間が必要で、最終成果物に多少の重複があるのは問題ない

    • 大規模サイトでなくても映画レビューに JSON-LD は使える
      私のサイトでは本、ゲーム、映画のレビューに使っていて、たいていの検索エンジンでは星評価のような情報が表示されているようだ
    • 403. That’s an error.
      クライアントにはこのサーバーの /search/docs/appearance/structured-data/intro-structured-data URL を取得する権限がないと表示される
    • でもデータを重複させると 水の使用量が増えるのでは。/s

  • リッチなリンクプレビューでは、JSON-LD より OpenGraph のほうがはるかに頻繁にサポートされている
    検索エンジン最適化が目的なら、検索エンジンがサポートする JSON-LD の種類は非常に具体的で限定的だ。対象の検索エンジンのドキュメント、つまり Google[1] や Bing[2] を見て、その通りに従うほうがずっとよく、それ以外は時間の無駄に近い
    検索エンジン以外でも、特定の目的がないなら JSON-LD はたいてい役に立たない。JSON-LD が必要な具体的要件があるなら、有用なデータを入れればよいが、それ以外のデータを入れるのは空に向かって叫ぶようなものだ
    IndieWeb[3] は構造化データを使っているが、JSON-LD を DRY 違反とみなし、代わりに Microformats[4] を使っている
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • すべてのWebサイトで実際に実装したいのは、Schema.org語彙を使う構造化データだと思う
    JSON-LDはその方法の1つで、RDFaやMicrodataもある
    最初に学ぶときはこの記事を参考にしたし、おすすめできる: https://neilpatel.com/blog/get-started-using-schema/
    どんなデータを追加するかはこのツールで確認できる: https://technicalseo.com/tools/schema-markup-generator/
    一覧全体はschema.orgサイトで見られる: https://schema.org/docs/schemas.html

  • 数年前、航空券が埋め込まれたり配送追跡情報が表示されたりする凝ったメール機能が、すべてメール内のJSON-LDで実装されていると知った
    ただ、私の知る限りではGmailだけが対応している
    追加情報: https://www.emailonacid.com/blog/article/email-development/s...

    • OutlookとiCloudも、チケットや予約のような一部機能には対応している

  • こうした属性が実際に検索での露出に役立つのか、それとも検索エンジンがユーザーを検索結果ページに引き留めやすくするだけなのか気になる

    • JSON-LDを追加したら、Googleが私のサイト内に入る下位リンクを表示し始めた。あれはよかった
    • ビジネスサイトなら、JSON-LDは地図プラットフォームにデータを供給するために使える
      住所、営業時間、電話番号、メニューなどだ

  • すでにセマンティックHTMLがあるのに、なぜかブラウザが処理しないscriptタグの中のカスタムな奇妙なJSONで、Webサイトの意味をまた表現しなければならない

    • 自分のWebサイトでJSON-LDを使ってみたが、セマンティックHTMLとは別のニーズを満たしていると思う
      セマンティックHTMLは、タイトルや見出しのようにブラウザが処理するものを指定する。JSON-LDのデータは、作成日、更新日、タグ、著者のようなメタデータだ
      これらはHTML内でmicrodataとして表現することもできるが、JSON-LDのほうが簡単なのでmicrodataを使うのはやめた
      JSON-LDはサイト生成に使うのと同じデータから埋めていて、このメタデータで2024年のブログ記事一覧やトピックXに関する記事一覧のような索引ページも作っている。JSON-LDの主な利用者は検索エンジンだ
      さらに腹立たしくなりたければ、同じページにOpenGraphメタデータも入れていることを考えればいい。つまり同じページに異なるメタデータ形式が2つある
    • Microdataもあって、間違っていなければJSON-LDと同じ語彙をサポートしている。schema.orgはよい資料だ
      ただJSON-LDがしばらく標準の選択肢になっていて、これは私たちがRESTをだいたい捨ててRPCに移ったのと似ている。今でも重要なパーサーがmicrodataをすべてサポートしているのかはよく分からないし、特にGoogle検索での露出を狙うECサイトのようなクライアントサイトを作るときは、基本的にLDを使ってきた
      セマンティックHTMLと比べたときの注目点もある。セマンティックHTMLはマークアップ構造の定義には役立つが、「これは販売中の商品だ」や「これは列車の時刻表だ」といった現実世界の文脈までは表現できない
    • この記事を十分理解できていないのかもしれない
      JSON-LDやscriptタグなしでも、HTML内でSchema.org/FOAF/WikiDataのようなオントロジーを使うことはできる
    • 理想的な世界は、サーバーとブラウザがコンテンツネゴシエーションできて、ブラウザがまずWebサイトにJSON-LDだけを要求し、その後で独自の内部レンダラー形式を使うことだと思う
    • セマンティックHTMLは、JSON-LDやほかのマイクロフォーマットが扱う範囲を包含していない
      記事に出てくるものだけ見ても、人、パンくずリスト、ソフトウェアアプリケーション、ブログ、ブログ投稿を表すセマンティック要素は何か、という話になる
      セマンティックHTMLは、スクリーンリーダーを使う人が「ナビゲーション」や「記事」のような一般要素をたどれるようにするためのものだ

  • これは単にOpenGraphをJSONで書いたものではないのか? 利点は何だろう

  • 2024年以降、うちのコンテンツベースのマーケティングページのトラフィックは約85%減った
    理解できないのは、ゼロクリック検索結果ページが増えたのならGoogleも大きな打撃を受けていないのか、という点だ
    クリックベースの検索結果ページ広告収益も同じように深刻に減っているはずだが、この仮説を反証または確認できる公開数値は見つけられていない

  • ある一線を越えると、共生が搾取に変わる微妙なバランスがある
    Webサイトが検索エンジンの助けで露出を得ようとする関係は、かなりの部分で相互利益だった
    しかし今は、Webサイトの所有者が汗を流して作った成果から何も得られない方向へ完全に向かっている