WooCommerce structured data and Google Merchant Center

WooCommerce structured data mismatch in Google Merchant Center

A WooCommerce product page can display the correct price and stock status to a customer while providing different information to Google through structured product data.

The WooCommerce product record may show one value, the visible landing page another, the page’s Product schema an older value and Google Merchant Center a fourth processed result.

This situation is commonly described as a structured data mismatch.

However, structured data mismatch is not always presented as one clearly named Merchant Center issue. It can contribute to or appear through problems involving:

• Inaccurate price
• Inconsistent price
• Availability mismatch
• Incorrect sale price
• Mismatched currency
• Product identity
• Variation selection
• Automatic product updates
• Information found on the website
• Landing-page inconsistencies
• Product eligibility

A dependable correction must determine which value is stored in WooCommerce, which value is visible to a logged-out customer, which value exists in the original page source, which value is submitted through the active product data source and which value Google processed.

Changing only one of these layers does not guarantee that the inconsistency has been removed.

The objective is not simply to make a structured-data testing tool display a green result.

The objective is to create one consistent product identity and commercial offer across WooCommerce, the public landing page, Product structured data, Merchant API product information and Google Merchant Center.

Google independently crawls, processes and evaluates this information. Valid structured data does not guarantee that a product will be approved, displayed or protected from every data-quality issue.

The short answer

A reliable WooCommerce structured data mismatch workflow consists of the following steps:

1. Open the exact affected product in Merchant Center.
2. Record the Merchant account, offer ID, country and marketing method.
3. Record the submitted and processed product values.
4. Open the exact WooCommerce product or variation.
5. Check the price, sale price, currency, stock and condition.
6. Open the public product page while logged out.
7. Select the exact submitted variation.
8. record the visible customer-facing values.
9. inspect the original HTML returned by the server.
10. Find every Product, ProductGroup and Offer object.
11. Identify duplicate or conflicting structured data.
12. Match the structured offer to the correct SKU or GTIN.
13. Compare price and currency.
14. Compare sale price and sale dates.
15. Compare availability.
16. Compare product condition.
17. Compare variation identity.
18. Identify which theme or plugin generates each Product object.
19. Correct the authoritative WooCommerce or schema source.
20. Remove conflicting duplicate output where appropriate.
21. Clear WordPress, server and CDN caches.
22. Retest the public page.
23. Submit the corrected product through the active data source.
24. Allow Google to process the update.
25. Compare the processed Merchant product again.
26. Monitor the page to ensure that an old source does not restore the mismatch.

Do not disable structured data merely to hide an error.

Correct the product information and the component responsible for generating the inaccurate markup.

Understand what structured product data does

Structured data is machine-readable information placed in the HTML of a web page.

On a WooCommerce product page, it can describe:

• Product name
• Description
• Image
• Brand
• SKU
• GTIN
• MPN
• Product condition
• Price
• Currency
• Availability
• Sale information
• Shipping
• Returns
• Reviews
• Ratings
• Product variations

Google distinguishes between product snippet structured data and merchant listing structured data.

Product snippets can support search results containing information such as price, availability, reviews and ratings. Merchant listing markup is intended for pages where customers can purchase a product and can support additional commercial information.

Google states that providing both Product structured data on the website and product information through Merchant Center can maximize eligibility and help Google understand and verify the data. Some Google experiences can combine information from both sources. Google’s Product structured data introduction explains this relationship.

Structured data is therefore not isolated SEO decoration.

For an ecommerce product page, it can become part of the evidence Google uses to understand what is sold, which price is active, whether the product is available and how the page relates to submitted Merchant information.

Separate the five product-data layers

A structured data investigation becomes easier when the product is divided into five separate layers.

WooCommerce source

This is the information stored in the product and variation records, including:

• Regular price
• Sale price
• Sale dates
• Stock quantity
• Stock status
• Backorder setting
• Tax configuration
• Product type
• SKU
• Attributes
• Variation values
• Product condition stored by an extension
• Currency determined by the store or currency plugin

Customer-facing landing page

This is what a customer sees after opening the submitted product URL.

It includes:

• Displayed price
• Currency symbol
• Sale price
• Selected variation
• Stock message
• Add-to-cart status
• Product name
• Image
• Required product options
• Checkout availability

Structured product data

This is the machine-readable Product, ProductGroup and Offer information in the page’s HTML.

It can be generated by:

