Case study: e-commerce +200% organic — architektura kategorii

Fashion e-commerce z katalogiem 8 400 SKU w sześć miesięcy zwiększył ruch organiczny o 212%, a przychód z kanału SEO o 186% — bez zwiększania budżetu na linki, bez zmiany platformy i bez masowego dopisywania treści. Cała dźwignia tkwiła w jednym obszarze: architekturze kategorii. Ten case study opisuje dokładnie, co zdiagnozowaliśmy, jak zaprojektowaliśmy nowy graf URL-i, jak wdrożyliśmy przebudowę bez utraty pozycji w trakcie migracji — i jakie liczby pojawiły się po kwartale, po pół roku oraz w długim ogonie.

Case jest fikcyjny, ale zbudowany na kompozycie trzech realnych wdrożeń, które prowadziliśmy w latach 2024–2026 dla sklepów fashion działających w segmencie średnio–premium. Liczby, krzywe i układ kategorii są reprezentatywne dla tej półki rynku. Jeżeli prowadzisz sklep e-commerce z podobnym katalogiem — znajdziesz tu gotowy playbook, a nie luźne „wskazówki”.

Kontekst — sklep, katalog, punkt startu

Marka, którą dla potrzeb tego case nazwiemy Velora, to sklep fashion online z ofertą damską i męską w segmencie smart casual / premium casual. Działa od 2019 roku, ma własny magazyn, własną fotografię produktową i rozsądnie skonfigurowaną infrastrukturę — Shopify Plus na froncie, serwis fulfillmentowy i klasyczny stack analityczny: GA4, Google Search Console, jeden zewnętrzny crawler. W momencie rozpoczęcia współpracy sklep miał 8 412 aktywnych SKU, 74 kategorii i podkategorii, około 120 stron informacyjnych i około 180 artykułów blogowych.

Sprzedaż organiczna była rozczarowująco niska w stosunku do wielkości katalogu i jakości produktów. Miesięcznie sklep notował średnio 94 000 sesji organicznych, z czego tylko 11% konwertowało na dodanie do koszyka, a 1,4% na transakcję. Blog generował 38% sesji, ale praktycznie nie wpływał na sprzedaż — odbijał ruch bez atrybucji. Kategorie produktowe, czyli to, co powinno być maszyną pieniądzoprodukującą w każdym dojrzałym e-commerce, generowały zaledwie 29% sesji organicznych.

Pierwsza hipoteza brzmiała: mamy problem z treścią na kategoriach, dopiszmy teksty SEO, domknijmy featured snippets i wracamy na ścieżki wzrostu. To była dokładnie ta hipoteza, która przez półtora roku blokowała sklep w stagnacji. Dopiero audyt, który zaczęliśmy od narysowania grafu URL-i zamiast od listy słów kluczowych, pokazał prawdziwy problem — i dlaczego warto było spalić poprzedni layout, a nie go łatać.

Diagnoza — trzy warstwy problemu

Poprawna diagnoza zabrała nam dwa tygodnie. W e-commerce ten etap jest krytyczny, bo architektura kategorii dotyka jednocześnie SEO, UX, merchandisingu i operacji. Zmiana podejmowana bez pełnej mapy zwykle pogarsza co najmniej jeden z tych obszarów. W Velorze znaleźliśmy trzy warstwy bólu, które nakładały się na siebie i wzajemnie wzmacniały.

Warstwa 1 — architektura „płaska ale głęboka”

Katalog Velory rósł organicznie. Każda kolekcja sezonowa, każda współpraca, każda promocja dorzucała jedną, dwie, czasem pięć nowych kategorii. Po pięciu latach mieliśmy 74 węzły katalogowe, ale bez jasnej hierarchii. Typowy użytkownik trafiał z Google na URL typu /kategoria/sukienki-wieczorowe-midi-czarne-2023, który miał 11 produktów, 340 słów opisu i linkował tylko do strony głównej oraz do kategorii rodzica (/kategoria/sukienki). Żadnej nawigacji poziomej. Żadnych linków między kategoriami siostrzanymi. Żadnej logicznej ścieżki dla robota wyszukiwarki, by zrozumieć, że sukienki wieczorowe midi czarne 2023 to wariant fasetowy, a nie osobny byt semantyczny.

Screaming Frog wyrzucał raport, z którego wynikało, że Velora ma średnio 3,2 kliknięcia od strony głównej do kategorii końcowej, a 41% URL-i kategorii miało mniej niż 8 linków wewnętrznych. To katastrofa crawl budgetu. Googlebot trafiał głęboko sporadycznie, a jak już trafiał — nie miał jak wrócić, bo struktura linków wewnętrznych była praktycznie drzewiasta, bez linkowania lateralnego.

Warstwa 2 — filtry fasetowe bez kontroli

Na Shopify Plus sklep używał aplikacji filtrującej, która generowała URL-e dla każdej kombinacji parametrów. Filtr „rozmiar + kolor + długość + cena” produkował dziesiątki tysięcy wariantów URL-i. Robots.txt nie blokował ich spójnie. Canonical w połowie przypadków wskazywał na kategorię rodzica, w drugiej połowie — na siebie samego. Googlebot widział ponad 180 000 unikalnych URL-i, z czego indeksował około 62 000. To w katalogu, który miał fizycznie 8 400 produktów i powinien mieć w indeksie góra 9 000 dokumentów.

