How to fix invalid product condition errors in Google Merchant Center

How to fix invalid product condition errors in Google Merchant Center for WooCommerce

An invalid product condition error in Google Merchant Center means that the condition submitted for a WooCommerce product is missing when required, uses an unsupported value or conflicts with the actual product and its landing page.

Google supports only three standard product condition values:

• new
• used
• refurbished

Descriptions such as “open box,” “like new,” “pre-owned,” “renewed,” “mint,” “display item” or “grade A” can be useful for customers, but they are not separate accepted values for the Merchant condition [condition] attribute.

Each WooCommerce offer must therefore be mapped to the supported value that most accurately represents the real product.

The correction should begin with the exact affected Merchant offer and end with confirmation that WooCommerce, the submitted product data, the public landing page and structured data all represent the same condition.

Changing a label inside Merchant Center without identifying the authoritative WooCommerce source may provide only a temporary correction. The next automatic synchronisation, scheduled source update or API operation can restore the previous value.

The short answer

To fix an invalid product condition error:

1. Open the exact affected product in Merchant Center.
2. Record the Merchant offer ID and active product source.
3. Inspect the processed condition value.
4. Identify where that condition originates in WooCommerce.
5. Determine the product’s real physical and commercial condition.
6. Map it to new, used or refurbished.
7. Remove unsupported condition labels from the submitted attribute.
8. Correct the authoritative WooCommerce field or mapping rule.
9. Check the product title, description and visible condition information.
10. Check Product structured data.
11. Check every active Merchant data source.
12. Submit the corrected product.
13. Review the product after Google processes the update.
14. Confirm that the issue has disappeared for every affected country and marketing method.

Do not select new simply because it is the easiest default.

Do not select refurbished merely because a used product was cleaned.

Do not pass a customer-facing cosmetic grade directly into the Merchant condition field.

The Merchant condition must describe the real product using one of Google’s supported values.

What does the condition attribute mean?

The condition [condition] attribute tells Google and potential customers whether the exact item being sold is new, used or refurbished.

It does not describe:

• Stock availability
• Whether the product is on sale
• Whether the product can be returned
• Whether the product is damaged in transit
• Whether the product is currently published
• Whether the product has passed an internal quality check
• Whether the product is in the WooCommerce catalogue
• Whether the product is backordered
• Whether the product is discontinued
• Whether the product is taxable
• Whether the product has a warranty by itself
• Whether the product is eligible for a promotion

These are separate product or business characteristics.

For example, a product can be:

• New and in stock
• New and out of stock
• Used and in stock
• Refurbished and on sale
• Used and non-returnable
• Refurbished and backordered

The condition and availability attributes should not be used as substitutes for one another.

Google’s official condition attribute requirements define the accepted product data values and the circumstances they represent.

The three supported condition values

Actual product condition	Product data value	Merchant API enum	General meaning
New	new	NEW	Brand-new product in its original unopened packaging
Used	used	USED	Previously used product or product whose original packaging has been opened or is missing
Refurbished	refurbished	REFURBISHED	Product professionally restored to working order and supplied with a warranty

The lowercase values are commonly seen in Merchant product data specifications and file-based sources.

The current Merchant API ProductAttributes reference represents condition through the NEW, USED and REFURBISHED enum values.

An integration should translate the WooCommerce selection into the correct format for the method being used.

Merchants should not manually change letter case or API payload structure without first identifying the source of the error.

When should a product be submitted as new?

Use new when the exact product is genuinely new.

Google’s Merchant API definition describes a new product as brand new and in its original unopened packaging.

Typical examples include:

• A factory-sealed retail product
• A newly manufactured product that has not been used
• A new garment with its original retail presentation
• A new device in unopened manufacturer packaging
• A new product supplied through an authorised distributor
• An unused product that accurately meets Google’s new-condition requirements

The fact that a product was recently added to WooCommerce does not make its condition new.

The following details also do not prove that an item is new:

• It has never been listed before.
• It has no previous orders.
• Its stock quantity was recently imported.
• It looks clean.
• It has no visible scratches.
• It was returned without an explanation.
• The merchant has not personally used it.
• It has been resealed by the store.
• It has been placed in replacement packaging.
• It has received a new WooCommerce product ID.
• Its price is similar to a new product’s price.

Condition is based on the actual item being offered, not the age of its WooCommerce record.

When should a product be submitted as used?

Use used when the product was previously used or when its original packaging has been opened or is missing.