• WooCommerce
• The active WordPress theme
• An SEO plugin
• A schema plugin
• A product-feed extension
• A page builder
• A custom code snippet
• A review plugin
• A marketplace extension
• A currency or pricing extension

Submitted Merchant product input

This is the product information sent through the active Merchant data source.

It can originate from:

• Merchant API
• A legacy Content API integration
• An XML or scheduled file
• A platform connection
• A manually entered product
• Another primary source
• A supplemental source

Processed Merchant product

This is the product Google creates after processing product inputs, applying applicable rules and combining primary and supplemental information.

Merchant API separates writable product inputs from read-only processed products. Google’s Merchant API migration guidance explains that ProductInput is used to insert or update source data, while the processed Product resource represents the result after Google applies rules and combines applicable sources.

These five layers can contain different values.

The audit should record each one separately instead of assuming they are identical.

Identify the exact affected offer

Do not begin with the general WooCommerce product page when Merchant Center identifies a specific variation.

Record:

• Merchant Center account
• Product data source
• Merchant offer ID
• WooCommerce product ID
• WooCommerce variation ID
• SKU
• GTIN where applicable
• Product URL
• Target country
• Content language
• Feed label
• Marketing method
• Issue name
• First detected date
• Submitted price
• Processed price
• Submitted currency
• Processed currency
• Submitted availability
• Processed availability
• Submitted condition
• Processed condition

A parent WooCommerce product and one of its variations are not interchangeable.

If the issue applies to a blue, size-medium variation, inspecting the parent product’s default price or the red variation’s structured data can lead to the wrong conclusion.

Check the product page as a customer

Open the product URL in a private browser window while logged out of WordPress.

This avoids administrator-specific behaviour such as:

• Hidden maintenance notices
• Administrator pricing
• Cache bypasses
• Wholesale roles
• Tax exemptions
• Preview content
• Logged-in currency preferences
• Personalised product availability

Confirm that the page:

• Loads without authentication
• Uses HTTPS
• Does not redirect to an unrelated product
• Displays the expected product name
• Selects or represents the submitted variation
• Shows the correct active price
• Shows the correct currency
• Shows the correct availability
• Allows the product to be added to the cart
• Uses the expected product image
• Does not require an unusual interaction before essential information appears

If a variation must be selected manually, determine what the product URL displays before and after that selection.

A Merchant offer for a specific variation should not open a page that initially represents another variation with a different price or availability without a clear way for Google and customers to identify the intended offer.

Inspect the original HTML response

The visible page is only one part of the investigation.

Inspect the original page source returned by the server and search for:

• application/ld+json
• "@type":"Product"
• "@type":"ProductGroup"
• "@type":"Offer"
• "@type":"AggregateOffer"
• "price"
• "priceCurrency"
• "availability"
• "itemCondition"
• "sku"
• "gtin"
• "productGroupID"
• "hasVariant"
• "variesBy"

Google’s Merchant Center documentation says that structured data used for matching should be present in the HTML returned from the web server and should not be generated only with JavaScript after the page has loaded. It also states that the markup must agree with the values shown to customers. Google’s Merchant Center structured data setup guide provides these conditions.

This distinction matters when:

• A variation script changes the visible price after page load.
• A currency selector rewrites the displayed currency.
• A sale countdown changes the price in the browser.
• Stock information is loaded asynchronously.
• A page builder injects Product markup only after interaction.
• The original source contains a default variation while the rendered page shows another one.

Inspect both the original source and the rendered page, but do not assume that a browser-side correction automatically repairs the product information available in the server response.

Find every Product object

A common WooCommerce problem is not missing Product schema but too many Product objects.

For one landing page, the source can contain:

• WooCommerce Product schema
• Theme-generated Product schema
• SEO-plugin Product schema
• Review-plugin Product schema
• Page-builder Product schema
• A manually added JSON-LD object

These objects may describe different values.

For example:

• WooCommerce reports a price of 79.00 EUR.
• The SEO plugin reports 89.00 EUR.
• The theme reports OutOfStock.
• A custom snippet reports USD.
• The customer sees 79.00 EUR and InStock.

A testing tool may identify more than one Product item without making it obvious which object Google will use for a particular Merchant comparison.

Record every Product object and its nested Offer information.

For each object, identify:

• The generator
• Product name
• URL
• SKU
• GTIN
• Price
• Currency
• Availability
• Condition
• Variation identity
• Image
• Date or cache state where relevant

