構造化データを入れれば表示される、わけではない｜Google公式が語ったマークアップの実際と14の誤解

検索を学ぶ

構造化データの話は、たいてい「入れましょう」で終わります。何を入れると何が起きるのか、そして入れても起きないことは何かまで踏み込んだ説明は、あまり見かけません。

Googleの説明を追っていくと、マークアップには2つの層があることが分かります。リッチリザルトやショッピング結果のように、入れることで機能が有効になるもの。 そしてHTMLの正しさやセマンティックな構造のように、入れても順位には効かないもの。 この2つを混ぜて語ると、話がおかしくなります。

この記事では、公式ポッドキャスト「Search Off the Record」でマークアップを扱った回から、商品情報・有料コンテンツ・画像の実務と、否定された14の通説をまとめました。

この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。

まず、期待値の話から

第72回（2024-04-25）に、生成AIにSEO関連のSNS投稿を作らせて内容を検証する、という実験的な回があります。その中で、構造化データを実装してもGoogleがリッチリザルト（星評価など）を必ず表示するとは限らないという皮肉的な内容が生成され、これは概ね技術的に正しいと確認されました。

構造化データは「表示される権利」を得るものであって、「表示される約束」ではありません。ここを踏まえたうえで、実際に何ができるのかを見ていきます。

商品情報：schema.orgとMerchant Centerの使い分け

第81回（2024-09-05）は、Google ShoppingチームのIrina氏がゲストの回です。ECサイトを運用しているなら、この記事でいちばん実務的な部分になります。

ショッピング結果は2つのインフラから出ている

ショッピング結果は、ウェブ検索インフラとショッピング検索インフラの両方から表示されます。人気サイトであれば、schema.orgマークアップがあればリッチスニペットやブルーリンクの商品情報として表示される、と説明されています。

Merchant Center登録なしでも取り込まれる

ここは知らない人が多いかもしれません。schema.orgマークアップがあれば、Merchant Centerへの登録がなくてもクロールによって無料で商品情報がShoppingに取り込まれます。 Google Adsを使っているかどうかは関係ありません。

では、どちらを使うべきか

“We recommend doing both”（第81回、2024-09-05）——両方です。

理由は、それぞれ得意なことが違うためです。

schema.orgマークアップMerchant Centerフィード
形式階層的。オープンソースでGoogle以外も利用フラットなキーバリュー。Google独自仕様
更新クロール依存日次・週次・月次を指定可能。自動アイテムアップロードなら商品単位でも指定可
強み網羅性更新頻度のコントロール

両方を使うことで、データの網羅性と更新頻度の両方をコントロールできる、というのがGoogleの推奨理由です。

なお、schema.orgとフィード仕様の間には属性のギャップが存在し、その解消に取り組んでいるとも語られています。片方にしかない項目がある、ということです。

価格が反映されないときの3つの原因

第81回で挙げられているのは以下です。

  1. データ品質の問題 — フィードとサイトの内容が一致していない
  2. ポリシー違反 — 模造品や処方薬の販売など
  3. クロール予算不足による更新遅延

価格が古いまま表示される、という相談はよくありますが、原因が3種類あることを知っていると切り分けが早くなります。

機能の展開は国ごとに違う

ショッピングポリシーは国・地域ごとに異なり（アルコールなどが例に挙がっています）、機能の展開も米国先行で、ヨーロッパは規制により遅れる傾向があると明言されています。

日本での対応可否や表示仕様がどうなっているかは、この回では触れられていません。個別に確認する必要があります。

進行中の拡張

Merchant Knowledge Panelのために、schema.orgのOrganizationタイプを拡張し、配送・返品情報やロイヤルティプログラムの情報を追加中だと語られています。

また、商品バリエーション（Variants）機能の実装には、schema.orgコミュニティとの議論、インフラ変更、リッチスニペット対応、Search Consoleレポートの拡張、ドキュメント整備まで約1年以上かかり、関与したチーム数は過去最大規模だったそうです。マークアップの仕様が増えるスピードが遅く感じられる理由の一端が見えます。

Search Console側では、Merchant Listing Reportにインプレッションとクリックのオーバーレイが追加され、マークアップ修正後にパフォーマンスが改善したかを確認できるようになっています。

注意: 第81回は収録から約2年が経過しています。Merchant Centerの機能やSearch Console連携、属性ギャップの解消状況は更新されている可能性が高い部分です。

有料・会員コンテンツ：paywall構造化データとログインページ

第99回（2025-09-04）は、ログインの背後にあるコンテンツをどう扱うかを扱った回です。会員制サービスを運営しているなら、ここは読む価値があります。

paywall構造化データの役割

ペイウォールコンテンツは、Googlebotに全文を見せつつ、paywall構造化データを付与することで、ユーザーには制限があることを示せます。全文をクロールさせつつクローキング扱いにならない、という仕組みです。

実装上の注意も語られています。ペイウォールで隠す部分は、JavaScriptで表示・非表示を切り替えるのではなく、HTMLのDOMに読み込まないようにすべきです。理由はSEOではなく、スクリーンリーダーが読み上げてしまう問題があるためでした。

