Sklep meblowy ze średniej wielkości katalogiem (około 3400 aktywnych indeksów, głównie sofy, stoły i systemy szaf) przez dwa lata rósł wyłącznie na klasycznym SEO. Wiosną 2026 właściciel zauważył coś, czego nie widział w Search Console: klienci zaczęli przychodzić z rekomendacjami wypisanymi przez asystenta. Dzwonili z gotową listą modeli, pytali o konkretną głębokość siedziska, cytowali wymiary, których nie było w opisie na stronie. Problem polegał na tym, że część tych danych asystent zmyślił, a część wziął od konkurencji.
Ten materiał opisuje, co dokładnie zmieniliśmy w kartach produktu przez jedenaście tygodni i jak to przełożyło się na ruch z asystentów AI. To nie jest historia o skoku o 400 procent. To historia o tym, ile pracy wymaga doprowadzenie danych produktowych do stanu, w którym model językowy w ogóle ma co cytować.
Punkt wyjścia i stan kart produktu
Karty produktu wyglądały tak, jak wygląda większość sklepów meblowych w Polsce. Na górze galeria dziesięciu zdjęć aranżacyjnych, obok cena i przycisk dodania do koszyka, niżej dwa akapity opisu marketingowego napisane przez copywritera w 2023 roku. Wymiary siedziały w rozwijanej zakładce, ładowanej dopiero po kliknięciu przez JavaScript. Materiał obicia był podany jako nazwa handlowa tkaniny, bez informacji o składzie ani ścieralności.
Audyt zaczęliśmy od prostego testu: zapytaliśmy ChatGPT, Perplexity i Gemini o rekomendację sofy narożnej z funkcją spania, pojemnikiem na pościel i szerokością poniżej 280 cm. Sklep miał w ofercie siedem modeli spełniających te kryteria. Żaden nie pojawił się w odpowiedziach. Zamiast tego modele wymieniały produkty trzech dużych sieci, które te same parametry podają w widocznej tabeli specyfikacji.
Drugi test dotyczył marki. Zapytaliśmy wprost o konkretny model z katalogu sklepu. Dwa z trzech asystentów podały wymiary, które nie zgadzały się z rzeczywistością o kilkanaście centymetrów, a jeden przypisał produktowi materiał, którego nigdy nie było w tej kolekcji. To był moment, w którym rozmowa przestała dotyczyć widoczności, a zaczęła dotyczyć kontroli nad tym, co maszyna mówi o twoim towarze.
Braki w danych, które blokowały rekomendacje
Po przejrzeniu 120 losowych kart wyszła lista braków, która była zaskakująco powtarzalna. Najważniejsze pozycje wyglądały tak:
- Wymiary w formie ciągu tekstowego typu „wym. 240x95x88” bez rozbicia na szerokość, głębokość i wysokość jako osobne pola.
- Brak wymiaru powierzchni spania przy sofach rozkładanych, czyli parametru, o który klienci pytają najczęściej.
- Materiał opisany nazwą własną tkaniny, bez składu procentowego i bez klasy ścieralności w cyklach Martindale.
- Zerowa informacja o możliwości zmiany strony narożnika, mimo że w koszyku taki wybór istniał.
- Czas dostawy podany globalnie w stopce, nigdy na poziomie pojedynczego produktu.
- Brak jakiejkolwiek informacji o gwarancji i o tym, czy mebel wymaga montażu.
Wspólny mianownik jest prosty. Model językowy nie zgaduje parametrów, których nie widzi w tekście, i nie klika w zakładki ładowane skryptem. Jeżeli twoja konkurencja podaje głębokość siedziska w tabeli, a ty w pliku PDF do pobrania, to w porównaniu wygenerowanym przez asystenta nie istniejesz. Ta sama zasada rządzi indeksacją dużych katalogów, co opisywaliśmy szerzej przy indeksacji 12 tysięcy SKU pod AIO, gdzie wąskim gardłem również okazała się jakość danych, a nie ich ilość.
Nowa struktura karty produktu
Przebudowa objęła układ treści, nie warstwę wizualną. Właściciel z góry postawił warunek, że nie zmieniamy layoutu ani nie ruszamy galerii, bo konwersja z ruchu płatnego była dobra i nie chciał jej testować od nowa. Zmiana dotyczyła więc tego, co jest w kodzie i w jakiej kolejności.
Pierwszy blok pod ceną zastąpiliśmy tabelą kluczowych parametrów. Osiem wierszy, zawsze te same, zawsze w tej samej kolejności: szerokość, głębokość, wysokość, powierzchnia spania, pojemnik, materiał obicia, ścieralność, czas dostawy. Tabela renderuje się po stronie serwera i jest widoczna w źródle strony bez wykonywania JavaScriptu.
Drugi blok to krótkie podsumowanie w trzech zdaniach, napisane tak, żeby dało się je zacytować w całości. Nie zaczyna się od nazwy marki ani od przymiotnika, tylko od kategorii i najważniejszego wyróżnika, na przykład: „Narożnik z funkcją spania o szerokości 264 cm, z powierzchnią spania 200×140 cm i pojemnikiem na pościel”. Ten wzorzec pisania pod cytowalność opisywaliśmy w materiale o pisaniu pod wyciągi LLM.
Trzeci blok to sekcja pytań i odpowiedzi na karcie, cztery pozycje, generowane z atrybutów produktu. Pytania o montaż, o zmianę strony narożnika, o czyszczenie tkaniny i o termin dostawy. Nie są to pytania wymyślone przy biurku, tylko cztery najczęstsze tematy z transkrypcji czatu obsługi klienta z ostatnich sześciu miesięcy.
Opis marketingowy nie zniknął. Zjechał niżej, pod specyfikację, i został skrócony mniej więcej o połowę. Usunęliśmy z niego zdania, które nie niosły żadnej informacji weryfikowalnej, w rodzaju „elegancja w każdym calu”.
Dane strukturalne i atrybuty
Sklep miał wcześniej podstawowy znacznik Product z ceną i dostępnością, wygenerowany przez wtyczkę. Rozszerzyliśmy go o właściwość additionalProperty z tablicą obiektów PropertyValue, po jednym na każdy parametr z tabeli. To pozwoliło podać wymiary jako wartości liczbowe z jednostką, a nie jako fragment zdania.
Dołożyliśmy też material, color, width, depth i height jako właściwości natywne typu QuantitativeValue, zgodnie ze specyfikacją opisaną na schema.org/Product. Warto pamiętać, że dokumentacja Google Search Central wymienia tylko część tych pól jako wymagane do wyników rozszerzonych, ale asystenci korzystają z całego grafu, nie tylko z podzbioru premiowanego w SERP-ach.
Osobnym tematem były opinie. Sklep zbierał je w zewnętrznym widżecie, ładowanym z domeny dostawcy, przez co treść recenzji nigdy nie trafiała do kodu strony. Przenieśliśmy pięć najnowszych opinii do HTML i podpięliśmy pod review, zostawiając widżet jako element interfejsu. Efekt uboczny był natychmiastowy: strony produktowe urosły średnio o 180 słów unikalnej treści, bez pisania czegokolwiek nowego.
| Element | Przed | Po |
|---|---|---|
| Pola w znaczniku Product | 5 | 19 |
| Parametry widoczne bez JS | 2 | 8 |
| Średnia długość karty (słowa) | 310 | 640 |
| Karty z powierzchnią spania | 0% | 100% |
Zmiany w feedzie i dostępności
Feed produktowy dostał te same atrybuty co karta. To wydaje się oczywiste, ale w praktyce większość sklepów utrzymuje dwa niezależne zestawy danych, które rozjeżdżają się w ciągu kilku miesięcy. Ustawiliśmy jedno źródło prawdy w bazie i generowanie zarówno karty, jak i feedu z tych samych pól. Szczegóły takiego podejścia rozbieramy w tekście o feedzie produktowym dla agentów AI.
Druga zmiana dotyczyła dostępności dla crawlerów. Plik robots.txt blokował katalog /produkt/ dla wszystkich agentów spoza listy Googlebota i Bingbota, co było pozostałością po wcześniejszej walce ze scrapowaniem cen. Odblokowaliśmy GPTBot, PerplexityBot i ClaudeBot, zostawiając blokadę na ścieżkach koszyka i wyszukiwarki wewnętrznej. Bez tego kroku cała reszta pracy byłaby bezużyteczna, bo boty nie miałyby czego pobrać.
Trzecia zmiana była techniczna i nudna: karty produktu zeszły z renderowania po stronie klienta na renderowanie serwerowe. Czas do pierwszego bajtu spadł z 1,3 s do 0,4 s, ale ważniejsze było to, że treść przestała zależeć od wykonania skryptu. Podobny mechanizm, tylko z odwrotnym skutkiem, opisywaliśmy przy wypadnięciu 900 podstron przez paginację.
Wyniki: ruch, zapytania, sprzedaż
Pomiar prowadziliśmy przez 90 dni od zakończenia wdrożenia, porównując do 90 dni poprzedzających start prac. Ruch z asystentów wydzieliliśmy w GA4 na podstawie odsyłaczy z domen chatgpt.com, perplexity.ai i gemini.google.com plus parametrów kampanii, które te narzędzia doklejają.
- Sesje z asystentów AI: wzrost z 214 do 1690 w okresie 90 dni.
- Udział tego kanału w całym ruchu organicznym: z 0,7% do 4,9%.
- Transakcje przypisane kanałowi: 11 wobec 2 w okresie bazowym.
- Średnia wartość zamówienia z tego źródła: 3120 zł, czyli o 28% wyżej niż średnia sklepu.
- Ruch organiczny z Google: wzrost o 9%, w granicach normalnej sezonowości.
Ciekawsze od liczb jest to, jak zmieniły się zapytania. W testach powtórzonych po 60 dniach sklep zaczął pojawiać się w odpowiedziach na pytania zawierające konkretny parametr: „narożnik z powierzchnią spania 200 cm”, „sofa z pojemnikiem do 260 cm szerokości”, „tkanina o ścieralności powyżej 40 tysięcy cykli”. W pytaniach ogólnych typu „gdzie kupić dobrą kanapę” nie pojawił się ani razu i nadal się nie pojawia. To dość dokładnie pokazuje, gdzie leży realna szansa mniejszego sklepu: nie w konkurowaniu o zapytania ogólne, tylko w byciu jedynym źródłem, które ma odpowiedź na pytanie z trzema warunkami.
Znikły też halucynacje na temat wymiarów. W powtórzonym teście markowym wszystkie trzy asystenty podały poprawne parametry, powołując się na kartę produktu. Podobny efekt, tylko na treściach eksperckich zamiast produktowych, widzieliśmy przy pierwszych cytowaniach firmy szkoleniowej w Gemini.
Koszt wdrożenia i czas pracy
Uczciwy rachunek, bo bez niego case study jest reklamą. Prace trwały 11 tygodni kalendarzowych, z czego realnej roboty było około 190 godzin.
| Zakres | Godziny | Kto |
|---|---|---|
| Audyt i testy w asystentach | 18 | specjalista AIO |
| Uzupełnienie danych produktowych | 96 | zespół sklepu |
| Przebudowa szablonu i SSR | 52 | programista |
| Dane strukturalne i feed | 16 | programista |
| Pomiar i raportowanie | 8 | specjalista AIO |
Największa pozycja to nie technologia, tylko żmudne uzupełnianie atrybutów przez ludzi, którzy znają towar. Dwie osoby z obsługi klienta przez sześć tygodni wypełniały tabele, mierząc część mebli fizycznie w magazynie, bo dane od producentów bywały sprzeczne. Nikt tego nie zautomatyzuje modelem językowym, przynajmniej nie w sposób, któremu można zaufać przy parametrach wpływających na zwroty.
Wniosek dla podobnych sklepów jest taki: koszt wejścia w widoczność w asystentach to w 60% praca operacyjna nad danymi, a nie budżet na SEO. Jeżeli twój katalog ma komplet atrybutów, jesteś kilka tygodni od wyniku. Jeżeli nie ma, żadna optymalizacja treści tego nie nadrobi.
FAQ
Ile trwało, zanim pojawiły się pierwsze cytowania?
Pierwsze poprawne wskazania modeli z katalogu zobaczyliśmy w testach po około 5 tygodniach od wdrożenia SSR i odblokowania botów. Wcześniejsze zmiany w treści nie dawały efektu, dopóki crawlery nie mogły pobrać strony.
Czy trzeba było odblokować boty AI w robots.txt?
W tym przypadku tak, bo katalog produktów był zablokowany dla wszystkich agentów poza Googlebotem i Bingbotem. Bez tego kroku pozostałe prace nie miałyby żadnego przełożenia na widoczność w asystentach.
Czy przebudowa karty zaszkodziła konwersji?
Nie. Współczynnik konwersji z ruchu płatnego zmienił się o 0,1 punktu procentowego w dół, co mieści się w wahaniach tygodniowych. Układ wizualny i galeria pozostały bez zmian, przesunęliśmy wyłącznie kolejność bloków tekstowych.
Który parametr okazał się najważniejszy?
Powierzchnia spania przy sofach rozkładanych. Był to jedyny atrybut, którego nie podawał żaden z bezpośrednich konkurentów w segmencie, więc sklep stał się jedynym źródłem odpowiedzi na pytania zawierające ten wymiar.
Czy taki sam efekt da się osiągnąć bez renderowania serwerowego?
Częściowo. Kluczowe jest to, żeby specyfikacja była w pierwszym HTML zwracanym przez serwer. Można to osiągnąć także statycznym fragmentem wstrzykniętym do szablonu, bez pełnej migracji na SSR, choć wtedy trudniej utrzymać spójność z bazą.
Ile produktów trzeba uzupełnić, żeby zobaczyć wynik?
W tym wdrożeniu efekt pojawił się po doprowadzeniu do kompletu około 40% katalogu, przy czym były to najlepiej sprzedające się kategorie. Uzupełnianie długiego ogona dołożyło niewiele ruchu z asystentów.