Supplier detection, the shrink guard, and the 410 life cycle

Last updated July 10, 2026

How supplier detection works

Marking products discontinued by hand does not scale when your catalog comes from supplier feeds. SWPL Discontinued Products includes a detection engine that does it for you, per supplier, using a simple and honest rule built around the carried set – the full list of SKUs the supplier’s feed currently carries.

• A SKU in your catalog that is absent from the supplier’s carried set is discontinued.
• A SKU that is present but flagged by a field rule you configured (for example a status column saying “discontinued”) is discontinued.
• A previously feed-discontinued SKU that returns to the feed is reactivated automatically.

Only feed-sourced discontinuations are auto-reactivated. A product you discontinued by hand stays discontinued until you act – the plugin records the source of every discontinuation so the two never mix.

Where carried sets come from

The engine accepts a supplier’s carried set from any of these routes; all of them pass through the same guarded pipeline:

• SWPL Product Import Export – after every completed full-feed run, the importer hands the engine its full SKU list automatically.
• The plugin’s own daily feed scan – point a supplier at a feed URL and name its SKU field, and the plugin reads the feed itself once a day. This works with any importer, or with no importer at all.
• WooCommerce’s built-in CSV importer – bind a “Carried-set supplier” in the CSV Importer settings and every completed import (Products > Import) delivers its SKU list to the engine, with a discontinued column usable as the flagged signal.
• WP All Import (legacy) – the original integration, now routed through the same guarded engine.

The Suppliers tab

Each supplier gets its own status panel under WooCommerce > Discontinued: the size, date, and source of the last carried set, the accepted baseline, the shrink-guard state, and the last detection result. Configuration lives there too – which part of the catalog the supplier covers, the import profile or feed URL it is linked to, field rules for flagged values, and the guard threshold.

The shrink guard: why a bad feed cannot empty your store

The dangerous failure mode of absence detection is a truncated feed: the supplier’s server hiccups, half the file arrives, and a naive system would read thousands of missing SKUs as thousands of discontinued products. The shrink guard makes that structurally impossible:

• A carried set smaller than the configured percentage of the last accepted set (default 50 percent) is held. Nothing is discontinued.
• A persistent admin banner appears, and the held snapshot waits on the Suppliers tab for a human decision: accept it (the shrink is real – the supplier genuinely dropped that many items) or discard it (the feed was bad).
• An empty carried set is always held, no matter the threshold.

There is no unguarded bulk path around this: even the developer helper for marking missing SKUs is shrink-guarded.

The 410 life cycle, end to end

1. Detection (or a manual mark) sets the product discontinued. If “Hide from Catalog” is on, it disappears from shop pages and site search immediately.
2. The old address answers 410. Shoppers see your 410 page – the built-in one or a custom page you designed with your page builder – with a “Continue Shopping” button pointing at the product’s category or your home page. Search engines see the 410 status and de-index the page far faster than they would a 404.
3. Hit tracking counts every request to the retired address and records the last hit, so you can watch crawler interest fade and spot external links still pointing at dead products.
4. Retention and cleanup: after your retention period (default 3 months), the automatic cleanup deletes the product – run on Action Scheduler with a real server cron, so it happens on schedule without depending on site traffic. Email notifications on deletion are available, and everything is written to the monthly log.
5. Return: if the supplier carries the SKU again before deletion, a feed-sourced discontinuation is reversed automatically, and the product’s visibility is restored to exactly what it was before the plugin hid it.

Practical guidance

• Set the guard threshold to match the supplier. A stable catalog supplier can use a strict threshold; a supplier whose feed genuinely swings in size needs a looser one, or you will be accepting held snapshots often.
• Use field rules where the feed is explicit. If the supplier publishes a status column, a flagged rule catches discontinuations even while the SKU is still listed – earlier than absence detection can.
• Do not redirect 410 pages. A 410 is a deliberate answer, not an error to patch over. Redirect managers that understand 410 (SWPL AI Visibility’s redirect manager does) will decline to redirect them, which is correct.
• Review the log after the first detection run for each new supplier. It records every product the run touched, so you can confirm the configuration reads the feed the way you intended.