Logo
SEO & Pricing

Product Schema and Merchant Center: Keep Product Data Consistent

Editorial illustration for Product Schema and Merchant Center: Keep Product Data Consistent
Published on: 14/08/2026
Modified: 02/08/2026

A product may have the correct price on its landing page, outdated availability in Merchant Center, and a different identifier in structured data. To a customer, this looks like a confusing offer. To Google, it is a conflict between several sources of product information.

The problem is rarely solved by only adding Product Schema or resubmitting the feed. The store needs one reliable source of product data and a clear process through which the page, structured data, and Merchant Center update consistently.

This guide explains how to organize that system, what to verify, and how to prioritize errors without mixing product-page content with the technical product-data layer.

The essentials at a glance

  • Product Schema describes the product and offer in a machine-readable format on the product page.
  • Merchant Center receives product data through a feed, automated extraction, an API, or a combination of sources.
  • The visible product page remains the primary source customers see and use when purchasing.
  • Price, currency, availability, identifiers, images, shipping, and returns should not conflict across these layers.
  • Structured data may provide eligibility for richer search presentations, but it does not guarantee that they will appear.
  • Merchant Center warnings do not have equal importance. An incorrect price or wrong variation is more critical than a missing recommended field.

Product Schema, Merchant Center, and a product feed are not the same thing

These terms are often used interchangeably, but they serve different roles.

Product Schema

Product structured data is a machine-readable description added to a specific product page. It may include information about:

  • product name;
  • images;
  • brand;
  • SKU, GTIN, or MPN;
  • the offer;
  • price and currency;
  • availability;
  • product condition;
  • shipping and returns;
  • ratings and reviews when they are genuine and eligible.

Google recommends merchant-listing markup for pages where a customer can purchase one specific product or variations of the same product. A category page containing many different products is not equivalent to a specific product offer.

Merchant Center

Merchant Center is the system through which a merchant provides and manages product data for different Google surfaces, advertising opportunities, and free shopping listings.

Problems may include:

  • price mismatch;
  • availability mismatch;
  • missing or invalid identifiers;
  • unsuitable images;
  • incorrectly grouped variations;
  • missing shipping terms;
  • policy or destination restrictions.

Product feed

A feed is a structured data source that sends products to Merchant Center. It may be a file, API integration, automated source, or combination of methods.

The feed should not become a second independent database that operates separately from the website. The more disconnected and manually maintained sources exist, the greater the risk that one product will have different values in different systems.

Define one source of truth for product data

The most important architectural decision is not which plugin generates Schema. It is where every value originates and who owns it.

For each critical attribute, you should be able to answer:

  1. Where is the value created?
  2. Where is it stored?
  3. How is it displayed on the product page?
  4. How does it enter Product structured data?
  5. How does it enter Merchant Center?
  6. How often does it change?
  7. Who verifies and corrects errors?

For example, price may come from an ERP or WooCommerce, appear visibly on the page, populate JSON-LD, and be sent to Merchant Center. When the feed also contains a separately maintained manual price field, a mismatch becomes possible.

Map the product-data flow

Visual guide to map the product-data flow

A practical map may look like this:

AttributePrimary sourcePageStructured dataMerchant CenterOwner
PriceProduct catalogVisible offerOffer.pricepriceE-commerce manager
AvailabilityInventory systemStatus and purchase buttonOffer.availabilityavailabilityOperations
SKUProduct catalogVisible when usefulskuid or separate fieldProduct manager
GTINManufacturer dataSpecificationsgtingtinCatalog team
ImageMedia libraryGalleryimageimage_linkContent team
ShippingShipping rulesOffer blockShipping detailsSettings or product attributeOperations
ReturnsPolicy systemVisible policyReturn policyMerchant Center settingsManagement

The table is not documentation for its own sake. It shows where inconsistencies can originate and who should correct them.

What a consistent product offer must describe

An offer is consistent when customers and systems see the same product, variation, and commercial terms.

The primary elements are:

  • accurate product identity;
  • correct URL;
  • exact variation when variations exist;
  • a title describing the same product;
  • valid price and currency;
  • real availability;
  • correct condition, such as new, used, or refurbished;
  • matching images;
  • brand and product identifiers;
  • clear shipping and return terms.

Product-data consistency test

Visual guide to product-data consistency test

Choose one real product and compare these four layers at the same time:

  1. Visible information on the product page.
  2. Product structured data in rendered HTML.
  3. Data received by Merchant Center.
  4. Actual add-to-cart and checkout behavior.

Compare these fields:

  • product name;
  • URL;
  • selected variation;
  • price;
  • currency;
  • availability;
  • SKU;
  • GTIN or MPN;
  • brand;
  • primary image;
  • shipping;
  • returns.

If the page displays a sale price while structured data or the feed contains the old regular price, the system is inconsistent. If the URL opens a blue variation while the image and SKU describe a black variation, the issue is even more serious because the product identity itself changes.

Price and currency

