WooCommerce Price Not Updating? Check the Storefront
Follow one WooCommerce item from its saved price to the public product page and a fresh cart. A practical checklist for variations, sales, caching, and mobile verification.
You changed a WooCommerce price, clicked Update, and opened the product page. The old number is still there. Before you edit the product again, find out which number you are looking at: the saved regular price, an active sale price, a different variation, or a previously generated copy of the page.
The quickest useful check follows one item through the store. Match its SKU and selected options, reopen its saved price fields, then compare the ordinary public product URL with a fresh cart. That sequence gives you evidence for the next change.
Write down one expected result
Suppose a US store sells a blue 12-ounce mug under SKU MUG-BLU-12. Its regular price is changing from $24 to $28. There is also a larger mug and a separate white variation. These products and amounts are an illustrative example, not a customer case study.
Before troubleshooting, write: “The blue 12-ounce mug should show $28 when no sale or customer-specific discount applies.” Record the product URL, variation ID if applicable, currency, and time checked. Keep a screenshot of the unexpected price and the selected options. A cropped image of “$24” alone leaves too many possible explanations.
For the first pass, use quantity one and an empty cart. Keep the same currency and customer context throughout. If the store changes prices for a customer group, country, or currency, record that condition before comparing results.
1. Reopen the saved product
Go back to the product editor after saving. Confirm that the expected value is still present. In the standard editor, simple products have regular and sale price fields under Product data > General; variable products have prices inside their individual variations. WooCommerce documents these locations in its product editor reference.
If the blue mug still has $24 in its saved regular price field, you have found a data problem before reaching the storefront. Check the product identity and whether the original update completed. Capture any save error. If the value initially saves as $28 and later returns to $24, note when that happens and review any connected import or pricing process with the person responsible for it.
A cache refresh cannot repair a value that was never saved. Correct the intended record first, then reopen it once more. For a batch update, keep the affected SKUs and their before-and-after values so that one missed item does not get lost inside a “completed” message.
2. Select the exact variation
WooCommerce variations can have their own regular price and sale price. Updating one size or color does not establish the price of every other combination. The official variable product guide explains the variation-level fields.
In our example, select blue and 12 ounces on the public page before reading the price. Then match that selection to MUG-BLU-12 in the editor. Do the same in the cart: read the options attached to the line item. A parent product title such as “Ceramic Mug” is not enough to identify which mug you tested.
If only the larger mug has $28 saved, update the intended variant through the normal product workflow. Avoid changing every variation simply to make the page look consistent. Different sizes may deliberately have different prices.
3. Check whether a sale explains the difference
A regular price and a sale price answer different questions. Imagine the mug now has a $28 regular price and an active $20 sale price. Seeing $20 as the selling price can be correct even though the regular-price update succeeded.
Inspect the sale field and any start or end dates alongside the regular price. WooCommerce’s product editor supports scheduled sale dates. Confirm what the promotion is supposed to do before removing it. If the intention was to raise the regular price while keeping the sale running, deleting the sale would change the offer.
For the rest of this example, assume there is no active sale. The saved regular price for MUG-BLU-12 is $28, the intended public selling price is $28, and you have selected the matching variant. If the public page still shows $24, investigate how that page is being served.
4. Compare the public page and its cache layers
Open the product’s normal URL in a fresh private browser session. Use the address customers receive, without preview parameters or an added cache-busting query string. A private window gives you a separate browser session; it does not guarantee a fresh response from the host or CDN.
Compare that result with the page you saw while signed in to WordPress. If one shows $28 and the other shows $24, record both results. The difference is a clue about the request being served, not proof that a particular plugin is responsible.
Check which caching services the store actually uses. A WordPress page-cache plugin, hosting cache, and CDN can each need attention. Follow the installed service’s documentation and refresh the affected product URL at the relevant layer. Include a shop or category page if its product card also shows the old price.
For example, WP Rocket documents partial cache clearing when content changes, including clearing the parent product when a variation is saved. That is expected behavior for that plugin, not evidence that every copy served by your hosting stack has refreshed.
If your configuration caches the page at Cloudflare, its single-file purge documentation describes clearing a URL and explains limitations for custom cache keys. Use the final product URL, and have the site administrator check the cache-key configuration if a targeted purge does not reach the stale copy.
Reload the ordinary public URL after each relevant action and record the result. Refreshing every cache at once can make it harder to establish which layer was stale. If the discrepancy persists, share the URL, timestamps, saved fields, and screenshots with your host or developer before attempting broader repairs.
5. Check a fresh cart and the mobile page
Add the same blue 12-ounce mug to an empty cart in the fresh session. Confirm quantity one and the selected options. Compare the item amount on the same basis, accounting for any displayed discounts or tax treatment. The final order total can also include shipping and other charges, so it is a poor substitute for checking the product line.
Open checkout far enough to inspect the item and pricing breakdown. You do not need to place or pay for an order to complete this price-display check. If the product page is correct but the cart behaves differently, preserve the evidence and investigate the cart or pricing configuration.
WooCommerce’s caching guidance says Cart, Checkout, and My Account need to remain dynamic because they contain customer-specific information. Review the relevant exclusions with whoever manages the cache. Avoid treating a stale cart as a reason to rewrite the product’s price again.
Repeat the product selection and cart check on a phone or a mobile browser test environment. Confirm that the options are visible and usable, the price is readable, and the selected item reaches the cart. Record which device and session you checked; a desktop screenshot cannot establish what happened on mobile.
Keep a short record of the mismatch
This small worksheet helps you hand the problem to a teammate without asking them to start over. Fill it with observations from your store.
| Checkpoint | What to record |
|---|---|
| Saved product | Product or variation ID, SKU, regular price, sale price, sale dates |
| Public product page | Normal URL, selected options, displayed amount, currency, session, time |
| Cart and checkout | Matching item and quantity, item amount, discounts and other adjustments |
| After a repair | Exact action taken, desktop result, mobile result, any remaining mismatch |
If the saved price is wrong, return to the product update. If the saved price is right but the public page is old, examine the rendered page and caching path. If only the cart differs, investigate the selected item and the rules applied there. These are starting points for diagnosis, not a claim that every store has the same cause.
Where Niwa can help with the check
With the appropriate WooCommerce tools and permissions, Niwa can inspect supported product data, prepare a focused price change, and read back the saved result. The WooCommerce automations overview describes that scope. The Niwa operator workflow also emphasizes checking the available tools before acting.
A useful first instruction for this example is:
Inspect MUG-BLU-12 and identify its product and variation IDs. Report the saved regular price, sale price, and any sale dates available through the connected tools. Compare them with the intended $28 regular price. Start with inspection and report any field you cannot verify.
Once the cause is understood, specify the exact correction and review its scope. Ask for the saved values afterward, together with the checks actually completed. Public browser testing and host or CDN cache actions require the corresponding access and tools; a product-data readback alone cannot confirm them.
For a walkthrough, bring one product to a Niwa demo and ask to follow it from the editor to the shopper’s cart. The useful finish is a recorded result for that item, with any unresolved difference clearly identified.
