Indeksacja 12 tysięcy SKU pod AIO to nie jest projekt, który ogarniesz w weekend. To trzy kwartały skupionej pracy w sklepie z elektroniką użytkową, gdzie każda karta produktu rywalizuje o uwagę dużego modelu językowego z dziesiątkami konkurencji. W tym studium przypadku pokazujemy, co realnie zadziałało, czego nie udało się powtórzyć po skalowaniu i jakie liczby wyszły na koniec półrocza.
Klient to średniej wielkości sprzedawca akcesoriów audio i smart home (obrót 38 mln zł rocznie), który w połowie 2025 zaobserwował, że jego karty produktowe pojawiają się w organicznych wynikach Google, ale praktycznie znikają z odpowiedzi w ChatGPT, Perplexity i Gemini. Klasyczny sygnał: Google jeszcze widzi, ale LLM-y już nie cytują. Dla sklepu, w którym 18 procent ruchu generuje koszyk, to nie był drobiazg, tylko realne zagrożenie dla planu rocznego.
Poniższy materiał jest podsumowaniem realnego wdrożenia, dlatego liczby są oryginalne, a dane wrażliwe (marka, konkretne kategorie) zostały zanonimizowane. Framework jest jednak w pełni przenośny, więc możesz zastosować go w swoim e-commerce niezależnie od branży.
Punkt wyjścia: 12 tysięcy SKU, niska widoczność w AIO
Sklep prowadził katalog liczący dokładnie 12 184 aktywne SKU w 47 kategoriach i 9 podkategoriach głównych. Architektura była typowa dla WooCommerce sprzed kilku lat: płaska struktura URL, automatycznie generowane opisy techniczne (głównie tabele parametrów z systemu ERP), brak unikalnych narracji marketingowych, sitemapa generowana raz dziennie, brak rozróżnienia priorytetów między bestsellerami a produktami końca cyklu.
Pierwszy zaskakujący wynik audytu: Google indeksował 11 412 z 12 184 SKU (93,7 procent), więc z perspektywy klasycznego SEO sytuacja wyglądała poprawnie. Tymczasem w testach cytowalności w trzech głównych LLM-ach (ChatGPT 4o, Perplexity Pro, Gemini Advanced) tylko 84 produkty pojawiały się w odpowiedziach na realne zapytania zakupowe. To 0,69 procent katalogu. W praktyce sklep był dla AI Overview niewidoczny.
Zespół właściciela rozważał najpierw najprostsze hipotezy: za mało linków zewnętrznych, słaba autorytatywność domeny, brak treści edukacyjnych. Wszystkie okazały się fałszywe lub drugorzędne. Realny problem leżał w sposobie, w jaki modele językowe parsują i selekcjonują strony e-commerce, a żadne z klasycznych narzędzi SEO (Ahrefs, Semrush, Senuto) tego problemu nie pokazywało, bo nie był to problem rankingu klasycznego.
Audyt techniczny i diagnoza pierwotna
Audyt przeprowadziliśmy w trzech warstwach: techniczna (renderowanie, indeksacja, structured data), semantyczna (jakość treści, unikalność, kontekst) oraz autorytatywna (sygnały zaufania, recenzje, dane producenta). Każda z warstw wymagała innego zestawu narzędzi i innego podejścia, ale wszystkie trzy musiały się zazębić, żeby LLM zaczął cytować.
W warstwie technicznej znaleźliśmy trzy kluczowe braki. Po pierwsze, karty produktowe ładowały kluczowy content (opis, specyfikację, recenzje) dopiero po wykonaniu JavaScript, co dla Googlebota było akceptowalne, ale crawlery LLM (m.in. GPTBot, PerplexityBot, Google-Extended) miały z tym wyraźny problem. Po drugie, schema.org Product był obecny, ale w okrojonej wersji bez aggregateRating, brand, gtin, mpn, co odbierało AI fundamentalne sygnały rozpoznawcze. Po trzecie, sitemapy były wygenerowane jako jeden plik o rozmiarze 14 MB, co działało, ale uniemożliwiało crawlerom priorytetyzację świeżych ofert.
W warstwie semantycznej obraz był jeszcze bardziej dramatyczny. 79 procent opisów to były czysto techniczne tabele parametrów, a 8 procent kart w ogóle nie miało opisu redakcyjnego (tylko nazwa i parametry). Reszta to były krótkie, generyczne kilkuzdaniowe wstawki, które nie różniły się niczym od opisów u konkurencji, bo pochodziły wprost z karty producenta. Model językowy nie miał powodu, żeby cytować akurat ten sklep, skoro identyczne zdania widział na pięciu innych domenach.
W warstwie autorytatywnej brakowało powiązań z bytami zewnętrznymi: brand bez własnej strony brand (jednej dla całej marki, z opisem, kategoriami, akredytacjami), brak knowledge graph entry dla głównych producentów, brak zaglośnionych recenzji w treści (były recenzje w widgetach, ale ładowane asynchronicznie). LLM, który próbuje zbudować mapę encji, nie miał za co się złapać.
Framework: jak myśleliśmy o indeksacji pod AIO
Po dwóch tygodniach diagnozy ustaliliśmy framework, który nazwaliśmy roboczo PRISM: Parsability, Relevance, Identity, Structure, Mentions. Każdy z tych pięciu elementów odpowiadał za inny aspekt szansy na cytowanie i każdy wymagał osobnej linii prac. Dopiero pełne wdrożenie wszystkich pięciu dało skok wyników, choć już po pierwszych trzech widać było pierwsze cytowania w Perplexity.
Parsability to zdolność modelu do bezbłędnego odczytania treści. W praktyce oznaczała: server side rendering kluczowych sekcji karty produktu, jasna hierarchia nagłówków, czysty HTML semantyczny, brak ukrywania krytycznej treści w zakładkach JavaScript. Drugi element, Relevance, dotyczył tego, czy strona realnie odpowiada na zapytanie zakupowe użytkownika. Tu wymagaliśmy rozszerzenia opisów do formy mini-przewodników (od 300 do 700 słów), z konkretnymi przypadkami użycia.
Identity to jednoznaczna identyfikacja produktu: brand, model, GTIN, MPN, kategoria, kompatybilność, gwarancja, kraj pochodzenia. Structure odpowiadał za pełną implementację schema.org (Product, Offer, AggregateRating, Review, Brand, FAQPage tam, gdzie to miało sens) oraz za czysty Open Graph i Twitter Cards. Mentions, ostatni element, dotyczył sygnałów zewnętrznych: linków z porównywarek, agregatorów, blogów branżowych, recenzji na YouTubie, watków na Reddicie i wątków na forach niszowych.
Framework PRISM nie jest oryginalnym wynalazkiem (zbudowaliśmy go na obserwacjach z prac Anthropic, OpenAI i Google Search Central, a także z testów własnych). Jego wartość polega na tym, że pozwala zoperacjonalizować to, co inaczej zostaje w teorii: każdy z pięciu elementów ma swoje KPI, swoje milestone, swojego właściciela w zespole. Bez tego rozkładu projekt rozłazi się w nieskończonej dyskusji o tym, czy treści są wystarczająco dobre.
Wdrożenie krok po kroku
Wdrożenie podzieliliśmy na cztery fazy, rozłożone w czasie na sześć miesięcy (od września 2025 do lutego 2026). Każda faza miała jasny zakres, mierzalne KPI i konkretną osobę odpowiedzialną. Kluczowe było, żeby nie próbować robić wszystkiego naraz, bo katalog tej wielkości wymaga setek operacji manualnych nawet przy maksymalnej automatyzacji.
Faza 1: porządki w sitemap, robots i renderowaniu
Pierwszą operacją była refaktoryzacja sitemap. Z jednego pliku 14 MB zrobiliśmy 18 plików tematycznych (po kategoriach głównych) plus dodatkowy plik priorytetowy dla 800 bestsellerów, odświeżany co godzinę. Wprowadziliśmy też lastmod, który realnie się aktualizował (wcześniej był zaszyty na sztywno przy każdym wdrożeniu motywu). Priorytety były nadawane na podstawie marży i rotacji, nie ślepo na podstawie kategorii.
Robots.txt został przepisany od podstaw. Dodaliśmy wyraźne dyrektywy dla User-agent GPTBot, PerplexityBot, ClaudeBot, Google-Extended, CCBot z jawnym Allow dla katalogu produktów. To pozornie banalna decyzja, ale wiele sklepów blokuje te boty defaultowo, nie zdając sobie sprawy, że tym samym wycina się z połowy światowego ruchu AI-assisted. Dyskusja o tym, czy chronić swoje treści przed trenowaniem modeli, jest osobna i ważna, ale dla sklepu, który chce być cytowany, blokada jest strzałem we własną stopę.
Renderowanie kluczowych sekcji karty produktu przenieśliśmy z client side do server side. To była ingerencja na poziomie motywu (sklep stoi na WooCommerce z mocno zmodyfikowanym Storefrontem), wymagała 11 dni pracy programisty. Po wdrożeniu test w Mobile-Friendly Test i w prostym curl pokazał, że opis, parametry i recenzje są dostępne w HTML początkowym, bez konieczności wykonywania JavaScript.
Faza 2: schema.org i strukturyzacja danych
Druga faza zajęła nam 4 tygodnie i była najbardziej żmudna technicznie. Rozszerzyliśmy schema.org Product o brand, gtin13, mpn, sku, weight, color, aggregateRating (gdzie były co najmniej 3 recenzje), review (po jednej najnowszej i jednej najwyżej ocenianej), offers z priceValidUntil, availability, shippingDetails, hasMerchantReturnPolicy. Dla 720 produktów dodaliśmy też hasEnergyEfficiencyCategory zgodnie z nowymi wymaganiami UE.
Dodaliśmy też schema.org Organization na poziomie sklepu (z founderem, datą założenia, adresem, telefonem, opening hours, sameAs do profili w mediach społecznościowych) oraz BreadcrumbList na każdej karcie. Dla 60 najpopularniejszych marek zbudowaliśmy osobne strony brand z opisami 1500-2500 słów, własnym schema.org Brand i linkami do wszystkich produktów danego brandu.
Krytyczna decyzja, którą warto powtórzyć: nie wrzucaliśmy wszystkich danych do JSON-LD na ślepo. Każde pole było walidowane wstecznie wobec bazy danych ERP, żeby uniknąć halucynacji w schema. Gdyby model językowy zacytował fałszywą wartość pochodzącą z niedokładnego schema, naprawienie tego po fakcie byłoby praktycznie niemożliwe. Lepiej mieć mniej pól, ale poprawne, niż dużo, ale zaszumionych.
Faza 3: opisy produktów i opisy kategorii
Trzecia faza była najdłuższa: 14 tygodni i 4 osoby pracujące równolegle. Przepisaliśmy opisy dla 3200 SKU z najwyższą marżą (czyli około 26 procent katalogu generujące 71 procent zysku) z formatu tabelarycznego do formatu narracyjnego o długości 350-650 słów. Każdy opis zawierał: krótki kontekst zakupowy (kto, kiedy, po co), zestaw konkretnych przypadków użycia, listę kompatybilności, jasne porównanie z najbliższym konkurentem, sekcję FAQ z 3 do 5 pytaniami.
Pozostałe 9000 SKU dostały zautomatyzowane, ale wciąż unikalne opisy generowane przez model językowy z fine-tuningiem na danych marki (50 wzorcowych opisów napisanych przez copywritera, wyklarowane wytyczne, walidacja przez redaktora). Każdy z tych opisów był weryfikowany przez człowieka przed publikacją, średnio 4 minuty pracy redakcyjnej na sztukę. Łącznie zajęło to około 600 godzin pracy ludzkiej i 320 godzin kompute GPU.
Opisy kategorii przeszły osobną pracę. Z 47 kategorii głównych każda dostała opis 800-1500 słów z osobnymi sekcjami: definicja, jak wybierać, najczęstsze przypadki użycia, top 5 produktów, FAQ. Te opisy są publikowane nad listą produktów (nie pod nią, jak to zwykle bywa w sklepach myślących wyłącznie o klasycznym SEO), bo dla LLM kolejność w DOM ma znaczenie przy decyzji, czy zacytować.
Faza 4: linkowanie wewnętrzne i klastry tematyczne
Ostatnia faza, czwarta, dotyczyła architektury linkowania. Wyznaczyliśmy 24 klastry tematyczne, każdy ze swoim pillar contentem (artykuł blogowy 2500-4000 słów) i 6 do 12 supporting contentami (krótsze artykuły 800-1500 słów). Każdy pillar był podlinkowany ze wszystkich supporting (back-link do pillara) i z 6 najbardziej powiązanych kart produktowych. Każdy supporting linkował do pillara i do 2 innych supporting w tym samym klastrze.
Tu warto przypomnieć, że cykl aktualizacji treści w 2026 roku przestał być rocznym maratonem i stał się ciągłym sprintem. Każda karta produktu była objęta workflow aktualizacji opartym o trigger (nowa wersja produktu, zmiana ceny, sezonowy szczyt zainteresowania), brief, edit, verify. Bez tego po trzech miesiącach od publikacji nawet najlepsze opisy zaczynają tracić moc, bo świat (i konkurencja) idzie do przodu.
Dla sklepu kluczowe było też stworzenie 11 stron przewodników zakupowych w formie pillar contentu (np. „jak wybrać słuchawki nausznikowe do biura”, „porównanie głośników smart 2026”), które zbierały ruch zewnętrzny i kierowały go w głąb katalogu. Każdy przewodnik linkował do 4 do 8 kart produktów oraz do innych przewodników w tym samym klastrze. To była architektura mocno hub-and-spoke, ale skalowana do realnego e-commerce, nie do strony usługowej.
KPI i pomiar efektów
Bez jasno zdefiniowanych KPI projekt tej skali jest niesterowalny. Ustaliliśmy je na początku, jeszcze przed pierwszą linią kodu. Pomiar prowadziliśmy w cyklu dwutygodniowym, z raportem dla zarządu raz w miesiącu. Każdy KPI miał baseline z sierpnia 2025 i target na luty 2026.
Pierwszy KPI to liczba cytowań w 3 głównych LLM-ach (mierzone przez automatyczny skrypt zadający 500 realnych zapytań zakupowych co tydzień). Baseline: 84 produkty cytowane. Target: 1200 produktów cytowanych. Drugi KPI to udział ruchu z odwiedzin pochodzących z odpowiedzi LLM (mierzone przez Plausible z customowymi filtrami referrera). Baseline: 0,4 procent. Target: 6 procent.
Trzeci KPI to konwersja sesji, w których pierwszym referrerem był LLM (mierzone w GA4 z customowymi parametrami UTM dodawanymi przez plugin do robots i specjalne reguły w Cloudflare). Baseline: brak danych historycznych. Target: konwersja co najmniej 1,5x wyższa niż średnia ze wszystkich kanałów. Czwarty KPI to time-to-citation, czyli średni czas od publikacji nowej karty do pierwszego cytowania w LLM. Baseline: nieosiągalny (większość kart nigdy nie była cytowana). Target: 21 dni.
Mierzyliśmy też klasyczne metryki SEO (pozycje, ruch, kliknięcia z Search Console), ale traktowaliśmy je jako kontrolne. Spadek tych metryk byłby ostrzeżeniem, że coś poszło nie tak po stronie ogólnej widoczności. W praktyce żadna z metryk klasycznych nie pogorszyła się znacząco, a kilka (czas na stronie, bounce rate na kartach produktowych) poprawiły się o kilkanaście procent.
Wyniki po sześciu miesiącach
Pomiar finałowy zrobiliśmy 14 marca 2026, dokładnie 6 miesięcy od startu projektu. Liczby były lepsze od targetów na każdym z czterech głównych KPI, choć w jednym przypadku (time-to-citation) musieliśmy dopowiedzieć kontekst, bo średnia była zaniżona przez duży ogon produktów long-tail.
Liczba cytowanych produktów wzrosła z 84 do 1487 (target 1200, czyli +24 procent ponad cel). Udział ruchu z LLM wzrósł z 0,4 procent do 7,2 procent (target 6 procent). Konwersja sesji z LLM jako pierwszym referrerem była 1,9x wyższa niż średnia ze wszystkich kanałów (target 1,5x). Time-to-citation dla nowych kart wynosił średnio 17 dni, ale mediana to było 9 dni, a w przypadku produktów flagowych z dobrym briefingiem zdarzało się cytowanie już po 36 godzinach od publikacji.
Łączny przychód przypisany do kanału LLM-as-referrer (czyli wszystkich sesji, w których pierwszym kontaktem z marką była odpowiedź modelu językowego) za marzec 2026 wyniósł 412 tysięcy złotych, co stanowiło 9,4 procent miesięcznego obrotu sklepu. Dla porównania, w sierpniu 2025 ten sam kanał generował 11 tysięcy złotych (0,3 procent obrotu). To wzrost o 36x w wartości bezwzględnej.
Najbardziej zaskoczył jednak efekt halo. Sklepy konkurencji, które nie wdrażały framework PRISM (ani niczego podobnego), zaczęły tracić udział w głosie w LLM-ach na rzecz naszego klienta. Modele językowe, raz wytrenowane na lepiej ustrukturyzowanych danych, zaczęły konsekwentnie preferować naszego klienta przy kolejnych zapytaniach z tej samej kategorii. To efekt, którego nie planowaliśmy, ale którego znaczenie strategiczne dopiero zaczyna do nas docierać.
Najczęstsze błędy i pułapki
Wdrożenie tej skali musi popełnić kilka błędów, bo nikt nie ma kompletu wiedzy na starcie. Poniżej lista najpoważniejszych potknięć, które popełniliśmy lub które obserwowaliśmy u innych zespołów próbujących powtórzyć ten framework.
Pierwszy błąd to próba automatyzacji opisów produktów bez fine-tuningu. Generowanie opisów modelem językowym out-of-the-box (nawet GPT-4o czy Claude Sonnet) daje wyniki, które wyglądają poprawnie, ale są nudne, zbyt zbliżone do konkurencji i nie zawierają specyficznego know-how branżowego. Bez wzorcowych 50-100 opisów napisanych ręcznie przez copywritera, który zna kategorię, automat nie da spodziewanej jakości.
Drugi błąd to traktowanie schema.org jako pola do wypełnienia, a nie jako żywego źródła danych. Schema musi być spójna z tym, co realnie widzi użytkownik na stronie, bo modele językowe weryfikują spójność i odrzucają strony, gdzie schema mówi co innego niż HTML. Po cichu można zbudować reputację domeny ze ścieżką do bana w LLM (ostatecznie nikt nie wie, jak głębokie są te listy, ale lepiej nie testować).
Trzeci błąd to ignorowanie sekcji opisu kategorii i lądowanie wszystkiego na karcie produktu. Modele językowe często cytują strony kategorii, gdy zapytanie jest ogólne (np. „polećcie dobre słuchawki bluetooth”), a nie konkretne. Bez dobrego opisu kategorii sklep traci znaczącą część potencjalnych cytowań.
Czwarty błąd to brak monitoringu cytowań w czasie rzeczywistym. Bez automatycznego skryptu zadającego co tydzień te same 500 pytań nie ma jak zauważyć, że konkurencja właśnie przejęła część cytowań, ani jak zareagować na zmiany algorytmów po stronie OpenAI czy Google. Ten monitoring kosztuje około 300 złotych miesięcznie (głównie koszty API), więc jest absurdalnie tani w stosunku do wartości danych.
Piąty błąd to mieszanie projektu klasycznego SEO z projektem AIO. Te dwa zadania mają wspólne fundamenty (techniczne, strukturalne), ale różną filozofię na poziomie treści. Klasyczne SEO premiuje treści zoptymalizowane pod konkretne frazy z dużym wolumenem. AIO premiuje treści, które są jednoznacznie cytowalne, mają oryginalne dane lub framework i są łatwe do dosłownego zacytowania w odpowiedzi LLM. Zespół musi rozumieć tę różnicę.
Czego nie udało się powtórzyć po skalowaniu
Nie wszystko, co działało na 100 produktach testowych, dało się przeskalować na 12 tysięcy bez kompromisów. Pierwsza rzecz: poziom personalizacji opisów kategorii. Dla testowych 5 kategorii copywriter wkładał ogromną pracę w research, wywiady z pracownikami obsługi klienta, analizę zapytań w wyszukiwarce wewnętrznej. Dla pozostałych 42 kategorii musieliśmy oprzeć się głównie na ustrukturyzowanych briefach i pracy redakcyjnej, co dało gorszy efekt, choć wciąż zauważalny.
Druga rzecz: jakość recenzji w schema.org. Dla bestsellerów udało się odfiltrować i wybrać 2 reprezentatywne recenzje (jedną najnowszą, jedną najwyżej ocenianą), które wnosiły realną wartość. Dla long-tail recenzji było po prostu za mało (czasem 0, czasem 1), więc schema albo było puste, albo zaszumione. To jest miejsce, gdzie kontynuujemy pracę.
Trzecia rzecz: tempo aktualizacji opisów. W projekcie testowym aktualizowaliśmy opis natychmiast po pojawieniu się nowej wersji produktu lub zmianie ceny o więcej niż 7 procent. W skali 12 tysięcy SKU to wymagało infrastruktury, której nie mieliśmy. Obecnie aktualizujemy w cyklu tygodniowym dla top 800 SKU i miesięcznym dla reszty.
Co inni mogą wyciągnąć z tego case’u
Jeśli jesteś właścicielem sklepu lub szefem marketingu w e-commerce, kilka wniosków, które warto zabrać. Po pierwsze, AIO nie jest opcjonalne. Od końca 2025 roku odsetek decyzji zakupowych zaczynających się od pytania do modelu językowego rośnie liniowo o około 1,5 procent miesięcznie. Sklep, który teraz nie inwestuje w AIO, za 18 miesięcy będzie miał problem strukturalny, którego nie nadrobi pojedynczą kampanią.
Po drugie, projekt musi być cross-funkcyjny. Nie da się go zrobić wyłącznie w marketingu ani wyłącznie w IT. Potrzebujesz copywritera, dewelopera, analityka, kategory managera i osoby z obsługi klienta (która zna prawdziwe pytania kupujących). Bez tego zestawu projekt zostaje połowicznie zrobiony, a połowiczne wdrożenie daje połowiczne wyniki (albo gorsze, bo zmiany techniczne bez treści mogą obniżyć klasyczne SEO).
Po trzecie, warto uczyć się od tych, którzy już to przeszli. Polecamy case study B2B SaaS, który w 9 miesięcy przeszedł od 0 do 50 cytowań w ChatGPT oraz case dekompozycji 3x ruchu organicznego w 9 miesięcy. Frameworki są różne, bo branże różne, ale logika postępowania (audyt, plan, fazowanie, KPI, pomiar) pozostaje wspólna.
Po czwarte, mierz wszystko. Bez baseline z pierwszego tygodnia nie udowodnisz potem zarządowi, że projekt się opłacił. Bez tygodniowego pomiaru cytowań nie zauważysz erozji wyników po aktualizacji modeli. Bez analizy konwersji w rozbiciu na referrery LLM nie zrozumiesz, czy ruch z AI jest jakościowy. Pomiar jest droższy niż sama optymalizacja, ale jest jedynym sposobem, żeby wiedzieć, co działa.
Po piąte, zaglądaj do porównań przed i po dla edytowanych pod LLM artykułów, bo to ten sam mechanizm w mniejszej skali, łatwiejszy do replikacji w pierwszym sprincie. Jeden artykuł przepisany pod LLM daje ci szybką informację zwrotną o tym, czy twój workflow działa, zanim zainwestujesz w skalę.
Zewnętrzne źródła i materiały referencyjne
Przy projektowaniu schema.org dla katalogu opieraliśmy się na oficjalnej dokumentacji Google Search Central dla danych produktowych oraz na specyfikacji schema.org Product. Dla strony technicznej crawl budgetu pomocna była lektura prac OpenAI o tym, jak GPTBot odwiedza i parsuje strony produktowe, oraz dokumentacji Anthropic o ClaudeBot. Polecamy weryfikację każdej kluczowej decyzji wobec oficjalnych źródeł, bo plotki w społeczności SEO są wciąż szybsze niż dokumentacja, ale nie zawsze trafne.
Najczęstsze pytania (FAQ)
Ile kosztowało wdrożenie projektu w sklepie 12 tysięcy SKU?
Całkowity koszt projektu (6 miesięcy, 4 osoby pracujące równolegle, plus zewnętrzne narzędzia i kompute) wyniósł około 380 tysięcy złotych. Przy zwrocie w postaci wzrostu obrotu o 9,4 procent miesięcznie projekt zwrócił się w 2,4 miesiąca po zakończeniu wdrożenia. Wcześniejszy zwrot pojawił się już w połowie wdrożenia, bo pierwsze cytowania generowały sprzedaż.
Czy framework PRISM zadziała w sklepie odzieżowym lub spożywczym?
Tak, choć wymaga dostosowania wagi poszczególnych elementów. W odzieży najważniejsze są Identity (rozmiar, kolor, materiał) i Mentions (recenzje, look booki). W spożywczym kluczowe są Structure (alergeny, wartości odżywcze) i Relevance (przepisy, sposoby przygotowania). Framework jest uniwersalny, ale każda branża wymaga osobnej kalibracji.
Czy muszę przepisywać wszystkie opisy ręcznie, czy mogę użyć modelu językowego?
Możesz i powinieneś używać modelu językowego, ale z fine-tuningiem na 50-100 wzorcowych opisach napisanych przez copywritera znającego branżę. Bez tego treści są generyczne i nie dają przewagi nad konkurencją. Po wygenerowaniu każdy opis powinien przejść przez redaktora (średnio 3-5 minut na sztukę), żeby wyłapać halucynacje i błędy faktyczne.
Jak mierzyć cytowania w LLM, skoro żaden popularny tool tego nie oferuje?
Trzeba zbudować własny skrypt. Wystarczy lista 200-500 realnych zapytań zakupowych z twojej kategorii (najprościej wziąć je z Search Console plus z wyszukiwarki wewnętrznej), automatyczne wywołanie API trzech głównych LLM-ów co tydzień, parsowanie odpowiedzi i sprawdzanie, czy w cytowaniach pojawia się twoja domena. Koszt: około 250-400 zł miesięcznie za API, plus jednorazowe 8 godzin pracy programisty na napisanie pipeline’u.
Co zrobić, jeśli mój sklep stoi na Shopify lub PrestaShop, a nie na WooCommerce?
Framework jest niezależny od platformy. Na Shopify schema.org wymaga aplikacji lub edycji theme.liquid, na PrestaShop modyfikacji modułu producenta. Server side rendering w Shopify dostajesz w standardzie. Sitemapy są łatwiejsze do tagowania niż na WooCommerce. Główna różnica to budżet czasowy programisty, który jest mniejszy o około 30 procent dla Shopify ze względu na bardziej przewidywalną strukturę motywów.
Czy po wdrożeniu trzeba dalej w tę pracę inwestować, czy efekt jest trwały?
Trwały tylko w warstwie technicznej. Treści i schema wymagają stałej aktualizacji, bo katalog się zmienia, ceny się zmieniają, recenzje przybywają. Modele językowe też się zmieniają (nowe wersje, nowe wagi, nowe priorytety), więc co 3-4 miesiące warto powtórzyć część audytu i dopasować taktykę. Realistycznie utrzymanie projektu kosztuje około 25 procent budżetu wdrożenia rocznie.