Jubiler Pagacz - sklep WooCommerce z wyszukiwarką diamentów

Punkt wyjścia

Salon przy ul. Bazarowej w Bielsku-Białej sprzedaje dwie różne rzeczy. Pierwsza to biżuteria z gabloty - łańcuszki, kolczyki, obrączki, rzeczy, które można sfotografować i wystawić. Druga to diament pod pierścionek zaręczynowy: klient przychodzi z budżetem, a jubiler szuka kamienia u dostawców. Sklep online nie zastępuje tu wizyty w salonie - ma sprawić, że klient z Bielska-Białej w ogóle na tę wizytę trafi, o czym piszemy w tekście o pozycjonowaniu lokalnym.

To jest salon widziany od frontu. Ewidencja po drugiej stronie lady - magazyn, zlecenia, komis i skup metali - chodzi w osobnym systemie magazynowym, który zbudowaliśmy dla tego samego jubilera.

Sklep internetowy obsługujący tylko pierwszą część byłby połową firmy. Obsługujący drugą przez trzymanie diamentów na stanie - niemożliwy, bo to zamrożenie kapitału w towarze, który leży miesiącami. Zresztą sama decyzja, na czym stawiać taki sklep internetowy, zapada raz i zostaje na lata - a przy katalogu tej wielkości lepiej ją podjąć świadomie, tak jak rozpisaliśmy to w porównaniu WooCommerce i Shopify na polskim rynku.

Decyzje, które ukształtowały projekt

Wyszukiwarka diamentów zamiast magazynu diamentów

Katalog kamieni pochodzi z API Nivoda i jest przeszukiwany na żywo: ponad milion certyfikowanych diamentów, każdy z numerem GIA, parametrami szlifu, wideo 360° i ceną przeliczoną na złotówki wraz z ceną za karat. Jubiler nie ma na stanie ani jednego z nich.

To jest sedno tego projektu. Klient dostaje wybór większy niż w jakiejkolwiek gablocie w Polsce, sprzedawca nie zamraża pieniędzy, a wartość, którą wnosi jubiler - dobór kamienia, oprawa, gwarancja autentyczności - zostaje po jego stronie. Bez tej integracji strona byłaby katalogiem gotowej biżuterii, czyli tym, co ma każdy konkurent.

Motyw z rynku, nie pisany od zera

Warstwa sklepu stoi na Neve z dedykowanymi szablonami i stylami (prefiks jp-). Przy dziewiętnastu tysiącach produktów motyw pisany od podstaw oznacza samodzielne utrzymywanie zgodności z każdą aktualizacją WooCommerce - a te potrafią zmieniać szablony koszyka i checkoutu. Praca własna poszła tam, gdzie tworzy różnicę: w strony diamentów, listing produktów i wygląd salonu, a nie w odtwarzanie koszyka, który już istnieje.

Katalog zbudowany skryptem, nie przepisywany ręcznie

Dziewiętnaście tysięcy produktów w dziewięciu kategoriach nie powstaje przez wpisywanie ich po kolei. Dane wyjściowe - waga, rozmiary i układ kamieni - pochodzą z kart produktowych odlewni, zdjęcia schodzą skryptem razem z przypisaniem do kategorii, a opisy każdego wzoru są pisane od nowa zamiast kopiowane od dostawcy.

Ten ostatni krok jest tu najważniejszy. Opis przeklejony z katalogu producenta ma w Google dokładnie taką wartość, jaką ma setny identyczny opis tego samego pierścionka na setnej identycznej stronie.

Cache dobrany do rozmiaru katalogu

Dziewiętnaście tysięcy produktów to zapytania, których WooCommerce nie obsłuży w rozsądnym czasie bez warstwy cache. LiteSpeed Cache stoi przed sklepem; po każdej zmianie w treści leci purge, bo cache, którego nikt nie czyści, jest gorszy niż brak cache.

Nawigacja po cenie, nie tylko po kategorii

Obok podziału na pierścionki, kolczyki i naszyjniki menu ma progi cenowe: do 500 zł, 500-1 000, 1 000-2 500, 2 500-5 000 i powyżej. Przy takim katalogu połowa klientów wie, ile chce wydać, zanim wie, co chce kupić - i to jest dla nich pierwszy filtr.

Staging przed produkcją, z drogą powrotną

Push na main wchodzi na staging automatycznie, promocja na produkcję jest ręcznym krokiem w GitHub Actions. Oba środowiska chodzą w Dockerze na VPS, w repo leży skrypt rollbacku. Przy sklepie, który realnie przyjmuje zamówienia, „zobaczymy, czy zadziała” na produkcji nie jest metodą pracy.

Utrzymanie po starcie

Sklep z takim katalogiem wymaga stałej opieki. Kilka zmian z września:

Baner zgód jako okno na środku ekranu. W rogu strony prawie nikt go nie klikał. Po przeniesieniu banera do okna modalnego współczynnik konwersji kampanii lokalnej w odczycie z 28 września wrócił do 9,5%.

Katalog dostawcy bez niespodzianek. Produkty wycofane u dostawcy trafiają do sklepu jako brak w magazynie, a nie jako szkic. Strażnik katalogu ocenia zmiany progiem względnym, a nie stałą liczbą, i po trzech nieudanych przebiegach wysyła alarm. Jeden przebieg pobiera katalog raz, zamiast pięciu razy.

Porządek dla Googlebota. Usunięte produkty zwracają 410 zamiast 404, łańcuchy przekierowań 301 zostały spłaszczone do jednego skoku, a robots.txt jest cache’owany na dobę zamiast na godzinę. Tydzień po zmianach udział błędów 404 w ruchu Googlebota spadł z 16,8% do 2,9%.

Drobne rzeczy, które ktoś w końcu zauważa. Przełącznik języka EN/DE w nagłówku zaczął faktycznie tłumaczyć stronę, maile ze sklepu mają log wysyłek (wcześniej nie dało się sprawdzić, czy powiadomienie doszło), a serwer wysyła alarm, gdy wspólny dysk przekroczy 85%.

Co z tego wyszło

Pomiar strony głównej z 13 września 2026, headless Chrome bez cache: 33 ms do pierwszego bajtu, 304 ms do pierwszego renderowania treści, 855 ms do zdarzenia load. To dobry wynik jak na sklep z takim katalogiem - LiteSpeed Cache robi swoje przy pierwszym bajcie.

Uczciwa uwaga do reszty liczb: 86 żądań i 3953 kB transferu to dużo - jeden dokument, 18 arkuszy stylów, 34 obrazy, 21 plików JavaScript, 7 fontów i 5 zapytań XHR/fetch do wyszukiwarki diamentów. Przy sklepie z dziewiętnastoma tysiącami produktów i osobną integracją z Nivoda to nie jest skandal, ale też nie ma sensu udawać, że strona jest lekka. Rezerwa jest w obrazach i w liczbie arkuszy stylów - to miejsce, w którym można szukać dalszych ms, dokładnie tak jak opisujemy w checkliście Core Web Vitals. Nie mamy pomiaru sprzed wdrożenia, więc nie porównujemy z „przed” - to jest stan po uruchomieniu, nie dowód poprawy.

Technicznie

WordPress z WooCommerce w Dockerze na VPS, motyw Neve z warstwą dedykowaną (jp- w CSS, jp_ w PHP), LiteSpeed Cache. Integracja z Nivoda w inc/nivoda-api.php z własnym frontem wyszukiwarki. Wersje PL / EN / DE. CI/CD w GitHub Actions: main na staging, promocja na produkcję ręcznie, skrypty deployu i rollbacku w repozytorium.