How to fix WooCommerce sale price errors in Google Merchant Center

How to fix WooCommerce sale price errors in Google Merchant Center

A WooCommerce sale may look correct inside the WordPress administration panel but still create an error, warning or missing sale annotation in Google Merchant Center.

The product page may display a discounted price while Google receives only the regular price. A scheduled WooCommerce sale may begin at midnight in the store’s timezone while the submitted sale period begins several hours earlier or later. A variable product may show a sale on its parent page even though one or more submitted variations do not have a valid sale price.

These situations can lead to mismatched prices, missing sale information, discarded strikethrough prices, automatic item updates or product disapprovals.

Fixing WooCommerce sale price errors requires more than entering a lower amount in the Sale price field. The regular price, active sale price, sale period, currency, product variation, structured data, landing page and checkout must describe the same offer at the same moment.

Google’s official sale price specification requires the original price to remain available in the price attribute when a separate sale_price is submitted. The sale price should be lower than the original price and should appear clearly on the product landing page.

The short answer

To fix WooCommerce sale price errors in Google Merchant Center:

• Identify the affected offer IDs and issue names.
• Match every offer to the correct WooCommerce product or variation.
• Confirm the WooCommerce regular price.
• Confirm that the sale price is lower than the regular price.
• Check whether the sale is currently active in WooCommerce.
• Review the sale start date, end date and website timezone.
• Confirm that the submitted price contains the original price.
• Confirm that the submitted sale_price contains the active discounted price.
• Submit a valid sale_price_effective_date when the sale has a defined period.
• Use the same currency for the regular and sale prices.
• Open the exact public landing page while logged out.
• Confirm that the active sale price is the most prominent price.
• Confirm that the original price is displayed as inactive or struck through.
• Inspect Product and Offer structured data.
• Test the cart and checkout.
• Check every affected WooCommerce variation separately.
• Review coupons, dynamic-pricing plugins and customer-role discounts.
• Purge page, object and CDN caches.
• Identify duplicate or competing product sources.
• Resynchronise the corrected product through the authoritative integration.
• Inspect the processed product in Merchant Center.
• Check the product again after the next scheduled operation.

An accepted Merchant API operation does not by itself prove that the sale price issue is resolved. Google still processes the submitted input, combines applicable data sources, crawls the landing page and evaluates the final product.

What are the Google Merchant sale price fields?

Google separates the ordinary product price from the temporary sale price.

The main fields are:

• price: The product’s original or normal price.
• sale_price: The lower price charged while the sale is active.
• sale_price_effective_date: The period during which the submitted sale price applies.

A correct example is:

• Regular price: 100.00 EUR
• Sale price: 80.00 EUR
• Sale period: 1 August through 15 August

While the sale is active, the landing page should make 80.00 EUR the current and most prominent price. The original 100.00 EUR price may remain visible as a struck-through or less prominent price.

Google’s sale price annotation guidance explains that the original price should continue to be submitted through price while the discounted amount is supplied through sale_price.

Incorrect examples include:

• Regular price: 100.00 EUR
• Sale price: 110.00 EUR

The supposed sale price is higher than the regular price.

Another incorrect example is:

• Regular price: 100.00 EUR
• Sale price: 80.00 USD

The amounts represent the same product but use different currencies.

A timing error could contain:

• WooCommerce sale starts: 10 August
• Submitted sale starts: 1 August
• Landing page on 5 August: 100.00 EUR
• Merchant Center on 5 August: 80.00 EUR

The individual values may be valid, but they are not active during the same period.

What does sale_price_effective_date do?

The sale_price_effective_date field tells Google when the sale price should apply.

Google uses an ISO 8601 date range consisting of a start and end time separated by a slash. A timezone or UTC indicator should be included.

A simplified example is:

2026-08-01T00:00+0300/2026-08-15T23:59+0300

Google’s sale price effective date documentation states that the attribute should be used together with sale_price. If no effective date is supplied, Google may treat the submitted sale price as continuously applicable.

This creates an important distinction:

• A sale price without an effective date is not necessarily invalid.
• A scheduled WooCommerce sale with missing effective dates can become inaccurate before or after the actual promotion.
• A sale period with the wrong timezone can activate or deactivate at the wrong moment.

The start date must be earlier than the end date. The date range should represent the period during which customers can actually purchase the product at the sale price.