This category can include:

• Second-hand products
• Pre-owned products
• Open-box products
• Customer returns with opened packaging
• Display products
• Demonstration units
• Ex-rental equipment
• Vintage products
• Products with signs of previous use
• Products in replacement packaging
• Products described as “like new”
• Products described through cosmetic grades
• Products tested or cleaned by the seller without qualifying professional refurbishment
• Products modified from their original condition

A merchant may describe the product more precisely on the landing page.

For example:

• Used – excellent cosmetic condition
• Used – minor scratches on the rear panel
• Used – original packaging not included
• Used – display unit
• Used – battery health measured at 91%
• Used – professionally cleaned and tested
• Used – accessories listed on the page are included

These descriptions help customers understand the offer.

However, the Merchant condition value remains used.

Values such as open_box, preowned, second_hand, like_new, grade_a or mint should not be sent as substitutes for used.

When should a product be submitted as refurbished?

Use refurbished only when the product has been professionally restored to working order and comes with a warranty.

A refurbished product may or may not retain its original packaging.

The important elements are:

• The product is not new.
• It has undergone a professional restoration process.
• It has been restored to working order.
• It comes with a warranty.
• The landing page accurately describes the refurbished condition.

Cleaning a used product is not automatically refurbishment.

Testing that a device powers on is not automatically refurbishment.

Resetting a phone to factory settings is not automatically refurbishment.

Replacing the packaging is not automatically refurbishment.

A product should not be submitted as refurbished merely because that description sounds more attractive than used.

Before selecting refurbished, verify:

• Who performed the refurbishment
• What work was completed
• Whether defective components were replaced
• Whether functionality was tested
• Whether the product comes with a warranty
• Whether warranty terms are publicly available
• Whether the landing page clearly identifies the product as refurbished
• Whether included and excluded accessories are disclosed
• Whether cosmetic defects are disclosed
• Whether the product title and description support the submitted condition

Google also provides separate guidance for compatible and refurbished third-party products.

Open-box products require special attention

“Open box” is not one of the three supported condition values.

According to Google’s Merchant API condition definition, a product whose original packaging has been opened or is missing falls within used.

This can apply even when:

• The customer states that the product was never used.
• The device appears untouched.
• All accessories remain present.
• The product passed inspection.
• The merchant resealed the package.
• The product is sold with a store warranty.
• The price remains close to the new retail price.

The merchant can still use “open box” in the visible product title or description when it accurately describes the offer.

A practical representation can be:

• Merchant condition: used
• Visible description: “Open-box product inspected by our team; original accessories included”
• Product image: The actual product or an accurate representation
• Warranty information: Clearly disclosed
• Packaging information: Clearly disclosed

Do not submit open_box as the Merchant condition value.

“Like new” is a cosmetic description, not a Merchant condition

“Like new” commonly indicates that a used product has little or no visible wear.

It does not create a fourth Merchant condition.

A product described as “like new” should normally still use used unless it genuinely meets the professional restoration and warranty requirements for refurbished.

For example:

Customer-facing description	Merchant condition
Like new	used
Excellent condition	used
Grade A	used
Very good	used
Good	used
Acceptable	used
Open box	used
Professionally refurbished with warranty	refurbished

Cosmetic grades can remain on the product page when they are clear and accurate.

They should not be passed directly into the condition attribute.

Common causes of invalid product condition errors

An invalid condition error can originate from several parts of a WooCommerce-to-Merchant workflow.

Common causes include:

• An unsupported value was submitted.
• The field was empty for a used or refurbished product.
• A translated condition label was submitted instead of the supported value.
• A numeric database value was passed without mapping.
• A WooCommerce attribute was mistaken for the Merchant condition.
• The product importer placed condition in an unexpected custom field.
• A condition plugin uses different internal values.
• The parent product and its variations use different sources.
• A default rule marks every product as new.
• A category rule overwrites a product-level selection.
• A previous product source continues to submit an old value.
• Structured data declares another condition.
• The public product page describes the product as used while Merchant data says new.
• A variation inherits the wrong parent condition.
• A returned product was placed back in new inventory.
• A refurbished product does not include a warranty.
• An API payload contains an unsupported enum.
• An empty condition is converted to a placeholder string.
• A multilingual value reaches the final submitted field.
• A CSV import changes the expected capitalization or field format.
• A scheduled synchronisation restores an outdated value.
• Cached Product structured data exposes the previous condition.
• Another plugin generates competing Product schema.
• A supplemental data source overrides the primary source.

