Merchant Centerの「価格の不一致」で不承認になる原因と直し方｜構造化データ・税込表示・セール価格・自動商品更新の切り分け手順

この記事のポイント

• Merchant Centerの価格の不一致は、フィードの価格とGooglebotがページから読んだ価格が違うときに起きる不承認である。
• 原因は「フィード・構造化データ・ページ表示・更新タイミング」の4層のどれかで、3点を並べて比べれば5分で絞れる。
• 日本では税込と税抜の取り違え、アプリによるJSON-LDの重複、セール期間のタイムゾーンのずれが原因になりやすい。
• 2026年9月の改訂後は、1日に何度も値段を変える商品で自動商品更新を安全装置として頼れない。
• 直したら「ウェブサイトの検証」をリクエストし、約12時間待って、残る商品の原因を層ごとにつぶすのが定石である。

「価格が一致しません」の不承認が、ある日いきなり増える。フィードは触っていないのに、注意が必要タブの件数だけが伸びている。Googleショッピング広告やP-MAXの運用者なら、一度は見たことのある場面だと思います。

先に結論の方向を言います。Merchant Centerの価格の不一致は、たいていフィードの値そのものより、サイト側の「Googlebotが何の価格を読んだか」に原因があります。フィードを何度見直しても直らないのは、そのためです。

この記事では、症状から原因の層をたどる切り分けと、日本のECで多い4つのパターンの直し方、そして2026年秋のヘルプ改訂を踏まえた自動商品更新の扱いを順に整理します。Merchant Center 価格の不一致の原因と対処を、当日中に動ける粒度でまとめました。

Merchant Centerの「価格の不一致」とは？不承認になる仕組み

Merchant Centerの価格の不一致とは、フィードに登録した価格と、Googlebotが商品ページから読み取った価格が一致しないために商品が不承認になる状態です。フィードの値が正しいかどうかではなく、ページ側の価格との照合で判定される点がまず押さえどころになります。

Googlebotはどこから価格を読むのか

Googlebotはまず、ページに埋め込まれた構造化データ（schema.org Offerなど）の価格を参照し、読み取れない場合にページ上で目立つ価格表示を参照する、という順で価格を判断します。つまり、見た目の価格が正しくてもJSON-LDの価格が違えば、そちらが優先されて不一致になりえます。逆に構造化データが無いサイトでは、ページ上で最も目立つ数字が拾われます。「取り消し線の元値」が大きく出ているデザインだと、そちらを現在価格と読み違える事故が起きるわけです。

価格の不一致と不実表示（アカウント停止）の違い

価格の不一致は商品単位の不承認で、不実表示（Misrepresentation）はアカウント全体の停止につながるポリシー違反です。前者は修正して再クロールされれば戻りますが、不一致が大量に長く残ると、ユーザーを誤認させていると見なされるリスクが高まります。すでに停止になっている場合は、不実表示でアカウント停止になったときの審査請求手順を先に確認してください。

まず何を確認する？5分でできる原因の切り分け

図1: 価格不一致を生む4つの層

原因の層は、フィードの値・JSON-LDのOffer・ページで目立つ価格の3点を並べて比べると、5分ほどで決められます。3つのうち1つだけ違うものが原因の層です。

注意が必要タブで対象商品と検知された価格を確かめる

Merchant Centerの「商品」から「注意が必要」タブを開き、「価格の不一致」を選んで対象商品を絞ります。商品ごとの詳細に、フィードの価格と、Googleが検知したページ側の価格が並んで出ます。ここで差額を見てください。ちょうど10%（または8%）分の差なら税込・税抜の問題、元値や別バリアントの価格なら構造化データか表示の問題、と当たりがつきます。

ページのソースでOfferのpriceとpriceCurrencyを確かめる

次に、対象URLのソースを開き、"@type": "Offer" を検索します。確認するのは、Offerが何個あるか、price が数値だけで書かれているか、priceCurrency が JPY になっているかの3つです。リッチリザルトテストでも見られますが、ShoppingFeederのヘルプでは、テストの結果に加えてソース内のOffer数を数えて確かめるよう勧められています。ツールでは1つに見えても、アプリが後から別のJSON-LDを差し込んでいるケースがあるためです。

症状別の早見表（一部の商品だけ／全商品／セール中だけ）

症状	疑う層	最初に見る場所
全商品で一律に数%ずれる	フィード（税込・税抜）	フィードのprice、カートの税設定
特定のテーマ・ページ種別だけ	構造化データ	ソース内のOffer数、アプリ追加の時期
バリエーション商品だけ	構造化データ（バリアント）	選択前に出るJSON-LDのprice
セール中・セール直後だけ	更新タイミング／表示	sale_price_effective_date、取り消し線
値段をよく変える商品だけ	更新タイミング	フィードの更新頻度、自動商品更新

税込と税抜のズレで不一致になるときの直し方

税込と税抜、どっちが出てる？

