何が起きたか:Googleは「矛盾したメタデータの優先順位」を公表していない
Search Engine Journalの記事(見出し:「Google’s Mueller: Fix Conflicting Metadata, Don’t Test It(GoogleのMueller氏:矛盾したメタデータは直せ、テストするな)」)によると、GoogleのJohn Mueller氏は、商品が在庫ありかどうかについて矛盾した情報が存在する場合に、どの情報源が優先されるのかをGoogleは表明していないと述べました。
記事は冒頭で、ページ上のコンテンツ、マークアップ(構造化データ)、そして商品フィード(product feed)が在庫の有無について食い違っている場合、Mueller氏は「Googleがどう解決するかを分析するのではなく、修正すべきだ」と述べていると要約しています。つまり、矛盾を残したまま「Googleはどちらを採用するのか」を突き止めようとする姿勢そのものに対して、否定的な見解が示された形です。
この記事はSearch Engine JournalのNewsおよびTechnical SEOカテゴリで公開されたもので、著者はSEJ STAFFのMatt G. Southern氏です。
詳細①:Blueskyでのやりとりと、Mueller氏の3つの発言
記事によれば、このコメントはBlueskyのスレッドの中で出たものです。Sebastián Galanternik氏が、ページ上では商品が在庫切れ(out of stock)と表示されているにもかかわらず、サーバーが返すHTMLと構造化データでは在庫あり(available)となっているリスティングを指摘し、両者が食い違う場合に無料リスティング(free listings)は在庫状況をどう扱うのかを尋ねました。
これに対するMueller氏の最初の返信は、答えそのものではなく矛盾の存在を指摘するものでした。原文では「I’d recommend not providing clashing meta data – it makes it hard to work out what’s relevant.(食い違うメタデータを提供しないことをお勧めします。何が適切なのかを判断しづらくなります)」と述べています。
Galanternik氏はさらに、フィードとページ上の構造化データが在庫状況について食い違う場合、Googleはどちらを正しいものとして扱うのかと重ねて質問しました。Mueller氏の回答は次のとおりです。「There’s no publicly defined order of precedence for metadata reconciliation here – if you’re giving conflicting metadata, you should fix it, not analyze if it’ll work regardless.(ここでのメタデータの調整について、公に定義された優先順位は存在しません。矛盾したメタデータを与えているのであれば、それでも機能するかどうかを分析するのではなく、修正すべきです)」
「order of precedence(優先順位)」が公に定義されていない、という表現がこの発言の核心です。どの情報源が勝つかというルールをGoogleは公開していない以上、外部から検証して当てにいく行為には根拠がない、というのがMueller氏の立場だと読み取れます。
詳細②:日付でも同じ問題が起きる――表示日付・dateModified・lastmod
記事によると、Mueller氏はさらに、ページ上の日付(dates on a page)が同じ問題のよくある一例だと付け加えました。この発言を受けて、ページに表示されている日付、構造化データのdateModified(更新日時)の値、そしてXMLサイトマップのlastmod(最終更新日)の値がすべて食い違っている場合についての質問が続きました。
Mueller氏の回答は次のとおりです。「All of these can have different weights & filters, + they’ll change over time. The web is very dynamic, and people are very creative :-). It’s just to say that understanding & interpreting metadata is hard, so the easier you can make it to pick the right value, the more likely it’ll work.(これらはすべて異なる重み付けやフィルタを持ち得ますし、時間の経過とともに変化もします。ウェブは非常に動的で、人々は非常に創造的です。要するに、メタデータを理解し解釈することは難しいので、正しい値を選びやすくしてあげるほど、うまく機能する可能性が高くなるということです)」
記事はこの回答について、在庫状況ではなく日付の値に関するものだった、と明示しています。裏を返せば、在庫についても日付についても、Googleが個別の情報源にどのような重み付けをしているかは外部からは分からず、しかもその扱いは時間とともに変わり得るということになります。「正しい値を選びやすくしてあげるほど、うまく機能する可能性が高くなる」という一節は、サイト側にできる対策が「シグナルを一本化して分かりやすくすること」に尽きることを端的に示しています。
背景:在庫情報は3つの経路でずれる
記事の「Why This Matters(なぜこれが重要なのか)」の項では、在庫状況が同期からずれやすい理由が説明されています。サイトはページの初期HTMLである値を返し、JavaScriptの実行後には別の値をレンダリングし、さらにMerchant Center(マーチャントセンター)のフィード経由で3つ目の値を送ることができてしまうためです。そしてGoogleはそのうちどれを使うかを公表していないため、どれが勝つかを推測するよりも、3つを揃えるほうが確実だとしています。
記事はまた、この食い違いが販売者側にどのような影響を及ぼすかについても過去に取り上げているとし、サイト・フィード・スキーマ(構造化データ)の間で価格が食い違うことがMerchant Centerでの不承認(disapprovals)を招いてきたと述べています。在庫だけでなく価格でも同種の事故が現実に起きている、という指摘です。
なお記事内では、商品フィードをSEO資産として捉える解説記事や、XMLサイトマップの日付を更新してもSEOには役立たないというMueller氏の過去の発言を扱った記事へのリンクも張られています。日付やフィードの扱いが以前から繰り返し論点になってきたことがうかがえます。
実務への影響:SEO・PPC・GEO運用のどこに効くか
記事の「Looking Ahead(今後に向けて)」の項では、具体的な確認手順が示されています。商品の在庫状況について矛盾したシグナルを送っていないかを確認するには、HTMLで見える値、レンダリング後のDOM(rendered DOM。JavaScriptの実行が終わった後のページ構造)で見える値、そしてフィードで送っている値を突き合わせる、というものです。そして、これらがすべて一致していない場合は、Googleがどの値に落ち着くかをテストするのではなく、矛盾そのものを修正すべきだとしています。
SEO側の作業に落とすと、確認すべきは「同じ商品ページについて、初期HTML・レンダリング後・フィードの3系統が同じ在庫状況を返しているか」という一点です。特に、在庫表示をJavaScriptで後から書き換えている構成や、在庫管理システムとフィード生成のタイミングがずれている構成では、3つのうちどれか1つだけが古い値のまま取り残されやすくなります。
PPC(運用型広告)の側では、記事が触れているとおり、価格の食い違いがMerchant Centerの不承認につながった事例があります。ショッピング関連の運用では、サイト表示・構造化データ・フィードの三者が一致していないこと自体が配信停止のリスクとして跳ね返るため、SEO担当と広告担当が別々にデータを持っている体制では特に注意が必要です。なお、AI検索(GEO)への影響について今回の記事は言及していないため、この点は次の「所感」で編集部の見解として述べます。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。今回のMueller氏の発言でもっとも実務的な意味を持つのは、「優先順位を検証しようとするな」という部分だと考えています。テクニカルSEOの現場では、シグナルが食い違ったときに「どちらが優先されるのか」を実験で突き止めようとする発想が根強くあります。しかしGoogleが優先順位を公開しておらず、しかもMueller氏自身が「重み付けやフィルタは時間とともに変わり得る」と述べている以上、ある時点の検証結果が翌月も成立する保証はありません。検証に費やす工数を、矛盾の解消そのものに振り向けたほうが合理的だという指摘は妥当だと感じます。
日本市場の事情に引き付けると、この問題はインハウス担当と代理店の分業体制で起きやすい構造を持っています。サイト本体のHTMLはインハウスの開発チーム、構造化データはSEO代理店のプラグインや実装、商品フィードは広告代理店のフィード管理ツールというように、3つの経路の担当者がそれぞれ異なるケースは珍しくありません。各担当者は自分の担当範囲では正しい値を出しているつもりでも、3つを並べて突き合わせる工程が誰の担当でもないために矛盾が放置される、という状況が生まれます。定例のチェックリストに「初期HTML・レンダリング後・フィードの突き合わせ」を1行足しておくだけでも、事故の芽はかなり潰せるはずです。
なお、今回の記事が扱っているのは在庫状況と日付の食い違いであり、canonical(正規URL)とサイトマップの不一致、metaタグとX-Robots-Tagヘッダーの矛盾、hreflangの相互参照ミスといった他の矛盾パターンには言及していません。ただし「矛盾を残したまま優先順位を当てにいくのではなく、矛盾を解消する」という原則自体は、これらの領域にもそのまま適用できる考え方だと編集部は捉えています。AI検索の文脈でも、構造化データとページ表示が食い違っていれば、どちらが引用されるかを制御できない状態になります。人間の検索ユーザーに対しても生成AIに対しても、シグナルを一本化しておくことが最も確実な対策になるでしょう。
まとめ
・GoogleのJohn Mueller氏が、商品の在庫状況などメタデータが食い違ったときに、どの情報源が優先されるかをGoogleは公表していないと明言したとSearch Engine Journalが報じた
・発言はBlueskyのスレッドで、Sebastián Galanternik氏が「ページ上は在庫切れ、サーバーHTMLと構造化データは在庫あり」というリスティングを指摘したことをきっかけに出たもの
・Mueller氏は「メタデータの調整について公に定義された優先順位は存在しない。矛盾したメタデータを与えているなら、それでも機能するかを分析するのではなく修正すべきだ」と回答した
・ページ上の表示日付・構造化データのdateModified・サイトマップのlastmodが食い違うケースについては、それぞれ異なる重み付けやフィルタを持ち得て時間とともに変化するとし、正しい値を選びやすくするほど機能しやすいと説明した
・記事は確認手順として、HTMLで見える値・レンダリング後のDOMで見える値・フィードで送っている値の3つを突き合わせ、一致していなければ矛盾そのものを修正するよう勧めている
よくある質問
Q1: メタデータが矛盾したとき、Googleはどの情報源を優先するのですか?
GoogleのJohn Mueller氏によれば、メタデータの調整に関して公に定義された優先順位は存在しません。原文の発言は「There’s no publicly defined order of precedence for metadata reconciliation here」というもので、どの情報源が優先されるかというルールをGoogleは公開していないという趣旨です。そのうえで同氏は、矛盾したメタデータを与えているのであれば、それでも機能するかどうかを分析するのではなく修正すべきだと述べています。
Q2: 今回の発言はどのような質問をきっかけに出たものですか?
Blueskyのスレッドで、Sebastián Galanternik氏が、ページ上では商品が在庫切れと表示されている一方、サーバーが返すHTMLと構造化データでは在庫ありとなっているリスティングを指摘し、両者が食い違う場合に無料リスティングは在庫状況をどう扱うのかを尋ねたことがきっかけです。Mueller氏は最初の返信で「食い違うメタデータを提供しないことをお勧めします。何が適切なのかを判断しづらくなります」と述べ、続けて優先順位が公開されていないと回答しました。
Q3: 自社サイトで矛盾が起きていないか確認するには何を見ればよいですか?
記事は、商品の在庫状況について矛盾したシグナルを送っていないかを確認する方法として、HTMLで見える値、レンダリング後のDOMで見える値、そしてフィードで送っている値の3つを突き合わせることを挙げています。これらがすべて一致していない場合は、Googleがどの値に落ち着くかをテストするのではなく、矛盾そのものを修正するよう勧めています。記事によれば、サイト・フィード・スキーマの間で価格が食い違ったことがMerchant Centerでの不承認を招いた事例もあります。
出典:Google’s Mueller: Fix Conflicting Metadata, Don’t Test It(Search Engine Journal、Matt G. Southern氏、2026年7月29日)https://www.searchenginejournal.com/googles-mueller-fix-conflicting-metadata-dont-test-it/584055/
