WooCommerce Variation Prices Not Displaying: Diagnosis Workflow

A variation price disappearing on a WooCommerce product page is one of those bugs that makes a store owner assume the whole plugin has broken. It hasn't. WooCommerce is actually doing its job, mostly. The problem lives in one of three layers, and until you know which one, every fix you try is just a guess.

So this post isn't a list of things to try and hope. It's a way to find the layer that's actually broken.

The Three Layers Where Variation Prices Break

Since WooCommerce 3.0, variation data including price gets pulled through REST endpoints on the front end every time a shopper picks an option, according to WooCommerce's REST API documentation. That one design choice is why this bug shows up so often and confuses so many people.

That price has to survive three separate systems before it lands on the page: the database and hooks layer that calculates it, the caching layer that stores it for speed, and the JavaScript layer that renders it. Any one of these can fail quietly while the other two keep working fine. That's exactly why "just clear the cache" fixes it for one person and does nothing for the next.

Most troubleshooting guides tell you to clear cache or deactivate plugins one by one. That treats the symptom. It never tells you which layer actually broke, so you end up repeating steps that already didn't work.

Step 1: Check the Browser Console and REST Endpoint

Start here. Always. Open the product page, pick a variation, and open your browser's developer console. Watch what happens the moment the price should update.

If you see a request to something like /wp-json/wc/v3/products/{id}/variations come back with a 500 error, you've found your layer. That failure means a plugin hook threw an exception somewhere in the pricing calculation. WooCommerce's own frontend script depends on that call succeeding, and when it doesn't, the variation JavaScript has nothing to work with. No error banner, no warning. The customer just sees a price that never changes.

Check your server error log next, usually /wp-content/debug.log if WP_DEBUG is on. The exception name in that log will almost always point straight at the plugin or function responsible.

If the REST call succeeds and the price still doesn't show, stop looking at the API. Your problem is downstream, in caching or display, and chasing hooks from here just burns time.

Step 2: Inspect Transients and Database Caching

WooCommerce caches variation prices as transients in wp_options for speed. You can confirm this directly in the WC_Product source code. If a cron job fails or transient cleanup breaks, those cached prices sit stale for hours, sometimes longer than that.

Check this yourself with a query against your database:

SELECT option_name FROM wp_options WHERE option_name LIKE '%transient%wc_product%'

Back up your database before touching anything here. Test the delete on staging first if you can. Once you're confident, remove the suspicious rows and reload the product page. If the price is correct now, you've confirmed the layer.

If it drifts stale again within a few hours, the transient was never your real problem. Your cron is. Check WP-Cron or whatever your host runs, because something isn't refreshing that cache on schedule.

Step 3: Audit Active Pricing Plugins for Hook Conflicts

This is where I spend most of my time on real projects, and it's the layer most articles on this topic skip entirely.

Custom pricing, subscription, and dynamic pricing plugins commonly hook into woocommerce_product_get_price or woocommerce_variation_prices_array. WooCommerce's own developer docs are blunt about this: custom pricing hooks have to respect WooCommerce's variation structure, or they cause exactly the display mismatch you're chasing right now.

Deactivate your pricing-related plugins one at a time and reload the page after each one. Don't uninstall anything yet, you're diagnosing, not removing. If the price comes back after deactivating one specific plugin, you've found your culprit.

Then look at what that hook actually does. A common bug: the plugin returns a price fine for simple products but returns null, or ignores the request entirely, for variations. WooCommerce's hooks reference is clear that pricing filters need to account for product type, and a lot of plugins out there were only ever tested against simple products.

I've run into this exact pattern on custom WooCommerce builds with layered pricing logic. It's rarely that the plugin is broken outright. It's that nobody taught it how to handle variations the way WooCommerce's own API expects. If you're building or reviewing a custom WooCommerce plugin yourself, this is the exact spot to test before you ship it.

Step 4: Clear Caching Layers (Page and Object Cache)

If the API is healthy and the hooks check out, look at caching on its own, separate from the transients you already checked in step two.

Page cache, whether that's Cloudflare, WP Super Cache, or an Nginx layer, and object cache like Redis or Memcached can each serve a stale price independently, according to WooCommerce's caching configuration guide. Back up your cache configuration before flushing anything in production. Test on staging first if you're not sure how your host has things wired.

Purge the actual product URL directly in your page caching service, not just through a WordPress cache-clearing plugin, since those often don't reach a CDN-level cache. For object cache, flushing from the command line (redis-cli FLUSHALL or the Memcached equivalent) will clear it, but talk to your host first if you're not comfortable in a terminal.

If the price is correct right after flushing but goes stale again within hours, caching was never your root cause. It's a symptom of the hook or transient problem sitting upstream.

When It's Not the Variation API: Display Logic and CSS

Sometimes the price is sitting right there in the HTML. Just invisible. Inspect the page source. If a .price or .variation-price element exists with the right number inside it but nothing shows on screen, you're looking at a CSS problem, not a data problem.

WooCommerce's own product page customization guide points out that theme edits can accidentally hide pricing elements with something as simple as display: none or a text color that matches the background. Child themes are the usual source. Search your theme and child theme CSS for .price, .variation-price, or .woocommerce-price-amount and see what's overriding them.

This is the fastest check on the whole list, and the one people skip most. Price missing from the HTML entirely means it's the API or hooks. Price present but invisible means it's this.

Where This Usually Leaves You

Across the WooCommerce stores I've built and maintained, most variation pricing bugs come down to one of two things: a pricing hook that never accounted for variable products, or a caching layer going stale for reasons nobody's watching. Neither requires tearing your setup apart. Both just require finding the layer first.

If you're dealing with more than pricing plugins, API integration mistakes follow a similar shape: a failure that's silent right up until a customer notices. And if the plugin update that broke this also crashed something else on the site, that's a different but related root cause worth ruling out too.

If none of these four steps surface the layer, get a second set of eyes on the hook chain directly. That's the kind of e-commerce debugging I do for stores that have outgrown generic advice.

FAQs

Is it safe to clear all WooCommerce transients at once?

Yes. Transients are cache, not source data. Clearing them just forces WooCommerce to recalculate prices on the next page load. Run the delete query above, or use a plugin like Transient Manager if you'd rather not touch the database directly.

If REST calls fail, do I need to rebuild WooCommerce?

No. Find the exception name in your error log, trace it to the plugin or hook throwing it, and fix or disable that specific piece. Almost all of these 500 errors are fixable