Do not use an expired sale period while continuing to send the discounted price. Do not send a future sale price as active before it appears on the public product page.

How WooCommerce stores sale prices

A standard WooCommerce product can contain:

• Current price
• Regular price
• Sale price
• Sale start date
• Sale end date
• Website timezone
• On-sale status
• Purchasable status

WooCommerce’s official product API documentation distinguishes between regular_price, sale_price, date_on_sale_from, date_on_sale_to and the read-only current price. It also provides local-time and GMT versions of scheduled sale dates. WooCommerce product API documentation

This distinction matters because the current WooCommerce price is contextual.

Before the sale:

• Regular price: 100
• Sale price: 80
• Current active price: 100

During the sale:

• Regular price: 100
• Sale price: 80
• Current active price: 80

After the sale:

• Regular price: 100
• Stored sale price may still be 80
• Current active price: 100

An integration should not assume that a populated sale-price field always represents the current price. It must also determine whether the scheduled sale is active.

Sale price errors and general price mismatches are different

A general price mismatch can occur without a sale.

Example:

• WooCommerce price: 100 EUR
• Submitted price: 120 EUR

A sale price error specifically involves the relationship between the ordinary price, discounted price or sale period.

Example:

• WooCommerce regular price: 100 EUR
• WooCommerce active sale price: 80 EUR
• Submitted price: 100 EUR
• Submitted sale price: missing

Another sale-specific error is:

• Submitted price: 100 EUR
• Submitted sale price: 80 EUR
• Landing-page sale price: 75 EUR

The sale exists in both places, but the discounted amounts differ.

For a broader price inconsistency, see how to fix price mismatch in Google Merchant Center for WooCommerce.

For currency-specific conflicts, see how to fix inconsistent currency errors in Google Merchant Center for WooCommerce.

Common WooCommerce sale price errors

The sale price is higher than the regular price

Google expects the sale price to be lower than the original product price.

Incorrect:

• Regular price: 90.00 USD
• Sale price: 100.00 USD

Correct:

• Regular price: 100.00 USD
• Sale price: 90.00 USD

This problem can be caused by:

• Manual data-entry mistakes
• Bulk editing
• Supplier imports
• Currency conversion
• Rounding rules
• Variation-level pricing
• Scheduled regular-price changes
• Dynamic-pricing plugins
• Incorrect API field mapping

Check the stored values, the current WooCommerce price, the public product page and the submitted product data.

The sale price equals the regular price

A sale price equal to the regular price does not represent a discount.

Example:

• Regular price: 100.00 EUR
• Sale price: 100.00 EUR

WooCommerce may accept or store the values, but Google has no meaningful difference to present as a sale.

Remove the unnecessary sale price or enter a genuine lower amount.

The sale price is zero

A zero sale price may represent a legitimate free product in a limited number of business models, but it often indicates:

• An empty value converted into zero
• A failed import
• A decimal parsing error
• An incomplete variation
• A percentage calculation mistake
• A missing supplier price
• A currency conversion failure

Do not automatically submit a zero value as a sale price. Confirm whether customers can genuinely purchase the exact product for zero at checkout and whether the intended destination supports that commercial offer.

The sale price uses another currency

The regular price and sale price must use the same currency.

Incorrect:

• Regular price: 100 EUR
• Sale price: 80 USD

Changing only the currency code is not a safe correction. The amount may also need controlled conversion.

If the WooCommerce store operates in EUR, its regular price, active sale price, landing page and checkout should normally describe the same EUR offer.

The sale price is active in WooCommerce but missing from Google

This can happen when:

• The integration reads only the regular-price field.
• A scheduled operation ran before the sale became active.
• The sale was activated after the product was last synchronised.
• A product update failed.
• A data-source rule removed the sale price.
• The integration treated the sale as inactive.
• Another source overwrote the submitted value.
• A variable product’s parent price was read instead of the variation price.
• The sale-price value was empty at the moment the product was processed.

Confirm the operation timestamp and compare it with the exact sale start time.

The sale ended in WooCommerce but remains active in Google

This is a frequent scheduled-sale problem.

Possible causes include:

• The end-of-sale update was never sent.
• WordPress scheduled events did not run as expected.
• The product was cached.
• The sale period was omitted from the submitted data.
• The submitted end time used the wrong timezone.
• A supplemental source reintroduced the old sale.
• A failed API operation was not noticed.
• The product source updates less frequently than the sale schedule.