差額が消費税分きっかりなら、フィードのpriceとページ表示の税込・税抜が揃っていないのが原因で、フィード側を税込に揃えれば直ります。日本で最初に疑うべき原因です。

フィードのpriceは税込が前提

日本向けのフィードは税込価格で登録するのが前提です。日本では税込表示が義務で税率も国内で一本のため、海外記事のように国別に別商品として登録する必要はありません。英国のTillisonは、国ごとにVATが違う場合に国別の商品登録を勧めていますが、日本の運用者が同じ対処を持ち込むと遠回りになります。日本で見るべきは、税込と税抜の取り違えに絞られます。

税抜のフィードしか出せない基幹システムなら、補助フィードやフィードルールで税込に上書きする手があります。設定場所はMerchant Center Nextで補助フィード・フィードルールを探す方法で整理しています。

Shopifyなどカート側の税設定とGoogleアプリの連携を確かめる

Shopifyでは、ストアの税設定で「価格に税を含める」がオンになっているかを先に確認します。ここが税抜表示のままだと、Google & YouTubeアプリが税抜の値をフィードに流し、ページ側だけ税込で出る、といった食い違いが起きえます。確認の順番は、(1) 管理画面の税設定、(2) 商品ページの表示、(3) Merchant Centerに届いたpriceの3点です。一部のカートでは、表示用の税込価格と内部の税抜価格を別項目で持っているので、フィード出力に使う項目がどちらかも見ておく必要があります。

構造化データが原因のときはどう直す？

差額が税率と関係なく、しかもフィードが正しいなら、JSON-LDの重複・バリアント価格・取り消し線価格のどれかが原因です。ここは公式ヘルプよりも、実務での切り分けが物を言う領域です。

レビューアプリやテーマによるOfferの重複

JSON-LDとは、ページに埋め込むJSON形式の構造化データのことです。テーマが出すProductのJSON-LDに加えて、レビューアプリや値引きアプリが別のProduct/Offerを出していると、Offerが複数存在します。ShoppingFeederのヘルプでも、この重複でGooglebotが別の価格を拾う例が挙げられています。Shopify、futureshop、makeshopなどで「アプリを足した直後から出始めた」なら、真っ先に疑ってください。直し方は、不要な側のマークアップを出力しない設定にするか、アプリの構造化データ機能をオフにして、1商品1Offerに戻すことです。

バリエーション商品で最初の価格が出る問題

バリエーション商品では、ページ読み込み時のJSON-LDが先頭バリアントの価格だけを出し、選択後も更新されないことがあります。フィードには選択中のバリアントの価格が入っているため、Googlebotから見ると食い違います。バリアントごとにURLを分け、そのURLのJSON-LDにそのバリアントの価格を出すのが確実な直し方です。

priceTypeで取り消し線価格を明示する

Search Engine Journalによれば、商品の構造化データでpriceType（strikethrough）を使い、元の価格が取り消し線価格だと明示できるようになりました。Googlebotが元値を現在価格と読み違える事故を、見た目を変えずにマークアップ側で防げます。日本のセール運用では二重価格表示が多いので、取り消し線価格がある商品はこの指定を優先して検討してよいと思います。

セール価格で不一致になるのはなぜ？

セールで不一致が出る主因は、sale_priceの有効期間とサイト側の価格切り替え時刻がずれることです。通常価格のときは出ないのに、セール開始・終了の前後だけ不承認が増えるなら、ここを疑います。

sale_price_effective_dateとタイムゾーンの書き方

sale_price_effective_dateは、sale_priceを有効にする期間を指定する属性です。開始と終了をISO 8601形式で書き、タイムゾーンまで明示します。日本時間なら末尾に +09:00 を付けます。

2026-11-11T00:00+09:00/2026-11-12T23:59+09:00

タイムゾーンを省くと、解釈が時差の分だけずれ、サイトの切り替えより早く（遅く）セール価格が適用されます。Relevant Audienceが取り上げた改訂後のヘルプでも、セール期間はタイムゾーンまで正しく設定する必要があるとされています。

ページで目立つ価格とsale_priceを揃える

期間が合っていても、ページで目立つ価格がsale_priceと違えば不一致になります。たとえば、通常価格が大きな文字で、セール価格が小さく添えられている場合です。セール価格を最も目立たせ、通常価格は取り消し線で小さく出す。この見せ方に加えて、JSON-LDのpriceも現在の販売価格にしておきます。

自動商品更新で価格が勝手に変わるのはなぜ？オンのままでいいかの判断

図2: 自動商品更新の判断ツリー

商品アイテムの自動更新（自動化）は、Googlebotが検知したページ上の価格や在庫でフィードの値を書き換える機能で、設定次第で「勝手に価格が変わる」ように見えます。2026年の改訂以降は、残すか止めるかを商品の性質で決める必要があります。

自動更新が価格を書き換える条件

自動更新は、フィードとページの価格が食い違い、ページ側が信頼できると判断されたときに、フィードの値を補正する仕組みです。不一致による不承認を減らす安全網として働く一方、ページ側の価格が誤っていれば、誤った価格がフィードに入ります。管理画面で「フィードの価格を変えていないのに変わった」と見えるのは、たいていこの動きです。

