SEO は、サイトの中を整える内部対策と、外からのリンクや評判を得る外部対策に分けられます。制作の段階で手を打てるのは内部対策で、その中でも、作る側がはっきり手を入れられて結果が目に見えるのが構造化データです。

構造化データとは

構造化データとは、ページに書かれている内容が何なのかを、機械が読める形で注釈として添える記述です。人が見る画面には表示されません。

たとえば画面に「2026年9月11日」と書いてあっても、検索エンジンにはそれが公開日なのか、イベントの開催日なのか、営業日なのかは分かりません。構造化データで「これは公開日（datePublished）です」と添えておくと、推測ではなく事実として扱われます。

語彙（どんな種類があり、どんな項目を持つか）は schema.org という共通の辞書で決まっています。検索エンジン各社がこれを参照しているため、1回書けばどこでも読めます。

何が変わるのか

構造化データを入れると、検索結果の見え方が変わることがあります。これをリッチリザルトと呼びます。

• 検索結果にパンくず（トップ > コラム > …）が出る
• 記事に公開日や画像が付く
• 商品の価格・在庫・評価が出る
• 求人情報が専用の枠に載る
• イベントの日付と場所が出る

表示が変わるとクリック率が変わります。順位が同じでも、情報量が多いほうが選ばれやすくなるためです。つまり構造化データは「順位を上げる仕組み」ではなく「クリックされやすくする仕組み」です。

書いたとおりに必ず表示されるわけではありません。リッチリザルトを出すかどうかは検索エンジン側の判断です。正しく書くことは条件ですが、保証ではありません。

書き方は JSON-LD が基本

構造化データの書き方は3通りあります。HTMLのタグに属性で書き込む microdata と RDFa、そしてHTMLとは分離して script タグの中に書く JSON-LD です。いまは JSON-LD が推奨されており、実務でもこれだけで足ります。

理由は運用のしやすさです。HTMLの中に属性として埋め込むと、デザイン変更でタグを組み替えたときに壊れます。JSON-LD なら1か所にまとまっているので、見た目の変更と無関係に保てます。

<script type="application/ld+json">
{ ... }
</script>

head の中でも body の中でも構いません。1ページに複数置いても問題ありません。

よく使う型

型（@type）はたくさんありますが、制作で実際に使うのは限られています。

FAQPage と HowTo は、以前はよくある質問や手順が検索結果に展開されましたが、2023年に一般のサイトでは表示されなくなりました。いま新しく入れても見た目は変わりません。古い記事では「FAQを入れると目立つ」と書かれていることがあるので注意してください。

実装例

BreadcrumbList｜まずこれを入れる

全ページに入れられて、検索結果の見え方がはっきり変わります。最初に入れるならこれです。最後の要素（いま見ているページ）には item を付けません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "トップページ", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "コラム", "item": "https://example.com/column/" },
    { "@type": "ListItem", "position": 3, "name": "構造化データとは" }
  ]
}
</script>

画面に出しているパンくずと、必ず同じ並びにしてください。画面と違う階層を書くと、見えない情報をマークアップしていることになります。

Organization｜トップページに1つ

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/img/logo.png",
  "telephone": "+81-3-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "100-0001",
    "addressRegion": "東京都",
    "addressLocality": "千代田区",
    "streetAddress": "1-1-1"
  },
  "sameAs": [
    "https://x.com/sample",
    "https://www.facebook.com/sample"
  ]
}
</script>

sameAs には公式のSNSアカウントを並べます。同じ社名の別会社と混ざらないようにする手がかりになります。

Article｜記事ページ

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データとは",
  "description": "検索エンジンに内容の意味を渡す記述です。",
  "image": "https://example.com/img/column/structured-data.webp",
  "datePublished": "2026-09-11T10:00:00+09:00",
  "dateModified": "2026-09-11T10:00:00+09:00",
  "author": { "@type": "Organization", "name": "ワプラボ" },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/column/structured-data/"
  }
}
</script>