Efekt? Klasyczna utrata focusa crawl budgetu. Strony, które powinny być indeksowane i rankować (główne kategorie, kategorie sezonowe, top 50 produktów) walczyły o uwagę Googlebota z URL-ami typu /sukienki?kolor=czerwony&rozmiar=S&dlugosc=midi&cena=200-300&strona=7. Robot przechodził je wszystkie, marnował zasoby, a potem tygodniami nie wracał na kluczowy URL kategorii.

Warstwa 3 — kanibalizacja na skalę katalogu

Najbardziej bolesna warstwa — i zarazem najtrudniejsza do zobaczenia gołym okiem. Velora miała osobne kategorie dla: sukienki, sukienki damskie, sukienki na co dzień, sukienki casualowe, sukienki dzienne. Każda z tych kategorii była w osobnym węźle katalogowym, każda miała swój opis, swój featured image, swoje 15–40 produktów. Google widział pięć niemal identycznych intencji, pięć podobnych stron — i decydował zwykle, że żadna nie jest wystarczająco autorytatywna. Średnia pozycja „sukienki casualowe” i „sukienki na co dzień” oscylowała w okolicach 17–24, a impresje stały w miejscu mimo sensownej jakości oferty.

Mapowanie tej warstwy wymagało ręcznej roboty. Wyciągnęliśmy 74 kategorie, każdej przypisaliśmy top 20 zapytań z GSC, zbudowaliśmy macierz intencji i przeszliśmy po niej wizualnie. Wyszło, że z 74 kategorii realnie unikalnych, niekanibalizujących się semantycznie węzłów było 41. Reszta to duplikaty, warianty sezonowe, bastardy z kampanii marketingowych lub stare URL-e niewyczyszczone po migracjach.

Strategia przebudowy — graf, nie drzewo

Najważniejsza decyzja strategiczna w tym projekcie brzmiała: przestajemy myśleć o katalogu jak o drzewie, zaczynamy myśleć jak o grafie. W klasycznym drzewie każda kategoria ma jednego rodzica i zbiór dzieci. W grafie — kategoria może mieć wiele wejść i wiele powiązań lateralnych. Dla użytkownika oznacza to, że do „sukienek midi” trafi i z „sukienki”, i z „midi”, i z „wieczorowe”, i z landingu sezonowego. Dla Googlebota — że crawl budget rozkłada się równomiernie, a każdy ważny węzeł ma wiele linków dochodzących.

Graf zaprojektowaliśmy w trzech warstwach:

Warstwa hub (8 węzłów) — najszersze kategorie odpowiadające intencji rodzajowej: Sukienki, Spodnie, Koszule, Marynarki, Swetry, Obuwie, Akcesoria, Outlet.
Warstwa spoke (33 węzły) — kategorie intencyjne, każda przypisana do dokładnie jednego huba: Sukienki midi, Sukienki maxi, Sukienki mini, Sukienki wieczorowe, Sukienki letnie itd. Spoke linkuje do huba, do 3–5 siostrzanych spoke’ów i do 2–3 powiązanych hubów.
Warstwa fasetowa (kontrolowana) — wybrane kombinacje filtrów, które mają realny volume wyszukiwań (np. „sukienki midi czarne”, „sukienki wieczorowe eleganckie”), promowane do statusu pełnej kategorii z własnym URL-em, własnym opisem i self-referential canonical. Wszystkie pozostałe kombinacje filtrowe — canonical na kategorię spoke + meta robots noindex.

Tę trzywarstwową architekturę opisaliśmy w przewodniku po architekturze kategorii w e-commerce, bo schemat sprawdza się powtarzalnie w sklepach od 2 000 do 50 000 SKU — a nawet dla znacznie większych katalogów pod warunkiem dołożenia warstwy 0 (mega-hubów tematycznych, np. „Lato”, „Biuro”, „Wieczór”).

Mapa kanibalizacji — od 74 do 41 węzłów

Drugi strategiczny ruch: konsolidacja. Z 74 kategorii wyprowadziliśmy 41 produkcyjnych węzłów. 33 kategorie zostały wygaszone — z czego 27 przez 301 na najbliższego merytorycznego następcę, a 6 przez 410 (gone) ponieważ odpowiadały kampaniom niepowtarzalnym (np. „Sukienki Walentynki 2022”). Każde przekierowanie było parowane 1:1, bez łańcuchów dłuższych niż jeden hop, i każda docelowa kategoria dostawała w opisie sekcję „szukasz X? Mamy Y”, by utrzymać intencję użytkownika, który przychodzi ze starych backlinków.

Plan linkowania lateralnego

Trzeci ruch — świadome linkowanie między spoke’ami w obrębie tego samego huba oraz między powiązanymi hubami. Każda strona kategorii spoke dostała szablonowy blok „Powiązane kategorie” (4–6 linków) oraz „Zobacz też w innych hubach” (2–4 linki). Blok nie był statyczny — linki były sortowane przez merchandisera raz na kwartał na podstawie danych sprzedażowych i sezonowości. To dało Googlebotowi stabilny, zmienny w czasie, ale zawsze logiczny graf.

Timeline — sześć miesięcy wdrożenia

Projekty architektoniczne w e-commerce mają tendencję do pełzania. Pomogło nam twarde pocięcie pracy na fazy i akceptacja, że nie wszystko trzeba robić równolegle. Oto rzeczywisty timeline Velory:

Tydzień 1–2 | Audyt i mapowanie. Pełny crawl (Screaming Frog + Sitebulb), eksport GSC i GA4 z 12 miesięcy, ręczna macierz kanibalizacji, dokumentacja 180 000 URL-i robota, mapa filtrów fasetowych z klasyfikacją „promote / keep / noindex / block”.

Tydzień 3–4 | Projekt nowej architektury. Graf URL-i, plan linkowania, brief dla copywriterów (33 nowe opisy kategorii spoke + 8 hubowych), decyzje merchandisingowe (które produkty do których nowych kategorii), mapa 301-ek (82 pozycje).

Tydzień 5–8 | Treść i front. Produkcja 41 tekstów kategoryjnych (hub po 800 słów, spoke po 450 słów + FAQ), przebudowa szablonu kategorii (blok „Powiązane”, breadcrumbs schema, lepszy pagination), testowanie na stage.

Tydzień 9 | Migracja. Deploy na produkcję w weekend, 301-ki aktywne od poniedziałku 00:01, sitemap submit, request indexing na 41 nowych URL-i, monitoring logów serwera pod kątem Googlebota (zwiększenie częstotliwości odwiedzin o 340% w pierwszych 48h — zgodne z planem).

Tydzień 10–12 | Stabilizacja. Kontrola crawla, domknięcia canonical dla filtrów fasetowych, poprawki w linkowaniu, pierwsza fala odzyskania pozycji (sukienki wieczorowe z pozycji 19 do 6, sukienki midi z 24 do 9).

Tydzień 13–18 | Wzmocnienie. Produkcja treści blogowych wspierających (16 artykułów pod spoke’i o najwyższym ROI), budowa backlinków do 6 najważniejszych kategorii, optymalizacja prędkości ładowania (LCP z 3,2s do 1,7s), wdrożenie Schema.org Product + BreadcrumbList + ItemList dla kategorii.

Tydzień 19–24 | Skalowanie wyników. Żadnych poważnych interwencji strukturalnych — tylko dopilnowanie, co rośnie, co wymaga dopięcia. Zwykle ten etap jest niedoceniany, a to w nim materializuje się dźwignia. Googlebot „uczy się” nowej architektury około 8–14 tygodni od deployu, zależnie od wielkości sklepu i siły profilu linkowego.

Rezultaty — liczby, nie slajdy

Poniższa tabela pokazuje porównanie ruchu organicznego per kategoria huba przed przebudową (średnia 3 miesięcy) i po sześciu miesiącach od deployu:

Kategoria hub	Sesje/mies. PRZED	Sesje/mies. PO	Zmiana	Przychód PO vs PRZED
Sukienki	18 420	61 830	+236%	+198%
Spodnie	9 110	27 340	+200%	+174%
Koszule	6 840	22 050	+222%	+189%
Marynarki	3 920	11 780	+200%	+212%
Swetry	5 210	15 440	+196%	+165%
Obuwie	8 970	23 610	+163%	+141%
Akcesoria	4 380	9 220	+110%	+88%
Outlet	2 100	8 940	+326%	+301%
Suma / średnia	58 950	180 210	+205%	+186%

Trzy rzeczy warte podkreślenia. Po pierwsze — największe skoki (Outlet +326%, Sukienki +236%) nie były przypadkowe. To kategorie, w których kanibalizacja była najgłębsza przed przebudową, więc konsolidacja dała im największy „boost autorytetu”. Po drugie — Akcesoria z 110% przyrostu to najmniej „rośnięty” węzeł, bo tam skala kanibalizacji była niewielka, a problemy miały głównie charakter treściowy. Po trzecie — rezultaty po 6 miesiącach nie są szczytem. Kategorie rosły dalej, z krzywą logarytmiczną sięgającą maksimum lokalnego po 9–11 miesiącach.

Dodatkowe, ważne metryki bizowe: średnia pozycja słów kluczowych w top 10 wzrosła z 24,8% do 47,3%. Liczba słów w top 3 urosła 4,1x. Impresje w GSC 2,8x. Współczynnik konwersji z sesji organicznej z 1,4% do 2,1% — częściowo dlatego, że ruch trafiał teraz na właściwe intencyjnie strony, a nie na zagubione węzły katalogowe.

Framework — e-commerce SEO playbook (10 kroków)

Velora nie była specjalnym przypadkiem. Te same kroki, w tej samej kolejności, zastosujesz w 90% sklepów fashion, home, electronics czy beauty od 1 000 do 50 000 SKU. Framework, który wyszedł z tego projektu, wygląda tak:

Wyrysuj pełny graf aktualnych URL-i kategorii. Nie tabelę, nie listę — graf wizualny. Ujawnia asymetrie i braki linkowania, których nie zobaczysz w spreadsheecie.
Zbuduj macierz kanibalizacji. Każda kategoria × top 20 zapytań z GSC. Ręcznie, bez automatów. Zajmie 4–6 godzin, oszczędzi tygodnie zgadywania.
Zdefiniuj warstwy: hub → spoke → faseta promowana → faseta kontrolowana. Hub 6–12 węzłów, spoke 25–60 węzłów, promowanych faset 15–40, reszta — noindex + canonical do spoke’a.
Zaprojektuj mapę 301. Jeden hop, bez łańcuchów. Każdy wygaszany URL dostaje jednego, merytorycznie najbliższego następcę. Jeżeli nie znajdujesz następcy — 410, nie 404.
Przerób szablon kategorii. Breadcrumbs, blok powiązanych, FAQ, Schema.org ItemList + BreadcrumbList, pagination z rel next/prev + self-referential canonical na każdej stronie paginacji.
Napisz 41 (lub ile masz) tekstów kategoryjnych. Hub 700–1000 słów, spoke 350–500 słów + 4 pytania FAQ. Treść intencyjna, nie SEO-mielenie. Dodaj wewnętrzne linki do 2–3 spoke’ów z tego samego huba.
Skonfiguruj filtry fasetowe. Promowane — indexable, self-canonical, własny opis 150 słów. Niepromowane — noindex, canonical na spoke. Blokuj w robots.txt tylko parametry śmietnikowe (sort, view), nigdy filtrów — bo tracisz sygnały o popularności kombinacji.
Deploy w weekend, monitor logów w poniedziałek. Obserwuj, czy Googlebot rośnie w ruchu na nowych URL-ach (powinien) i czy 301-ki są przechodzone (powinny — sprawdź w log analyzer).
Wspomóż treścią blogową po 4–6 tygodniach. Każdy kluczowy spoke dostaje 1 artykuł wspierający z mocnym linkiem do spoke’a. Nie odwrotnie. Spoke nie linkuje do bloga — blog zasila spoke’a.
Zmierz po 6 miesiącach, nie po 6 tygodniach. E-commerce SEO ma długą krzywą uczenia Googlebota. Realne rezultaty restrukturyzacji architektury widać od 12. do 24. tygodnia, a konsolidują się do 11. miesiąca.

Jeżeli planujesz wdrożenie takiego playbooka, polecamy zacząć od kroku 1 (graf URL-i), nawet jeśli masz pokusę zacząć od kroku 6 (pisanie nowych opisów). Bez grafu piszesz treść pod architekturę, która sama w sobie jest problemem — i zabijasz ROI przed startem. Więcej o priorytetyzacji wdrożenia znajdziesz w naszym case study migracji fashion e-commerce, które rozbija ten sam problem z perspektywy zmiany platformy.

Najczęstsze błędy — pięć pułapek, które widzimy w 80% sklepów

Pułapka 1: „Dopiszmy teksty SEO do kategorii”

Najczęstszy pierwszy ruch — i najczęstsza strata budżetu. Dopisywanie tekstów do kategorii, które są kanibalizowane strukturalnie, daje krótkotrwały boost (2–6 tygodni) po którym Google wraca do zdegradowanej pozycji. Tekst nie naprawi grafu URL-i. Najpierw graf, potem teksty.

Pułapka 2: „Niech aplikacja filtrująca sama sobie poradzi”

Większość aplikacji do filtrów na Shopify, WooCommerce czy Magento tworzy URL-e fasetowe bez kontroli indeksacji. Domyślna konfiguracja zwykle jest katastrofalna — canonical na self, brak noindex, URL-e paginacji bez rel=prev/next. Audytuj aplikację ręcznie po instalacji, nie wierz że „skoro popularna to OK”. Krótki przewodnik po konfiguracji znajdziesz w oficjalnych dokumentach Shopify SEO.

Pułapka 3: „Wygasimy stare kategorie 404”

Błąd, który kosztuje 10–30% ruchu przez pół roku. 404 oznacza dla Google „tej strony nigdy tu nie było” — tracisz cały nabyty autorytet, linki przychodzące, równo ze wszystkim. Zawsze 301 na najbliższego następcę merytorycznego. Tylko kampanie niepowtarzalne i sezony, do których nie ma merytorycznego następcy — 410 (gone), czytelny sygnał dla Google, że strony nie ma i nie będzie.

Pułapka 4: „Zrobimy migrację w środę o 14:00”

Deploy w godzinach szczytu oznacza: ruch organiczny na 301-kach, jednocześnie robot na starych URL-ach, jednocześnie nowa architektura z niedogranymi canonicali. Weekend, 2 w nocy, monitoring logów. To nie przesada — to różnica między -15% ruchu w pierwszym tygodniu a +5%.

Pułapka 5: „Zmierzymy po 4 tygodniach i jak nie ma, cofamy”

Cofanie migracji architektonicznej po miesiącu jest tragedią. Googlebot potrzebuje 8–14 tygodni, by „zrozumieć” nowy graf. Jeżeli po 4 tygodniach widzisz ubytek — to normalny etap cyklu. Paniczne cofanie daje drugą falę 301-ek, drugą falę crawl chaosu i zwykle kończy się trwałym spadkiem.

Infrastruktura danych — co zmierzyć przed, w trakcie, po

Wdrożenie architektury bez pomiaru jest grą w ciemno. W Velorze postawiliśmy trzy warstwy pomiaru, które działały równolegle przez całe 6 miesięcy.

Warstwa log-analytics. Logi serwera przepuszczane przez Screaming Frog Log Analyzer, co tydzień raport: ile razy Googlebot odwiedził nowe URL-e, ile razy stare, jak przechodzi 301-ki, czy nie ma pętli canonical, czy crawl budget się rozkłada zgodnie z planem. Ta warstwa pokazała, że w tygodniu 3 Googlebot zwiększył aktywność na kategoriach hub o 412%, co było sygnałem, że graf został „zrozumiany”.

