A faster alternative to heavy WoodMart AJAX filters

Layered nav in WoodMart typically loads the full filter tree up front, refetches the whole product loop on each change and re-runs theme scripts (swatches, quick view, wishlist) on every result set. On a 3G-class phone with a few thousand SKUs that shows up as visible lag between tapping a filter and seeing products.

Filtered combinations can create a large number of near-duplicate URLs, or the opposite — states held only in JavaScript that Google never sees. Neither is ideal:

• Uncrawlable filters hide legitimate landing pages (e.g. "red leather sofas")
• Unbounded filter URLs waste crawl budget and dilute signals
• Inconsistent canonicals send mixed instructions to search engines

If filtering is slow only because of oversized images, an uncached query or one heavy third-party script, the pragmatic fix is Redis object caching, correctly sized thumbnails and cutting the filter widget down to the four or five attributes shoppers actually use — not a rebuild. That path stops working once the catalogue passes roughly 10,000 variations or the filter set spans more than a handful of taxonomies, because the query cost grows faster than caching can hide it. A free audit tells you which side of that line you are on before you spend on migration.

On a Next.js storefront, chosen filters become real, indexable URLs where you want them (curated attribute pages) and JavaScript-only state where you don't. Results render server-side for the first paint, then update client-side without a full reload, so filtering feels instant while WooCommerce keeps serving product and stock data through the API.

The biggest missed opportunity in WoodMart's default filtering is not speed, it is SEO upside. Combinations like "red leather sofas" or "waterproof hiking boots size 10" are real searches with buying intent, but as ephemeral AJAX states they can never rank. The better model promotes a curated set of these high-demand combinations into genuine landing pages: a stable URL, a descriptive heading and short intro, and the filtered products beneath. Instead of thousands of thin parameter URLs, you get a handful of pages built to win specific searches — while every other filter combination stays usable but out of the index.

A practical frustration with WoodMart AJAX filters is that they often break browser history: a shopper filters, taps into a product, hits back, and lands on the unfiltered category having lost their selection. Encoding filter state in a real URL fixes this. Back and forward behave as expected, a filtered view can be bookmarked or shared with a colleague or customer, and returning to the link reproduces the same results. It is a small change that removes a recurring source of lost sessions on large catalogues.

On a large catalogue, filtering and search solve different intents, and knowing which to invest in matters. Filters serve shoppers who are narrowing by known attributes — size, colour, price. Search serves shoppers who arrive with a specific query in mind. WoodMart's default site search is a `LIKE` query against post titles and content, which gets both slow and imprecise once the catalogue passes a few thousand SKUs. Past that size, spend on a search index before you spend on another filter: a typo-tolerant, relevance-ranked index recovers the shoppers who typed a part number and got nothing, and no amount of filtering reaches them. Keep URL-based filters for browsing and add the index for intent-driven search. Under about 500 products this is the wrong priority — default search is adequate at that size, and the money belongs in the product pages instead.

We inventory your current attributes and filter combinations, decide which deserve crawlable pages, map redirects for any old filter URLs, and rebuild the filter UI as a lean component. WooCommerce stays the source of truth for attributes, prices and inventory, and we launch only after crawl and analytics checks on staging.