日付は ISO 8601 の形式で、時差（+09:00）まで書きます。2026/9/11 のような書き方は読まれません。dateModified を入れるなら、実際に直したときに更新してください。中身を変えていないのに日付だけ新しくするのは、評価を得るための操作と見なされます。

WordPressでの入れ方

SEO系のプラグインを入れていれば、Organization・Article・BreadcrumbList あたりは自動で出力されています。まずソースを見て、すでに出ているものを確認してください。

足りない型や、カスタム投稿タイプのぶんは functions.php から出します。

add_action("wp_head", function () {
    if (!is_singular("works")) {
        return;
    }
    $data = [
        "@context"      => "https://schema.org",
        "@type"         => "Article",
        "headline"      => get_the_title(),
        "datePublished" => get_the_date("c"),
        "dateModified"  => get_the_modified_date("c"),
        "mainEntityOfPage" => [
            "@type" => "WebPage",
            "@id"   => get_permalink(),
        ],
    ];
    echo '<script type="application/ld+json">'
        . wp_json_encode($data, JSON_UNESCAPED_UNICODE)
        . '</script>';
});

get_the_date("c") は ISO 8601 の形式で返します。自分で日付を組み立てる必要はありません。

script タグの中のJSONに JSON_UNESCAPED_SLASHES を付けないでください。記事の本文に </script> という文字列が含まれていた場合、スラッシュがそのまま出力されてスクリプトタグが途中で閉じ、ページが壊れます。URLが \/ のように見えるのは正しい状態で、検索エンジンは問題なく読みます。

プラグインと自分のコードで同じ型を二重に出していることもあります。二重になっていると、どちらが使われるか分からなくなるので、出力元は1つに絞ってください。

書いたら必ず確認する

1. リッチリザルトテスト … そのURLがどのリッチリザルトの対象になるかを判定します
2. スキーママークアップ検証ツール … schema.org として書式が正しいかを見ます
3. Search Console の「拡張」 … 実際に検出された数とエラーが、サイト全体で分かります

最後のものが運用では一番役に立ちます。書いた直後は正しくても、記事が増えるうちに画像が無い記事や日付が空の記事が混ざり、エラーとして溜まっていきます。月に一度は見てください。

よくある失敗

• 画面に書いていない情報をマークアップする … ガイドライン違反です。表示されている内容と一致させます
• 自社サイトで自社に評価（レビュー）を付ける … 違反として扱われます
• 価格や在庫が実際の表示と違う … ECで起きやすく、違反になります
• 全ページに同じ BreadcrumbList を出す … コピーして置いたままにすると、階層が合いません
• 日付の形式が違う … 読まれずに無視されます
• プラグインと自作で二重に出力している

共通しているのは「画面と食い違っていないか」です。構造化データは画面の内容を説明するものなので、画面より多くを語ってはいけません。

構造化データだけでは順位は上がらない

これは過大評価されやすい施策です。構造化データは検索結果の見え方に効きますが、順位そのものを押し上げるものではありません。先に済ませておく項目があります。

• 検索エンジンが見られる状態か … noindex や robots.txt で止めていないか、http と https で重複していないか
• タイトルと説明文 … ページごとに違う内容になっているか
• 見出しの構造 … h1 は1つ、その下に h2・h3 と段が下がっているか
• 内部リンク … どこからもリンクされていないページを作っていないか
• 表示速度 … 画像が大きすぎないか

この5つができていないサイトに構造化データだけ足しても、結果は変わりません。逆に、ここが整っているサイトでは、構造化データは手間に対して効果が見えやすい施策になります。

「SEO対策込み」とうたう制作でも、実際にやっているのは内部対策の範囲です。構造化データをどの型まで入れるか、記事を書くところまで含むかは、必ず確認してください。

構築時点で組み込みます

当社では、パンくず・会社情報・記事の構造化データを構築時点で入れています。あとから足すこともできますが、テンプレートの作りによっては全ページに手を入れることになるため、最初に入れておくほうが安く済みます。

既存サイトで、いま何が出力されているか調べてほしい、エラーが溜まっているので直したい、というご相談にも対応しています。