# Selling car and motorbike parts online > In this trade the buyer isn’t looking for a product, they’re looking for what fits their car or bike. The whole shop architecture follows from that inversion, and it is what makes these projects unlike any other. - Source canonique : [https://allaux.fr/en/secteurs/pieces-detachees-auto-moto](https://allaux.fr/en/secteurs/pieces-detachees-auto-moto) - Langue : EN - Dernière mise à jour : 2026-09-30 ## The catalogue is indexed on the vehicle, not on the product A brake pad has no usable commercial name. It is found through a cascade: make, then model, then engine variant, then production years, then engine code. That path describes a many-to-many relation between catalogue references and vehicle types, and the number of pairs runs into the hundreds of thousands as soon as a catalogue gets serious. No e-commerce CMS ships that model: neither PrestaShop, nor WooCommerce, nor Shopify has any notion of a compatible vehicle. So you need a dedicated compatibility table, a cascading selector that queries it without reloading the whole page, and sometimes an extra entry point by number plate or VIN. That last one necessarily goes through a third-party service, since the information exists nowhere inside the shop. ## Constraints specific to spare parts - Sector data formats: TecDoc-style catalogues on the parts maker side, the national vehicle type approval code, the 17-character VIN. Using them means aligning an external reference set with your own. - Quarterly updates of those reference sets: a part number vanishes, a fitment changes, a maker renumbers a range, and existing product pages must not break because of it. - OEM and aftermarket equivalences: the same part carries a manufacturer reference plus several aftermarket ones. Internal search has to reach the product page from any of them. - Typing tolerance on those references: hyphens, dots and spaces sit in different places depending on the source and on the buyer. The cross-reference field has to be indexed in a normalised form. - Volume: across several hundred thousand references, native search and faceted filtering give way. On PrestaShop, rebuilding the search index becomes a project of its own, and moving to an external engine becomes a serious question. - Core charges and exchange units: an extra order line, refunded when the used part comes back. It is not a tax, not a product and not a discount, and it has to reach the invoice and then the refund. - Oversized shipping: bumpers, exhaust lines, pallet consignments, and tyres sold in sets with tapered carriage that follows no weight grid. ## How I work on this kind of shop 1. **Move fitment out of the product tables** — I put the vehicle-to-reference relation in a dedicated table, indexed on the columns the selector actually queries. It is the only way to keep response times workable as the number of pairs grows, and it stops the CMS feature tables from swelling to breaking point. 2. **Absorb the parts maker reference set** — The import goes through a mapping layer between external and internal identifiers, kept from one release to the next. A quarterly delivery can then be replayed on a test set, compared against what is live, and applied only once disappearances and renumberings have been identified. 3. **Normalise cross-references** — Each reference is stored twice: as shown to the buyer, and reduced to upper case with no separators, which is the only form used for comparison. Search then accepts all three ways of writing the same thing without returning empty pages. 4. **Offload search and faceting** — Past a certain volume the native index no longer holds. I move full-text search and filtering to an external engine fed asynchronously, so a category page no longer depends on core search queries or on their rebuild. 5. **Treat the core charge as a typed line** — The core charge becomes a dedicated cart line, excluded from discount rules, carried unchanged onto the invoice, and tied to the return of the used part so the refund stays traceable in the accounts. ## Neighbouring pages worth opening - **Large catalogue performance** — What breaks once the number of references exceeds what the CMS can take, and where to start. ([/expertises/performance-catalogue-volumineux-prestashop](/expertises/performance-catalogue-volumineux-prestashop)) - **Search misses an existing product** — Incomplete index, word too short, reference never indexed: the real causes behind an unreachable page. ([/prestashop/problemes/recherche-interne-ne-trouve-pas-produits](/prestashop/problemes/recherche-interne-ne-trouve-pas-produits)) - **Category filters gone** — How faceted filtering behaves as the catalogue grows or a category configuration changes. ([/prestashop/problemes/filtres-page-categorie-disparus](/prestashop/problemes/filtres-page-categorie-disparus)) - **Bulk product import** — What makes an import of several thousand rows fail, and how to make it replayable without duplicates. ([/prestashop/problemes/import-produits-masse-csv](/prestashop/problemes/import-produits-masse-csv)) ## Wrong fitment costs more than a lost sale > A delivered part that will not fit means a return, a refund, carriage both ways and a buyer who does not come back. Before opening a vehicle selector to the public I measure the real coverage of the compatibility table, and I would rather show fitment as unknown than as guessed. ## FAQ ### Can a part be found from a number plate? Yes, but not from the shop alone: matching a plate to a vehicle type comes from a third-party service queried over an API. The shop’s job is to turn that answer into an identifier the compatibility table knows, and to fall back on the manual selector when the service is down. ### Module or custom development for fitment? Off-the-shelf modules cover the simple case: a hand-entered list of vehicles attached to a product. As soon as an external reference set has to be absorbed, updated and served at scale, the table and the selector get built. ### How do manufacturer and aftermarket references coexist in search? By indexing a cross-reference field separate from the product’s main reference, and applying the same normalisation at index time and at query time: upper case, hyphens, dots and spaces removed. ### Can a core charge be handled with a dedicated product? That is the usual workaround and it holds badly: the product enters totals, discounts, carriage calculation and sales statistics. A typed order line takes more work but stays correct on the invoice and on the refund. ### At what volume does an external search engine become necessary? There is no universal threshold. The useful signal is the response time of a filtered category page and the duration of an index rebuild. Once the rebuild runs into hours and blocks other jobs, the question is settled. ### Are tyres handled like the rest of the catalogue? No. They vary by size, load index and speed rating, they often sell in sets of two or four, and their carriage follows a grid by quantity rather than by weight. It is a sub-catalogue with its own delivery rules.