WooCommerce Price Sync in the WhatsApp Preview

A WooCommerce price sync in the WhatsApp preview means the number on the card is drawn from your catalogue at the moment the card is generated — not baked into a picture someone made once. When that is true, the only remaining question is when WhatsApp re-reads the link, and that is the one thing no store can control.

The short answer

A price can only appear in a preview if the image is built from live product data. A static featured image has no price to show, ever; a card designed once has whatever price it had that day. WooCommerce hands out no price-tagged image by default, so the "old price in the preview" complaint is really two questions:

  1. Does the card know the current price? — a design decision, and the one you can fix.
  2. Has the platform re-read the page since the price changed? — WhatsApp's clock, not yours.

Why the price goes stale

Cause What you see Why it happens
The tag points at the featured image No price at all A product photo has no price in it
The card was authored once The price from design day Nothing regenerates it
A sale ended A strike-through for a discount that is over The image still carries the old badge
The page cache is serving old HTML The old card, again The crawler never sees the new og:image URL

Only the first three are about the card. The fourth is about your caching layer, and it looks identical from the outside — which is why the check order in Instant WhatsApp Image Update for WooCommerce matters.

What a synced card actually reads

FastOG signs a cover URL per request, and the props come from the live product:

Card element Source Note
Price get_price() On a discounted product this is the sale price
Compare-at ("was") price the regular price Sent only when the product is actually on sale — a "was" equal to the current price is a strike-through nobody earned
Sale badge the product's sale state Appears and disappears with the sale
Stock stock status Reflects the catalogue at render time
Photo featured image first, then gallery Composed inside the card, not cropped by the platform

That is the difference between "dynamic" and actually dynamic: the values are not placeholders a designer filled in, they are read from your store each time a card is built.

How "sync" works in both directions

Catalogue → card. Every value above is read at render time. Change a price and the next render shows the new one; there is no export step and no file to re-upload.

Card → cache. Each value also travels inside the signed cover URL. So a price edit changes the URL — which means the old image is no longer addressable, the CDN has nothing stale to serve, and no cache-busting is needed. Nothing else in this category works this way, because a self-hosted plugin keys its image on a filename that never changes.

Card → Facebook. Saving a product fires WooCommerce's native product.updated webhook, and FastOG queues a Meta re-scrape for that product's permalink, so Facebook replaces the cached card instead of waiting weeks. See Force a Facebook Open Graph Cache Refresh.

Card → WhatsApp. Nothing can be pushed. The correct card is waiting for the next read.

The scheduled-sale edge case

A sale that starts at midnight with nobody touching the product fires no webhook at all — a detail that breaks every "we refresh on save" design, including our Facebook ping.

What saves the card is that it is not generated in advance: the cover is built on request from current catalogue data, so the first fetch after midnight already shows the sale price and the badge. The stale number can only survive in a platform's preview cache, where it will be replaced on that platform's own schedule. A card that is rendered, rather than exported, is the only kind that survives a sale nobody saved.

Verify the number is in sync

The price is visible in the cover URL itself, which makes this checkable without a debugger:

bash
# What the page is serving right now
curl -s https://your-store.com/product/example | grep -o 'og:image[^>]*' | head -1

# Open that cover URL in a browser and compare the number against the product page.

If the URL's parameters and the rendered card both carry the current price, and the product page shows the same, the store side is synced and any remaining staleness is a platform cache. If the URL still carries the old price, the page cache is serving pre-edit HTML — purge it.

To see it end-to-end, paste a product URL into See Your Links The Way Buyers Do: it reads the live tags and renders a cover from the same product data, side by side with what the platforms would show today.

FAQ

Serve an og:image that contains the price — which means an image generated from your catalogue, not a static photo. WhatsApp renders whatever image the tag points at, at 1200×630; the price only appears if it was drawn into that image.

Why does the preview still show the old price after I ended the sale?

Two likely causes: the image the page serves has not changed (page cache, or a static image), or WhatsApp is showing a cached preview from before the edit. Check the current og:image URL first — if its price is old too, the store is the problem; if it is current, WhatsApp is.

Does the card show the sale price or the regular price?

The sale price — that is what WooCommerce reports as the current price — with the regular price alongside it as the compare-at, and only when the product is genuinely on sale.

Do all plans draw the price and the sale badge?

Yes. Template fields are not gated to a tier on FastOG: price, compare-at price and stock badges are available on every plan. Plans differ by page types, item allowance and template breadth, not by what a cover can say.

For Facebook, FastOG requests a re-scrape after the product update. For WhatsApp, LinkedIn and X, the next read happens on each platform's own schedule; no public timing guarantee or programmatic refresh API is claimed for those platforms.

What if I change the price but not the template?

That is the normal case and it works: the template defines the layout, the catalogue supplies the values. Nothing needs re-designing and no image needs re-exporting.

Only as long as a platform's cached preview survives. The cover URL changes with the catalogue, so the first fresh read gets the post-sale card.

Is there a free plan?

No — every FastOG plan is paid, deliberately, so render capacity and bandwidth serve paying stores rather than a queue of free accounts. The 14-day trial has no credit card requirement.

Try it free — no signup required

Preview and test dynamic OG images in seconds.

Open the Free OG Image Tester