Every marketplace plans for vendors arriving and almost none plan for vendors leaving, which is why offboarding is where trust quietly leaks. A vendor pauses, goes out of stock across their range, or ends the relationship — and if the marketplace handles it sloppily, shoppers keep finding and buying products that will never ship. Safe offboarding is a strict order of operations: disable, then hide, then purge — each step doing one job, with a reversible window before anything is destroyed. Here is the sequence, and the specific bug that taught us why "hide" has to go through exactly one place.
Why the order matters
The three steps are not interchangeable, and doing them out of order causes the exact failures you are trying to avoid. Disable is the intent — the operator's decision that this vendor is off. Hide is the immediate consequence — the products vanish from everything a shopper can reach, right now. Purge is the eventual cleanup — the data is destroyed, but only after a retention window during which the decision can be reversed. Skip straight to purge and you cannot undo a mistake; hide without a clean disable and syncs keep resurrecting the vendor; disable without an immediate, total hide and you get ghost products. The order exists so that the fast, reversible action happens first and the slow, irreversible one happens last.
Hide immediately through one choke point
"Hide the products" sounds trivial until you count the surfaces a product appears on: search results, category browse, recommendations, the direct product page, the sitemap, structured data, internal APIs. Hiding a vendor means all of them, atomically. The only way that is reliable is to enforce the exclusion at a single point every one of those surfaces passes through, rather than patching each surface and hoping you found them all.
When we first built vendor-hiding, we added the exclusion to the search path we knew about — and a disabled vendor's products still appeared, because a second code path queried the index directly and bypassed the filter. There were two ways to reach search, and we had only closed one. The fix was to funnel every search caller through a single choke point that applies the exclusion once, so there is no second door to forget. The lesson generalises: if a rule has to hold everywhere, enforce it in the one place everything passes through, not in every place you can think of.
This is the whole argument for a central choke point, and it is why hiding is instant and total: flip the vendor's state, and because every read goes through one gate, the products are gone from every surface in the same moment. No crawl, no per-surface cleanup, no window where some pages still show them.
Stop the syncs
Hiding the products is not enough if the ingestion pipeline is still reading the vendor's store, because the next sync will happily re-add everything you just hid. So disabling a vendor must also stop their syncs — and this is another place a partial fix bites. It is not enough to remove them from the schedule; the on-demand and full-sync paths have to honour the disable too, or a manual reingest or a nightly full run resurrects the catalog. Disable is a single state that every part of the pipeline consults, the same way every read consults the hide gate.
This is the mirror image of onboarding: onboarding connects the store and starts the syncs; offboarding stops the syncs and cuts the connection. Both hinge on the pipeline treating the vendor's enabled state as authoritative everywhere.
Retention window, then hard purge
Hidden is not gone. A hidden vendor's data still occupies your search index, your vector store and your database, and holding it forever is both wasteful and, under data-minimisation principles, wrong. So after a retention window — long enough to reverse an accidental or temporary disable — the data is hard-purged from all three stores.
The purge is a three-place delete, the same reconciliation an ingest of a shrinking catalog performs: remove the vendor's products from the keyword index, the vector index and the primary database, so nothing lingers anywhere. Gate the destructive action so it only runs against a vendor that is actually disabled — an accidental purge of a live vendor is a far worse incident than a few extra days of retained data — and offer a deliberate "purge now" for the cases where you want the data gone immediately.
Reversible until purge
The retention window is the safety feature, so treat it as one. Between disable and purge, re-enabling a vendor should bring everything back exactly — products, categories, enrichment — because nothing was destroyed, only hidden and paused. Vendors pause for seasons, sort out a supply problem, renegotiate terms; a marketplace that can un-hide instantly keeps those relationships cheap to resume. Only when the window closes does the door actually lock. Design the whole sequence so the point of no return is late, explicit, and gated — never a side effect of a flag flipped in haste.
Ghost products erode trust
All of this exists to prevent one thing: the ghost product. A ghost is a listing for something that cannot be bought — a departed vendor's catalog still in search, an orphan left by a shrinking feed, a variant collapsed to an out-of-stock representative. Every ghost is a shopper who searched, found, clicked, maybe bought, and then hit a wall, and each one costs more trust than it returns in traffic. Offboarding done in order — instant total hide, syncs stopped everywhere, reversible retention, gated purge — is how you guarantee that when a vendor leaves, their products leave with them, cleanly, and stay gone. It is the same trust discipline that runs through marketplace operations: the catalog should never promise what it cannot deliver.
Key takeaways
- Offboard in order — disable, hide, purge; the fast reversible action first, the irreversible one last, so a mistake is always recoverable.
- Hide through one choke point every surface passes through, so the products vanish from search, browse, recommendations and pages in the same instant.
- Stop syncs everywhere, not just on the schedule — on-demand and full runs must honour the disable, or the next sync resurrects the catalog.
- Purge is a three-place delete — keyword index, vector store, database — gated so it can only run against a genuinely disabled vendor.
- Keep it reversible until purge; the retention window lets a paused vendor return instantly, and makes the point of no return late and deliberate.
- Ghost products are the failure you are preventing — a listing that cannot be bought costs more trust than the traffic it earns.
Frequently asked questions
How do you remove a vendor from a marketplace safely?
Why do hidden products sometimes still appear in search?
Do you delete a vendor's data immediately when they leave?
What is a ghost product on a marketplace?
When a vendor leaves, their products should too.
Our managed marketplace hides a disabled vendor everywhere at once and purges cleanly on a retention window — no ghost products, no broken promises.
Request early access See the live marketplace →