Warstwa GSC + GA4. Standardowa, ale z custom dashboards: crawl stats per sekcja URL, coverage per sekcja, impresje i klik per hub/spoke z breakdownem. GSC API pobierany dziennie, składany w BigQuery, dashboard w Looker Studio. Dzięki temu po 3 miesiącach mieliśmy czytelną krzywą, że spoke’i zachowują się inaczej niż huby (spoke’i rosły szybciej, ale huby rosły dłużej).

Warstwa produktowa. GA4 e-commerce events per kategoria, GMC feed quality (mocno istotny dla kategorii indeksowanych również w Google Shopping — więcej w dokumentacji Google Merchant Center), konwersje per ścieżka wejścia. Ta warstwa pokazała realny ROI projektu — nie wszystkie kategorie, które rosły w ruchu, rosły też w przychodach proporcjonalnie. Akcesoria były przykładem „ruchu bez przychodu”, co dało nam informację do kolejnej fali priorytetyzacji.

Techniczne detale, które zadecydowały

Kilka mniejszych decyzji, które w sumie dały około 30% wyniku — warte są osobnej sekcji, bo każda z nich jest pułapką, w którą wpadają sklepy działające „na szablonie”.

Pagination z rel next/prev + self-canonical

Mimo że Google oficjalnie ogłosił w 2019 roku, że nie używa rel=next/prev, praktyka pokazała, że kombinacja tych tagów z self-referential canonical na każdej stronie paginacji daje mierzalną różnicę w indeksacji głębokich produktów. W Velorze produkty ze strony 3 i dalej paginacji wzrosły o 89% w indeksowaniu po tej zmianie.

Schema ItemList + BreadcrumbList + Product

Kategorie dostały ItemList z listą produktów w widocznej części strony + BreadcrumbList. Produkty dostały Product z offerami i aggregateRating. Rich results w GSC wzrosły 3,4x w ciągu 3 miesięcy, co przełożyło się na średni CTR kategorii z 2,1% na 3,4%.

LCP i INP

Szablon kategorii miał LCP 3,2s i INP 380ms — poza progiem „good”. Po refactorze (lazy loading produktów poza fold, preload hero image, removal of blocking third-party scripts) LCP spadł do 1,7s, INP do 140ms. Core Web Vitals jako ranking factor są umiarkowane, ale CWV jako UX factor są silne — a to wzmacnia wszystkie inne sygnały (czas na stronie, bounce rate, konwersja).

Hreflang (gdy sklep jest multilang)

Velora działała tylko na polskim, więc tu hreflanga nie ruszaliśmy — ale w dwóch pokrewnych projektach, które prowadziliśmy równolegle, poprawne hreflangi między .pl, .cz i .sk dały dodatkowe 15–20% ruchu organicznego dzięki lepszej dystrybucji autorytetu między wersjami językowymi.

Co poszło nie tak — i czego się nauczyliśmy

Żaden projekt nie przebiega bez błędów. W Velorze mieliśmy trzy momenty, które warto przyznać otwarcie, bo dają więcej wartości niż laurki.

Błąd 1 — za wczesna warstwa fasetowa. W tygodniu 5 włączyliśmy 40 promowanych faset. W tygodniu 8 okazało się, że 12 z nich ma kanibalizację ze spoke’ami, które właśnie rankują. Zdegradowaliśmy te 12 faset z powrotem do noindex. Lekcja: promowane fasety włącza się po ustabilizowaniu spoke’ów, nie równolegle. Idealnie z 6–8-tygodniowym opóźnieniem.

Błąd 2 — za mało treści na hubach. Początkowo pisaliśmy huby po 500 słów. Po 6 tygodniach zorientowaliśmy się, że huby rankują na długich, rodzajowych frazach („sukienki damskie”) gorzej niż konkurencja, która ma tam 1200 słów. Dopisaliśmy huby do 900–1100 słów w tygodniu 14. Wynik — dodatkowy skok o 31% w hubowym ruchu w ciągu następnych 6 tygodni.

Błąd 3 — nie zakotwiczyliśmy schemy produktowej na początku. Product schema doszło dopiero w tygodniu 16. Gdybyśmy wdrożyli od razu z nową architekturą, rich results weszłyby 8 tygodni wcześniej, co prawdopodobnie dałoby dodatkowe 12–18% ruchu w pierwszym kwartale.

FAQ — pytania, które dostajemy w każdym pitchu

Ile trwa projekt restrukturyzacji architektury kategorii w sklepie średniej wielkości?

Dla sklepu 5 000–15 000 SKU — realnie 4–6 miesięcy end-to-end, z czego 2 miesiące to przygotowanie (audyt, strategia, treść), miesiąc migracja i stabilizacja, 2–3 miesiące dojście do pełnych rezultatów. Pierwsze mierzalne efekty (odzyskane pozycje, wzrost impresji) widać w tygodniach 6–10.

Czy potrzebuję zmieniać platformę?

Zwykle nie. Velora została na Shopify Plus, nasze pokrewne projekty restrukturyzowały się na WooCommerce i Magento bez zmiany platformy. Jeżeli platforma nie pozwala na kontrolę canonical, meta robots i strukturę URL-i — to raczej aplikacja filtrująca jest problemem, nie platforma. Przed migracją platformy zweryfikuj, czy nie da się rozwiązać problemu jednym customowym snippetem.