Do not add another Product object as a quick correction. This can create one more competing version of the product.

The safer approach is to determine which component should remain authoritative and stop inaccurate components from generating conflicting commercial data.

Check the Product and Offer relationship

Google’s Merchant structured data guidance describes a product page using:

1. A Product object that identifies the item.
2. A nested Offer object that describes how that item is sold.

The Offer normally contains commercial information such as:

• Price
• Price currency
• Availability
• Item condition
• Offer URL

A Product object without an applicable Offer may be insufficient for merchant listing information.

An Offer that describes another variation can be equally problematic.

Google’s current merchant listing structured data documentation requires an active price and corresponding three-letter ISO 4217 currency for merchant listing pricing. Availability is a recommended Offer property for search merchant listings and is also important for Merchant Center matching and automatic updates.

The Product and Offer must describe the same purchasable item.

Compare price values without symbols

Record the numeric value and currency separately.

For example:

• Numeric price: 1299.90
• Currency: TRY
• Displayed customer format: ₺1.299,90

A Turkish storefront can display decimal and thousands separators according to local conventions, while machine-readable structured data should still provide an unambiguous numeric price and an ISO currency code.

Investigate problems such as:

• Currency symbols inside the numeric price value
• Comma used in a way that changes the numeric meaning
• Thousands separators included incorrectly
• Tax-inclusive visible price with tax-exclusive schema price
• Regular price submitted while the active sale price is displayed
• Variation price replaced by the parent’s minimum price
• A price range represented as one specific offer
• Cached pre-sale price
• Currency-converted display with base-currency structured data
• Customer-location pricing
• Role-based pricing
• Quantity-based pricing
• Deposit or instalment amount presented as the full product price

The structured-data price must represent the actual current price a customer is expected to pay for the identified offer, subject to Google’s applicable product and pricing requirements.

A product-page headline such as “From €20” does not necessarily identify the price of the submitted variation.

Audit sale prices and scheduled sales

WooCommerce can store:

• Regular price
• Sale price
• Sale start date
• Sale end date

A mismatch can occur when:

• The visible sale has started but structured data still contains the regular price.
• The sale has ended but cached schema retains the sale price.
• The WordPress timezone differs from the server timezone.
• A variation has its own sale schedule.
• A pricing extension creates a customer-visible discount without updating Product schema.
• A coupon price is incorrectly used as a universally available product price.
• The structured data contains both old and current prices without a clear active offer.
• A theme uses the lowest variation price while Merchant submits a specific variation.

Google’s Merchant structured data instructions state that when a sale price is shown and is the price the customer will actually pay, that active price should be represented in the structured data.

Retest scheduled sales:

• Before the start
• Immediately after the start
• Before the end
• Immediately after the end
• After all relevant caches expire

The correction must survive the next scheduled price transition.

Compare availability values

WooCommerce stock behaviour can involve more than an in-stock or out-of-stock checkbox.

Check:

• Manage stock setting
• Stock quantity
• Stock status
• Backorders
• Parent stock
• Variation stock
• “Sold individually”
• Pre-order extensions
• External inventory integrations
• Warehouse stock
• Country-specific restrictions
• Product visibility
• Purchase permissions

Common schema values include:

• https://schema.org/InStock
• https://schema.org/OutOfStock
• https://schema.org/BackOrder
• https://schema.org/PreOrder
• https://schema.org/LimitedAvailability
• https://schema.org/Discontinued

The selected value must reflect the real purchase status.

A product is not necessarily in stock merely because the landing page loads.

If the Add to cart button is disabled, the required variation is unavailable or the product cannot be purchased for the target country, a generic InStock value may create contradictory evidence.

Also inspect whether a variation marked out of stock inherits the parent product’s in-stock schema.

Check product condition

WooCommerce does not always provide a standard customer-facing product condition field for every store configuration.

Condition information may be introduced by:

• The Merchant integration
• A custom product field
• A marketplace plugin
• A schema plugin
• A product template
• A used-product extension

Compare:

• WooCommerce condition source
• Visible landing-page condition
• Structured-data itemCondition
• Submitted Merchant condition
• Processed Merchant condition

Do not let structured data describe a product as new while the landing page or Merchant data identifies it as used or refurbished.

Google’s automatic product-information feature can use landing-page information for price, sale price, availability and condition. This makes inaccurate condition markup a commercial-data problem rather than a cosmetic schema warning.

