Auto Delovi RM — web shop of body parts for all brands

Auto Delovi RM from Zaječar sells new body parts for passenger and light commercial vehicles. Bumpers, wings, hoods, headlights, brake lights, fog lights, masks, rear-view mirrors, underwings, sliders for sliding doors — everything that can be seen on the outside of a car and is most often changed after a collision. There is no physical storefront: orders are made through the website, payment is made by cash on delivery, and it is sent by courier throughout Serbia.

In the catalog there are 1,081 parts distributed in 29 categories, and the vehicle tree covers 69 brands and about 1,794 models. The largest group are rear lights, with about 350 items; other major groups include headlights, fog lights, engine guards, bumpers and sliders. The offer is not frozen — the owner supplements it himself, from the panel, and it can be seen on the site immediately.

According to their own description, three decades of work with drivers and craftsmen stand behind the store. What the business lacked was a web presence it owned. Until then, everything went through the ad platform, where competitors appear on the same page, ranking depends on someone else’s rules, and an algorithm change can make an advert disappear overnight.

The request was simple to say and not at all simple to execute: customers must be able to find a part for their vehicle in two clicks.

• Search by vehicle, rather than product name. Most customers do not know a catalog number; they know the make, model and year, and sometimes only have the VIN from the vehicle registration document.
• Each part needs its own page. It can then be shared, revisited and indexed. On someone else's platform, the part is one line in someone else's list.
• No cards and no advance payment. The buyer pays the courier; the site must not ask for a card number or account registration.
• The owner manages the offer himself. New parts, prices, images and promotions are all managed from the panel, including on a phone, without developer assistance.
• Same part for multiple vehicles. Ducato, Boxer and Jumper are the related vans built on the same platform. A slider that fits on one also fits on the other two, and the customer searches for it by its brand.

There was a condition that is easy to overlook: everything has to work on the phone, because most of the traffic comes from Facebook and Viber — small screen, weak connection, someone who has just photographed a damaged bumper and wants to see the price.

The offer on all parts page has filters by part type, make and model, year, side and position, with search and sorting by name and price. It works well for a customer browsing the catalog.

But a filtered catalog has limited value for search engines — it still presents a thousand variations under one URL. That's why there are dedicated URLs alongside it: the category page, the brand page, the brand and model page, and cross-categories with the brand and model. The query "brake lights for Golf 5" thus has a place to land, on the page with its title, its description and its list.

Each product page presents the information a repairer needs: vehicle and generation, year range, side and position, catalog number when available, price and human-written description. Below are parts for the same vehicle from the same group and a link to all parts for that vehicle — because the person who bought the headlight usually also buys the turn signal.

Parts that the owner wants to highlight are collected on the featured parts page, and sale items carry the old and new prices side by side. Categories, listings by vehicle, and individual parts have share buttons with the correct share URL in the server-rendered markup, rather than inserting it later, because it gets lost right when it's most needed.

The first version of the search looked for every typed word to match. That sounds about right until someone types in "rear light for Audi A4 04-07" and gets zero, or "bumper" and gets the entire catalog. The search was therefore rewritten from scratch and tested over the entire catalog.

• Empty words are ignored — for, from, to, should, urgent, please. A full sentence no longer prevents a useful result.
• The years from the query become the filter, not the text. "04-07" and "2006" narrow the year instead of being treated as literal text.
• The catalog number is read compactly — "1K0 853 677", "1K0-853-677" and "1K0853677" give the same result.
• Synonyms in narrow groups: fender and wing, rear-view mirror and mirror, indicator and turn signal, mask and grille. Deliberately narrow — a broad group of headlights, lights, lamps returned half the catalog.
• Cyrillic and accented Latin characters are normalized. Because of one missed letter, the query "citroen" returned zero, and Citroën has over eighty parts in its offer.
• Results are ranked by where the matching word appears in the name. "Front bumper" comes before "Rear bumper reflector". Without that, a search for “bumper” filled the first page with reflectors.

