まず同じ商品バリエーションを固定し、商品データ、米国ページに表示される価格、構造化データの順で照合してください。今週は、問題画面と対象URLを保存し、データとページが一致するまで地域やCookieの調査を後回しにするのが安全です。

この記事は、Google Merchant Centerで価格不一致や商品拒否が表示された米国向けEC事業者向けです。Shopifyなどの独立型サイトを運営する担当者、開発者やGoogleサポートへ再現情報を渡す責任者にも役立ちます。

01

診断情報の固定

価格不一致は、現在ブラウザーで見える価格だけを確認しても解決しません。管理画面に表示された問題名、対象商品、検出時刻、例として示されたURLを保存し、価格そのものか、セール価格、通貨、地域別価格のどれが問題なのかを切り分けます。

商品バリエーションが複数ある場合は、色やサイズなどの選択状態を先に記録します。商品データのURLと、購入ボタン付近に表示されるページのURLが別バリエーションを指していれば、価格が正しくても不一致と判定される原因になります。

商品データとサイトの価格が同じなのにエラーになる場合、最初に確認することは何ですか。

管理画面の表示価格ではなく、同じバリエーションの price、通貨、セール価格の適用条件、商品リンクを並べてください。さらに、検出時刻とサイトの更新時刻を比較します。更新直後であれば、古いデータが残っていた可能性もあるため、修正前後の時刻を残しておくことが重要です。

Googleが説明する地域別の価格や可用性の確認方法は、地域別の価格問題に関する公式案内で確認できます。管理画面のメニュー名や問題名は変更されるため、古い解説記事の手順をそのまま使わないでください。

02

商品データの一致指標

商品データ源では、次の項目を同じ商品バリエーションについて確認します。

  • 通常価格。ページの通常価格と同じ数値か。
  • セール価格。割引表示があるとき、sale_price の値と適用条件が一致しているか。
  • セール期間。sale_price_effective_date が設定されている場合、サイト側のキャンペーン期間と矛盾していないか。
  • 通貨。米国向けページが米ドル表示なら、送信データの通貨も対応しているか。
  • 商品リンク。既定のバリエーションや地域設定が異なるURLになっていないか。

price、sale_price、sale_price_effective_date の定義は、sale_priceの公式仕様に合わせて確認します。フィードの更新に任せて、サイトの改定だけを先に行う運用は避けてください。

価格を変更した担当者は、変更前のデータ、変更後のデータ、サイト反映時刻を1行ずつ記録します。正しい値に直したつもりでも、バリエーションテンプレートや別のデータソースが古い価格を上書きすることがあります。

03

米国ページの表示指標

米国ユーザーが見る商品ページを確認するときは、初回表示で最も目立つ価格、既定で選択されたバリエーション、購入ボタンの近くにある価格を見ます。画面下部だけに正しい価格があっても、冒頭に別の価格や価格帯が表示されていれば、機械的な確認結果と一致しない場合があります。

ログアウト状態、Cookieを削除した状態、対象バリエーションを直接指定した状態を分けて保存してください。会員価格、割引コード入力後の価格、地域選択ポップアップ、遅延読み込みによる価格変更も確認対象です。

商品データ源と米国の落地ページでは、どの位置を照合すべきですか。

商品データの価格と通貨を、ページ初回表示の価格、既定バリエーション、購入ボタン付近の価格と照合します。チェックアウトだけで表示される送料や税金は、商品価格と混同しないよう別欄に記録してください。Googleの落地ページ要件は、公式のランディングページ要件を基準にします。

地域別価格が原因と思われるときは、価格を一律に合わせればよいですか。

先に、地域設定がどの段階で価格を変更しているかを確認します。IP、Cookie、ブラウザー言語、配送先などの条件によって、審査時と消費者向けに異なる価格を見せる方法は使わないでください。地域別価格を設定する場合も、送信データ、ページ表示、構造化データの関係をGoogleの地域別価格設定の説明に沿って確認します。

04

構造化データと取得可能性

画面上の価格を修正しても、HTML内の構造化データが古いままだと不一致が続きます。商品ページのソースまたは生成結果で、次のプロパティを確認してください。

  • offers.price
  • offers.priceCurrency
  • offers.availability