The error message alone may not identify which system introduced the value.

The complete data path must be reviewed.

WooCommerce does not treat every product state as Merchant condition

Many WooCommerce installations do not contain one universally used core field dedicated to Google Merchant condition.

The condition may instead come from:

• A Merchant integration field
• Product metadata
• A global integration setting
• A product category rule
• A custom product attribute
• An import mapping
• An ERP field
• A supplier catalogue
• A marketplace importer
• A structured data extension
• A custom code snippet
• A multilingual mapping
• A previous feed plugin

Do not assume that WooCommerce stock status controls Merchant condition.

WooCommerce stock states such as:

• In stock
• Out of stock
• On backorder

describe availability, not condition.

WooCommerce product statuses such as:

• Published
• Draft
• Pending
• Private

describe publication state, not condition.

WooCommerce product types such as:

• Simple
• Variable
• Grouped
• External or affiliate

describe catalogue structure, not condition.

The actual field used by the active Merchant source must be identified.

First identify the exact affected offer

Do not begin by changing every WooCommerce product.

Start with one affected Merchant offer.

Record:

• Merchant Center account
• Merchant offer ID
• WooCommerce product ID
• WooCommerce variation ID
• SKU
• GTIN
• Product title
• Submitted URL
• Processed condition
• Active product source
• Target country
• Content language
• Feed label
• Marketing method
• Issue name
• Issue severity
• Date first detected

The Merchant offer ID is particularly important.

A WooCommerce product can create several Merchant offers when it contains variations or is submitted for multiple countries, languages or data-source configurations.

Search for the exact offer rather than relying only on the product title.

Inspect the processed product in Merchant Center

Open the affected product and review the condition Google has processed.

Ask:

• Is condition missing?
• Is the value unsupported?
• Does it say new, used or refurbished?
• Which data source supplied it?
• Does the issue affect one country or several?
• Does it affect free listings, Shopping ads or another marketing method?
• Does the processed value match WooCommerce?
• Does the product page use another description?
• Has Google detected a mismatch?
• Is automatic item updating involved?
• Is another source overwriting the field?

Google’s condition mismatch guidance recommends investigating the update process and making the relevant product attributes reflect the same condition.

The processed product is more useful than an assumption based only on the most recently edited WooCommerce field.

Distinguish an invalid value from a condition mismatch

These two problems are related but not identical.

Invalid condition value

The submitted value is not supported or cannot be interpreted correctly.

Examples include:

• open_box
• pre_owned
• like new
• second hand
• grade a
• renewed
• mint
• damaged
• 0
• 1
• yes
• no
• none
• An empty required value
• A translated label
• An invalid Merchant API enum

The correction is to map the real condition to a supported value.

Condition mismatch

The submitted value is technically supported, but it conflicts with other information.

Examples include:

• Merchant data says new, but the landing page says “used.”
• Merchant data says new, but structured data says UsedCondition.
• Merchant data says refurbished, but the page describes an ordinary second-hand item.
• Merchant data says used, but structured data says NewCondition.
• A title says “open box,” but the submitted condition says new.
• A product description states that original packaging is missing, but the condition says new.
• One active source says used, while another says new.

In this situation, changing the spelling or data format is not enough.

The systems must agree on the real product condition.

Check the public WooCommerce landing page

Open the exact submitted URL while logged out.

Review:

• Product title
• Short description
• Long description
• Condition label
• Variation selection
• Image
• Price
• Availability
• Warranty
• Packaging information
• Included accessories
• Cosmetic grade
• Defect disclosure
• Return information
• Seller notes
• Product specifications

The page must describe the same item represented by the Merchant offer.

For a used or refurbished product, the page should not create the impression that the customer will receive a brand-new factory-sealed item.

For a new product, the page should not contain inherited text such as:

• Minor signs of use
• Original packaging not included
• Professionally restored
• Replacement parts installed
• Customer return
• Open box
• Demo unit
• Display model
• Refurbished
• Pre-owned

These phrases can reveal that the Merchant condition and the public offer are inconsistent.

Inspect Product structured data

The WooCommerce page may include Product structured data generated by:

• WooCommerce
• The active theme
• An SEO plugin
• A schema plugin
• A Merchant integration
• Custom code
• A page builder
• A review extension

The relevant schema.org property is commonly itemCondition.

