The import succeeded, the catalogue count matches, and sales are down. Products can exist perfectly in an admin panel and be completely unreachable by a customer — here's how that happens.
"Imported" and "findable" are different states
Every migration post-mortem we've been called into follows the same shape. The import ran clean. The product count matches. Someone spot-checked a few items in the admin and they were all there. And then traffic to product pages fell off a cliff.
The gap is that an admin panel shows you what exists. It doesn't show you what a customer can reach. Those are separate things, and only the second one earns money.
The five ways a product hides in plain sight
1. Not published to the sales channel
Multi-channel platforms let a product exist while being switched off for the online store specifically. Imports frequently create products in this state by default. In the admin, it looks completely normal.
2. In no collection at all
If your storefront navigation is built from collections — and it almost always is — a product in zero collections has no path to it except the direct URL. It exists, it's published, and no browsing customer will ever land on it.
3. Automated collection rules that no longer match
This one is sneaky. Smart collections populate from rules based on tags, product type or vendor. If those fields changed shape during migration — a tag that was Mens becoming mens, or a product type that didn't carry across — the rule stops matching and the collection quietly empties.
4. Zero inventory with "hide when out of stock"
If inventory didn't migrate and your theme hides out-of-stock items, you get a catalogue that's technically complete and visibly empty. The products are fine. The stock numbers aren't.
5. Orphaned from navigation
Menus don't migrate with products. A collection that exists but isn't linked from anywhere is only reachable by typing its URL. Customers don't do that.
Why counting doesn't catch any of this
The standard post-migration check is a count: 1,240 products in the old store, 1,240 in the new one, done. Every failure above passes that test perfectly. The products are all present. They're just not reachable.
The check that actually matters: for every product, can a customer arriving on your homepage reach it by clicking? That's a different question from "does it exist", and it's the only one that correlates with revenue.
What a visibility audit checks
For each product, in order:
- Publish state — is it active, not draft or archived?
- Sales channel — is it switched on for the online store specifically?
- Collection membership — is it in at least one collection that exists and is populated?
- Navigation path — is that collection actually linked from the menu?
- Inventory — does stock reflect reality, given how your theme handles zero?
- Direct reachability — does the product URL return a real page, not a redirect loop or a 404?
- Indexability — is it excluded by robots rules or a stray noindex carried over from staging?
Run across the whole catalogue, that turns "the migration went fine" from an assumption into something you can actually evidence.
When to run it
Twice. Once on the development store before go-live, which is when fixing things is cheap. Once again immediately after go-live, because the act of publishing changes channel and theme behaviour in ways that only show up on the live store.
The pattern worth remembering
Migrations fail quietly far more often than they fail loudly. A crashed import is obvious and gets fixed within the hour. Three hundred products live but uncategorised produces no error anywhere — just a slow decline in a metric that takes weeks to attribute to the migration. Verifying reachability, not just existence, is what catches it.