汎用ログインページの罠

この回でいちばん実務的なのがこれです。

“If you have a very generic login page”（第99回、2025-09-04）——ユーザー名とパスワードだけの汎用的なログインページに多数のプライベートURLがリダイレクトすると、Googleはそれらを重複と判断します。結果としてログインページ自体がインデックスされ、サービス名で検索してもログインページしか出てこないという状態になります。

対策は2つ挙げられています。

ログインページに説明文を入れる。 サービス内容についての簡単な説明があれば、Googleがその情報をインデックスできます。複数のサービスが同じログインページを使っていても区別がつくようになります。実際、GoogleもDocsやSheetsなどでそれぞれ少し異なるログインページを用意しているそうです。

未ログイン時はマーケティングページにリダイレクトする。 Search Console自身がこの仕組みを採用しており、未ログインでプライベートURLにアクセスするとマーケティングページにリダイレクトし、そこに「ここでサインイン」というリンクを表示しています。

robots.txtでブロックしてはいけない

プライベートコンテンツは、robots.txtでブロックするのではなくnoindexを使うか、ログインページにリダイレクトすべきとされています。

robots.txtでブロックすると、GoogleはURLの存在自体は把握しつつ内容を確認できません。その結果、どこかからリンクされていれば検索結果にURLだけが表示される可能性があります。隠したつもりが、URLだけ晒される形になります。

関連して、URLにユーザー名やメールアドレスなどの個人情報を含めるのは避けるべきだとされています。ランダムなハッシュ文字列程度なら大きな問題にはなりません。

確認方法

自分のサイトが正しく扱われているかを確認する最良の方法として挙げられているのは、シークレットウィンドウで自社サービス名やページ内容を検索してみることです。上位に何が出るか。ログインページだけか、それとも適切なマーケティングコンテンツか。

すぐできるわりに、やっていない人が多そうな確認だと思います。

注意: 第99回は2025年の収録ですが、paywall構造化データやインデックス処理の仕様は継続的に更新されます。最新の公式ドキュメントで詳細を確認してください。

画像：マークアップより先にやること

第97回（2025-08-07）は写真家向けの回ですが、画像を多く扱うサイト全般に当てはまる内容です。

個別のランディングページを作る

“If you’re interested in having your images individually findable, definitely make individual landing pages.”（第97回、2025-08-07）

個々の画像に固有のランディングページ（説明文付き）を用意すると、画像検索経由でその画像が主要な画像だと理解しやすくなります。逆に、フラグメント（#）で区切っているだけで個別URLを持たない実装は不利です。

ゲストのMartin氏自身の写真サイトが、静的サイトジェネレーターでギャラリーページを作り、個別画像がフラグメント区切りになっている——つまり不利な構成になっている、という自虐的な例として語られています。

ギャラリーページに説明文がないと判断できない

画像だけが並んでいて説明文がないページは、そのページが探している情報と合致しているかをGoogleが判断しづらくなります。テキストで場所や特徴を明記すると見つけやすくなる、とされています。

効かないもの

  • 透かし（ウォーターマーク） — 入れてもGoogleがサイトを不利に扱ったりペナルティを与えたりすることはありません
  • 先にアップロードすること — 自分のサイトに先に画像をアップして先にインデックスされれば、SNS上の同じ画像より正規（canonical）扱いになる、という仕組みではありません
  • レスポンシブ画像 — 良い実践ではありますが、それ自体が特定キーワードでの上位表示を保証するものではありません

なお、同じ写真をSNSとサイトの両方に載せても、ウェブページ自体はデザインが異なるため通常は別々に扱われます。ただし画像検索では重複と見なされる可能性がある、という補足がありました。

動画の扱いが変わっている

動画がページの主要コンテンツでない場合——大きなギャラリーページに付随する動画など——動画として検索結果に表示されにくくなっています。 これは収録の約1年前に変更された仕様だとMartin氏が言及しています。

ページの片隅に動画を置いて動画検索からの流入を期待する構成は、現在は成立しにくいということです。

マークアップそのものは、順位を上げない

ここからが2つ目の層です。第105回（2026-02-26）と第94回（2025-06-26）で、技術者が信じやすい通説がまとめて否定されています。

HTMLの標準準拠度（validity） がランキングに直接影響するという通説は明確に否定されました。セマンティックマークアップ——見出し階層やHTML5の構造要素の適切な使用——も、アクセシビリティやブラウザには有用だが検索エンジンのランキングにはほとんど影響しない、とされています。resource hints（DNS prefetch、preload、preconnect）も、Googlebotは同期的な取得を行わずキャッシュを利用するため無関係です。

裏付けとして、第94回では “0.5% of the top 200 websites have valid HTML on their homepage.”（第94回、2025-06-26）という調査結果が紹介されています。上位200サイトのうち、ホームページに有効なHTMLを持つのは0.5%。それでも上位に表示されています。

同じ回では、HTMLが壊れていると必ず深刻な悪影響が出るという考えも過度な誇張だとされ、テキストとして読める部分は多くの場合問題なく扱われる、と説明されました。