Price is one of the most sensitive attributes. It should be:

  • visible on the landing page;
  • accessible without hidden interactions;
  • identical in structured data;
  • identical in Merchant Center;
  • connected to the correct currency;
  • connected to the selected variation;
  • updated when promotions start and end.

Common causes of mismatch include:

  • a cached page;
  • feed updates running separately from website updates;
  • a sale price that expired in only one system;
  • price excluding tax in one source and including tax in another;
  • different currencies or automatic conversion;
  • a variation selector that changes visible price but not structured data;
  • a JavaScript-generated price missing from rendered output.

During diagnosis, first determine whether the error exists in the primary source, in the page transformation, or in the feed transformation. Do not correct only the final export while the source remains incorrect.

Availability and offer condition

Availability must describe what the customer can actually purchase.

It is not enough for a product page to display "in stock" when:

  • the purchase button does not work;
  • the selected variation is unavailable;
  • the delivery time contradicts the promise;
  • Merchant Center receives out_of_stock;
  • structured data describes another configuration.

Different states should be distinguished:

  • available for immediate purchase;
  • temporarily out of stock;
  • preorder;
  • backorder;
  • discontinued or permanently unavailable.

The long-term URL decision for a discontinued product belongs to the separate owner for out-of-stock and discontinued products. The focus here is ensuring that data accurately describes the current state.

Brand, GTIN, MPN, and SKU

Visual guide to brand, GTIN, MPN, and SKU

Identifiers help the same product be recognized consistently across systems.

Brand

The brand should be the actual product brand, not the store name, unless the store is genuinely the manufacturer or brand owner.

GTIN

Use a GTIN only when it has been validly assigned by the manufacturer. Do not invent values to fill the field.

MPN

The MPN is the manufacturer's part number. It may be important when no GTIN exists or when product identity requires the manufacturer number.

SKU

The SKU is the merchant's internal identifier. It should remain stable and correspond to the correct product or variation.

Variations and item-group relationships

For products with variations, the data must distinguish:

  • the primary product family;
  • the exact variation;
  • a stable variation identifier;
  • the common variation group;
  • size, color, material, or configuration;
  • the URL of the selected variation;
  • price and availability for that same variation.

The decision about whether variations use one URL or separate URLs belongs to the product variations and SEO owner. The product-data layer must execute that decision consistently.

A critical defect occurs when one URL sends:

  • an image for one color;
  • an SKU for another color;
  • a price for a third size;
  • availability for the parent product rather than the selected variation.

Images are product data, not only design

The primary image should represent the same product and variation sold on the landing page.

Check whether:

  • the image is accessible to Google;
  • its URL is stable;
  • it is not a placeholder or broken file;
  • the primary image matches the selected variation;
  • it does not contain misleading elements;
  • quality and dimensions are sufficient;
  • the feed does not point to an outdated image version.

In April 2026, Google announced a future increase in the minimum Merchant Center image resolution to 500 × 500 pixels, with warnings during 2026 and enforcement from January 31, 2027. This does not mean 500 × 500 pixels is an ideal creative standard. The practical lesson is not to build a catalog around small images that are difficult to replace.

Shipping and returns

Shipping and return information may exist across several layers:

  • visible information on the product page;
  • site-wide policy pages;
  • Product or Offer structured data;
  • Merchant Center account settings;
  • product-level shipping attributes.

These layers should agree.

A problem exists when the page promises free delivery while Merchant Center receives a paid shipping charge, or when handling and delivery times do not match real operations.

In 2026, Google added new product-level shipping capabilities, including handling cutoff time and minimum order value. They should represent real business rules rather than create promises the store cannot fulfill.

Structured data and feeds can complement each other, but they must not conflict

Structured data helps Google understand the information on the landing page. The feed provides organized product data to Merchant Center.

They should not be treated as competing methods. In a well-organized store, they use the same source data and provide opportunities to verify each other.

When a conflict appears, investigate causes such as:

  • outdated feed data;
  • cached page output;
  • incorrect transformation logic;
  • variation mismatch;
  • different product IDs;
  • a manual correction applied in only one system;
  • different shipping or tax configuration.

Product Schema does not guarantee a rich result

Valid markup means a page may be eligible for selected search presentations. It does not require Google to display them.

Do not evaluate success only by whether one query produces a rich result. Track:

  • structured-data validity;
  • coverage;
  • Merchant Center approval;
  • data accuracy;
  • impressions and clicks;
  • product-level performance;
  • frequency of mismatch errors.

Common Merchant Center issues and how to prioritize them

1. Incorrect price or availability

This is a critical issue because it affects the offer itself. Check the source of truth, cache, variation selection, and feed refresh.

2. Incorrect product or variation

Check the URL, title, image, SKU, GTIN, item group, and selected state. This is an identity problem, not merely a missing field.

3. Invalid identifiers

Do not replace a missing GTIN with an invented value. Verify manufacturer data and the rules for the specific product category.

4. Unsuitable images

Check accessibility, quality, product correspondence, and whether the image URL has changed or is blocked.

5. Missing shipping or return data

