Anyone who sells through an online car parts store knows that buyers here do not browse: they arrive with a particular car and a part to replace. If they cannot find out quickly that the brake pads on the screen fit their car, they leave, and if they are told wrongly, the part comes back at your expense.
The starting point is usually one of two situations: either you have a warehouse and a catalogue kept in your stock management software, or you work with distributors’ goods and receive files with prices and stock levels from them.
Search by make, model, engine and part number
There are two kinds of buyer. The driver picks the make, model, year of manufacture and engine, then sees only the parts that fit. The mechanic types in a number: the vehicle manufacturer’s original number (known as OE), the parts manufacturer’s own number or an equivalent number. Search has to forgive the way people type, so that “AB 123-456” and “ab123456” lead to the same part.
Compatibility is a link between the part and vehicles, not a piece of text in the description. The data comes either from the supplier or from a licensed catalogue such as TecDoc, a database widely used in the industry to link parts to vehicles. You obtain the licence from the data provider; we build on the source you have.
- Vehicle selector: make, model, generation, engine, with the choice remembered for the whole visit.
- Compatibility table on the part’s page, with the fitting restrictions (front axle only, for example).
- Equivalents: the same part from other manufacturers, at different price points.
A catalogue fed from supplier feeds
A large catalogue is not entered by hand. Suppliers provide feeds, meaning files or interfaces (CSV, XML, API) with products, prices and stock. We write the import separately for each supplier, because each has a different structure and a different way of writing part numbers.
The full import (names, images, compatibility) runs rarely. Price and stock are updated often and separately, touching only what has changed. When the same part is available from two suppliers, a rule you choose decides which of them it is sold from.
On the part’s page, the stock information tells the truth. “In our warehouse” means the part can leave straight away; “at the supplier” means a lead time for bringing it in, shown next to the price and repeated in the basket.
- Markup rules: by supplier, by brand or by price band.
- Import log: what changed and which rows were rejected.
- Products that have disappeared from the feed: taken off sale, not deleted, so that their page addresses do not return an error in Google.
Online car parts store with tens of thousands of products: what keeps it fast
At volumes like these, WooCommerce (the store built on top of WordPress) runs well only if it is prepared from the start. Compatibility records, which can mean hundreds of rows for a single part, are kept in our own database tables, with indexes, not in WordPress’s general-purpose fields, which become slow.
We move search to a dedicated engine such as Elasticsearch, Meilisearch or Typesense: software made specifically to search large catalogues quickly and to tolerate typing mistakes. Pages are served from cache (a copy prepared in advance), and imports run in the background, in batches. A catalogue like this needs a server with its own resources, not a shared hosting package.
The part that does not fit: returns, warranties and exchange parts
However good the search is, some parts come back: the same car can have two versions of brake pads, depending on its specification. Before the order, we display the fitting restrictions and prompt the buyer to compare the number on the old part. A return is requested from the account, and over time you see which parts and which suppliers produce the most mismatches.
The conditions for parts that have been fitted, electrical parts or parts brought in to special order, the right of withdrawal and the warranty are written together with a lawyer. So are the rules for parts sold “on exchange”, where the buyer leaves a sum as a deposit until they hand in the old part; the store can show it separately from the price.
One supplier and one group of parts, then the rest
We do not start with the whole catalogue. We take a single supplier and a single group, brakes for example, and follow the route right to the end: import, compatibility, search, order, return. Only when it runs without intervention do we add the other feeds.
We state the limit from the outset: compatibility data that is incomplete in the feed stays incomplete in the store, until someone fills it in.
- Inventory of sources: which feeds you have, in what format, what compatibility data they contain.
- The imports and the pricing rules, tried out on real data.
- The vehicle selector and the search, tested with mechanics, not just by us.
- A gradual launch, with alerts when a feed stops arriving.
Frequently asked questions
Is it possible to search by chassis number?
It is, but decoding the number down to the exact specification requires a paid data service, separate from the store. Without it, you are left with a check done by someone on your team.
Can WooCommerce cope with a catalogue this large?
Yes, if the data structure, the search and the hosting are designed for volume. For catalogues in the hundreds of thousands of parts we also discuss the option of a custom-written application.
What does the timescale for a store like this depend on?
On the number of suppliers, on how tidy their feeds are and on the source of the compatibility data. The imports and the data cleaning usually take more time than the store itself.
This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.