Czy 301-ki z wygaszonych kategorii nie zabiją mi ruchu?

Jeżeli 301 idzie do kategorii naprawdę merytorycznie blisko — nie. Traci się zwykle 5–10% „juice’u” w procesie przekierowania, ale odzyskuje się to w 6–10 tygodni przez konsolidację autorytetu na mniejszej liczbie mocniejszych węzłów. Projekty z 30+ 301-kami, które prowadziliśmy, po 3 miesiącach miały wyższą łączną widoczność niż przed migracją.

Jak klasyfikować filtry fasetowe — co promować, co noindex?

Prosty test: jeżeli kombinacja filtra ma mierzalny volume wyszukiwań (>200/mies. w twojej niszy) i realną podaż produktową (>15 produktów, nie ściąga stanów magazynowych na zero), warto promować. Jeżeli nie — noindex + canonical na spoke. Promowane fasety muszą mieć własny, oryginalny opis 120–200 słów, inaczej wygenerujesz duplicate content.

Ile treści potrzebuję na kategorii, żeby rankować?

Dla spoke’ów: 350–500 słów opisu + 3–5 pytań FAQ wystarczy, żeby konkurować z dobrze zoptymalizowaną konkurencją. Dla hubów: 800–1100 słów. Ważniejsza od ilości jest intencyjność — opis musi odpowiadać na to, co użytkownik zawarł w zapytaniu, a nie opisywać ogólnie „dlaczego nasze sukienki są fajne”.

Czy blog jest konieczny w sklepie e-commerce?

Nie, ale jeżeli inwestujesz w spoke’i, blog daje bardzo dobry ROI jako warstwa wspierająca. Jeden artykuł informacyjny („Jak dobrać sukienkę midi do sylwetki”), który linkuje do odpowiedniego spoke’a, potrafi dać temu spoke’owi dodatkowe 20–40% ruchu w cyklu kwartalnym. Bez bloga da się rankować, ale graf jest „cieńszy”.

Co z AI overviews i cytowaniami w LLM?

Architektura grafowa, którą opisujemy, pomaga też w AI Overviews i cytowaniach przez LLM. Googlebot (i indeksery OpenAI, Anthropic, Perplexity) lepiej rozumieją spoke’i, które mają FAQ, Schema.org i jasne breadcrumbs. W Velorze po 6 miesiącach kategorie pojawiały się w AIO na 23 zapytaniach, czego nie było przed migracją. Więcej o optymalizacji pod AI znajdziesz w przewodniku po AIO w e-commerce.

Ile to kosztuje?

Projekt podobny do Velory — koszty zewnętrzne: 35–60 tys. PLN (audyt + strategia + content + deploy), koszty wewnętrzne: około 80–120 godzin pracy zespołu sklepu (merchandising, testowanie, akceptacje). Na tle dodatkowego ruchu i przychodu, zwraca się w 2–4 miesiące po stabilizacji rezultatów.

Co dalej — od architektury do mocnego profilu długofalowego

Restrukturyzacja architektury kategorii daje bazę, ale nie jest punktem końcowym. Velora po 6 miesiącach wchodzi w kolejną fazę — budowę profilu topikalnego, czyli tematycznego autorytetu, który przekłada się na rankingi nie tylko transakcyjne, ale też informacyjne. To znaczy: artykuły edukacyjne wokół spoke’ów, content wideo na YouTube w ścisłej integracji z kategoriami, materiały poradnikowe dla ChatGPT i Perplexity (bo to one coraz częściej decydują o tym, gdzie użytkownik zacznie ścieżkę zakupową), guides do stylingu powiązane ze spoke’ami.

Drugi wymiar — skalowanie grafu na nowe rynki. Velora rozważa ekspansję na Czechy i Słowację. Wiedza zdobyta przy przebudowie architektury polskiej pozwoli zrobić to „od razu dobrze”, bez długu technicznego i bez okresu stagnacji charakterystycznego dla wczesnych wersji grafu. Cross-rynkowe hreflangi, wspólna biblioteka schemy, wspólny playbook content — to wszystko buduje się znacznie szybciej, gdy fundament architektoniczny jest solidny.

Trzeci wymiar, który rekomendujemy każdemu sklepowi po takim projekcie — pomiar ciągły, nie audyt raz na rok. Architektura kategorii nie jest artefaktem, który raz się wdraża i zapomina. Sklep rośnie, dodaje kolekcje, marki, kampanie. Bez ciągłego pilnowania grafu (miesięczny review, kwartalny audyt, półroczna rekonfiguracja warstwy fasetowej) graf znów się zdegeneruje w ciągu 18–24 miesięcy. Velora ma wpisany ten proces w kalendarz operacyjny — i to jest prawdopodobnie najważniejsza pojedyncza decyzja po samej migracji, bo to ona decyduje, czy wzrost +200% utrzyma się w roku drugim, trzecim i czwartym.

Jeżeli prowadzisz sklep e-commerce z podobnymi bolączkami — rozproszony graf, niekontrolowane fasety, kanibalizacja między sezonami — zacznij od jednej rzeczy: narysuj dziś graf swoich kategorii na kartce. To 45 minut pracy, które zadecyduje, czy następny kwartał ruchu organicznego przyniesie ci wzrost, czy kolejną stagnację. Architektura kategorii nie jest „detalem technicznym” — jest fundamentem, na którym stoi cały ruch organiczny sklepu e-commerce.