Google’s supported structured data mapping maps Merchant conditions as follows:

Merchant condition	Supported schema.org value
new	https://schema.org/NewCondition
refurbished	https://schema.org/RefurbishedCondition
used	https://schema.org/UsedCondition or https://schema.org/DamagedCondition

A new product can be represented as:

"itemCondition": "https://schema.org/NewCondition"

A used product can be represented as:

"itemCondition": "https://schema.org/UsedCondition"

A refurbished product can be represented as:

"itemCondition": "https://schema.org/RefurbishedCondition"

Do not add several conflicting Product objects merely to expose different condition values.

Check whether:

• The theme outputs one condition.
• An SEO plugin outputs another.
• The selected variation changes but structured data remains on the parent condition.
• Cached HTML exposes an old value.
• The visible page says used while schema says new.
• A global schema template forces every product to NewCondition.
• A condition plugin adds a second Product schema block.
• DamagedCondition is used for a product submitted as refurbished.
• The schema belongs to another product shown on the same page.

Google states that structured data should match the user-visible landing-page information.

Variable products need offer-level condition decisions

A variable WooCommerce product can contain items with different conditions.

For example, the same phone model might be sold as:

• New – 128 GB – black
• Used – 128 GB – black
• Refurbished – 256 GB – silver

These should not be treated as one indistinguishable offer.

Each submitted variation may require its own:

• Offer ID
• SKU
• GTIN
• Price
• Availability
• Image
• Condition
• Description
• Warranty information
• Landing-page state

A parent-level default can create problems when individual variations have different conditions.

Review whether:

• The condition is stored on the parent product.
• The variation has its own condition field.
• The integration supports variation-level condition values.
• The parent value overwrites the variation.
• Every variation uses the same landing-page URL.
• The correct variation is preselected or identifiable.
• Structured data changes after variation selection.
• The product title makes the variation condition clear.
• The offer ID can be matched to the exact variation.

Do not correct one variation by changing the entire parent product unless every variation genuinely has the same condition.

Returned products should not automatically return to new inventory

WooCommerce can restore stock after an order is cancelled or refunded.

That stock movement does not determine the physical condition of the returned item.

A returned product may still be new only when it genuinely continues to meet the applicable new-condition requirements.

If its original packaging has been opened or is missing, it may need to be sold as used.

A safe returns workflow should distinguish:

• Unopened, factory-sealed return
• Opened but unused return
• Used return
• Damaged return
• Product requiring refurbishment
• Product not suitable for resale

Do not let an automated stock-restoration process classify every returned unit as new.

Stock quantity and condition should be managed separately.

Cosmetic grades should be mapped, not submitted directly

Merchants selling used electronics, tools, furniture, books or collectibles may use internal grades.

For example:

• Grade A
• Grade B
• Grade C
• Excellent
• Very good
• Good
• Acceptable
• Mint
• Fair
• Parts only

These values can help customers understand wear and appearance.

However, they are not independent Merchant condition values.

A mapping may look like:

Internal grade	Merchant condition	Public disclosure
Grade A	used	Explain minimal cosmetic wear
Grade B	used	Explain visible signs of use
Grade C	used	Explain heavier wear or defects
Professionally refurbished Grade A with warranty	refurbished	Explain restoration and warranty
Open box	used	Explain opened packaging
Factory sealed	new	Confirm actual new condition

The mapping should be based on the business’s real grading process.

Do not describe a damaged or incomplete product in a way that misleads the customer.

Some products may also be restricted or unsuitable for particular Google programmes independently of their condition value.

Multilingual stores should not translate the submitted token

A multilingual WooCommerce store may display customer-facing condition labels in several languages.

For example:

• New
• Yeni
• Neu
• Nouveau
• Nuevo

The visible product page can use the appropriate customer language.

The Merchant condition attribute must still use the supported product data or API representation.

A translation system should not turn the underlying submitted value into:

• yeni
• neu
• nouveau
• nuevo
• Another local label

The integration should preserve a stable internal meaning and submit the supported Merchant value.

Check:

• Translation plugin string rules
• Product custom fields
• CSV import language
• Locale-dependent mappings
• API payload creation
• Language-specific product copies
• Country-specific product sources
• Structured data for each language

A translated page and a translated Merchant attribute are not the same thing.

Check all active Merchant data sources

A corrected WooCommerce value can remain ineffective when another source supplies conflicting information.

Review:

• Merchant API source
• Scheduled XML or text source
• Uploaded product file
• Google Sheets source
• Ecommerce platform connection
• Automatic website source
• Supplemental data source
• Previous WooCommerce integration
• Manual product data
• Country-specific sources

For each source, identify:

• Which offer IDs it controls
• Which condition it supplies
• How often it updates
• Whether it can override another source
• Whether it uses the same product ID
• Whether it has a country or language restriction
• Whether it submits parent or variation data
• Whether it still contains old condition values

Do not leave duplicate active offers with different conditions.

Do not assume that the source edited most recently is the source shown in the processed product.

Correct the authoritative WooCommerce source

After identifying the true source:

1. Open the exact WooCommerce product.
2. Open the exact variation where applicable.
3. Locate the condition field or mapping used by the active integration.
4. Select the value that represents the real item.
5. Save the product.
6. Clear only applicable caches.
7. Confirm that the public page displays accurate information.
8. Confirm that structured data reflects the same condition.
9. Submit or synchronise the corrected offer.
10. Record the operation result.
11. Review the processed product after Google handles the update.

If the condition comes from an import or ERP synchronisation, correct the upstream mapping as well.

Otherwise, the next import may reverse the WooCommerce correction.

Merchant API condition handling

Merchant API uses a defined condition enum.

The current values include:

• NEW
• USED
• REFURBISHED

CONDITION_UNSPECIFIED is documented as a default enum value that is unused. It should not be treated as a fourth customer-facing condition.

An invalid payload may result when an integration attempts to send values such as:

"condition": "OPEN_BOX"

or:

"condition": "LIKE_NEW"

or:

"condition": "SECOND_HAND"

These are not supported Merchant API condition enums.

The integration should translate the store’s real classification into the correct enum.

For example:

• Open box → USED
• Pre-owned → USED
• Like new → USED
• Professionally restored with warranty → REFURBISHED
• Factory-sealed new product → NEW

The customer-facing description can remain more detailed than the API enum.

Technical acceptance does not prove condition accuracy

A product operation may be accepted in a technically valid form and still develop a condition-related issue after processing.

The sequence can be:

1. WooCommerce stores the condition.
2. The integration prepares the product operation.
3. Merchant API receives the operation.
4. Google processes the product.
5. Google compares relevant product signals.
6. The processed offer appears in Merchant Center.
7. A mismatch or data-quality issue appears later.

An accepted operation does not guarantee:

• The real product is correctly classified.
• The landing page agrees with the product data.
• Structured data agrees with the product data.
• Another source will not override the value.
• The product will be approved.
• The product will remain approved.
• The product will appear in free listings.
• The product will appear in Shopping ads.
• The product will receive impressions or clicks.
• Google will accept a refurbished classification.
• The account has no other issues.

Always inspect the processed product.

Automatic item updates and condition mismatches

Google can use landing-page signals to detect certain differences between submitted product data and the website.

Google’s automatic item update documentation explains that condition checks can compare the submitted condition with other product information.

Automatic updates should not be used as a permanent substitute for accurate WooCommerce data.

If Google detects a mismatch:

• Identify the authoritative source.
• Correct WooCommerce.
• Correct structured data.
• Correct the public description.
• Correct other active product sources.
• Resubmit the product.
• Review the result after processing.

Do not deliberately submit an inaccurate value and expect automatic systems to correct it continuously.

How to verify the correction

After submitting the update:

1. Open the correct Merchant Center account.
2. Go to Products.
3. Open the Needs attention area.
4. Search for the exact offer ID.
5. Open the processed product.
6. Confirm the active product source.
7. Confirm the processed condition.
8. Confirm the target country.
9. Confirm the marketing method.
10. Open the submitted landing-page URL.
11. Check the visible condition while logged out.
12. Check the selected variation.
13. Check Product structured data.
14. Check the Merchant operation result.
15. Allow processing time.
16. Review the issue again.

Do not delete and recreate the product unless the exact problem requires that action.

A condition correction should normally preserve the stable offer identity.

What PW Merchant API can support

PW Merchant API provides an API-oriented workflow between WooCommerce and Google Merchant Center.

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

• Review WooCommerce products.
• Work with simple and variable products.
• Inspect supported product information.
• Prepare supported condition data.
• Submit supported Merchant product operations.
• Maintain controlled offer IDs.
• Review operation results.
• Display applicable Merchant product issues.
• Synchronise supported product changes.
• Compare WooCommerce and processed Merchant information.
• Identify incomplete or unsupported product records.

