euroboxx is a parts catalogue built in WordPress and Elementor where search, filtering and checkout stay out of the buyer’s way — and stay fast as the catalogue grows. Catalogue sites fail differently to brand sites: nobody is browsing for pleasure, everyone arrives knowing roughly what they need, and every extra second or extra click between arriving and finding it is a lost order.
The brief
A parts buyer is not a casual visitor. They have a part in mind, often a number, and they are comparing two or three suppliers in adjacent tabs. The site’s entire job is to confirm quickly that the part is here, that it is the right one, and that ordering it is straightforward.
That inverts the usual priorities. Visual impact matters far less than it does on a brand site; retrieval speed matters far more. A catalogue that looks superb and takes five seconds to filter loses to a plain one that responds instantly.
The problem
Finding, not browsing
Category navigation alone does not serve someone who already knows what they want. Search has to handle part numbers, partial numbers and plain-language descriptions, and it has to return something useful rather than an empty page when the match is imperfect.
Filtering that stays fast as the catalogue grows
Filtering is cheap to build and expensive to get wrong. A naive implementation is fine at two hundred products and unusable at two thousand, and the failure arrives gradually enough that nobody notices until customers complain.
Weight that scales with the listing
A category page showing sixty products is sixty images, sixty sets of markup and however much JavaScript the builder decided to attach to each. Page weight on a catalogue is not a fixed cost — it multiplies with the listing, which is exactly where builder-heavy sites fall over.
Checkout that doesn’t editorialise
A trade buyer wants to get to the end. Every upsell, every account-creation wall and every extra confirmation step is friction placed between them and an order they had already decided to make.
How I built it
01 · Put search where it cannot be missed
Search sits in the header on every page and every breakpoint, not tucked behind an icon on mobile. It handles part numbers and partial matches, and a query with no exact hit returns near matches and the relevant category rather than a dead end.
02 · Filter on indexed fields, not on everything
Product attributes are structured and indexed, so filtering queries a prepared index rather than scanning the whole catalogue. Filter state lives in the URL, which means a filtered view can be bookmarked, shared with a colleague, or sent by a salesperson — and it also means the back button behaves the way people expect.
Building it this way costs a little more at the start and is the difference between a catalogue that still responds instantly at several thousand products and one that has to be rebuilt.
03 · Keep the listing markup lean
Product cards on listing pages are rendered by a purpose-built custom Elementor widget rather than a stack of nested containers. One card’s worth of saving is trivial; sixty cards’ worth is the difference between a page that feels immediate and one that does not.
Images are WebP, sized for the card rather than scaled down from something larger, with explicit dimensions so the grid does not shift as it loads, and lazy loading below the fold.
04 · Shorten the path to the order
Guest checkout, the minimum number of fields, no forced account creation, and no interruptions between the basket and the confirmation. Clear stock and delivery information shown before checkout rather than discovered inside it, because a surprise at the payment step is where trade buyers abandon.
05 · Make it maintainable by the people who run it
Adding a product is filling in fields; the listing, the filters and the card layout all follow automatically. Nobody has to touch a layout to add stock, which means the catalogue stays current — the single most important property a catalogue has.
What this means for a similar project
If you are planning a catalogue build, the decisions that determine whether it works are structural and are made early: how product attributes are modelled, whether filtering queries an index or the whole catalogue, and how much markup one product card emits. Visual design matters, but it is not where these sites are won.
The honest test is to imagine the catalogue at ten times its current size and ask which parts still work. Anything that fails that test should be built differently now, because retrofitting it later means rebuilding the listing, the filters and the templates together.
Build notes
- Stack — WordPress, Elementor flex containers, custom theme
- Search — header-level on all breakpoints; part numbers and partial matches
- Filtering — indexed attributes, filter state held in the URL
- Listing — custom widget for product cards; WebP, card-sized, lazy below fold
- Checkout — guest checkout, minimum fields, no forced account creation
Building or fixing a catalogue?
Tell me roughly how many products and what people search by. I’ll tell you which parts need to be structural and what it will cost. Or book a 15-minute call and we will talk it through.