「リニューアルしたのに、検索結果での見え方が前より地味になった気がする」「競合はパンくずや星評価がリッチに出ているのに、うちは青いリンクとテキストだけ」「会社名で検索しても、ナレッジパネルに会社情報がまとまって出ない」——受託でサイトを引き継ぐと、こうした相談をよく受けます。デザインは新しくなったのに、検索結果という「もう一つの入口」での見栄えだけが取り残されている。原因の多くは、構造化データ（JSON-LD）が欠けているか、入っていても中身がページの表示内容とずれていることにあります。
構造化データは、ページの中身が「記事なのか」「会社情報なのか」「パンくずなのか」を検索エンジンに機械可読な形で伝える仕組みです。これが正しく入っていると、検索結果に発行日や著者、パンくず、会社のロゴといった付加情報（リッチリザルト）が出やすくなり、クリックされやすくなります。本記事では、Googleが今もサポートしている型と正しい書き方、そして受託でやりがちな実装ミスを、制作を請け負う立場から整理します。
リニューアルで構造化データが消える、よくある経緯
引き継いだサイトで構造化データが欠けているとき、たいてい原因は次のどれかです。
ひとつは、旧サイトのCMSが自動で出していたものが、移行で消えたケースです。WordPressのテーマやプラグインが裏で記事のArticleやパンくずのBreadcrumbListを出力していたのが、別のCMSや静的サイトへ移ったときにそのまま抜け落ちる。デザインだけ移植して、見えない部分の出力が引き継がれていない状態です。
ふたつめは、そもそも一度も入れていなかったケース。見た目は整っているのに、検索エンジンから見ると「ただのHTML」で、これが記事なのか商品なのか判別する手がかりがない。
みっつめが厄介で、入ってはいるが中身が間違っているケースです。古いテンプレートのまま著者名が空だったり、表示していない情報をマークアップしていたり、JSONとして壊れていて検索エンジンに無視されている。「入れたつもり」で安心しているぶん、見つかりにくい負債です。
検索結果での見栄えは、流入の入口そのものです。構造化データがそもそもなぜ検索やAI検索で効くのかという土台は、構造化データとAI検索の記事で扱っています。
形式はJSON-LD一択でよい
構造化データの書き方には、JSON-LD・Microdata・RDFaの3つがありますが、新しく実装するならJSON-LDを選んでおけば間違いありません。GoogleもJSON-LDを推奨しています。理由は明快で、JSON-LDは <script type="application/ld+json"> というブロックにまとめて書くため、HTMLの見た目のマークアップと完全に分離できるからです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "グリームハブ株式会社",
"url": "https://gleamhub.net/",
"logo": "https://gleamhub.net/logo.png"
}
</script>HTMLのタグの中に属性として埋め込むMicrodataと違い、JSON-LDは構造化データだけを独立したブロックとして管理できます。受託で他人が書いたデザインを壊さずに後から追加でき、更新も一箇所で済む。保守のしやすさが段違いです。なお、弊社のコーポレートサイトはAstroで構築していて、構造化データの出力には astro-seo-schema を使い、ページ種別ごとにJSON-LDを組み立てる方式をとっています。レイアウト側でまとめて出すことで、記事ごとに手書きする漏れを防いでいます。
いま入れるべき型は、ほぼこの4つ
schema.orgには膨大な型がありますが、受託で扱うコーポレートサイトやメディアで「まず正しく入れる価値があるもの」は、実のところ多くありません。Googleがリッチリザルトとして扱う主要な型に絞ると、判断が楽になります。
| 型 | どんなページに | 検索結果で何が起きるか |
|---|---|---|
| Organization | サイト全体（会社情報） | 会社名・ロゴ・SNSがGoogleに認識されやすくなる |
| Article | 記事・ブログ・お知らせ | 発行日・著者・見出しが構造的に伝わる |
| BreadcrumbList | 階層のあるページ全般 | 検索結果にパンくず階層が表示される |
| FAQPage | よくある質問のあるページ | （表示は環境依存。後述の注意あり） |
OrganizationとBreadcrumbList、記事ページのArticleの3つを正しく入れるだけで、冒頭に挙げた「会社情報がリッチに出ない」「パンくずが出ない」という症状の多くは解消に向かいます。型の選び方や優先度に迷ったら、まずこの並びで考えると外しません。SEOそのものの全体像を押さえたい場合は、SEO初心者ガイドも土台として役立ちます。
FAQやHowToに過度な期待をしない
注意したいのが、FAQPageやHowToといった型です。Googleはここ数年、リッチリザルトの整理を進めており、FAQやHowToのリッチな表示は大きく縮小しました。2025年から2026年にかけての変更で、FAQリッチリザルトの表示は大幅に減り、HowToも実質的に表示されなくなった、という報告が複数あります。マークアップ自体は無効ではありませんが、「FAQを入れれば検索結果が派手になる」という前提で工数を割くと、見返りが合いません。確実に効く型から固めるのが、受託では堅実です。
受託で一番やらかすのは「表示とのずれ」
技術的な書き方そのものより、受託で深刻なのはマークアップした内容とページに表示されている内容がずれていることです。Googleの構造化データガイドラインは、ユーザーに見えていない情報をマークアップすることを明確に禁じています。JSON-LDに書いた著者名・日付・説明は、ページ本文にも同じものが見えていなければなりません。
これに反すると、最悪の場合、リッチリザルトの対象から外す手動による対策（マニュアルアクション）を受けます。検索順位そのものが下がるわけではありませんが、リッチな表示の資格を失います。せっかく入れた構造化データが、逆効果になるわけです。
弊社が改修を引き継いだあるコーポレートサイト（社名は伏せます）では、トップページに古いテンプレート由来のJSON-LDが残っていて、すでに退任した代表者名や、もう提供していないサービス名がマークアップされたままでした。表示されている内容とJSON-LDの中身が食い違っている状態です。私たちはまず、ページに実際に表示されている会社情報・サービス内容とJSON-LDを突き合わせ、表示にないものをすべて削り、表示しているものだけを正確に記述し直しました。やったのは派手な作業ではなく、「見えているものと、機械に伝えているものを一致させる」だけです。それだけで、ナレッジパネルに正しい会社情報が出るようになりました。
ありがちな実装ミスは、表示とのずれ以外にもいくつかパターンがあります。
| ミス | 症状 | 直し方 |
|---|---|---|
@context の書き忘れ | ブロック全体が無視される | 各ブロック先頭に "@context": "https://schema.org" を置く |
| JSONの文法エラー（末尾カンマ等） | 構造化データが丸ごと読まれない | 末尾カンマを削る・ダブルクォートに統一する |
| 必須プロパティの欠落 | リッチリザルトの対象外になる | 型ごとの必須項目を埋める（Articleなら見出し等） |
これらは目視では気づきにくいので、検証ツールに頼るのが確実です。
公開前に必ず検証ツールへ通す
構造化データは「書いて終わり」ではなく、機械が正しく読めるかを公開前に確認する工程まで含めてはじめて完成します。確認手段は主に二つです。
- Rich Results Test（リッチリザルトテスト） — Googleがリッチリザルトとして認識できるか、どの型が有効かを判定する。エラー（リッチリザルトが出ない）と警告（任意項目の不足だが動く）を分けて教えてくれる。
- Schema Markup Validator（validator.schema.org） — schema.orgの語彙として文法的に正しいかを検証する。Googleの対象外の型でも、構造として妥当かを確認できる。
受託では、納品前にこの二つを通して「エラーゼロ」を確認するところまでをセットにします。警告は許容できる場合もありますが、エラーが残っていると、せっかくのマークアップが検索結果に反映されません。公開後も、Google Search Consoleの拡張レポートで、検出された構造化データのエラー数を継続的に見ておくと、CMSの更新で壊れたときに早く気づけます。
検索結果での見栄えと並んで、表示速度などのページ体験もクリックと評価に効きます。あわせて整えるなら、Core Web Vitalsの記事の観点も同時に確認しておくと無駄がありません。
どこから着手するか
引き継いだサイトの検索結果での見栄えを取り戻したいなら、まず現状のページを一枚ずつ検証ツールに通し、「構造化データが入っているか」「入っているなら表示内容と一致しているか」を切り分けるところから始めます。何も入っていなければOrganizationとBreadcrumbList、記事ページのArticleを正しく足す。古い間違った記述が残っていれば、表示している内容に合わせて直すか、いっそ削ってから入れ直す。派手な施策ではありませんが、検索結果という入口の見え方を、確実に競合と並べるところまで持っていけます。
最初の一手としては、トップページのOrganizationと、記事一覧のArticle・BreadcrumbListを、Rich Results Testでエラーゼロにすることをお勧めします。ここが整うだけで、会社情報とパンくずの表示が変わり、効果を実感しやすいはずです。
リニューアル後に検索結果の見栄えが競合に負けている、引き継いだサイトに構造化データが入っているか分からない、入れたはずなのにリッチリザルトが出ない——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトの構造化データを検証ツールで棚卸しし、表示内容とのずれを切り分けたうえで、効く型から正しく入れ直します。
Sources
- Intro to How Structured Data Markup Works － Google Search Central
- General Structured Data Guidelines － Google Search Central
- Learn About Article Schema Markup － Google Search Central
- JSON-LD Tutorial: Syntax, @id, @graph, Validation (2026)
- Schema Markup After March 2026: Structured Data Update － DigitalApplied
- A beginners guide to JSON-LD Schema for SEOs － SALT.agency