This can help expose situations where:

• Condition is missing.
• A condition value is unsupported.
• Parent and variation information differ.
• The WooCommerce source requires correction.
• The processed Merchant offer contains an unexpected value.
• A product operation has failed.
• Another product issue remains after condition is corrected.

PW Merchant API cannot physically inspect a product.

It cannot independently determine whether packaging was opened, whether a device was previously used or whether refurbishment meets the required standard.

It cannot:

• Turn a used product into a new product.
• Make an open-box value supported as a separate Merchant condition.
• Create a warranty that does not exist.
• Confirm a professional refurbishment process.
• Correct inaccurate supplier information without an authoritative source.
• Prevent another active source from overwriting product information.
• Guarantee Google approval.
• Guarantee Shopping visibility.
• Guarantee impressions, clicks or sales.
• Override Google’s product-data requirements.
• Repair misleading landing-page information automatically.
• Decide condition solely from product price or stock status.

The merchant remains responsible for representing the real item accurately.

Common mistakes

Submitting “open box” as condition

Open box is a useful customer description, but not a supported Merchant condition value. It should generally map to used.

Submitting “like new” as condition

Like new normally describes the cosmetic state of a used product. The Merchant value remains used.

Marking every WooCommerce product as new

A global default can misclassify returned, opened, used, display or refurbished products.

Using refurbished for every cleaned product

Cleaning, testing or resetting a used product does not automatically satisfy professional refurbishment and warranty expectations.

Confusing condition with stock status

In stock, out of stock and backorder are availability values.

Confusing condition with return eligibility

A new product can be non-returnable, and a used product can be returnable. Return rules do not determine the Merchant condition.

Translating the submitted value

Customer-facing labels can be translated, but the underlying Merchant value must remain supported.

Correcting only Merchant Center

A manual correction may be overwritten by the active WooCommerce source.

Ignoring variations

Different variations can have different physical conditions and require separate offer data.

Ignoring structured data

A page that submits new while exposing UsedCondition can create conflicting signals.

Ignoring old product sources

A previous feed or platform connection may continue supplying another condition.

Stopping after a successful API response

Technical receipt does not prove that the processed condition is accurate or approved.

Frequently asked questions

Which product condition values does Google Merchant Center accept?

Google accepts new, used and refurbished for the condition attribute.

Can I submit “open box” as a condition?

No. Open box is not a separate supported condition value. A product with opened or missing original packaging generally maps to used.

Can I submit “like new” as a condition?

No. Like new can be used as an accurate customer-facing description, but the Merchant condition will normally be used.

Can a customer return still be sold as new?

Only when the actual item continues to satisfy the applicable new-condition requirements. An opened or missing original package can require the product to be treated as used.

Does a used product need the condition attribute?

Yes. Google’s product data specification requires the condition attribute for used and refurbished products. It is optional for new products, although an integration may submit it explicitly.

Can a cleaned product be submitted as refurbished?

Not merely because it was cleaned. Refurbished products must be professionally restored to working order and come with a warranty.

Is a seller warranty enough to make a product refurbished?

A warranty alone does not demonstrate professional restoration. The product should genuinely meet the complete refurbished definition.

Is product condition the same as stock status?

No. Condition describes whether the item is new, used or refurbished. Stock status describes availability.

Is product condition the same as return condition?

No. A return policy may specify the condition in which customers must return products, but that is different from the condition of the item being sold.

Should every variation use the parent product’s condition?

Only when every variation genuinely has the same condition. Otherwise, condition should be determined for each submitted variation.

Can I use Grade A as the Merchant condition?

No. Grade A can remain as a customer-facing cosmetic grade, but it should be mapped to used or, when all refurbishment requirements are genuinely met, refurbished.

Why does the error return after I correct WooCommerce?

Another importer, scheduled synchronisation, product source, category rule or integration may be restoring the previous value.

Can structured data cause a condition mismatch?

Yes. Product structured data that declares another condition can conflict with the submitted product and visible landing page.

Does an accepted Merchant API operation mean the condition is correct?

No. It confirms technical receipt. Google still processes and evaluates the product.

Do I need to request a review after correcting condition?

Follow the action shown for the exact Merchant issue. Many item-level data corrections are reprocessed after updated product data is submitted, while some account-level situations can provide a review action.

