Skip to content
WP Visibility

WooCommerce SEO guide

Fix a WooCommerce Price Mismatch in Google Product Results

Trace a wrong price through the product page, the selected variation, tax display, structured data, caches, and your Merchant Center feed, and fix the source that is wrong.

Published

On this page

When Google shows a different price from your WooCommerce store, find out which of four values disagrees before changing any setting: the price a logged-out visitor sees, the price in the page’s structured data, the price in your Merchant Center feed (if you use one), and the price Google displays. Five causes are worth ruling out in turn: tax display, a selected variation, a sale schedule, a cached page, and a feed that updates on a different timetable. Fix the source, then ask Google to recheck.

Understand how Google compares prices

Google’s Merchant Center help on mismatched product prices, checked September 27, 2026, says Google crawls landing pages and compares “the price [price] attribute in your data source with the prices on your landing page or in your structured data markup (if implemented).” It lists causes including “time differences between updates on your website and Merchant Center product data,” “structured data markup on your website is incorrect,” and “price shown to users is different to the price crawled by bots.” It also covers sale prices, where the sale’s effective dates must be set correctly.

For the structured data itself, Google’s merchant listing documentation, checked September 27, 2026, defines price as “the current, active offer price of a product” and warns that a listing “may not display if the priceValidUntil property indicates a past date.” If both offers.price and offers.priceSpecification are present, Google uses offers.price.

So there can be three independent sources of a price in Google’s view of your product: the page, the markup, and the feed. They need to agree with each other and with what a shopper pays.

Three sources of one price. Product page: What a logged out shopper sees. Structured data: The offer price in the page markup. Merchant feed: The price your data source sends.
Google can compare all three. Find which one disagrees before changing a setting; the diagram shows sources, not how often each is wrong.

Reproduce the price and shopping context

Write down the exact context before you look at any code. Prices in WooCommerce can depend on it.

  1. The Google surface and the value it shows. A product result, a Merchant Center diagnostic, or both. Take a screenshot with the date.
  2. The product URL, and which variation if it is a variable product.
  3. The visitor state. Log out or use a private window. Logged-in customers can see different prices because of roles, memberships, or saved addresses.
  4. Location and currency. If you run a currency switcher or show tax based on location, note the country the visitor appears to be in.
  5. The time. Sale prices start and end on schedule, so a mismatch can appear only on either side of a sale boundary.

Then open the product in that state and record the price exactly as displayed, including any “incl. tax” or “ex. tax” suffix.

Compare page, schema, and feed values

Capture the server’s HTML for the product (a curl of the URL, not the page after scripts run) and read the Product node’s offers.price. For a variable product, read the offer for the specific variant. The product schema check shows how to extract it. Then read the product’s price in your feed, or in the Merchant Center product details.

Fill in a table like this one. The numbers are illustrative.

Source Value Notes
Page, logged out 24.00 incl. tax Variation: large
Structured data offers.price 20.00 Variant offer for large
Merchant Center feed 24.00 Last fetched yesterday
Google product result 20.00 Screenshot saved

Now match the pattern:

Pattern Likely cause Where to look
Markup lower or higher than the page by the tax amount Prices stored excluding tax, shown including it (or the reverse) WooCommerce tax settings
Markup matches the parent or the cheapest variation The page shows a selected variation; the markup describes another Variation defaults and variant offers
Page shows a sale price, markup or feed does not (or the reverse) Sale schedule changed after a cache or feed was built Sale dates, cache, feed schedule
Page matches in your browser, differs in a crawler capture Price inserted by JavaScript, or a different cached copy served to bots Page cache and theme scripts
Page and markup agree, feed differs Feed not regenerated after a price change Feed plugin or Merchant Center schedule

Check tax display first

Tax is a structural cause rather than a timing one, because WooCommerce separates how prices are entered from how they are shown. WooCommerce’s tax settings documentation, checked September 27, 2026, describes three settings that interact: Prices entered with tax, Display prices in the shop, and Display prices during cart and checkout. The same page warns that mixing them can cause rounding differences, and that WooCommerce alerts you when they conflict.