Match SKU and GTIN correctly

Google explains that when a page contains multiple offers, each offer should be annotated with an SKU or GTIN, and the corresponding Shopping product should use a matching identifier.

This is particularly important for variable WooCommerce products.

Check whether:

• The parent SKU is applied to every variation.
• Each variation has a unique SKU where required by the store’s workflow.
• The wrong GTIN is inherited from the parent.
• A GTIN belongs to another size, colour or pack quantity.
• The schema SKU differs from the Merchant offer identity.
• A product plugin exposes an internal database ID instead of the commercial SKU.
• A theme removes variation identifiers from structured data.
• An SKU contains unintended whitespace.
• Duplicate products reuse the same identifier.

SKU and GTIN do more than fill optional-looking fields. They can help Google associate the structured Offer with the applicable submitted product.

Do not invent an identifier to make a test warning disappear.

Use only authentic identifiers belonging to the exact product or variation.

Handle WooCommerce variations as separate offers

Variable products create some of the most difficult structured-data mismatches.

A parent product can have variations by:

• Colour
• Size
• Material
• Pattern
• Capacity
• Pack quantity
• Compatibility
• Style

Each variation can have a different:

• SKU
• GTIN
• Price
• Sale price
• Stock status
• Image
• Weight
• Shipping class
• Purchase URL

Google supports product variant structured data using ProductGroup, Product, variesBy, hasVariant and productGroupID. Google’s product variant structured data documentation explains how these properties help Google understand products belonging to the same variation group.

A WooCommerce store is not required to force one implementation onto every theme without testing. However, the chosen structured-data representation must identify the real products accurately.

Inspect whether:

• The parent Product object contains only a price range.
• Every variation is represented.
• Only the default variation is represented.
• The selected variation changes the structured data.
• Each variation URL can be identified.
• Query parameters are preserved.
• Canonical URLs hide variation identity.
• The submitted variation links to the parent without a selection.
• productGroupID remains consistent across the group.
• Variation-specific SKUs and GTINs are correct.
• Shared brand and review information does not overwrite variation-specific information.

A valid ProductGroup structure cannot compensate for an incorrect variation landing experience.

Investigate multicurrency and geolocation behaviour

Currency extensions can make the visible page differ according to:

• IP address
• Browser language
• Cookie
• Customer account
• Selected country
• Shipping destination
• Manually selected currency

Google’s Merchant structured data setup guidance says that landing-page content, including pricing, should not dynamically change based on user information such as IP address or browser type when matching structured data with product information.

A store can still operate internationally, but the submitted product URL, content language, currency, target country and public landing-page experience must form a coherent combination.

For every target country, test:

• The product URL in a clean session.
• The default currency.
• The visible currency.
• The structured-data currency.
• The submitted Merchant currency.
• The checkout currency.
• Any currency query parameter.
• Whether Google can access the same state without a saved cookie.
• Whether a CDN varies cached HTML by location.

Do not assume that a currency symbol displayed by JavaScript changes the underlying structured data.

Identify the schema generator

Before making a correction, determine which component owns the inaccurate output.

Useful evidence can include:

• Script identifiers
• HTML comments
• Schema graph structure
• WordPress plugin settings
• Theme documentation
• Source-code prefixes
• Repeated property order
• Whether the output disappears in a controlled staging test when one component is disabled

Do not disable several plugins at once on a live store merely to see whether the problem disappears.

Use a staging environment where possible and test one controlled change at a time.

Potential sources include:

• WooCommerce core output
• Theme schema
• SEO-plugin schema
• Dedicated schema plugin
• Product-feed plugin
• Merchant integration
• Custom theme functions
• Code-snippet plugin
• Child theme
• Page-builder template
• Review system

The final goal is normally one coherent Product representation, not several partial objects that disagree.

Understand what validation tools prove

The Rich Results Test can help identify:

• JSON-LD syntax errors
• Missing required properties
• Invalid property types
• Merchant listing eligibility problems
• Product variant markup problems
• Detected Product objects

Search Console can help inspect indexed or live page information and structured-data reports.

These tools are valuable, but a successful result does not prove that:

• Merchant Center received the same price.
• The submitted variation is correct.
• Merchant Center processed the latest input.
• Another primary source is not active.
• Automatic updates used the intended value.
• The product is eligible for Shopping ads.
• The product is approved in every country.
• The checkout price matches.
• A customer can purchase the product.
• Google will display a rich result.