When a sale ends, Google should receive the corrected commercial state. This may involve removing the sale price and its effective period or updating the product so the ordinary price becomes current again.

The sale dates are reversed

A sale cannot end before it starts.

Incorrect:

2026-08-20T00:00+0300/2026-08-10T23:59+0300

The start date is 20 August, but the end date is 10 August.

Review manual mappings, imported dates and date-format conversions.

The timezone is wrong

WooCommerce sale dates may be stored and exposed using the site’s configured timezone and corresponding GMT values.

Google’s date range should include a clear timezone.

A store in Europe/Istanbul could schedule a sale for local midnight. If an integration interprets that value as UTC without conversion, the Google sale could begin or end three hours later than intended during a UTC+3 period.

Review:

• WordPress timezone
• WooCommerce local sale dates
• GMT sale dates
• Server timezone
• PHP timezone
• Integration timezone
• Merchant API timestamps
• Customer-facing sale activation time

Do not rely on the server timezone alone. The website’s configured commercial timezone should be explicit.

The landing page shows only the regular price

Google may receive a sale price that is not yet visible to customers.

Possible causes include:

• Page cache
• An inactive sale schedule
• Customer-location rules
• Role-based pricing
• A variation that has not been selected
• A theme template that hides the sale price
• A JavaScript pricing error
• A mobile layout problem
• A product add-on that changes the final price

Open the exact submitted URL while logged out and verify the public response.

The landing page shows only the sale price

If price and sale_price are submitted separately, the landing page should clearly communicate both the original price and active discounted price.

Google’s guidance says the active sale price should be the most prominent price, while the original price should be less prominent and may be struck through or greyed out.

A product page that shows only 80 EUR gives Google less evidence that the submitted 100 EUR value represents a genuine original price.

The original struck-through price is wrong

Google can discard a strikethrough price when the original price displayed on the website does not match the submitted price.

For example:

• Submitted original price: 100 EUR
• Submitted sale price: 80 EUR
• Landing-page strikethrough price: 120 EUR
• Landing-page active price: 80 EUR

The active amount matches, but the claimed original amount does not.

Google’s mismatched strikethrough price guidance identifies incorrect original prices, missing sale_price data, dynamically added prices and delayed product updates as common causes.

The sale price changes after a variation is selected

A variable product can show a general price or price range before the customer selects a variation.

After selection, the active variation may have:

• A different regular price
• A different sale price
• A different sale period
• No sale price
• A different currency because of another plugin

The submitted offer must lead to the correct purchasable variation.

For example:

• Small variation: regular 50 EUR, sale 40 EUR
• Medium variation: regular 60 EUR, no sale
• Large variation: regular 70 EUR, sale 55 EUR

These are three distinct offers. Sending a single parent sale price for all variations can create inaccurate product data.

A coupon was submitted as a sale price

A coupon and an unconditional sale price are not always the same commercial offer.

A coupon may require:

• A coupon code
• A minimum order value
• A specific customer account
• First-time customer status
• A selected payment method
• A membership
• A certain product combination
• A minimum quantity

If every customer does not receive the discounted product price directly on the landing page, it should not automatically be submitted as the ordinary sale_price.

Use Google’s appropriate Promotions or loyalty mechanisms when applicable. Do not convert every WooCommerce coupon into a sale price.

A customer-role price was submitted publicly

Wholesale, trade, logged-in, subscriber or employee prices are not ordinary public sale prices.

A crawler visiting without the required role may see the regular public price while the product data contains a restricted discounted price.

Confirm which customers can obtain the submitted price and whether the discount belongs in a supported loyalty or promotional programme.

Dynamic pricing changes the amount in the cart

Some WooCommerce pricing systems apply discounts only after:

• A quantity is selected
• Several products are added
• A category threshold is met
• The cart reaches a minimum total
• A customer logs in
• A coupon is applied

A conditional cart discount should not be presented as an unconditional product sale price unless the product page and submitted offer accurately communicate the conditions through a supported mechanism.

How to diagnose WooCommerce sale price errors

1. Record the exact Merchant Center issue

Start with the affected product in Merchant Center.

Record:

• Issue name
• Offer ID
• Product title
• Product source
• Target country
• Feed label
• Submitted regular price
• Submitted sale price
• Sale effective period
• Detection time
• Page-crawl time
• Affected destination
• Current product status

Issue names may include:

• Mismatched product price
• Missing sale information
• Invalid sale price
• Automatic updates active
• Mismatched strikethrough price
• Inaccurate price
• Missing required attribute
• Unsupported or malformed date value

The exact issue determines which values require comparison.

2. Match the offer to the correct WooCommerce product

Use:

• Offer ID
• WooCommerce product ID
• Variation ID
• SKU
• GTIN
• Product URL
• Item group ID
• Variation attributes

Do not rely only on the product title. Similar variations may have nearly identical names but different prices and sale periods.

3. Identify the authoritative product source

Determine whether the product is managed through:

• PW Merchant API
• Another Merchant API integration
• XML
• CSV
• Google Sheets
• An automated website source
• A supplemental source
• Another WooCommerce plugin
• An ERP
• A supplier import
• Manual Merchant Center editing

A manual Merchant Center correction may be overwritten by the next scheduled WooCommerce operation.

4. Inspect the WooCommerce regular price

Confirm that the regular price:

• Is numeric
• Is not empty
• Uses the intended currency
• Represents the genuine ordinary price
• Matches the public original price
• Matches the submitted price
• Belongs to the correct variation
• Has not been changed during the sale without updating Google

Do not use an artificial reference price solely to create a larger-looking discount.

5. Inspect the WooCommerce sale price

Confirm that the sale price:

• Is numeric
• Is lower than the regular price
• Uses the same currency
• Is available to ordinary customers
• Applies to the correct product or variation
• Appears on the landing page
• Is charged at checkout
• Matches the submitted sale_price

6. Determine whether the sale is active

A populated sale-price field does not prove that the sale is currently active.

Compare the current time with:

• Sale start date
• Sale end date
• WordPress timezone
• WooCommerce local dates
• Stored GMT dates
• Product synchronisation time
• Merchant Center processing time
• Google page-crawl time

Record the state as:

• Future sale
• Active sale
• Expired sale
• Unscheduled continuous sale
• Invalid date range

7. Inspect the submitted product attributes

Compare:

• price
• sale_price
• sale_price_effective_date
• Currency
• Product URL
• Offer ID
• Data source
• Variation information

A correct active sale could be represented conceptually as:

• price: 100.00 EUR
• sale_price: 80.00 EUR
• sale_price_effective_date: Valid current period

Do not replace the original price with 80.00 EUR while also submitting sale_price as 80.00 EUR. The two fields have different purposes.

8. Open the exact public product URL

Test the URL submitted for the affected offer.

Use:

• A logged-out browser
• A private window
• An empty cart
• No remembered currency
• No customer account
• Desktop
• Mobile
• Relevant customer locations

Confirm:

• Current active price
• Original price
• Currency
• Selected variation
• Sale badge
• Sale period
• Add-to-cart button
• Availability

9. Inspect structured data

Review every Product and Offer entity.

Check:

• Active price
• priceCurrency
• Original strikethrough price
• priceType
• validFrom
• validThrough
• priceValidUntil
• Variation URLs
• Availability
• Duplicate offers

Google’s merchant listing structured data documentation explains how the current sale price, original strikethrough price and sale duration can be represented.

A theme and an SEO plugin may both generate Product schema. If their values conflict, Google may find more than one version of the offer.

10. Test the cart and checkout

Add the exact product or variation to the cart.

Confirm:

• Product price
• Quantity
• Discount
• Tax
• Currency
• Shipping
• Cart subtotal
• Order total
• Payment amount

The submitted sale price should normally be obtainable without discovering an unexpected restriction at checkout.

11. Review caches

Clear and test:

• WordPress page cache
• WooCommerce transients
• Object cache
• Server cache
• CDN cache
• Browser cache
• Mobile cache
• Edge cache
• Structured-data cache

Scheduled sales are especially sensitive to stale caches. WooCommerce may activate the sale correctly in the database while a cached product page continues displaying the previous price.

12. Review scheduled operations

Check whether WordPress scheduled events and Merchant operations ran around:

• Sale start
• Sale end
• Regular-price update
• Product import
• Currency update
• Cache purge

A sale that starts or ends between product synchronisations can temporarily create a mismatch.

13. Review competing sources