Merchandising a SEO — pole, w którym tradycyjne zespoły się nie spotykają

Jedna z najciekawszych obserwacji z projektu Velory dotyczy tematu, który w klasycznym e-commerce traktuje się osobno: relacji między merchandisingiem a SEO. W 90% sklepów, które audytujemy, merchandiser decyduje o sortowaniu produktów na kategorii, o featured items, o promocjach wizualnych — w oderwaniu od danych o tym, co Googlebot widzi jako pierwsze w HTML-u i co ma wpływ na rankingi. W Velorze połączyliśmy te zespoły już w fazie projektowej grafu, i to dało jakąś bardzo konkretne efekty.

Przykład pierwszy — sortowanie domyślne. Stary szablon Velory domyślnie sortował produkty po „najnowsze”. Dla użytkownika rozsądnie, dla Googlebota katastrofalnie: najnowsze produkty to zwykle te, które mają najmniej opinii, najmniej sprzedaży i najsłabszy sygnał popularności. Zmieniliśmy domyślne sortowanie na „bestseller w kategorii za ostatnie 30 dni”, z fallbackiem na „najpopularniejsze w kolekcji”. Efekt — strony kategorii zyskały lepszy ItemList w schemie (produkty z opiniami jako pierwsze), lepszy CTR w SERP-ie (bo rich results z aggregateRating pokazywały średnią gwiazdek), lepszy czas na stronie (bo użytkownik widział produkty, które statystycznie go interesują).

Przykład drugi — rotacja featured items. Merchandiser Velory ustawiał featured items raz na sezon. To znaczyło, że przez 3 miesiące Googlebot widział tę samą listę na górze kategorii. Zmieniliśmy rotację na tygodniową, z wyraźnymi sygnałami „nowe w tym tygodniu” widocznymi w HTML i w Schema.org. Googlebot zaczął częściej wracać na strony kategorii (wzrost częstotliwości crawlu o 47%), bo widział regularną aktualizację treści, a nie statyczną listę.

Przykład trzeci — integracja danych sprzedażowych z decyzjami o linkowaniu. Blok „Powiązane kategorie” na spoke’ach Velory nie był ustalany ręcznie przez SEO, ani intuicyjnie przez merchandisera. Zbudowaliśmy prosty algorytm: powiązane kategorie = top 5 kategorii, do których użytkownicy z tej kategorii dodają produkty do koszyka w tej samej sesji. To dało linkowanie lateralne, które jest jednocześnie SEO-skuteczne (mierzalne sygnały odwiedzin) i UX-skuteczne (realnie podpowiada produkty, które użytkownika interesują).

AI Overviews i LLM jako nowy kanał — dlaczego architektura grafowa pomaga

W 2026 roku każdy projekt SEO, który ignoruje AI Overviews Google i cytowania przez LLM (ChatGPT, Perplexity, Claude, Gemini), zostawia pieniądze na stole. W Velorze przyglądaliśmy się temu od początku — i pojawiło się kilka wniosków, które są wartościowe dla każdego sklepu e-commerce.

Pierwszy wniosek: LLM-y preferują treści z jasną strukturą semantyczną. Hub → spoke → faseta to dokładnie taka struktura, którą model językowy potrafi „przeczytać” i zreprodukować. Po 4 miesiącach Velora była cytowana przez Perplexity na 17 zapytaniach typu „jak dobrać sukienkę midi” i „w jakim sklepie kupić eleganckie marynarki damskie”, z bezpośrednim linkiem do odpowiednich spoke’ów. Stary, płaski graf był dla LLM-a nieczytelny — nie było jasne, który URL jest autorytetem dla danej intencji.

Drugi wniosek: FAQ na spoke’ach znacząco zwiększa szansę na cytowania. Każdy spoke Velory miał 4–5 pytań FAQ z konkretnymi, krótkimi odpowiedziami (80–150 słów). LLM-y lubią taki format, bo mogą wycinać odpowiedź i cytować źródło. W GA4 widzieliśmy sesje z Perplexity i Claude jako referrerów, z bardzo wysokim współczynnikiem konwersji (4,8% vs 2,1% średnio dla SEO) — to jest ruch wysokiej intencji, już zdecydowany.

Trzeci wniosek: Schema.org to nie tylko SEO, to też AI readable. Product schema, BreadcrumbList, ItemList, FAQPage — każdy z tych typów schemy ułatwia LLM-om zrozumienie, co jest na stronie. Velora miała wszystkie cztery typy poprawnie wdrożone. Efekt — cytowania w AI Overviews Google pojawiły się po 5 miesiącach, co jest poniżej średniej branżowej (zwykle 8–12 miesięcy od poważnego upgrade’u architektury).

Zespół i procesy — co potrzeba, żeby taki projekt wypalił

Architektura kategorii to nie jest projekt, który robi „sam SEO”. Wymaga zgrania zespołu, procesów i decyzyjności, która w wielu firmach jest rozproszona. Z perspektywy Velory, pięć ról było krytycznych:

Sponsor projektu (dyrektor e-commerce) — ktoś, kto ma autorytet, by podjąć decyzję o migracji i nie cofnąć jej po 4 tygodniach, gdy pojawi się naturalny dip.
Strateg SEO — autor grafu, macierzy kanibalizacji, mapy 301, specyfikacji technicznej. Osoba, która myśli w kategoriach grafu, nie listy.
Dev (frontend + backend) — wdraża szablon, canonical, schema, 301-ki. W Velorze mieliśmy jednego dewelopera Shopify + jednego backendowego do customowych snippetów.
Copywriter e-commerce — nie klasyczny content writer, ale ktoś, kto rozumie różnicę między „hubem” (szeroka intencja) a „spoke’em” (wąska intencja) i pisze pod właściwą warstwę.
Merchandiser — właściciel decyzji o tym, które produkty idą do której nowej kategorii, jak rotują featured items, jaki jest domyślny sort. Bez jego zaangażowania SEO robi pracę na sucho.

W firmach mniejszych role 2 i 4 często łączy jedna osoba (strateg + copywriter), 3 i 5 bywają zewnętrzne. Kluczowe jest jasne przypisanie odpowiedzialności, nie rozmycie. W Velorze każda z 41 nowych kategorii miała „właściciela” (merchandiser) i „redaktora” (copywriter). Jeżeli kategoria nie miała właściciela — trafiała na koniec kolejki i ryzyko, że zostanie niedopięta przed deployem, było wysokie.

Z procesów najważniejszym okazał się tygodniowy war room przez 12 tygodni projektu. Raz w tygodniu na 60 minut: co zrobione, co blokuje, co decyduję. Bez tego war roomu projekty podobnej skali pełzną na 9–12 miesięcy zamiast 6. Po deployu war room przeszedł w kwartalny review, co jest wystarczające dla utrzymania grafu w dobrym stanie.

Porównanie z alternatywami — co testowaliśmy, a co odrzuciliśmy

Przed wybraniem grafowej architektury rozważaliśmy dwa alternatywne podejścia. Krótko, dla porządku, żeby było jasne, dlaczego graf wygrał:

Alternatywa A — pozostawienie istniejącej architektury + masowa produkcja treści. Ta opcja była najtańsza (brak dewa, brak migracji, tylko copywriting). Symulowaliśmy ją dla pierwszych 8 kategorii i po 6 tygodniach zobaczyliśmy krótki wzrost (8–15% na poziomie pojedynczych kategorii), ale bez efektu systemowego. Przyczyna — kanibalizacja strukturalna nadal blokowała konsolidację autorytetu. Odrzucone.

Alternatywa B — pełna migracja na Magento 2 z natywną fasetą. Technologicznie czyste, ale nierealnie drogie (budżet 400–600 tys. PLN) i z 6–8 miesiącami zamrożenia wzrostu sprzedaży podczas migracji. Klient po zapoznaniu się z kosztem alternatywnym (w postaci utraconej sprzedaży) odrzucił. Wrócimy do tego tematu w projekcie za 2–3 lata, jak Velora przekroczy pułap, na którym Shopify Plus zaczyna ograniczać.

Wybrane — przebudowa grafu na istniejącej platformie. Koszt w okolicach 45 tys. PLN zewnętrznie + 100 godzin pracy wewnętrznej, ryzyko kontrolowane, deploy w 9 tygodni, pełne rezultaty w 24 tygodnie. Ten bilans okazał się optymalny.

Co przenosisz do swojego sklepu — checklist pierwszego tygodnia

Jeżeli po tym case chcesz zacząć własny projekt, oto konkretna lista zadań na pierwszy tydzień. Każde z nich zajmuje 2–6 godzin i razem dają fundament, na którym zbudujesz cały projekt.

Eksport pełnej listy kategorii i ich URL-i z twojego CMS/platformy. W Shopify — CSV, w WooCommerce — przez REST API, w Magento — przez backend admin.
Pełny crawl sklepu (Screaming Frog lub Sitebulb). Cel: dowiedzieć się, ile realnie URL-i widzi robot. Jeżeli liczba przekracza liczbę SKU razy 3, masz problem z fasetami.
Eksport top 500 zapytań z GSC za 12 miesięcy, z przypisaniem do URL-u kategorii. Ręczna macierz kanibalizacji — zaznacz na żółto pary kategorii, które rankują na podobne frazy.
Rysunek aktualnego grafu URL-i. Tak, na kartce lub w Miro/FigJam. Cel: zobaczyć asymetrie, klastry, braki linkowania lateralnego.
Analiza feeda Google Merchant Center. Czy produkty są poprawnie przypisane do kategorii? Czy feed ma błędy? Czy kategorie w feed’zie odzwierciedlają kategorie na stronie?
Pierwsza propozycja mapy docelowej hub → spoke. Jeszcze bez liczby URL-i, bez decyzji o 301-kach, tylko „jak powinien wyglądać idealny graf”.
Pitch do decydentów. Jeżeli projekt ma wypalić, dyrektor e-commerce musi być sponsorem, nie obserwatorem. Pokaż mu 3 slajdy: diagnoza (liczby z crawlu), propozycja (nowy graf), oczekiwany ROI (benchmark Velory lub podobnego case’a).

Jeżeli po tym tygodniu masz pierwszą wersję grafu i sponsora — jesteś na torze. Reszta to realizacja według playbooka, który opisaliśmy wyżej. Projekty, które pomijają pierwszy tydzień „planistyczny” i od razu lecą w deploy, mają 70% wskaźnik niepowodzenia lub bardzo mocno rozjechany harmonogram. Pierwszy tydzień to inwestycja, która się zwraca wielokrotnie w każdej kolejnej fazie.