WooCommerce BOGO Promotions: Why They’re Harder to Set Up Than They Look (And How to Do It Right)

You decide to run a Buy One Get One promotion. Reasonable choice — BOGO deals are among the most effective promotions for moving inventory and increasing order size. You open WooCommerce, look for the BOGO option, and find nothing. No toggle, no rule builder, no “Buy X Get Y” field anywhere in the product settings or discount area. You search the docs and discover that WooCommerce simply doesn’t have this feature.

So you search for a plugin. There are several. One has a 2.3-star rating. Another has a recent review that reads: “you can only create a title for your BOGO rule.” Another installs fine, works in testing, then silently breaks when you activate the newer block-based checkout. You pick one, spend an hour on configuration, and end up with a promotion that kind of works — until it doesn’t.

This is one of the more frustrating gaps in the WooCommerce ecosystem. BOGO is a standard retail promotion that most store platforms handle natively. WooCommerce doesn’t. And because it doesn’t, the third-party plugin space has filled the void with solutions of wildly varying quality. Knowing what separates a reliable setup from a fragile one will save you a support ticket at the worst possible moment — mid-promotion.

Why WooCommerce can’t do BOGO natively

WooCommerce’s pricing model is built around product-level sale prices and coupon codes. A sale price is a number stored on a product or variation. A coupon can offer a percentage off, a fixed cart discount, or free shipping. Neither of those primitives can express “when the customer has N units of product X in their cart, make Y units free or discounted.”

BOGO is a cart-level conditional. It depends on quantity, not just on which product is in the cart. WooCommerce’s architecture doesn’t have a native hook for “evaluate the cart contents and modify prices based on what’s there and how much of it there is.” That logic has to be built on top.

This isn’t a minor oversight — it’s a genuine architectural gap. WooCommerce is designed around individual product pricing. Cart-level conditional pricing requires a different layer: something that watches the cart, evaluates rules, and injects modified prices. That’s non-trivial to build correctly, which explains why the plugin quality varies so much.

The two technical approaches plugins use (and why one fails)

When a plugin implements BOGO on top of WooCommerce, it has two ways to make the “free” or discounted item appear in the cart. Understanding the difference matters because one approach is solid and one causes problems.

Approach 1: Auto-add a free product to the cart

The plugin detects that the qualifying condition is met (customer has 2 of product X), then automatically adds another unit of product X to the cart at a modified price (free, or 50% off, or whatever the rule specifies). This is the most literal interpretation of “Buy One Get One” — the free item actually appears as a separate cart line with a modified price.

The problem with this approach is that it creates friction. Customers who deliberately remove a product from their cart find it being added back. Customers who don’t want the free item — or don’t qualify anymore because they changed quantities — see the cart behave unexpectedly. Edge cases multiply fast: what happens if the free item is out of stock? What if the customer has a coupon that applies to it? What if they remove the qualifying product after the free one was added?

Approach 2: Price modification at the cart level

The plugin evaluates the cart on the fly and modifies the price of the qualifying item directly. If you buy 2 units and the deal is “Buy 1 Get 1 Free,” the plugin sets the effective price of one unit to zero and charges regular price for the other. The cart still shows 2 items, but the second one has a price of £0 (or 50% off, or whatever the rule specifies).

This approach is cleaner from a cart experience perspective. There are no phantom items being added and removed. The customer sees their chosen quantity with a modified price that reflects the deal. It also handles edge cases more gracefully — remove a unit, the discount recalculates.

Most well-built BOGO plugins use price modification. The auto-add approach tends to appear in older or lower-quality plugins where the developer took the literal interpretation without thinking through the edge cases.

Where BOGO plugins fall short in practice

Even among plugins that use the correct technical approach, there are common failure points worth knowing about before you commit to one.

The “title only” problem

Some plugins let you configure a BOGO rule name, set the products, and save — but the implementation beneath it is incomplete. The rule exists in the database but the cart-level logic to apply it either doesn’t work correctly or only works in specific conditions. This is the failure mode behind reviews like “you can only create a title for your BOGO rule.” The UI looks feature-complete but the engine isn’t.

This usually affects newer plugins where BOGO was promised in the roadmap but not fully shipped, or older plugins that haven’t been updated to work with recent WooCommerce versions.

Scheduling is an afterthought

Most BOGO plugins treat a rule as a permanent configuration. You turn it on, it runs. You want to stop it, you turn it off. There’s no concept of “run this promotion from November 29 to December 2 and then stop automatically.”

For any time-limited promotion — which is what most BOGO deals are — this means you’re responsible for manually activating and deactivating the rule. If you forget, the promotion keeps running after it was supposed to end. If you’re travelling or otherwise unavailable, you need someone else to do it. The operational discipline required to manage this manually is higher than most store owners anticipate.

Conflict handling is missing

What happens if a customer has a BOGO deal active and also uses a coupon code? What if you have a sitewide percentage discount running alongside a BOGO rule on specific products? Most BOGO plugins have no concept of conflict resolution. The result is either double-discounting (both apply, unexpectedly reducing price) or one silently cancelling the other. Neither is a good outcome, and you often don’t know which will happen until a customer reports something odd.

Cross-product BOGO is often unsupported