第68回（2024-01-25）のSEOスターターガイド刷新の回でも、同種の否定が並んでいます。メタキーワードはランキングに全く影響せず今後も使用する予定はないこと。見出しやtitle要素以外のHTML構造はランキングにそれほど影響しないこと。そして、”using any other Google product will not influence your ranking in Google Search”（第68回、2024-01-25）——他のGoogleプロダクトを使うことが検索順位に影響することはない、と。

構造化データは機能を有効にするためのもので、HTMLの正しさは順位のためのものではない。 この線引きが、マークアップ全体を理解する軸になります。

Googleが否定した14の通説

このクラスタに含まれる回で否定された項目をすべて挙げます。マークアップという括りが広いため、一部は他の記事で詳しく扱っています。

構造化データ・画像まわり

通説Googleの説明出典鮮度
画像に透かしを入れるとGoogleに不利に扱われるペナルティを与えることはない第97回 2025-08-07要確認
自サイトに先にアップして先にインデックスされればcanonical扱いになるそういう仕組みではない第97回 2025-08-07要確認

HTML・マークアップまわり

通説Googleの説明出典鮮度
メタキーワードはランキングに影響する全く影響しない。今後も使用する予定はない第68回 2024-01-25要確認
ドメイン名（URLのキーワードなど）はランキングに影響する影響はほとんどない第68回 2024-01-25要確認
見出しやtitle以外のHTML構造がランキングに影響するそれほど影響しない第68回 2024-01-25要確認
他のGoogleプロダクトを使うと検索順位に有利になる影響することはない第68回 2024-01-25要確認
HTMLの標準準拠度（validity）が順位に直接影響する明確に否定第105回 2026-02-26要確認
セマンティックマークアップが順位に大きく影響する否定。アクセシビリティには有用第105回 2026-02-26要確認
resource hintsがクロール・ランキングに有用無関係。Googlebotは同期的取得を行わない第105回 2026-02-26要確認
HTMLが壊れていると必ず深刻な悪影響が出る過度な誇張第94回 2025-06-26新しめ

他の記事で詳しく扱う項目

通説Googleの説明出典詳細
JavaScriptは自動的にSEOに悪い／Google製フレームワークなら有利どちらも誤り第94回 2025-06-26レンダリング編
Indexing APIで任意のURLをインデックスさせられる対象は求人情報とライブ動画配信のみ第94回 2025-06-26クロール編
rel=prev/nextでページネーションの重複を伝えられる廃止済みで無視される第72回 2024-04-25国際化編
Googleは別ページからランダムに抜粋する抜粋は該当ページ内からのみ第72回 2024-04-25国際化編

日本のサイト運営者にとって

これらの回で日本語検索や日本市場に特化した言及はほとんどありません。そのうえで、関わりやすいものを挙げます。

ECサイトを運営している場合

第81回のとおり、schema.orgマークアップだけでもMerchant Center登録なしで無料でShoppingに取り込まれます。Adsを使っていないから関係ない、と判断しているなら見直す余地があります。

ただし機能の展開は米国先行だと明言されており、日本での対応状況は個別に確認が必要です。この回で日本については触れられていないので、断定できる材料がありません。

会員制・サブスクリプションサービスを運営している場合

第99回の内容は日本語圏でもあまり解説を見かけません。特に、汎用ログインページに全URLをリダイレクトしてサービス名検索でログインページしか出てこなくなる問題は、実際に起きていても気づきにくいと思います。シークレットウィンドウでサービス名を検索する確認は、今日できます。

プライベートコンテンツをrobots.txtでブロックしている場合

第99回で明確に否定されている実装です。URLだけが検索結果に出る可能性があります。noindexかリダイレクトに切り替える必要があります。

画像を多く扱うサイトの場合

第97回のとおり、フラグメント区切りで個別URLがないギャラリー実装は不利です。国内のポートフォリオサイトや商品ギャラリーでも、この構成は珍しくありません。

開発チームに説明する場合

第105回と第94回の内容は、HTMLの品質改善を「SEOのため」と説明している場合に効きます。保守性やアクセシビリティという本来の理由に言い換えたほうが、結果的に通りやすいはずです。

まとめ

マークアップについて語られてきた内容を並べると、入れると機能が有効になるものと、入れても順位には効かないものがはっきり分かれていました。

前者は、商品情報のschema.org、ペイウォールの構造化データ、画像の個別ランディングページ。これらは実装すると具体的に何かが変わります。ただし構造化データを入れたからといってリッチリザルトが必ず表示されるわけではなく、あくまで表示される候補になるだけです。

後者は、HTMLのvalidity、セマンティックマークアップ、resource hints、メタキーワード。上位200サイトの99.5%が有効なHTMLを持っていないという数字が、この層の実態を表しています。

そして、この記事で拾った中でいちばん実害が大きそうなのは、プライベートコンテンツをrobots.txtでブロックする実装と、汎用ログインページへの一括リダイレクトです。どちらも良かれと思ってやっている構成が、逆の結果を生みます。

なお、この記事で「要確認」と付けた項目は、収録から時間が経っており仕様が変わっている可能性があります。実装を決める前には developers.google.com の最新ドキュメントで裏を取ってください。

関連記事