Woocommerce Google ads agency

Google Ads on WooCommerce: tax basis fixed before the first feed, variations sent properly, and feed refreshes on a real cron rather than on traffic.

Most WooCommerce advertising problems start in the feed, and most WooCommerce feed problems start with two settings nobody thinks about. The first is how tax is displayed. WooCommerce can show prices including or excluding tax, and the value written into a feed is not always the one on the page, which produces price mismatch warnings across the whole catalogue. The second is scheduling. WordPress runs its scheduled tasks when someone visits the site, so on a quiet store the feed regeneration you set for 3am may run at 9.40am, or not at all.

After that it is the usual work, done in a WooCommerce shape. Variations have to reach the feed as individual items with a shared parent, because sizes and colours are what people search for. Global attributes have to be mapped to Google's colour, size and material fields rather than left as unstructured text. Conversion tracking has to fire on the order received page, which changed for stores using the newer block based checkout.

We run everything in your own Google Ads and Merchant Center accounts, and fix the WordPress side rather than working around it.

Native on WooCommerce

The official Google integration for WooCommerce, which builds a feed and adds conversion tracking
Product variations, each with their own price, stock and attributes, ready to be sent as separate items
Global attributes that map cleanly to Google's colour, size and material fields
Tax display settings that decide whether the feed price includes tax
WordPress scheduled events, which can be replaced with a server cron for reliable feed runs
The order received page, where conversion tracking belongs on both the classic and block checkout

Settings that matter

Fix the tax basis before the first feed run

Decide whether prices are entered and displayed including or excluding tax, make sure the feed uses the same basis, and check a product page against the feed value by hand. Getting this wrong disapproves items in bulk for price mismatch, and because the crawler works through the catalogue over days, it looks like a gradual mystery rather than a single setting. Stores selling into markets with different tax treatment need a feed per market rather than one adjusted figure.

Send variations, not just parent products

A parent product hides the sizes, colours and capacities people actually search for, and it cannot carry a single accurate price when variations differ. Each buyable variation should be its own feed item with its own identifier, price, availability and image, grouped under a shared item group so the channel understands they belong together. On large catalogues this multiplies the item count, which is normal and is what makes the feed match specific searches.

Move feed generation onto a real cron

WordPress fires scheduled tasks on page loads, so a low-traffic store can go hours past a scheduled regeneration. On a store with changing prices or stock that means advertising numbers that are no longer true. We disable the traffic-triggered scheduler and run the site's cron from the server on a fixed interval, then check the feed's generation timestamp rather than assuming the schedule held.

Confirm conversion tracking on the checkout you actually run

WooCommerce stores are split between the classic checkout and the newer block based one, and tracking added for one does not always fire on the other. We place a test order, watch the tag fire on the order received page, confirm the value and currency arrive, and check that a refunded order does not leave a phantom conversion behind. Where consent management is in place, we make sure it is not blocking the tag for everyone by default.

What we avoid

Leaving feed regeneration to the traffic-triggered scheduler on a store with few daily visitors
Exporting parent products only, which hides the variants people search for and misstates the price
Stacking two feed generators, which produces two versions of the same catalogue and doubles the errors

Questions

Nearly always tax, occasionally currency conversion, sometimes a sale price with an expiry that passed in one place and not the other. WooCommerce stores a base price and applies tax according to your settings, so a feed reading the raw field sends a different number from the one shown to shoppers. Fix the basis rather than adjusting the feed by a percentage, because rounding will keep breaking individual items.

It depends on the catalogue. The official integration handles a straightforward store well and keeps everything in one place. Extra tooling earns its cost when you need title patterns per category, supplemental data, several destinations, or rules WooCommerce cannot express. We would rather use what you already have than add a subscription that solves a problem you do not have.

Through the order received page, the same as before, but the tracking has to be added in a way the block checkout supports rather than by hooking a template that is no longer used. We test with a real order rather than a preview, since the two behave differently. If the store recently migrated checkout and reported conversions dropped, this is usually the reason.

Yes, and it needs a feed per country with the right currency, tax treatment and shipping, plus a Merchant Center target for each. Currency switcher plugins that convert at display time are the usual complication, because the feed and the page can end up disagreeing. Where prices genuinely differ by market, a separate feed is far more reliable than a conversion applied on the fly.

Send your WooCommerce store.

The plan is written for your store on the platform it runs on.