A WooCommerce Google Merchant Center plugin may submit the correct sale price while another feed or supplemental source changes it later.

Compare all active sources controlling:

• Regular price
• Sale price
• Effective dates
• Currency
• Product URL

There should be a clear owner for every field.

14. Correct the source of truth

Apply the correction where the inaccurate value originates.

Possible corrections include:

• Updating the WooCommerce regular price
• Lowering or removing the sale price
• Correcting sale dates
• Correcting the WordPress timezone
• Fixing a variation price
• Correcting an import rule
• Updating the Merchant API mapping
• Removing an inappropriate coupon mapping
• Purging caches
• Disabling a duplicate product source
• Correcting structured data
• Updating the checkout pricing rule

15. Resynchronise and verify

Send the corrected product through the authoritative integration.

Then verify:

• Operation result
• Submitted product input
• Processed product
• Regular price
• Sale price
• Effective period
• Product issues
• Destination status
• Landing-page result

Allow Google time to process the change before making another unrelated alteration.

Simple WooCommerce products

For a simple product, create a comparison containing:

• Product ID
• SKU
• Regular price
• Stored sale price
• Current active price
• Sale start
• Sale end
• WordPress timezone
• WooCommerce currency
• Submitted price
• Submitted sale_price
• Submitted effective period
• Landing-page price
• Structured-data price
• Cart price
• Checkout price

A simple product is easier to diagnose because there is one primary purchasable offer, but extensions can still introduce conditional pricing.

Variable WooCommerce products

Variable products require offer-level review.

WooCommerce allows individual variations to have their own prices, stock and other product data. WooCommerce variable-product documentation also describes variation-level price and scheduled sale controls.

For each affected variation, compare:

• Parent product ID
• Variation ID
• Variation SKU
• Offer ID
• Item group ID
• Colour
• Size
• Material
• Pattern
• Regular price
• Sale price
• Sale dates
• Currency
• Landing-page selection
• Structured-data Offer
• Checkout result

Do not assume that the lowest value in a price range is the sale price of every variation.

For a complete variation workflow, see how to submit WooCommerce variable products to Google Merchant Center.

Sale schedules and timezone consistency

Scheduled sales commonly fail at their boundaries.

Suppose a WooCommerce store is configured for Europe/Istanbul and a sale should begin at 00:00 on 1 August.

The integration must understand whether the stored value represents:

• Local website time
• UTC
• Server time
• Browser time
• Merchant account time

The submitted Google interval should represent the same real moment.

A reliable process should:

• Use the WordPress-configured timezone as the commercial reference.
• Read local and GMT sale values correctly.
• Convert dates only once.
• Include a timezone or UTC indicator.
• Test sale activation before the campaign begins.
• Schedule a product update near the start.
• Schedule another update when the sale ends.
• Verify the public page after both transitions.

Daylight-saving changes should also be considered for timezones that observe them.

Landing-page price presentation

During an active sale, customers should be able to identify the current payable price without confusion.

A clear presentation could show:

• Original price: 100 EUR, struck through
• Current sale price: 80 EUR, visually prominent
• Sale period: where appropriate
• Tax information: according to the target-country requirements
• Selected variation: clearly identified

Avoid:

• Several competing reference prices
• An unclear “from” price
• A hidden sale price
• A price visible only after login
• A price that changes only after adding to cart
• A struck-through price that does not match price
• A sale price added only through delayed JavaScript
• Different desktop and mobile prices

Google evaluates the purchasable offer, not merely the visual presence of a discount badge.

Structured data and sale prices

The visible page can be correct while structured data remains outdated.

Possible conflicts include:

• Active visible price: 80 EUR
• Structured-data price: 100 EUR

Or:

• Visible currency: EUR
• Structured-data currency: USD

Or:

• Sale ends on 15 August
• Structured-data priceValidUntil: 31 August

Review whether:

• WooCommerce generates the schema.
• The active theme generates another Product entity.
• An SEO plugin generates a separate Offer.
• A schema plugin adds a third version.
• Cached JSON-LD contains the previous price.
• Parent and variation offers are mixed.

Prefer one accurate structured-data source over several conflicting sources.

Taxes and sale prices

Tax settings can create a numerical mismatch even when the underlying sale price is correct.

The website may display prices including tax while the submitted data excludes tax, or the reverse.