When the query really doesn't make sense, the site says there are no results. It doesn't dump the entire catalog — that's the fastest way to make a customer think the site doesn't understand them, so they go somewhere else.

The most common complaint concerned lost context, rather than a display error. A customer opens a product, shares it on Facebook, returns to the site — and finds an empty catalog. For each subsequent part, he must type the make and model again.

The reason was that the entire selection lived only in page memory and never reached the URL. The solution was to make the URL the single source of truth: every filter change is written to the URL, but through the history of the browser, without a new request to the server. This is important because the page has over a thousand parts, so a full refresh for each typed letter would be unusably slow.

In addition, the site remembers the selected vehicle. The magnifying glass in the header, the "Parts" item in the menu, and the return from the parts page lead back to the offer for that car, instead of an empty catalog. Every product page includes an “All parts for” shortcut with the name of the vehicle, right below the share buttons — where customers naturally look after returning from a shared link.

It's also worth saying that this was a series of small leaks, not a single bug: the header search sent the query but dropped the vehicle, the logo reset the selection, the back button could return to Facebook, and the category path dropped the selected model. Each of them seemed innocuous separately, but together they meant that the customer starts over on every visit.

Checkout is deliberately concise. The part is added from the card or from the product page, the total is shown in the basket, and checkout asks for a name, phone number and delivery address. No registration, no account, no password to remember.

Payment is by cash on delivery. For a store like this, it's not a disadvantage, but an advantage: lower cost, no other people's cards on the server and none of the card-handling obligations that come with online payments. In the note field, the buyer can enter the VIN, so compatibility is confirmed before the package leaves.

What is not visible: the price of the order is calculated by the server from its database, not by the browser. A cart that trusts the price from the browser is a store where a shopper can alter the price in the browser console. The order receives a unique reference, is entered into the database with all the items and immediately goes to the e-mail from the store's domain. The buyer gets confirmation, the owner gets the order — without waiting for someone to open the panel.

Forms that receive orders and inquiries limit the number of attempts from the same IP address. The first version of that limit trusted a request header supplied by the visitor, so it was circumvented by simply changing that value; attempts are now counted using the IP address established by the server. It's a mistake that's easy to make and hard to spot, because the limit still appears to work from the outside.

The site is a Next.js application that runs on the server, and the data is in the SQLite database: parts, brands, models, categories, orders, inquiries, all site copy and promotional banners. The database is accessed through the built-in module, without native plugins that break with every upgrade.

Why SQLite and not MySQL: a store of this scale has one writer and many readers. The entire content of the site fits into one file that is copied in seconds, and one less system means one less system that can crash. If the volume grows one day, the transition is a change to the data access layer, not a new site.

The application runs as a service under its own user, behind nginx, with its own domain and certificate, and with a complete email setup for that domain — signed messages, SPF and DMARC, so orders don't end up in spam.

All pages are server-rendered on every request. It was a decision that was once a problem, and an instructive one at that: while part of the page was not dynamic, the changes from the panel were visible on the homepage and not on the page About Us — the text was frozen at the time of creating the site, so the owner rightly reported that the panel was not working, although everything was written properly in the database. Since the entire site reads the database on every request, the change from the panel is visible immediately, without rebuilding or redeploying the site.

The catalog was initially imported from the ad platform, and 957 photos carried someone else's watermark across the middle. A new store cannot launch with someone else's name on every picture, and retouching a thousand product images by hand was not practical.

The watermark was not a single flat color, but a transparent layer with a white letter filling and a dark outline, in different proportions across the image — that's why only the outline was visible on the white background, and full white letters on the dark background. It was solved computationally: first, the watermark’s transparency and color were measured using samples placed over both pure white and very dark areas, so the watermark’s opacity, offset and scale were estimated for each image, then the overlay was mathematically removed. 951 images have been corrected; on 23, a visible trace remained and they were listed to be replaced by real photographs. Everything was done on a copy, with a full backup of the original.

