Next.jsサイトに構造化データ（JSON-LD）を入れた実録 —「検出なし」から「エラーなし」まで

Googleの検証ツールにサイトのURLを入れたら、「No items detected（何も検出されませんでした）」——僕のサイトの構造化データは、文字通りゼロでした。

これは、僕の会社（株式会社U.ai）のサイトに構造化データ（JSON-LD）と著者ページを実装した記録です。「構造化データを入れましょう」という記事は世に多いですが、実際に何をどう書き、どのツールでどう確認したかを実例つきで公開します。

**この記事の結論：**構造化データは「誰が運営するサイトか」をGoogleに宣言する名刺です。Person・Organization・WebSiteを@idで連結して実装し、検証はリッチリザルトテストではなくvalidator.schema.orgで行います。

この記事で分かること：

• 構造化データが「誰が運営しているサイトか」の証明になる理由
• Person・Organization・WebSiteを連結して書く実装パターン
• 検証ツールの使い分け——「No items detected」と表示されても壊れていない話

1. なぜ入れるのか — Googleへの「名刺」

構造化データは、ページの内容を機械が読める形式でGoogleに伝えるデータです。人間には見えませんが、検索エンジンはこれを読んで「このサイトは誰が、どんな組織として運営しているか」を理解します。

Googleはコンテンツの評価軸として、経験・専門性・権威性・信頼性（いわゆるE-E-A-T）を重視するとされています。その出発点は「発信者が実在する誰なのかが分かること」。構造化データは、これを検索エンジンに宣言する名刺の役割を果たします。

2. 実装した3点セット — Person・Organization・WebSite

僕が実装したのは、次の3つを@graphで連結した1つのJSON-LDです。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/#person",
      "name": "（代表者名）",
      "jobTitle": "代表取締役",
      "worksFor": { "@id": "https://example.com/#organization" },
      "sameAs": [
        "https://x.com/（アカウント）",
        "https://www.instagram.com/（アカウント）",
        "https://www.youtube.com/@（アカウント）"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "（会社名）",
      "founder": { "@id": "https://example.com/#person" }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

ポイントは3つあります。

1. @idで相互参照する — Person（代表者）とOrganization（会社）をworksFor/founderで結び、「この人＝この会社の代表」という関係を機械可読にする
2. sameAsに本人の全SNSを列挙する — X・Instagram・YouTubeなどの公式アカウントURLを並べることで、「サイトの運営者とSNSのあの人は同一人物」とGoogleに宣言する。分散していた発信の信頼が1点に集まる
3. 全ページに出力する — うちはNext.jsのルートレイアウトに<script type="application/ld+json">として埋め込み、全ページのheadで配信しています

3. 著者ページとのセット実装

構造化データだけでは「宣言」で終わりです。人間の訪問者にも同じ情報を見せるため、著者ページ（/profile）を新設し、ProfilePageスキーマのmainEntityでPersonの@idを参照させました。

さらにブログ記事には、記事ごとにBlogPostingスキーマを出力し、authorに同じPersonの@idを指定しています。こうすると、記事を書けば書くほど「この著者の実績」がGoogleの中で同一人物に積み上がっていく構造になります。書き捨てにならないのがこの設計の利点です。

4. 検証ツールの使い分け — ここで一度つまずいた

実装後、Googleの「リッチリザルトテスト」で確認したところ、表示されたのは——また「No items detected」でした。実装したのに、です。

原因は仕様の理解不足でした。リッチリザルトテストは、検索結果の特別表示（リッチリザルト）の対象になるタイプしか表示しません。Person・Organization・WebSiteは対象外のため、正しく実装されていても「検出なし」と表示されます。壊れているわけではありません。

目的が違う2つの検証ツールの使い分けです。

構造化データそのものの検証は、Schema.org公式のバリデーター（validator.schema.org）を使います。こちらで確認すると、WebSite・Organization・Personの3つが「エラーなし・警告なし」で検出されました。

5. 結果と、正直な注意点

実装の結果、僕のサイトはBefore「構造化データゼロ」→ After「WebSite・Organization・Person検出・エラーなし」になりました。

実装前後で検証結果がどう変わったかです。

**注意：**構造化データを入れた瞬間に順位が上がる、という性質のものではありません。これは「Googleがサイトを正しく理解するための土台」で、効果は記事の蓄積や被リンクなど他の要素と合わさってじわじわ効く類のものです。即効性を期待して入れるものではなく、発信を積み上げる前に整えておく地盤だと考えています。

あわせて読みたいSEOに効く内部リンク設計の基本 — サイトを「行き止まりの家」にしない

よくある質問

プラグインなしで書く必要がありますか？

WordPressならSEO系プラグインが自動生成してくれる場合が多いです。Next.jsのような自前実装のサイトでは、この記事のようにJSON-LDを直接書きます。どちらでも中身は同じです。

sameAsに載せるSNSは多いほどいいですか？

数より正確さです。実際に本人・自社が運用しているアカウントだけを載せてください。放置アカウントや他人のアカウントを混ぜると、信頼の証明という目的に反します。

実装して検索結果はすぐ変わりますか？

すぐには変わりません。Googleが再クロールして認識するまで時間がかかりますし、前述のとおり構造化データ単体で順位が動くものでもありません。Search Consoleでインデックス状況を見ながら、記事の蓄積と並行して育てるものです。

まとめ

• 構造化データは「誰が運営するサイトか」をGoogleに宣言する名刺
• Person・Organization・WebSiteを**@idで連結**し、sameAsで本人のSNSを紐付ける
• 著者ページとブログ記事のauthorを同じPersonに参照させると、書くほど信頼が積み上がる
• 検証はvalidator.schema.orgで。リッチリザルトテストの「No items detected」に慌てない

この実装を含むサイト改善の経緯は表示速度改善の実録でも公開しています。自社サイトの構造化データ・SEO土台整備のご相談はお問い合わせからどうぞ。