1日に何度も値段を変える商品は不承認になりうる（2026年9月の改訂）

Search Engine Roundtableの報道では、2026年9〜10月の改訂でヘルプに注意書きが加わりました。価格や在庫が1日に1回を超えて変わる商品では自動更新が働かず、更新されないまま不承認になることがある、という内容です。タイムセールやダイナミックプライシングを使う国内ECでは、「自動更新があるから大丈夫」という前提がもう成り立ちません。Relevant Audienceによると、改訂後のヘルプは、値段をよく変える商品ではContent APIではなくMerchant APIでの更新を勧め、取り消し線価格が複数ある商品ページでは価格の自動更新を有効にしないよう案内しています。

オンのまま・オフ・Merchant APIへ移行の判断表

商品の状態	判断	理由
価格変更が1日1回以下で、ページが安定	オンのまま	取りこぼしを補正できる
取り消し線価格が複数ある	オフ	元値を現在価格と読み違える恐れ
1日に何度も価格が変わる	Merchant APIへ移行	自動更新が働かず不承認になりうる
ページ価格が誤りになりやすい運用	オフ	誤った価格がフィードに入る

直した後の再審査はどう進める？

修正後は検証リクエストして待つ

修正後は、Merchant Centerで「ウェブサイトの検証をリクエスト」し、約12時間待つのが基本の流れです。異議申し立ては不承認の判断自体に納得できないときの手段で、価格を直しただけの場合は検証リクエストを使います。

一括修正（CSV）と個別修正

対象が数十件以上なら、フィード側を一括で直します。補助フィードやフィードルールで税込に揃える、CSVを再アップロードする、といった方法です。ページ側の問題（JSON-LD、表示）はサイトの修正になるので、フィードの再送では直りません。数件なら個別に価格を直し、検証をリクエストします。

承認されないときに確かめること

12時間を過ぎても残るなら、次の順で見ます。

1. ソース内のOffer重複が本当に消えているか（キャッシュの影響も含めて）
2. 取り消し線価格が現在価格に読まれていないか
3. バリアントのURLごとにJSON-LDが正しいか
4. sale_price_effective_dateが過去の期間のまま残っていないか

複数の媒体で同じフィードを使っているなら、Metaカタログ広告の商品不承認の診断フローと同じ手順で、Meta側のエラーも同時に見ておくと原因の共通点が見えます。

再発させないための運用ルール

再発防止の要は、価格を変えるタイミングとフィードの更新タイミングを合わせ、アプリやテーマを触った日に必ず点検することです。

フィードの更新頻度と価格を変えるタイミングを合わせる

価格の変更頻度に対して、フィードの更新が遅ければ不一致が出ます。価格を変える時刻をあらかじめ決め、その直後にフィードが更新される運用にします。1日に何度も変える商品は、前節のとおりMerchant APIでの更新を検討します。フィード全体の品質を見直すなら、Merchant Centerのフィード品質診断と商品グループ設計も合わせて読むと運用設計まで広げられます。

大型セール前の点検リスト

11.11や年末商戦の前に、次の点を確認します。

• sale_price_effective_dateにタイムゾーン（+09:00）が入っている
• 取り消し線価格がある商品のpriceType指定と、自動更新の設定
• 直近で追加したアプリ・テーマ変更の後に、Offer数を数えた
• バリエーション商品の代表URLでJSON-LDの価格を見た
• 注意が必要タブの「価格の不一致」が0件か、増加傾向でないか

よくある質問

Q：価格を直したのに不承認が解除されないのはなぜですか？

Googlebotの再クロールに数時間から数日かかるためです。ウェブサイトの検証をリクエストした場合は、約12時間が目安になります。待っても解除されないときは、構造化データのOffer重複や、バリアントの価格が残っていないかを確かめてください。

Q：自動商品更新はオフにしたほうがいいですか？

1日に何度も値段を変える商品や、取り消し線価格が複数ある商品は、オフにするかMerchant APIでの更新を検討します。それ以外の、価格変更が安定している商品はオンのままで問題ありません。

Q：Merchant Centerの価格は税込と税抜どちらで登録しますか？

日本向けは税込で登録します。ページの表示と構造化データの価格も税込に揃えてください。

Q：価格の不一致を放置するとアカウント停止になりますか？

不一致が大量に長く続くと、不実表示と判定されたり、自動更新が止められたりするリスクがあります。早めに原因の層を特定して直すのが安全です。

Q：バリエーションごとに価格が違う商品はどう登録しますか？

バリアントごとに商品IDとURLを分けて登録します。ページ側では、選択中のバリアントの価格を構造化データに出します。

---

真策堂では、Googleショッピング広告やP-MAXのフィード設計・不承認の原因切り分けについて、こうした観点でご相談を受けています。価格の不一致が続いている、複数媒体のフィード運用を整理したいといった場合は、お気軽にお問い合わせください。