A true BOGO can be “Buy product A, get product B at 50% off.” Many BOGO plugins only support same-product rules: Buy 1 of X, Get 1 of X free. If your promotion is “Buy a coffee machine, get a bag of beans free,” you need cross-product support. Not all plugins have it, and the ones that do often implement it incompletely.

The block-based cart and checkout problem

This deserves its own section because it’s the most recent and most common cause of BOGO plugins suddenly not working.

WooCommerce has been migrating from its classic PHP-rendered cart and checkout to a new block-based implementation using Gutenberg blocks. The classic checkout is a PHP template. The block checkout is a React application. They are fundamentally different in how they render and how they interact with WooCommerce’s pricing logic.

Many BOGO plugins were written for the classic checkout. They hook into PHP filters and actions that fire during the classic checkout render. Those hooks either don’t fire, fire at the wrong time, or fire differently in the block checkout. The result is a BOGO deal that appears to work in your product testing (if you tested on the classic checkout) but fails silently when a real customer uses the block-based checkout — which is now the default in WooCommerce and the direction the platform is heading.

If you’re evaluating a BOGO plugin, test it explicitly on the block-based checkout, not just the classic version. Go to WooCommerce → Settings → Advanced → Features and check whether the block checkout is active on your store. If it is, your BOGO plugin must support it.

What a reliable BOGO setup actually looks like

A BOGO implementation worth relying on has a few non-negotiable properties:

• Price modification, not auto-add. The discount is applied to the qualifying item’s price at the cart level, not by adding phantom products.
• Scheduled activation and deactivation. The promotion has a defined start and end time and runs itself. You set it up in advance and don’t need to remember to turn it off.
• Block checkout compatibility. The cart pricing logic works correctly with both the classic and block-based WooCommerce checkout.
• Conflict handling. When other discounts are active, the behaviour is predictable. Either there’s a priority system or the plugin documents clearly what happens when promotions overlap.
• Flexible buy/get configuration. Buy 1 get 1, buy 2 get 1, buy X get Y — and the ability to set the discount on the “get” unit anywhere from 1% to 100%.

That last point matters because “BOGO” is shorthand for a family of deals that all follow the same structure. “Buy One Get One Free” is the extreme version (100% off the get unit). “Buy Two Get One at 50% Off” is a milder version that’s often better for your margins. A flexible implementation lets you use the same setup for all of these rather than needing a different plugin for each variant.

Smart Cycle Discounts includes BOGO in its free version with this kind of flexibility. You configure the buy quantity, the get quantity, and the discount percentage on the get unit (from 0% to 100%). The deal runs as a scheduled campaign with a defined start and end date — it activates automatically and deactivates automatically. It works with both the classic and block-based WooCommerce cart and checkout. And because it sits inside a campaign management system that handles conflict resolution by priority, overlapping promotions don’t produce unpredictable stacking.

Step-by-step: setting up a BOGO campaign

Here’s what a complete BOGO setup looks like using Smart Cycle Discounts. The same principles apply regardless of which plugin you use — the key decisions are universal.

Common configuration mistakes and how to avoid them

Setting the buy quantity too low

Buy 1 Get 1 Free is the most commonly configured BOGO — and the most expensive. On a product with a 40% gross margin, a true BOGO deal means the combined margin on both units is 40% (you’re giving away the second unit entirely). Buy 2 Get 1 Free is often a better deal structure: the customer still feels rewarded, but the margin hit is spread across three units instead of two. Many stores configure Buy 1 Get 1 without checking the margin impact first.

If you’re unsure whether your BOGO deal makes financial sense, the WooCommerce discount calculator on the Webstepper site can help you model it before you commit.

No end date

A BOGO rule with no end date runs indefinitely. If you’re using a plugin that requires manual deactivation and you forget, customers continue getting the deal long after your promotional window closed. Always set an explicit end date. If you want a permanent deal, that’s a different product pricing decision — not a promotion.

Forgetting that “get” quantity adds to the cart total

When the deal is “Buy 2 Get 1 Free” and the customer only puts 2 units in the cart, nothing happens — they need to add the third unit for the deal to apply (or the plugin needs to add it automatically, which brings its own problems). Make sure your store’s product pages or cart clearly communicate the deal mechanics. “Add 3 to qualify for Buy 2 Get 1 Free” is clearer than a vague “BOGO deal active” banner that doesn’t tell customers what they need to do.

Applying the deal to products with variable costs

Products where the cost varies significantly by variation (a small item at £5 vs. a large at £25) can produce unexpected results with a flat BOGO rule. If “Buy 1 Get 1 Free” applies equally to all variations, a customer buying one large and getting one large free may be getting a far better deal than you intended. Consider scoping the rule to specific variations or products rather than an entire variable product if the cost difference is meaningful.

Conflicting campaigns without priority settings

If you have a percentage discount campaign active (say, 15% off sitewide) at the same time as a BOGO campaign on specific products, those products fall under both campaigns. Without conflict resolution, the result is unpredictable — you might get both discounts applied, or one might override the other depending on the order they’re evaluated. Use a priority system to make this explicit: set which campaign wins when they overlap, rather than leaving it to chance.

Frequently asked questions