The second half of the problem was that the images did not have a common frame — with widths ranging from 200 to 1,000 pixels, so in the same row one card was full and the other almost empty. Now every photo fits into the same 4:3 ratio frame, without cropping and without enlarging, and images uploaded through the panel are resized before transfer. A small image is not stretched to fill the frame, because a stretched image looks blurry and the owner notices it first.

One detail took time to resolve: copies of the same part for other vehicles share the same image file. Replacing the image for one van left the others with the old one. Now the panel itself tells how many parts use that image and offers to replace it everywhere, and that's the default behavior.

The most expensive mistake in this project was invisible to the naked eye. The site placed the title, description and canonical URL in the middle of the document instead of the document head. Bingbot got it right, but Googlebot and the regular browser didn't — the measurement showed that the title did not appear until roughly the 120,000th character of the response. The fix was a single line in the config, but the cause was found through measurement, not reading the code.

After that, what was really missing was added — pages by vehicle and pages by cross-category with vehicle. The query "rear light for Golf" previously had nowhere to rank. The sitemap has grown from about a thousand to 1,733 URLs, each with its own title, description and actual last-modified timestamp. Pages with too few parts are intentionally left out of the index: a page with a single part is an almost verbatim copy of that part's page, so two of our addresses would conflict with the same query.

In addition: titles shortened so as not to repeat the vehicle twice, Serbian forms with numbers ("1 part", "2 parts", "5 parts"), Product structured data without an invented price for parts that don't have one, and internal linking that leads from each product page to the indexed vehicle page instead of a filtered catalog that the robot doesn't index anyway.

Each change in the panel reports new and updated URLs to rapid indexing services, and the complete sitemap is submitted once a day. On 20 August 2026, Google Search Console reported 1,438 indexed URLs for this domain, for a domain registered in July of the same year.

The owner does not receive a generic content management system, but a panel designed around the work they actually do, including on a phone. It is installed as an app on a separate subdomain that is not indexed and does not interfere with the shop.

The panel contains parts, categories, makes and models with images, orders with line items and statuses, contact inquiries and all site copy. The copy matters more than it may seem: headings, section descriptions, opening hours, phone number and email address are changed in one place and update everywhere — in the header, footer, contact page and structured data read by Google. The same phone number previously appeared in seven places in the code.

Three features came directly from day-to-day feedback:

• Copying a part to multiple vehicles. The owner selects a make and several models, reviews the exact item names that will be created, and can reuse a clean product name instead of joining several vehicle names together.
• Replying to customers from the panel. Each order shows the requested part, its image and a link to the product page. A response written in the panel is sent as a genuine email from the sales address and stored with the order.
• Promotional placements. More than twenty positions are available across search, page headers, categories, product pages and the cart. Banners rotate three at a time on desktop and one at a time on mobile, follow a display schedule and link to the destination selected by the owner. They support the store’s own campaigns and can also be offered to selected partners.

The panel updates itself when something changes on another device. A persistent connection to a small service written without third-party libraries delivers the update without a manual refresh. It is a small feature that makes the difference between a panel people trust and one they reload constantly.

A store on its own domain, with its own email and database. There is no monthly subscription to the platform, no commission per sale, no third-party algorithm that decides whether someone will see it today. If the owner decides to move providers, the codebase and database can be copied and transferred with the business.

Practically, the day looks like this: a new part added in the panel appears in the catalog immediately and reported to search engines; the order arrives by email with every line item; the customer who sent the chassis number receives a reply before the package leaves; a promotion appears in a top-of-page placement and is removed automatically when its scheduled end date passes.

The site is still under active maintenance. Changes are applied to the live site, with a backup before each change and a real browser check afterwards. On this project, it paid off several times: a banner was present in the HTML but failed to render, a video was present in the HTML but blocked by the security policy, a button color was defined in a class but overridden by the CSS cascade. None of these failures is reliably visible through code inspection — it's only visible when the site is actually opened and measured.