Review:

• Store location
• Target country
• Customer location
• Tax-inclusive or tax-exclusive display
• Product-page tax display
• Cart tax display
• Submitted price treatment
• Variation tax class
• Customer-role tax exemptions

The sale price compared by Google should match the amount customers are expected to pay under the applicable price requirements.

Sale prices, coupons and promotions

These concepts should not be combined indiscriminately.

A sale price is generally an immediately available lower product price.

A coupon normally requires an additional customer action or condition.

A Google Merchant promotion is a supplemental offer that may describe a code, percentage discount, free gift or another supported promotional benefit.

A loyalty price may require membership in a defined programme.

Before submitting a WooCommerce discount, ask:

• Does every customer see the price?
• Does every customer qualify?
• Is a code required?
• Is login required?
• Is membership required?
• Is there a minimum quantity?
• Is another product required?
• Does the discount appear before checkout?
• Is the discounted price available on the landing page?

This determines whether the value belongs in sale_price or another supported mechanism.

Merchant API sale price representation

Merchant API product attributes include:

• price
• salePrice
• salePriceEffectiveDate

Google defines salePrice as the advertised sale price and salePriceEffectiveDate as the interval during which the product is on sale. Merchant API ProductAttributes reference

The integration must map the complete WooCommerce commercial state rather than copying one database field without context.

A reliable mapping should determine:

• The regular product price
• Whether a sale price exists
• Whether the sale is active
• The sale start time
• The sale end time
• The correct currency
• The correct product variation
• The exact landing-page URL

Common Merchant API implementation mistakes include:

• Mapping the active WooCommerce price to both price and salePrice
• Sending the stored sale price after it expires
• Omitting the regular price
• Sending a sale price higher than the regular price
• Converting the amount without updating the currency
• Applying timezone conversion twice
• Using the parent product’s sale price for every variation
• Retaining a previous effective-date interval
• Reading a formatted HTML price instead of numerical values
• Sending an empty value as zero
• Updating the sale price but not the effective date
• Removing the date while retaining a future sale price

After updates, inspect the processed product rather than relying only on the outgoing request.

Automatic item updates

Google can use landing-page information to address certain temporary price or availability differences.

Automatic item updates can reduce the immediate effect of some mismatches, but they are not a replacement for accurate product data.

If Google repeatedly changes a submitted price automatically, treat that as evidence of an unresolved source problem.

Check:

• Which value Google detected
• Which value the integration submitted
• The page-crawl timestamp
• Whether the sale was active at that moment
• Whether structured data matched the visible page
• Whether another source later restored the incorrect value

Correct WooCommerce or the authoritative mapping rather than relying permanently on Google to repair every price.

Sale price annotations are not guaranteed

A correct sale price and an eligible sale annotation are related but different outcomes.

A product can contain technically valid sale-price information without receiving a visible annotation.

Google evaluates additional factors for annotations, including:

• Whether the sale price is lower than the base price
• Discount range
• Base-price history
• Target country
• Destination
• Landing-page presentation
• Data quality

Google’s current sale price annotation requirements vary by country and destination. Google also states that annotations are not guaranteed even when stated requirements are met.

Therefore:

• A missing annotation does not always mean the sale price is invalid.
• A valid-looking discount does not guarantee an annotation.
• Changing prices repeatedly to force an annotation can damage consistency.
• Google independently decides which annotations appear.

Focus first on accurate product data and customer experience.

Correcting sale prices across a large catalogue

For a large WooCommerce store, create an audit table containing:

• Offer ID
• Product ID
• Variation ID
• SKU
• Data source
• Regular price
• Sale price
• Currency
• Sale start
• Sale end
• WooCommerce active price
• Landing-page price
• Structured-data price
• Checkout price
• Merchant Center price
• Merchant Center sale price
• Detected issue
• Root cause
• Correction
• Synchronisation result
• Final status
• Verification time

Group products by root cause:

• Sale price greater than regular price
• Equal regular and sale prices
• Zero sale price
• Missing sale price
• Expired sale
• Future sale sent too early
• Wrong timezone
• Variation mismatch
• Tax mismatch
• Currency mismatch
• Coupon incorrectly mapped
• Dynamic-pricing conflict
• Structured-data conflict
• Cache problem
• Duplicate source
• Failed scheduled update
• Import overwrite
• Merchant API mapping problem