Here is why that matters for markup. If your prices are entered excluding tax and shown including tax, the number stored on the product is not the number a shopper sees. Any structured data that reads the stored number will disagree with the page by the tax amount.

In WP Visibility 2.10.3, checked against the released code, the Product offer’s price is the product’s active price as stored in WooCommerce (the sale price during an active sale), and it is not adjusted for tax display. The Open Graph product:price:amount tag, by contrast, uses the display price, which follows the Display prices in the shop setting. On a store where entered and displayed tax treatment match, the schema price and the shown price are the same number for a shopper taxed at your store’s base rate. (When prices are entered including tax, WooCommerce’s price display code, checked September 27, 2026, by default takes off the base tax and adds the shopper’s own rate when the two differ, so the displayed price can change with location.) On a store where entered and displayed treatment differ, the two numbers differ on taxable products whenever a nonzero tax rate applies, and settings in the SEO plugin will not change that.

Your options, in order of preference:

  1. Align the settings so prices are entered and displayed on the same basis, if that suits your market and your accountant.
  2. Check what your feed sends and what the country you target expects. Merchant Center’s help asks for prices in “the appropriate currency for the country that you’re targeting.”
  3. If you need a different schema price, that is custom development, for example a developer filter on the structured data. Test it on staging and repeat the comparison afterward.

Check variations, sales, and caches

Variations. WooCommerce’s variable product documentation, checked September 27, 2026, describes default form values, which preselect a variation when the page loads. If the page opens with the large size selected, the shown price is the large size. Confirm that the variant offer for that same variation has the same price. In WP Visibility 2.10.3, a variant is identified in the markup by its SKU, not by its size or color values, and only the first 30 variations get a variant entry. The variable-product schema guide covers the full variant comparison.

Sales. Check the product’s sale start and end dates. After a sale ends, confirm that the page, the markup, and the feed all dropped the sale price. If a structured data priceValidUntil date is in the past, Google’s documentation says the listing may not display.

Caches. A full-page cache, a CDN, or a host cache can keep serving HTML built before a price change. Fetch the page with a query string that bypasses your cache (if your cache supports one), purge the product URL, and fetch again. If the price changes after a purge, set your cache to clear product pages when a product is saved, and when a scheduled sale starts or ends. Price text inserted by JavaScript after load is a separate problem: Merchant Center’s help says that data “passed dynamically with JavaScript after the page is loaded” will trigger an error.

Correct the source and verify after refresh

Change the one thing the table pointed to, then verify in this order:

  1. Purge caches for the product URL.
  2. Recapture the server HTML logged out and confirm the markup price matches the page.
  3. Regenerate or refetch your feed, and confirm its price matches.
  4. In Merchant Center, if the product was disapproved, request a website check. Google’s help says it “may take up to 12 hours to review your website” after you ask.
  5. For the page itself, use the URL Inspection tool in Search Console, checked September 27, 2026, to test the live URL and request indexing. Google does not commit to when a search result updates: its help says indexing “typically takes only a day or so, but can take much longer in some cases” and that a request “does not guarantee that the page will appear in the Google Index.” Record the date of your fix and check again rather than assuming a timeline.

Keep your table with the dates. If the mismatch returns, compare the new capture with the old one; a recurrence at the same time of day can point to a scheduled job, such as a feed or a sale.

Checklist

  • Visitor state, location, variation, and time recorded with the wrong value.
  • Page, markup, feed, and Google values side by side.
  • Tax entry and display settings compared.
  • Selected variation matches the variant offer compared.
  • Sale dates and priceValidUntil checked.
  • Cache purged and HTML recaptured before and after the fix.

Read next

WordPress SEO with your own assistant.

WP Visibility is $99 a year for unlimited sites, client sites included, with a 30-day refund. Use its SEO tools in WordPress or connect a supported assistant. Read how proposal review and permissions work.