Verify whether the information is configured at the correct account or product level and whether it agrees with the website.

6. Recommended fields

Recommended fields can improve completeness, but they should not displace critical issues involving product identity, price, and availability.

Error-priority matrix

PriorityProblemReason
CriticalIncorrect price, currency, or availabilityThe customer sees a different offer
CriticalIncorrect product or variationProduct identity is broken
HighInvalid identifiers or destination disapprovalThe product may be restricted
HighBroken or mismatched imageThe presentation is misleading
MediumMissing shipping or return detailsThe offer is incomplete
LowRecommended field with no direct impactOptimize after critical issues

Practical implementation workflow

Step 1: Map data sources

Document where every critical field originates and who owns it.

Step 2: Select representative products

Test at least:

  • a simple product;
  • a product with variations;
  • a product on sale;
  • a temporarily unavailable product;
  • a product with special shipping or other terms.

Step 3: Compare the four layers

  • visible page;
  • rendered structured data;
  • Merchant Center data;
  • cart and checkout behavior.

Step 4: Correct the source, not only the export

When an error originates in the product catalog or ERP, the correction should begin there.

Step 5: Validate

Use:

  • Rich Results Test;
  • URL Inspection;
  • Merchant Center's Needs attention section;
  • direct review of the landing page;
  • a test purchase or add-to-cart action;
  • comparison of the exact product ID.

Step 6: Monitor changes

Price, availability, and promotions change frequently. They require automated or periodic monitoring rather than a one-time review.

What to measure

Useful indicators include:

  • percentage of approved products;
  • number and share of disapproved products;
  • price-mismatch rate;
  • availability-mismatch rate;
  • products without valid identifiers;
  • structured-data errors and warnings;
  • products with variation inconsistencies;
  • time required to correct a critical error;
  • impressions, clicks, and commercial outcomes by product.

Do not confuse correlation with causation. More valid fields do not automatically guarantee more sales. The objective is for Google and customers to receive an accurate, complete, and consistent offer.

Practical checklist for Product Schema and Merchant Center

Visual guide to practical checklist for Product Schema and Merchant Center

Source of truth

  • [ ] Every critical attribute has one primary source.
  • [ ] A data owner is assigned.
  • [ ] Independent manual prices or availability values are not maintained in several systems.

Product identity

  • [ ] URL, title, image, and identifiers describe the same product.
  • [ ] Variations have stable IDs.
  • [ ] Brand, GTIN, MPN, and SKU are not invented or exchanged.

Offer

  • [ ] Price and currency match.
  • [ ] Availability matches the real purchase state.
  • [ ] Promotion periods are synchronized.
  • [ ] Shipping and returns do not conflict.

Technical validation

  • [ ] Structured data is valid in rendered output.
  • [ ] Merchant Center has no critical mismatch errors.
  • [ ] Primary images are accessible and current.
  • [ ] Feed-refresh and cache behavior have been verified.

Monitoring

  • [ ] Critical errors trigger an alert or recurring review.
  • [ ] A correction and revalidation process exists.
  • [ ] Changes are tested on real products and variations.

When professional help is needed

Professional work is justified when:

  • thousands of products use different data sources;
  • Merchant Center repeatedly reports price or availability mismatches;
  • variations are mixed across URLs, images, SKUs, and feeds;
  • structured data is generated by a separate plugin with no connection to the primary catalog;
  • ERP, WooCommerce, feeds, and Merchant Center update on different schedules;
  • warnings are corrected manually but return after the next synchronization.

As part of comprehensive e-commerce SEO, product data should be evaluated together with store structure, category pages, product pages, and technical maintenance. When a new store is being developed, this foundation should be included in e-commerce website design rather than added after the catalog already contains thousands of inconsistent records.

Frequently asked questions

Are Product Schema and Merchant Center the same thing?

No. Product Schema is structured data on the product page. Merchant Center is a platform for providing and managing product data. They should use consistent information, but they serve different functions.

Is a product feed mandatory?

The specific method depends on the Merchant Center setup and the size of the store. A large and dynamic catalog needs a reliable automated source that updates consistently.

Does Product Schema guarantee rich results?

No. Valid markup provides eligibility, but Google decides whether and how to display a richer presentation.

Which matters more, structured data or the feed?

What matters most is that the visible page, structured data, and Merchant Center describe the same offer. The decision should not be framed as one method versus the other.

What should I correct first in Merchant Center?

Correct price, availability, and product identity first. Then address identifiers, policy or destination disapprovals, images, and missing supplementary data.

Should category pages use Product Schema?

Merchant-listing guidance is intended for pages representing one specific product or variations of the same product, not broad categories containing different products.

Building a reliable product-data system

Product Schema and Merchant Center are not separate SEO checkboxes. They are parts of one product-data system.

A sustainable approach begins with one source of truth, clear ownership of attributes, and consistency between the page, structured data, feed, and actual purchase process. When those layers describe the same product, variation, and offer, diagnosis becomes faster, the risk of disapprovals is lower, and customers receive more reliable information.

Гласувай
crosschevron-down