Test a representative group before updating the entire catalogue.

A shared timezone or mapping correction may resolve thousands of products. Editing each product manually would be inefficient and could introduce additional mistakes.

How PW Merchant API fits into sale price management

PW Merchant API is designed to support controlled WooCommerce and Google Merchant API product operations.

Depending on the installed version and supported configuration, it can help users:

• Read supported WooCommerce product information.
• Work with simple and variable products.
• Prepare supported regular and sale-price data.
• Send new products.
• Update existing products.
• Plan catalogue operations.
• Review successful and unsuccessful operations.
• Identify products requiring attention.
• Maintain a more organised product-management workflow.

As a WooCommerce Google Merchant Center plugin, PW Merchant API can help communicate supported WooCommerce price information through an API-based process.

However, it cannot independently determine every merchant’s intended discount strategy.

PW Merchant API cannot:

• Decide whether a sale price is commercially genuine.
• Correct an unrelated dynamic-pricing plugin automatically.
• Control another active product source.
• Guarantee that WordPress scheduled events run correctly.
• Correct conflicting theme schema automatically.
• Decide whether a coupon should become a sale price.
• Prevent supplier imports from overwriting WooCommerce.
• Guarantee sale price annotations.
• Guarantee product approval.
• Guarantee Shopping visibility, clicks or sales.
• Change Google’s independent processing or policy decisions.

WooCommerce remains the commercial source of product data, PW Merchant API manages supported communication, and Google Merchant Center independently processes and evaluates the submitted information.

Common sale price correction mistakes

Changing only Merchant Center

The next WooCommerce synchronisation can restore the original error.

Removing the regular price

A separate sale price does not replace the need to provide the original price.

Keeping an expired sale price

A stored WooCommerce sale value may remain present even after the active sale period ends.

Ignoring timezones

A correct date with the wrong timezone can still activate at the wrong moment.

Testing while logged in

Administrator accounts may receive special pricing, bypass caches or use remembered currency settings.

Treating coupons as ordinary sale prices

A conditional discount is not automatically the public product price.

Using the parent product’s lowest price

The lowest variation price does not describe every variation.

Ignoring checkout

The product page may show the discount while the cart uses the regular price.

Ignoring structured data

The visible page may show the correct sale while JSON-LD reports an old value.

Assuming automatic updates are a permanent fix

Automatic item updates do not remove the need for accurate source data.

Expecting a guaranteed sale badge

Google independently determines annotation eligibility and display.

Updating the entire catalogue without a test

A faulty percentage or currency rule can affect every product.

Frequently asked questions

Why is my WooCommerce sale price not showing in Google Merchant Center?

The product may not have been resynchronised after the sale began, the sale may not be active, the submitted sale_price may be missing, the update may have failed or another source may have overwritten it.

Should the regular price remain in Merchant Center during a sale?

Yes. When you submit a separate sale_price, continue submitting the original product price through price.

Must the sale price be lower than the regular price?

Yes. A sale price should represent a genuine reduction from the original price.

Can the regular and sale prices use different currencies?

No. They describe the same product offer and should use the same currency.

Is sale_price_effective_date required?

It is used to define the sale period. Without it, Google may treat the submitted sale price as continuously applicable. Scheduled WooCommerce sales should therefore be mapped carefully.

Why does my WooCommerce sale begin at a different time in Google?

The WordPress timezone, server timezone, UTC conversion or submitted timezone offset may not match.

Can I submit a future WooCommerce sale before it begins?

The sale and its effective period can be prepared, but the data, timing and landing page must remain consistent. The future sale should not appear as the current payable price before it becomes active.

Why does Google show my regular price instead of the sale price?

The sale may be inactive, invalid, missing, expired or inconsistent with the landing page. Google may also still be processing the latest update.

Why did Google remove my strikethrough price?

The original price shown on the landing page may not match the submitted price, the sale_price may be missing or the relevant price may have been added dynamically after the page loaded.

Does a coupon count as a sale price?

Not automatically. A coupon can require a code, minimum order or another condition. Use the appropriate supported mechanism for the actual offer.

Can customer-role pricing be submitted as sale_price?

A restricted wholesale or member price should not be represented as an ordinary public sale price unless it meets the relevant programme and landing-page requirements.

Do variable products need separate sale prices?