商品バリエーションを構造化データで表現している場合は、選択可能なバリエーションと価格の組み合わせも確認します。仕様上の書き方は、Productバリエーションの公式ドキュメントと、Merchant Listingsの価格仕様を参照してください。

次に、リダイレクト、ログイン必須画面、地域ポップアップ、JavaScript実行後にだけ表示される価格を確認します。Googleが対象URLを取得できても、正しいバリエーションや価格を読み取れているとは限りません。

構造化データの確認には、Rich Results Testを使います。結果画面のスクリーンショットだけでなく、検査したURL、検査時刻、検出された価格と通貨も記録してください。属性の扱いは、Merchant Centerの構造化データ属性資料でも照合できます。

05

変数管理と復核資料

米国の購入者が見るページを確認したい場合でも、いきなりIPだけを変えないでください。アクセス地域、ブラウザー言語、Cookie、ログイン状態、配送地域、商品バリエーションを一覧化し、毎回ひとつだけ変更します。

米国ノードのMacは、同じブラウザー状態を保った再確認や、担当者間の作業引き継ぎに向いています。たとえば、米国向けMac環境の案内を確認し、固定すべき条件を先に決めておくと、担当者の自宅回線だけに依存しにくくなります。ただし、これは復現用の環境です。審査システムと消費者に異なる価格を見せる手段ではなく、拒否解除や承認を保証するものでもありません。

Shopifyの地域設定を使っている場合は、価格だけでなく配送先、通貨、チェックアウトまで一緒に確認します。サイトの表示条件を整理したいときは、VpsMeshのMac環境に関する案内も、チームでの確認環境を選ぶ材料になります。

注意：米国ページだけを正しく見せ、審査時には別の価格を返す設計は、価格不一致の解決ではありません。ページ、データ、構造化データを同じ内容に直してください。

修正後は、例として表示された商品だけでなく、同じテンプレートを使う商品も確認します。復核に進む前に、次の資料をひとつのフォルダーへまとめます。

  • 商品リンクと対象バリエーション
  • 検出時刻と再確認時刻
  • 修正前後の商品データ
  • 未ログイン状態のページ画像
  • 構造化データの検査結果
  • 地域、Cookie、配送先などの確認条件
  • 担当者、変更内容、反映確認の記録

Googleの問題処理の考え方は、Merchant Centerの問題対応に関する公式説明に従います。データがまだ一致していないなら、復核の反復ではなく修正を続けてください。管理画面の意味や復核入口が判断できない場合は、資料を添えてGoogleの公式サポートへ確認します。

06

選択条件の比較

確認方法 固定する条件 分かること 次の判断
商品データの照合 価格、セール価格、通貨、商品リンク 送信値の誤りや更新遅延 データを修正
ページ表示の照合 バリエーション、ログイン、配送地域 購入者画面の価格差 テンプレートや地域設定を修正
構造化データの照合 price、priceCurrency、在庫状態 Googleが読み取る値 マークアップを修正
条件を一つずつ変更 IP、Cookie、言語、配送地域 表示差を生む条件 条件の設計を見直す
07

修正後の判定表

判定状態 復核へ進むか 対応
3つの情報源が同じ商品と価格を示す 進む 証拠資料を添えて現在の手順で申請
価格は同じだがバリエーションが異なる 進まない URL、既定選択、フィード対象を修正
Cookieや地域で価格が変わる 進まない 表示条件を整理し、一貫した価格にする
構造化データだけ古い 進まない キャッシュとマークアップを更新して再検査
問題名や復核入口の意味が不明 保留 画面記録を添えて公式サポートへ相談

結局、価格不一致の確認で優先すべきなのは、米国IPを用意することではなく、同一バリエーションの3つの価格情報を一致させることです。現在の回線や共有ブラウザーでは米国ページを安定して再現できない、Cookieや地域条件が担当者ごとに異なる、証拠を毎回取り直す必要がある、といった問題があるなら、米国ノードのMacを復現・記録・協業用にレンタルする方が運用しやすい場合があります。

ただし、長期的に大量の商品を常時処理する場合や、物理的な端末操作が必要な場合は、自社でMacを保有する方が適しています。短期の原因調査、米国ページの確認、担当者間の同一条件の再現が目的なら、VpsMeshのMac環境を候補に入れ、まず固定する変数と保存する証拠を決めてから利用を検討してください。