ハクソク

世界を動かす技術を、日本語で。

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

2026年6月22日原文(hawksley.dev)

概要

JSON-LD はウェブページに構造化データを追加するためのフォーマット SEO やリッチリンクプレビュー、検索順位向上に貢献 Schema.org ベースでノードごとに適切な型・プロパティを設定 主要ノード： WebSite, WebPage, Person, ProfilePage, SoftwareApplication, BreadcrumbList, CollectionPage ページごとに適切なノードを選択・実装が推奨

JSON-LDの基本と導入方法

  • JSON-LD （JSON Linked Data）は、ウェブページに 構造化データ を追加するためのフォーマット
  • Webクローラー がサイトの意味的構造を理解しやすくなり、 リッチなリンク表示 や SEO向上 に寄与
  • <script type="application/ld+json">タグ内にJSON-LDを記述し、 head要素 内に配置するのが基本
    • このMIMEタイプ指定により、 ブラウザのJSエンジン では実行されず、Googlebot等の 専用クローラー が解析
  • { "@context": "https://schema.org" }で Schema.org スキーマを指定し、 有効なキー・値ペア の範囲を定義
  • JSON-LDは@graph配下に ラベル付き有向グラフ としてノードを記述
    • 各ノードは@type（型）、@id（一意な識別子）、 プロパティ （属性値ペア）を持つ

主要ノードの使い方

WebSiteノード

  • サイト全体の メタデータ を記述
  • name, url, alternateName, description, inLanguage, publisher, image 等のプロパティを活用
  • ルートページには 詳細版、他ページには 簡易版 を使用可能

WebPageノード

  • 現在のページ 自体を表現
  • @type: WebPageで、 物理的なHTMLページ を指す
  • name, url, isPartOf, inLanguage, breadcrumb 等を記述
  • ProfilePage, CollectionPage などの サブタイプ も存在

Personノード

  • 個人サイト では必須。 運営者情報 を詳細に記述
  • name, givenName, familyName, image, sameAs, url が特に重要
    • sameAs で他のプロフィールやSNSアカウントを明示し、 知識グラフ の構築に貢献
  • affiliation, alumniOf, nationality, jobTitle 等で詳細な情報も追加可能

ProfilePageノード

  • 人物紹介ページ 等に使用
  • isPartOf でWebSiteと関連付け、 mainEntity で誰のページか明示
  • dateCreated, dateModified で新鮮さもアピール

SoftwareApplicationノード

  • ソフトウェア紹介ページ に適用
  • name, url, description, applicationCategory, operatingSystem, creator, sameAs, offers 等を記述
  • offers.price はFOSSの場合でも0を明示

BreadcrumbListノード

  • パンくずリスト を構造化データで表現
  • itemListElement 配下に ListItem として階層情報を記述
  • SEO上のパス表現 をコントロールしやすくなる

CollectionPageノード

  • リスト主体のページ （例：ブログ一覧、プロフィール一覧）で使用
  • name, description, isPartOf, about, breadcrumb 等を記述
  • breadcrumb は必ず該当ページのものを参照

JSON-LD設計のポイント

  • @id はURL＋ハッシュで ユニーク性 を確保
  • 複数ページで同じ@idを使う場合 は、クローラーによる プロパティ統合 を考慮
  • Schema.org には多様なノード型が存在。 SEO効果が高い型 を優先的に実装
  • 詳細な記述 が推奨されるが、プロパティは 必要に応じて省略 も可能

まとめ

  • JSON-LD は SEO・リッチ表示 ・ 機械可読性向上 に有効
  • 主要ノード をページ種別ごとに適切に選択・設計
  • 構造化データ の充実が、 検索エンジンやAI による理解・評価を高める
  • Schema.org の公式ドキュメントも適宜参照し、 最新仕様 に準拠した実装が重要

Hackerたちの意見

セマンティックHTMLはあるけど、なんか変な理由で、また独自の変なJSONをスクリプトタグに入れて、ブラウザが処理しない意味を再表現しなきゃいけないんだよね。

└

自分のウェブサイトでJSON-LDを使ったことがあるけど、セマンティックHTMLとは別のニーズを満たすんだよね。セマンティックHTMLはブラウザが処理するタイトルや見出しみたいなことを指定するけど、JSON-LDのデータはメタデータ、つまり作成日や更新日、タグ、著者情報みたいなもの。これらはマイクロデータを使ってHTMLで表現できるけど、JSON-LDの方が楽だからマイクロデータはやめた。JSON-LDはサイト生成に使うデータから取得して、インデックスページ（2024年のブログ投稿一覧とか、トピックXに関連する投稿とか）を生成するのに使ってる。JSON-LDの主な利用者は検索エンジンだよ。もし傷つきたいなら、私たちがウェブページにOpenGraphメタデータも入れてることを考えてみて。同じページに対して二つの異なるメタデータフォーマットがあるんだ。