Each submitted variation should contain accurate pricing for that exact purchasable offer. Variations may have different regular prices, sale prices and sale schedules.

Can structured data cause a sale price mismatch?

Yes. An outdated or duplicated Product or Offer entity can report a price that conflicts with the visible page and submitted product data.

Should I enable automatic item updates?

They can help with temporary mismatches, but they should not replace regular and accurate WooCommerce product updates.

Does a valid sale price guarantee a Google sale annotation?

No. Google applies additional country, destination, discount and price-history requirements and does not guarantee that an annotation will appear.

Does an accepted Merchant API update mean the issue is fixed?

No. Google must still process the input, merge sources, crawl the landing page and evaluate the final product.

How long will the correction take?

Processing time varies. Check the operation result, processed product and Needs attention area rather than repeatedly changing a verified configuration.

Can another plugin restore the wrong sale price?

Yes. Another WooCommerce integration, XML source, supplier import, ERP, supplemental source or automated rule can overwrite the correction.

Does PW Merchant API guarantee sale price approval?

No. It supports applicable product-management and communication processes, while Google independently evaluates the product.

Final checklist

Before considering a WooCommerce sale price error resolved, confirm that:

• The exact Merchant Center issue was recorded.
• Every affected offer ID was identified.
• Each offer was matched to the correct WooCommerce product.
• The correct variation was identified.
• The authoritative product source is known.
• Competing product sources were reviewed.
• The WooCommerce regular price is valid.
• The regular price represents the genuine ordinary price.
• The sale price is numeric.
• The sale price is lower than the regular price.
• The sale price is not unintentionally zero.
• The regular and sale prices use the same currency.
• The sale is available to ordinary customers.
• The sale start date is correct.
• The sale end date is correct.
• The start date occurs before the end date.
• The WordPress timezone is correct.
• Local and GMT dates were interpreted correctly.
• The server timezone did not change the intended period.
• The submitted price contains the original price.
• The submitted sale_price contains the active discounted price.
• The submitted effective period matches WooCommerce.
• An expired sale is no longer sent as active.
• A future sale is not shown prematurely.
• The public landing page was opened while logged out.
• The active sale price is the most prominent price.
• The original price is less prominent or struck through.
• The strikethrough price matches the submitted price.
• The selected variation displays the correct price.
• Desktop presentation was checked.
• Mobile presentation was checked.
• Customer-location behaviour was tested.
• Currency-switcher behaviour was tested.
• Structured Product data was inspected.
• Structured Offer data was inspected.
• Duplicate schema output was reviewed.
• The structured-data price matches the active price.
• The structured-data currency is correct.
• Structured sale dates were reviewed.
• The product was added to the cart.
• The cart uses the sale price.
• Tax treatment is correct.
• Checkout uses the sale price.
• The payment amount is correct.
• Coupons were not incorrectly mapped as public sale prices.
• Customer-role discounts were reviewed.
• Dynamic-pricing rules were reviewed.
• Minimum quantities were reviewed.
• Product bundles were reviewed where applicable.
• Page caches were purged.
• Object caches were purged.
• CDN caches were purged.
• WooCommerce transients were reviewed.
• WordPress scheduled events were checked.
• Sale-start operations were checked.
• Sale-end operations were checked.
• Supplier imports were reviewed.
• ERP updates were reviewed.
• The Merchant API mapping was checked.
• Parent and variation values were not mixed.
• Empty values were not converted into zero.
• Currency conversion was not applied twice.
• The corrected product was resynchronised.
• The operation result was inspected.
• The processed product was inspected.
• Google was allowed time to process the update.
• The Needs attention area was checked again.
• Automatic item updates were not treated as the permanent solution.
• A later scheduled operation did not restore the error.
• A representative product group was tested before a bulk update.
• The final sale-price configuration was documented.

A WooCommerce sale price error is not merely a discounted-number problem. It is a consistency problem involving the ordinary price, active sale price, sale period, currency, variation, landing page, structured data and checkout.

The most reliable correction begins with the exact affected offer, identifies the authoritative data source, verifies whether the WooCommerce sale is genuinely active and compares every price-bearing layer of the purchasing process.

When WooCommerce, the landing page, structured data, PW Merchant API and Google Merchant Center describe the same sale at the same time, sale-price errors are less likely to return and customers receive a clearer, more trustworthy offer.