Auto parts hosting for a catalogue nobody browses.
Nobody shops for a brake pad. They tell you a 2014 Golf and expect the site to know which of forty thousand parts fits it.
The search is the store.
A parts catalogue is not browsed by category. It is queried by vehicle, and that query is the only interaction that matters.
Year, make, model, and then the part
Each step narrows a compatibility table with millions of rows. Those lookups are indexed for the exact sequence customers work through rather than for the catalogue's own structure.
Compatibility data larger than the catalogue
One part fits two hundred vehicles, so the fitment table dwarfs the product table. It is stored and queried as its own dataset rather than as product meta.
A wrong fit is a return
Showing a part as compatible when it is not costs a return, a refund and the customer. Fitment data updates are applied as a whole rather than partially.
Supplier catalogues that import fully
Parts data arrives as large periodic files covering the whole range. Imports run as batches so a full update completes instead of leaving the fitment table half current.
Roll back a bad fitment update
A wrong compatibility file is worse than an outdated one, because it actively sells the wrong part. Daily backups make it reversible.
Millions of rows, three clicks.
A customer answers three questions and expects an exact answer. Behind that is a join across a compatibility dataset far larger than the products it describes.
- Fitment lookups indexed for the customer's sequence
- Compatibility stored as its own dataset
- Fitment updates applied atomically
- Supplier imports run as complete batches
Three dropdowns, one answer.
The measure for a parts store is how long the last dropdown takes, because that is the query that touches the whole compatibility dataset.
What we change for parts stores
One relationship drives everything: parts to vehicles, many to many, and much bigger than the catalogue itself.
| Setting | What we do | Why |
|---|---|---|
| Fitment storage | Held as its own dataset rather than as product meta | A single part fits hundreds of vehicles, so storing compatibility as meta rows makes the postmeta table larger than the store and unqueryable at speed. |
| Lookup indexing | Indexed for the year, make, model, part sequence | Customers narrow in that exact order, so indexes built for the catalogue's own hierarchy answer a question nobody is asking. |
| Fitment updates | Applied atomically rather than row by row | A partially applied compatibility file sells the wrong part with confidence, which is more expensive than showing nothing at all. |
| Supplier imports | Full-range files processed as batches | Parts data arrives as complete periodic catalogues, and a run that stops leaves half the range describing last quarter's fitment. |
| Search fallbacks | Part number lookup kept separate from vehicle lookup | Trade customers arrive knowing the part number and should not be forced through a vehicle selector built for consumers. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why is my year/make/model lookup slow?
How big does compatibility data get?
What happens if a fitment import fails half way?
Can trade customers search by part number?
Answer the fitment question first.
Move the parts store across - migration is free, fitment data included.