Give every product variation its own expiration date

A “variable” product in WooCommerce is really several products wearing one listing. A 250ml and a 1L bottle, a 30-count and a 90-count, vanilla and chocolate — each is a separate variation with its own SKU and stock. So when the line is perishable, one expiration date for the whole product doesn’t fit: each variation can come from a different delivery and lapse on a different day. This guide shows how to set an independent expiration date on every variation, fall back to a parent default where you want one, and have the store treat each variation correctly — all with the free Sellinor Product Expiration Dates plugin.

Set a date on each variation

Once the plugin is active, variable products get an Expiration Date field on every variation. Open the product, go to the Variations tab, expand the variation you want, set its date, and repeat for the others. Save changes, then update the product.

That’s the whole workflow. Each date is independent, so the 90-count and the 30-count of the same supplement can expire months apart and the store tracks both correctly. Dates are stored as standard product metadata on each variation, so they travel with exports and stay put if you ever move tools. Full setup lives in Expiration dates.

Inherit a parent default for dateless variations

You rarely need to type a date into every variation. Set an expiration date on the parent variable product, in its Expiration tab, and any variation without its own date inherits that parent default. Variations that do carry their own date use theirs instead.

This is the right model when most variations share one date and only one or two differ. Set the common date once on the parent, then override only the exceptions at the variation level. A variation’s own date always wins over the inherited parent date, so there’s no conflict to reason about — most specific wins.

The product hides only when every variation has expired

This is the part that trips up naive setups. With per-variation dates, expiry actions apply at the parent level only once every variation has expired. As long as at least one variation is still in date, the product stays available in your catalogue. An individual variation that has expired simply becomes unavailable to select — shoppers see the remaining in-date options, not an empty listing.

In other words, you don’t lose a whole multi-variation listing because one size lapsed. The product comes off the shelf only when there’s genuinely nothing sellable left. That behaviour is automatic; you don’t configure it per variation.

Choose what “expired” does, and when

Under Products → Expirations → Settings → General, pick the automatic expiry action that fires when a variation reaches its date:

• Hide from catalog — the product drops out of shop pages, category listings and search once all variations have expired. Applied immediately on each page load; the URL still resolves so existing links don’t break.
• Set out of stock — the product can stay visible with an out-of-stock label but can’t be bought. Applied by an hourly background check, so it can take up to an hour to flip after the date.
• Both — gone from the catalogue and unpurchasable.

You can fire the action early with the days before setting — set it to 3 and the threshold moves three days ahead of each variation’s date, giving you a buffer. Details are in Expiry actions.

Whenever an action is enabled, cart and checkout protection is immediate: an expired item can’t be added to the cart, and if something expires while it’s already in a basket, it’s removed at checkout with a notice — so even before the hourly sweep runs, no one completes a purchase of expired stock.

Show the right date as shoppers switch variation

When frontend display is on, the expiration date renders near the add-to-cart area, and it updates as the shopper selects a variation — showing that variation’s date, or the parent default if the variation has none. Two settings shape this:

• Label text lets you set “Best Before”, “Use By” or “Expires” in front of the date, whatever your category needs.
• A display threshold shows the date only when a variation is within a set number of days of expiry; set it to 0 to always show it.

If your theme uses a fully custom product template and the date doesn’t appear, drop in the [edfw_expiration_date] shortcode — it accepts an optional id attribute and suppresses the plugin’s own placement so the date never shows twice.

Manage variation dates at scale

With dozens of variations, you won’t want to open each product. The Products list gets a sortable Expiration column for an at-a-glance view, and Quick Edit and Bulk Edit let you set dates from the list — see Getting started.

For a spreadsheet-driven load, the CSV import/export page matches rows by Product ID or SKU. Because each variation has its own ID and SKU, you can prepare a file with one row per variation and import every date in a single pass — far faster than clicking through the Variations tab for a large catalogue.

When per-variation dates aren’t enough

One date per variation is the right model when each variation has a single, known shelf life. If you receive the same variation in repeated deliveries with different dates, you’ll eventually want each delivery tracked separately — that’s batch (lot) tracking with automatic First-Expired-First-Out deduction, in the Pro add-on. See the batch tracking docs or how FEFO stock rotation works on a WooCommerce store. For everyone else, free per-variation dates with parent inheritance cover the job: honest dates on every size and flavour, and a listing that only goes offline when there’s truly nothing left to sell.