Validation should be combined with a direct comparison of WooCommerce, the public page, source HTML, submitted product input and processed Merchant result.

Correct the authoritative source

Make durable corrections where the value originates.

Examples include:

• Fix the WooCommerce variation price instead of editing generated JSON-LD manually.
• Correct the stock state used by both the page and schema.
• Update the currency configuration responsible for the public offer.
• Correct sale dates in the applicable variation.
• Remove an obsolete Product object generated by an inactive schema system.
• Configure the intended SEO or schema plugin as the sole schema owner.
• Correct a custom field mapped to Merchant condition.
• Repair variation identifiers in the product source.
• Update a theme template that exposes parent data for every variation.

Avoid editing cached output or Merchant Center values as the only correction.

The next page render, scheduled synchronisation or product update can restore the original problem.

Clear all relevant cache layers

After correcting the source, clear only the relevant cache layers, including where applicable:

• WordPress page cache
• Object cache
• WooCommerce transients
• Server cache
• Reverse-proxy cache
• CDN cache
• Edge cache
• Theme-generated schema cache
• SEO-plugin cache
• Product-feed cache
• Currency cache
• Variation-price cache

Then open the product URL while logged out and inspect the original source again.

Confirm that the old Product or Offer object no longer appears.

A correct WordPress administration value does not prove that a public cached page has changed.

Understand automatic product updates

Merchant Center can automatically update certain product information using structured data and information extracted from landing pages.

Google currently identifies price, sale price, availability and condition as supported automation areas. Google also states that automations are intended to correct temporary inconsistencies for a limited portion of products and are not a replacement for regular accurate product updates. Google’s automatic product information documentation explains these limitations.

Automatic updates should not be treated as a catalogue-maintenance strategy.

If Google repeatedly changes submitted values using the website, investigate why the two sources disagree.

Possible causes include:

• Delayed WooCommerce synchronisation
• Stale API product input
• Stale structured data
• Currency conversion
• Incorrect sale schedule
• Wrong variation URL
• Competing product source
• Manual Merchant rule
• Incorrect Product schema
• Cache timing
• Customer-specific pricing

Disabling automatic updates may hide one symptom but does not correct inaccurate product information.

Resubmit the corrected Merchant product

After the public page and structured data are correct:

1. Identify the active primary product data source.
2. Confirm the Merchant offer ID.
3. Submit the supported product update.
4. Record the operation time.
5. Record the submitted price and currency.
6. Record availability and condition.
7. Record the landing-page URL.
8. Confirm whether the request succeeded.
9. Allow Google to process the product.
10. Retrieve or inspect the processed result.
11. Compare processed attributes with the corrected page.
12. Review item-level issues.
13. Review destination status.
14. Review the applicable country and marketing method.

Google’s Merchant API Product resource represents processed product information and includes product status, destination status and applicable item-level issues. Google notes that processing can take several minutes after a product input is changed. Merchant API’s processed Product reference explains this distinction.

A successful product-input operation confirms only that the request was accepted.

It does not confirm that:

• The landing page was recrawled.
• Structured data was accepted.
• The processed product already changed.
• The item is eligible.
• Every destination is approved.
• Another source did not affect the result.

What PW Merchant API can support

PW Merchant API supports an API-oriented connection between WooCommerce product information and Google Merchant Center.

Depending on the installed version, configuration, product mappings and connected Merchant account, it can help merchants:

• Review WooCommerce product information.
• Work with simple products and variations.
• Preserve controlled product offer identities.
• Prepare supported product attributes.
• Submit supported product updates.
• Synchronise applicable price and stock changes.
• Record product-operation results.
• Display supported Merchant product issues.
• Compare applicable WooCommerce information with Merchant results.
• Identify products requiring attention.
• Schedule supported synchronisation operations.

These functions can support a structured data investigation by helping the merchant compare the WooCommerce product with applicable submitted and processed Merchant information.

PW Merchant API cannot independently:

• Control Product schema generated by every WordPress theme.
• Remove schema created by unrelated plugins.
• Correct inaccurate WooCommerce source information.
• Guarantee that a page builder returns schema in the original HTML.
• Guarantee that a currency plugin displays one stable value to every crawler.
• Validate an invented GTIN or SKU.
• Correct an inaccessible checkout.
• Guarantee a Merchant Center recrawl time.
• Guarantee automatic-update behaviour.
• Guarantee product approval.
• Guarantee Shopping impressions or clicks.
• Override Google’s policies.
• Replace testing of the public landing page.

