Product Filters Show Zero Results After a Migration? Audit the Data Before Redesigning the UI
You can open a product by its direct URL, yet selecting its size, color or category produces “0 results.” After a migration, this usually means the filter query no longer matches the catalog data it searches. A new sidebar design will not repair a missing attribute mapping. Start with one known product and one filter that should return it.
Establish a reproducible example
Write down the product ID or SKU, the old and new product URLs, its expected category and attribute values, and the exact filter combination. Check whether the product appears in the unfiltered category, whether site search finds it, and whether its product page is published and available to the current market. These observations narrow the failure to catalog visibility, search index, filter mapping, or front-end state.
Check the product record and filter vocabulary
Migrations often transform labels. “Navy Blue” may become “navy-blue,” a size value may move from a variant option to a custom field, or a category ID may be replaced. The UI can still show an old label while the backend queries a new field. Compare the raw product record against the filter configuration: field name, field type, value, case, locale and variant scope.
Check a few products that work and a few that fail. If only imported items fail, inspect the migration mapping. If every item fails after a deployment, inspect the query builder or indexing pipeline. A product can also be excluded by market, stock status or publication rules even when the page is directly accessible.
Check index, URL and cache separately
If the records are correct, check when the search or faceted index last completed and whether import jobs failed. Reindex only after identifying the source data issue; otherwise the same bad values return. Inspect the actual network request made after selecting a filter and compare its parameters with the backend's accepted values. Clear or bypass caches for a controlled test, but keep a record of which layer served the stale response.
A bookmarked filtered URL may carry a legacy parameter from the old site. Test the filter from a fresh category page and from the old URL. Map or redirect old valuable paths deliberately, and avoid turning every filter combination into an indexable page. Google notes that faceted navigation can generate a very large set of URLs, so the crawl policy deserves a separate decision from the shopper-facing fix.
Repair, then verify a matrix
Fix the mapping or index and test single values and combinations: category plus size, color plus price, in-stock plus brand. Include a legitimate no-results case. The empty state should tell shoppers what happened and offer a way to clear filters. A failed query should not masquerade as a valid zero-results response; log errors separately.
Check the original URLs and important category pages after deployment. If the migration changed URLs, verify redirects and canonical signals. Product discoverability in search depends on those paths as well as a working storefront filter.
Frequently asked questions
Should an empty filtered page return 404?
That depends on whether it is a crawlable URL and your faceted-navigation policy. Shopper-facing empty states and HTTP responses to search crawlers serve different needs. Google recommends a 404 for crawlable filter combinations with no results in its faceted-navigation guidance; do not apply that mechanically to an in-page UI state.
Will reindexing alone fix it?
Only if the source values and query mapping are already correct. Inspect a sample record first so you do not rebuild an index from faulty migrated data.
Comments