└

理想的なのは、サーバーとブラウザがコンテンツ交渉できる世界だと思う。ブラウザがまずウェブサイトからJSON-LDだけをリクエストして、自分の内部レンダラーフォーマットを使うような感じ。

└

マイクロデータもあるし、間違ってなければJSON-LDと同じ語彙をサポートしてるよ（schema.orgはいいリソースだね）。とはいえ、JSON-LDはしばらく前からデフォルトになってるし、RESTをRPCに大体放棄したのと同じように。今でも重要なパーサーがマイクロデータをサポートしてるかは正直わからないけど、クライアントのために作ったサイトでは、特にGoogle検索の露出を狙うeコマースサイトではLDを使うのがデフォルトになってる。編集：セマンティックHTMLとの比較も注目に値するね。セマンティックHTMLはマークアップの構造を定義するのに役立つけど、「これは販売用の製品です」とか「これは電車の時刻表です」といった現実の文脈はカバーしてない。

└

セマンティックHTMLはJSON-LDや他のマイクロフォーマットがカバーするものをカバーしていない。記事だけを見ても、個人のためのセマンティック要素は何？ パンくずリスト？ ソフトウェアアプリケーション？ ブログ？ ブログ投稿？ セマンティックHTMLは、スクリーンリーダーを使う人が「ナビゲーション」や「記事」みたいな一般的な要素をナビゲートするのを助けるためにあるんだ。

└

記事を十分に理解してないと思うよ。JSON-LDやスクリプトタグなしでも、HTMLでSchema.orgやFOAF、WikiDataなどのオントロジーを使えるからね。

実用的な考え方を持ってる人には、Googleのウェブサイト向けのJSON-LDに関するドキュメントを読むことを勧めるよ； https://developers.google.com/search/docs/appearance/structu... たくさんの情報が特定のサイトの小さなサブセットにしか関係ないことにも気づくと思う。Rotten Tomatoesは映画の批評評価をJSON-LDで公開できるけど、私には関係ない（たとえ映画のレビューを書いても）。JSON-LDは簡単で、実際に検索エンジンに使われてるからいいよね。確かにウェブページ自体の情報を重複させることもあるけど、情報を完璧に注釈して、ドキュメントに一度だけ表示されるっていう夢は、まあ、球体の牛や無質量のロープの夢みたいなもんだと思う。ウェブページを作るには人間の努力が必要だし、最終的な製品にちょっとした重複があっても全然構わないよ。

└

でも、データを重複させると水道代が増えるよね。/s

└

403。エラーだよ。あなたのクライアントはこのサーバーからURL /search/docs/appearance/structured-data/intro-structured-data にアクセスする権限がないよ。それが全てだね。

ウェブクローラーがあなたのサイトのセマンティックな構造を理解するのを助け、リッチなリンクプレビューの資格を得たり、検索ランキングを改善する可能性もあります。これは比喩的に言うと、過去の戦争と戦っているようなものです。私と私のWWWサイトに関して言えば、今のGoogleは私のコンテンツを長いLLM生成のバージョンで、エラー付きで、実際のコンテンツの上に表示するようになってしまった。『パンくずリスト』やドメイン名の代わりにきれいな表示名を得ることは、Googleがそれらを優先順位を下げている事実には対処していない。これは、実際に私のサイトを直接訪れる人が決して見ることのないものに対して多くの努力をかけているし、Googleを使っている人がそのLLM化されたコンテンツの折り返しの上に見つけることもない。

└

そうだね。何年も前から、トラフィックを増やすために「マイクロデータ」タグや属性をウェブサイトに詰め込んできたけど、結局それがしたのはGoogleのAIを育てるだけだった。人々がGoogleから出て行かないようにね。

└

もし、こういうデータを提示することが重要だと思うなら、種をまこう。たとえGoogleが使わなくても、こういうメタデータを適用することで、インターネット全体が肥沃になって、非LLMスクレイピングの競合が代替オプションを提供できるようになるから。Googleに屈するだけじゃ、彼らが支配的なままで、競合が高いハードルを越えなきゃいけなくなるし、同じ技術を使うことになるよ。

Hacker Newsで議論の続きを見る