WooCommerce remains the merchant’s customer-facing commercial product source. PW Merchant API supports applicable product communication, while Google independently crawls the website and processes product eligibility.

Common structured data correction mistakes

Fixing only the visible page

The structured Product object can still contain an old price or availability.

Fixing only JSON-LD

The WooCommerce product or checkout can still charge a different price.

Adding another Product object

An extra object can increase conflicts rather than establish one authoritative result.

Disabling all schema

This removes useful product information without correcting the product source or Merchant submission.

Changing only Merchant Center

The next WooCommerce synchronisation can restore the previous value.

Assuming a green Rich Results Test means Merchant approval

The tool validates supported structured data behaviour; it does not decide Merchant eligibility.

Testing the parent product instead of the affected variation

The specific variation may have a different price, stock state, SKU, GTIN or image.

Ignoring server-generated HTML

A browser script may display the correct value while the original response contains something else.

Ignoring duplicate schema

Two individually valid Product objects can contradict each other.

Using a currency symbol instead of an ISO currency code

Machine-readable currency should be supplied clearly through the appropriate property.

Submitting the lowest variation price as every variation’s price

Each submitted variation must represent its actual offer.

Using automatic updates as a permanent repair

Google states that automations do not replace accurate and frequently updated product data.

Clearing only the browser cache

The old schema can remain in WordPress, server, object or CDN caches.

Frequently asked questions

What is a WooCommerce structured data mismatch?

It is an inconsistency between the WooCommerce product, customer-facing page, Product or Offer structured data, submitted Merchant product information or Google’s processed result.

Does Merchant Center always call it a structured data mismatch?

No. The problem may appear through price, availability, sale price, currency, landing-page or automatic-update issues.

Is Product schema required for every WooCommerce Merchant product?

Google strongly recommends structured product information, and it can support Merchant verification and automatic updates. The exact applicable requirements depend on the Google experience and product configuration.

Can valid Product schema still contain the wrong price?

Yes. Structured data can be syntactically valid while describing inaccurate commercial information.

Why does the Rich Results Test show two products?

More than one theme, plugin or custom component may be generating Product schema. Inspect each object and determine which source should remain authoritative.

Should I delete the duplicate Product object?

First identify its generator and role. Remove or disable the conflicting output only after confirming that another authoritative component supplies complete and accurate product information.

Should structured data use the regular price or sale price?

It should represent the active price the customer will actually pay for the identified offer. Scheduled sale timing and caches must also be correct.

Why does schema show the parent product’s lowest price?

Some WooCommerce themes or schema generators describe a variable product using a price range or minimum price. This can conflict with a Merchant offer for a specific variation.

Can every variation use the same SKU?

The identifiers must accurately distinguish and match the submitted products. Do not reuse identifiers in a way that causes separate variations to be confused.

Does changing the SEO title correct Product schema?

Not necessarily. The SEO plugin may generate part of the schema, but WooCommerce, the theme or another plugin may remain responsible for the commercial Offer.

Can JavaScript update the structured-data price after variation selection?

A browser can modify the rendered page, but Google’s Merchant Center guidance says matching markup should be present in the HTML returned by the server rather than generated only after page load. Test the original response and the exact landing-page design.

Can automatic updates fix all price and stock mismatches?

No. Google describes automatic updates as a temporary corrective mechanism for a limited portion of products, not a substitute for accurate scheduled product updates.

Should I disable automatic product updates?

Not merely to hide a mismatch. First correct WooCommerce, the landing page, structured data and submitted product source. Review the Merchant automation setting according to the store’s controlled data workflow.

Why does Merchant Center still show the old structured-data value?

Google may not have recrawled the page, an old cache may still be public, another Product object may remain, processing may be incomplete or another product source may control the Merchant value.

Can PW Merchant API correct my theme’s Product schema?

Do not assume so. Its applicable purpose is WooCommerce–Merchant product communication. Theme and unrelated plugin schema normally must be corrected at the component generating the markup.

Will correct structured data guarantee product approval?

No. Google independently evaluates product data, landing pages, website requirements, policies, countries and marketing methods.

Final structured data checklist

Before considering the mismatch resolved, confirm that:

• The correct Merchant Center account was opened.
• The correct product issue was recorded.
• The offer ID was recorded.
• The WooCommerce product ID was recorded.
• The variation ID was recorded where applicable.
• The SKU was checked.
• The GTIN was checked where applicable.
• The primary product data source was identified.
• Supplemental product sources were identified.
• Merchant Center rules were reviewed.
• Manual Merchant edits were reviewed.
• The target country was recorded.
• The content language was recorded.
• The feed label was recorded.
• The marketing method was recorded.
• The exact product URL was tested.
• The page worked while logged out.
• HTTPS worked.
• Redirects were correct.
• The intended variation was represented.
• The visible product name was correct.
• The visible price was correct.
• The visible currency was correct.
• The visible sale price was correct.
• The visible availability was correct.
• The visible condition was correct.
• The product could be added to the cart.
• The checkout used the expected price.
• The checkout used the expected currency.
• The original HTML source was inspected.
• Every Product object was identified.
• Every ProductGroup object was identified.
• Every Offer object was identified.
• Every AggregateOffer object was reviewed.
• Duplicate Product schema was investigated.
• The generator of every Product object was identified.
• Product and Offer objects represented the same item.
• The structured product name was accurate.
• The structured SKU was accurate.
• The structured GTIN was accurate.
• The structured brand was accurate.
• The structured price was numeric.
• The structured price represented the active offer.
• The structured currency used the correct ISO code.
• The structured sale price was current.
• Sale start and end dates were reviewed.
• The structured availability was accurate.
• The structured condition was accurate.
• The structured URL was correct.
• The structured image represented the product.
• Parent and variation information were not confused.
• Variation identifiers were unique where required.
• productGroupID was reviewed where used.
• variesBy values were reviewed where used.
• hasVariant relationships were reviewed where used.
• A variation did not inherit another variation’s price.
• A variation did not inherit another variation’s stock.
• A variation did not inherit another variation’s SKU.
• A variation did not inherit another variation’s GTIN.
• A variation did not inherit another variation’s image.
• Multicurrency behaviour was tested.
• Geolocation behaviour was tested.
• Cookie-dependent pricing was investigated.
• Logged-in pricing was investigated.
• Wholesale pricing was investigated.
• Tax display was checked.
• Quantity discounts were checked.
• Deposit prices were checked.
• Page-builder residue was investigated.
• JavaScript-only structured data was investigated.
• WordPress caches were cleared.
• WooCommerce transients were cleared.
• Object caches were cleared.
• Server caches were cleared.
• CDN caches were cleared.
• The corrected original source was retested.
• The Rich Results Test was used.
• Critical structured-data errors were corrected.
• Merchant listing warnings were reviewed.
• The authoritative generator remained active.
• Obsolete duplicate output was addressed.
• The WooCommerce source was corrected.
• The corrected Merchant product was submitted.
• The product operation result was recorded.
• Rejected operations were investigated.
• Google was allowed time to process the update.
• The processed product was inspected.
• The processed price was correct.
• The processed currency was correct.
• The processed availability was correct.
• The processed condition was correct.
• Item-level issues were reviewed.
• Destination status was reviewed.
• Country status was reviewed.
• Automatic update results were reviewed.
• No obsolete data source could restore the old value.
• No scheduled sale could restore the old value.
• No cache could restore the old value.
• No approval or visibility guarantee was claimed.

WooCommerce structured data mismatch correction should begin with the exact affected product and finish with Google’s processed Merchant result.

The merchant must compare the WooCommerce source, visible landing page, original HTML, every Product and Offer object, submitted product input and processed Merchant product.

A valid schema test is useful, but syntax alone does not prove commercial accuracy.

Prices, currencies, availability, condition, identifiers and variations must represent the same real offer across every layer.

When several WordPress components generate Product schema, the durable correction is to identify one authoritative source and resolve conflicting outputs. Adding another Product object or editing Merchant Center manually can create only a temporary appearance of consistency.

After the source is corrected, relevant caches should be cleared, the public page retested and the product submitted through the active data source. The processed Merchant information and item-level status must then be checked again.

PW Merchant API can support controlled WooCommerce product communication, variation handling, operation results and applicable Merchant issue visibility. It cannot correct every theme or schema plugin, replace accurate WooCommerce information or guarantee Google approval.

Consistent structured data helps Google understand and verify a product, but the complete WooCommerce landing page and purchasing experience must remain equally accurate.