> ## Documentation Index > Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # How to find out why a listing isn't selling > The ordered checklist for a listing that looks complete in the admin and won't sell: five independent layers, cheapest and most common first. catalog/listings A listing that isn't selling fails silently — nothing crashes and no error appears, the listing simply never turns up where a customer would find it. Five independent layers decide whether a listing can be sold, and any one of them alone is enough to produce nothing: the listing itself, its pricing rows, the location fulfilling it, the stock behind it, and whether the storefront can even reach it. Work through them in the order below — cheapest and most common first — rather than guessing which one it is. **Built this catalog by import, or with an AI-assisted or demo-store build?** Run this checklist once against a real date before assuming it's live. A bulk import or an automated build inherits whatever the tool auto-wired — default pricing rows, generated fulfilment rules, channel switches nobody chose on purpose — so a listing built that way can look complete in the admin and be unreachable on the storefront, with no record of the setting that caused it, because nobody set it deliberately. This is the "nothing about this listing works" version of the question. If you already know a specific stock item is involved and need to clear one date for one customer, [Check availability](/docs/guides/inventory/check-availability) is the shorter path. ## Prerequisites **Required permission:** listing view rights, pricing table view rights, location view rights, and stock item view rights. All four system roles — Owner, Admin, Manager and Member — hold every one of these. **Have ready:** which sales channel you're checking (Online store, Admin, or Check-in), which location, and — if this is about a specific date rather than the listing in general — the dates the customer tried. All three change the answer: the same listing can be sellable in one channel or location and not another. ## The Walkthrough Open the listing and start on **General** and **Publishing**. | Check | Where | What wrong looks like | | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Not published | General tab — **Status** is Draft, not Public | Invisible in every channel | | Archived | Listing is archived, not just Draft | Gone from the storefront and from the default Listings table — a different, more permanent state than Draft | | Wrong sales channel | Publishing tab — **Online store**, **Admin**, and **Check-in** are three independent switches | Works when you create an order in the admin, invisible on the storefront. The single most common report | | Not linked to a location | Publishing tab — **Store locations** has nothing attached | Nothing can fulfil it, so it has nowhere to be sold from | | Outside its duration or order-deadline limits (bookings only) | Limits tab — minimum/maximum duration, the increment, the order deadline | A request that falls outside any of these returns no bookable option, with nothing that looks broken | Duration and deadline limits are their own guide, not repeated here: [Purchase and booking limits](/docs/guides/catalog/purchase-and-booking-limits). This is the layer most often wrong, and the hardest to see, because the listing itself looks entirely correct. | Check | Where | What wrong looks like | | ----------------------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------- | | Row switched off | Pricing tab — a row's **Enabled** setting | Row visible to you in the admin, absent at checkout | | Row hidden | a row's **Hidden** setting | Priced, but never offered — same effect as switched off, different setting | | Restricted to certain weekdays (booking rows) | a row's available weekdays | Sellable Monday to Friday, silently dead at the weekend | | Restricted to a time of day (booking rows) | a row's time-of-day range | Morning bookings work, evening ones return nothing | | Outside its seasonal window | a row's validity period | A summer-only row still set to last summer | | No row at all for the purchase type being tried | Pricing tab | Priced to rent and not to buy, or the reverse, so that option never appears | Read more: [Price a listing](/docs/guides/catalog/price-a-listing) and [Build a price table](/docs/guides/catalog/build-a-price-table) cover how these rows are built and why a listing can carry more than one. Every check above can pass and the listing can still fail at the location it's meant to sell from. | Check | Where | What wrong looks like | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Location inactive or archived | the location's own status, under **Settings** | Every listing sold there disappears at once — rule this out before suspecting the listing | | Location not enabled for the channel | the location's own Online store / Admin / Check-in switches | The same trap as the listing's own channel switches, one level up | | Fulfilment not enabled for the way this is being sold | the location's fulfilment rules, set **per purchase type** | The one a merchant almost never thinks to check — a location can accept sale pickups and refuse rental pickups, or the reverse | | Fulfilment hours resolve to nothing | the location's pickup and return hours — following opening hours, offset from them, or a custom schedule | A custom schedule with no hours defined in it, or an offset buffer large enough to shrink the window to zero | | Closed that weekday | the location's opening hours | Nothing to check availability against on a day it's shut | | Timezone | the location's timezone setting | Off-by-one-day at the boundaries — an order deadline resolves in the location's timezone, not yours | Read more: [Locations](/docs/concepts/admin/locations) and [Availability](/docs/concepts/catalog/availability) cover how eligibility at a location is actually decided. A listing can be published, correctly priced, and sold from the right location, and still have nothing behind it. | Check | What wrong looks like | | ------------------------------------------------------------ | -------------------------------------------------------------------- | | A fulfilment rule matches nothing | The rule exists and resolves to zero stock items | | A rule needs more units than exist | The rule wants 2, one unit exists, availability is zero | | One variant has no matching rule | One variant sells fine, another never does, same listing | | The stock itself is inactive or archived | Contributes no capacity even though it's visibly in inventory | | Buffer time closes the gap | Back-to-back orders become impossible without anything looking wrong | | Already committed to another order, or held by a reservation | Looks free on a quick glance, isn't free on the calendar | This layer is covered field by field elsewhere — read [Listing inventory rules](/docs/guides/catalog/listing-inventory-rules) for writing and checking a rule's matches, and [Check availability](/docs/guides/inventory/check-availability) for working a specific unit and date once you suspect this is the layer. Everything above can be correct and a customer can still never find the listing, because nothing points at it. | Check | What wrong looks like | | ---------------------------------------------------------------------- | ------------------------------------------------------------ | | Not in any collection the storefront's navigation or homepage links to | The listing is sellable, and nothing on the site leads to it | | Storefront not published for this channel | The whole store is unreachable, not just this listing | | This isn't the store's primary domain | Reachable at one URL, not the one being tested | A listing found this way is not broken — it just has no path leading in. Add it to a collection the navigation actually links to, or link it directly, and it starts selling with nothing else changed. ## How do I know it worked? Browsing the storefront as a customer would — same channel, same location, same dates — you can see: * The listing shown in its channel, at the location you checked. * The correct price and purchase options for the dates you tried. * A path to the listing from the storefront's own navigation, without knowing the direct URL. "It should work" is not one of these three. If you get there, name which layer actually failed — the fix belongs on that layer, not on a guess. ## Troubleshooting / Common Pitfalls **Cause:** the Publishing tab's sales-channel switches are independent. Admin can be on while Online store is off, so an order draft succeeds while the storefront shows nothing. **What to do:** open the Publishing tab and check all three switches, not just the one you assume is relevant. **Cause:** the active pricing row's available weekdays don't include the day being requested. This is the single most common way a rate-based listing goes quiet on specific days, and nothing in the admin flags it as an error. **What to do:** open the Pricing tab and check which weekdays each row actually covers, not just whether a row exists. **Cause:** a location's fulfilment rules are set per purchase type. A location can accept pickup for a sale and refuse it for a rental without anything else about the location looking wrong. **What to do:** check the location's fulfilment rules for the specific purchase type being tried, not fulfilment in general. **Cause:** on a listing with more than one fulfilment rule, all of them must resolve — one rule with nothing free blocks the whole listing regardless of how much stock the others have. **What to do:** check each rule's match count separately rather than the total. See [Listing inventory rules](/docs/guides/catalog/listing-inventory-rules). **Cause:** this is almost always the storefront layer, not a configuration error on the listing at all. A sellable listing with no collection linking to it, and no direct link anywhere on the site, is unreachable by browsing even though a direct URL works. **What to do:** check which collections the listing belongs to, and whether the storefront's navigation or homepage actually links to any of them. **Cause:** an automated build sets every field it touches, including the ones a person would have set deliberately — default pricing rows, generated fulfilment rules, channel switches. None of these are wrong in the sense of being invalid; they're just not what the catalog actually needs. **What to do:** run this checklist once per listing type against a single real date before assuming the catalog is live, rather than discovering the gaps one support ticket at a time. ## Related articles The model behind every check in this guide. The shorter path when you already know the stock item and the date. Writing and checking the rules that bind a listing to stock. The duration and order-deadline settings behind the first check. Fulfilment rules, hours, and the channel switches a location carries of its own.