Can PW Merchant API decide whether my product is used or refurbished?

It can work with the information available in WooCommerce and supported Merchant results, but it cannot physically inspect the item or verify a refurbishment process.

Will correcting condition guarantee approval?

No. Other product-data, website, policy or account issues can still affect eligibility.

Final product condition checklist

Before considering the invalid condition problem resolved, confirm that:

• The correct Merchant account was opened.
• The exact affected offer was identified.
• The Merchant offer ID was recorded.
• The WooCommerce product ID was recorded.
• The variation ID was recorded where applicable.
• The SKU was recorded.
• The GTIN was recorded where applicable.
• The submitted URL was recorded.
• The active product source was identified.
• The target country was recorded.
• The content language was recorded.
• The feed label was recorded.
• The marketing method was recorded.
• The exact Merchant issue was recorded.
• The processed condition was inspected.
• The physical product was inspected.
• The original packaging status was checked.
• Previous use was checked.
• Customer-return status was checked.
• Display or demonstration use was checked.
• Cosmetic wear was checked.
• Missing accessories were checked.
• Product modifications were checked.
• Restoration work was checked.
• The party performing refurbishment was identified.
• Professional restoration was confirmed where applicable.
• Warranty availability was confirmed.
• Warranty terms were publicly available where applicable.
• New products genuinely met new-condition requirements.
• Used products were not incorrectly marked as new.
• Open-box products were not submitted as a separate unsupported value.
• Like-new products were mapped to a supported value.
• Cosmetic grades were mapped to a supported value.
• Refurbished products genuinely met the refurbished definition.
• Unsupported condition labels were removed from the submitted attribute.
• The correct Merchant value was selected.
• The correct Merchant API enum was used.
• CONDITION_UNSPECIFIED was not treated as a fourth condition.
• Condition was not confused with availability.
• Condition was not confused with product status.
• Condition was not confused with return eligibility.
• Condition was not inferred only from price.
• Condition was not inferred only from stock quantity.
• The authoritative WooCommerce field was identified.
• Parent-level condition rules were checked.
• Variation-level condition rules were checked.
• Category-level condition rules were checked.
• Import mappings were checked.
• Supplier data was checked.
• ERP synchronisation was checked.
• Marketplace imports were checked.
• Translated values were checked.
• Locale-dependent mappings were checked.
• The public product title was reviewed.
• The short description was reviewed.
• The long description was reviewed.
• Visible condition information was accurate.
• Packaging information was accurate.
• Included accessories were disclosed.
• Cosmetic defects were disclosed.
• Warranty information was accurate.
• The exact variation appeared on the landing page.
• Product structured data was inspected.
• itemCondition matched the actual product.
• Duplicate Product schema was checked.
• Cached schema was refreshed where applicable.
• Every active Merchant data source was identified.
• Old feeds were checked.
• Supplemental sources were checked.
• Automatic website sources were checked.
• Previous WooCommerce integrations were checked.
• No source could restore an inaccurate condition.
• The corrected WooCommerce product was saved.
• The corrected variation was saved.
• Applicable caches exposed the correction.
• The correct product was submitted.
• The operation result was recorded.
• The processed Merchant product was reopened.
• The processed condition was checked.
• Target-country status was reviewed.
• Marketing-method status was reviewed.
• Needs attention issues were reviewed.
• Processing time was allowed.
• The correction remained stable after scheduled synchronisation.
• No approval or performance guarantee was assumed.

An invalid product condition error should not be corrected by selecting the most convenient value.

The merchant must determine whether the exact WooCommerce offer is genuinely new, used or professionally refurbished.

Factory-sealed products that meet the applicable new-condition requirements can use new.

Previously used products, open-box products, display items, customer returns with opened packaging and products described through cosmetic grades normally use used.

Products professionally restored to working order and supplied with a warranty can use refurbished.

Detailed customer-facing descriptions such as “open box,” “like new,” “Grade A” and “display item” can remain on the product page, but they must be mapped to one of Google’s supported condition values.

WooCommerce, the submitted Merchant product, the visible landing page and Product structured data should all represent the same real item.

PW Merchant API can support controlled product communication, variation identity, supported attribute preparation, operation results and applicable issue visibility. It cannot inspect the physical item, verify professional refurbishment or guarantee Google approval.

Accurate condition information protects customers from receiving a product different from the one they expected.

It also provides Merchant Center with a consistent description of the offer across the complete WooCommerce purchasing journey.