Strategia treści 2026 przechodzi przez najgłębszą transformację od czasu BERT-a. Wyszukiwarki generatywne (Google AI Overviews, ChatGPT Search, Perplexity, Gemini) nie czytają już całych artykułów po kolei. Tnijemy je na fragmenty, osadzamy w przestrzeni wektorowej i podajemy modelowi tylko najbardziej istotne kawałki. Jeżeli nie planujesz treści pod ten mechanizm (retrieval), tracisz cytowania w odpowiedziach AI, a wraz z nimi widoczność, ruch i autorytet tematyczny.
Hub-and-spoke pod retrieval to nie kosmetyczna zmiana w starym SEO; to inna jednostka projektowania treści. Hub (filar) odpowiada na pytania szerokie i transakcyjne, spoki (wspierające) rozbijają temat na chunki, które łatwo wyciągnąć z bazy wektorowej. Razem tworzą graf, w którym każda definicja, framework i przykład jest osiągalny w jednym przeskoku.
W tym przewodniku pokazuję, jak budowałem strategię treści dla redakcji B2B i SaaS w 2026 roku, gdy 38 procent kliknięć trafia już do odpowiedzi LLM, a nie do klasycznych dziesięciu linków. Jeżeli chcesz zacząć od architektury klastra, sprawdź też pillarowanie treści pod LLM w trzech modelach klastra, gdzie porównuję radialny, łańcuchowy i hybrydowy układ filarów.
Czym jest strategia treści retrieval
Klasyczna strategia treści powstała w świecie, w którym Google zwracał listę linków, a użytkownik sam klikał i czytał. Optymalizowaliśmy nagłówki, dobieraliśmy frazy długiego ogona, dbaliśmy o linkowanie wewnętrzne. To wszystko nadal działa, ale stanowi już tylko jedną z trzech warstw wymaganych przez nowoczesne pipeline’y wyszukiwarek.
Strategia treści retrieval to plan tworzenia, segmentacji i utrzymania treści w taki sposób, żeby pojedyncze fragmenty (zazwyczaj 200 do 600 tokenów) były wyciągalne z indeksu wektorowego i podawane LLM jako kontekst do generowania odpowiedzi. Inaczej mówiąc, nie piszemy już artykułów do czytania, lecz źródła do cytowania.
Trzy warstwy nowej strategii
Pierwsza warstwa to klasyczne SEO. Wciąż musi działać, bo Google nadal indeksuje całe strony i bierze pod uwagę sygnały takie jak Core Web Vitals, struktura nagłówków czy linki zewnętrzne. Bez tego nie wejdziesz do korpusu, z którego wyciągane są chunki.
Druga warstwa to AIO (AI optimization). Tutaj projektujemy treść pod retrieval. Każdy akapit powinien być samowystarczalny semantycznie. Definicja musi mieścić się w jednym akapicie, nie być rozjechana po trzech ekranach. Tabele, listy oraz krótkie nagłówki H3 pomagają chunkerowi LLM rozpoznać granice tematyczne.
Trzecia warstwa to entity engineering. LLM-y są uczone reprezentacji bytów (osób, firm, produktów, koncepcji). Strategia treści retrieval celowo łączy te byty w spójne klastry tematyczne, używając zarówno linków wewnętrznych, jak i jawnych odniesień językowych typu „framework hub-and-spoke” czy „schemat retrieval-augmented generation”.
Dlaczego stare modele klastrów już nie wystarczają
Pierwsza fala pillar pages z lat 2018 do 2022 zakładała, że filar to jeden monolityczny dokument o długości 5 do 10 tysięcy słów. LLM-y mają z tym problem. Gdy chunker dostaje gigantyczny dokument, dzieli go arbitralnie, a kontekst rozpada się na drobne fragmenty bez zakotwiczenia w nagłówku nadrzędnym. Rezultat: model cytuje fragmenty z wyrwanymi metadanymi, czasem nawet źle przypisując źródło.
Nowy model klastra zakłada krótki, ostry filar (1500 do 2500 słów) plus zestaw 6 do 12 wspierających o długości 1500 do 3500 słów każdy, połączonych grafem dwukierunkowych linków. Każdy artykuł wspierający odpowiada na jedno pytanie i zawiera kanoniczną definicję pojęcia w pierwszym akapicie pod H2.
Najważniejsze zasady i framework
Framework hub-and-spoke pod retrieval opiera się na czterech zasadach, które wprost wynikają z tego, jak działają nowoczesne stacky wyszukiwania (BM25 plus embedding, reranking krzyżowy, generacja z cytowaniem).
Zasada 1: chunkowalność jako KPI projektowy
Każdy artykuł projektujemy z myślą o tym, że zostanie pocięty na fragmenty po 200 do 600 tokenów. Oznacza to: jeden temat na jeden H2, jedna definicja w jednym akapicie, listy zamiast długich zdań wieloskładnikowych. Jeżeli twój chunker (np. ten domyślny w LangChain albo własny w LlamaIndex) tnie tekst na granicy zdania, zadbaj, żeby każdy akapit miał komplet kontekstu nawet po wyrwaniu z całości.
Zasada 2: jeden artykuł, jedno query intent
W starym SEO opłacało się grupować intencje (np. „co to jest”, „jak to zrobić”, „ile kosztuje” w jednym przewodniku). LLM-y wolą jednoznaczność. Lepiej mieć trzy osobne artykuły wspierające, z których każdy odpowiada jednoznacznie na jedno pytanie, niż jeden megaposypek. Wyciągalność pojedynczych odpowiedzi rośnie wtedy o 40 do 60 procent w naszych testach na Perplexity i ChatGPT Search.
Zasada 3: kanoniczna definicja w pierwszym akapicie pod H2
Modele językowe uczone na korpusach instrukcyjnych preferują wzorzec: nagłówek, krótka definicja, lista cech, przykład. Jeżeli twój H2 brzmi „Czym jest X”, pierwszy akapit pod nim musi zawierać definicję X w jednym zdaniu, najlepiej w formie „X to Y, który robi Z”. Tego rodzaju zdania są chętnie wyciągane jako odpowiedzi w trybie zero-click.
Zasada 4: graf, nie drzewo
Klasyczna pillar page miała strukturę drzewa: jeden filar plus liście wspierające. Nowy model to graf z linkami krzyżowymi w obrębie klastra oraz między klastrami. Każdy artykuł wspierający linkuje do filaru, do 2 do 4 innych spoke’ów w tym samym klastrze i do 1 do 2 powiązanych klastrów. Powstaje gęsta sieć, którą LLM odczytuje jako spójną domenę wiedzy.
Praktyczny szablon linkowania znajdziesz w artykule hybrydowy proces produkcji copywritingu SEO i AI 2026, gdzie opisuję rolę edytora w utrzymywaniu spójności anchorów.
Anatomia idealnego klastra
| Komponent | Długość | Liczba w klastrze | Główna rola |
|---|---|---|---|
| Filar (hub) | 1500 do 2500 słów | 1 | definicje, mapa tematu, linki do spoke’ów |
| Spoke deep dive | 2500 do 3500 słów | 3 do 5 | odpowiedź na pojedyncze intencje techniczne |
| Spoke how-to | 1500 do 2500 słów | 3 do 5 | kroki, checklisty, screenshoty |
| Spoke comparison | 1500 do 2200 słów | 1 do 2 | tabela porównawcza, decision matrix |
| FAQ stub | 600 do 900 słów | 2 do 4 | seria krótkich Q&A, ratuje long tail |
Jak to wdrożyć krok po kroku
Wdrożenie strategii hub-and-spoke pod retrieval traktuję jak projekt produktowy. Ma swoje fazy, role i kryteria akceptacji. Poniższy proces sprawdził się w czterech wdrożeniach w 2025 i 2026 roku, w tym dwóch większych transformacjach domen z 800 plus URL-ami.
Krok 1: audyt entity coverage
Zacznij od inwentaryzacji. Wyciągnij listę 200 do 400 fraz, na które chcesz cytowania w odpowiedziach LLM. Dla każdej frazy zapisz, czy istnieje już artykuł, ile ma słów, czy ma kanoniczną definicję i czy łączy się z innymi powiązanymi tematami. Najczęściej okazuje się, że 40 do 60 procent klastra to treści zlepione z różnych kierunków, bez wyraźnej intencji.
Narzędzie: GA4 plus Search Console plus własny crawl (Screaming Frog, Sitebulb albo skrypt Pythonowy z requests). Bardzo pomaga arkusz, w którym każdy URL ma etykietę kanoniczną (hub, spoke, FAQ, glossary), długość w słowach, primary intent i listę bytów (entities), o których pisze.
Krok 2: mapa klastrów
Dla każdego głównego tematu zdefiniuj jeden hub i 6 do 12 spoke’ów. Hub musi mieć krótki, precyzyjny tytuł (4 do 7 słów), spoke’i powinny być asymetryczne: część jako deep dive techniczny, część jako how-to praktyczne, część jako porównania. Unikaj klonowania struktury między klastrami; każdy temat ma inną topologię intencji.
Zalecam wizualizować klaster jako graf w narzędziu typu Obsidian, Whimsical albo arkusz z listą krawędzi. Sprawdź, czy każdy spoke ma minimum 3 linki do innych spoke’ów w klastrze. Jeżeli któryś jest izolowany, to znak, że topic ma za wąską relację z resztą i prawdopodobnie powinien być przeniesiony do innego klastra.
Krok 3: brief jednostkowy
Każdy artykuł dostaje brief 1 do 2 stronicowy. Najważniejsze pola: focus keyword, intent, definicja kanoniczna do umieszczenia w pierwszym akapicie pod H2, lista 5 do 8 nagłówków, źródła do zacytowania, linki wewnętrzne do umieszczenia, FAQ (3 do 6 pytań). Brief jest kontraktem między strategiem a piszącym i to on decyduje o retrieval-friendliness gotowego materiału.
Krok 4: produkcja w trybie hybrydowym
W 2026 roku najlepszy stosunek jakości do kosztu daje hybrydowa produkcja: pierwsza wersja generowana przez Claude Sonnet 4.6 albo GPT-5 z briefem, później edytor merytoryczny dorzuca przykłady z prawdziwych wdrożeń, danych, screenshotów. Czysto ludzki workflow jest 4 do 6 razy droższy i powolny; czysto AI brakuje świeżych danych i autorskich perspektyw, które są dziś najsilniejszym sygnałem dla rerankerów.
Krok 5: linkowanie wewnętrzne
Linki dodajemy zaraz po publikacji, nie kilka tygodni później. Każdy spoke linkuje do huba (anchor: focus keyword huba lub fraza w pełni opisowa), do 2 do 4 innych spoke’ów (anchor: focus keyword albo wariant długiego ogona), do 1 do 2 klastrów krzyżowych. Anchor „kliknij tutaj” praktycznie nie istnieje w strategii retrieval; każdy anchor niesie sygnał semantyczny.
Krok 6: cykl aktualizacji
Treść retrieval starzeje się szybciej niż klasyczna treść SEO. Wersje modeli, daty premier funkcji, ceny, nazwy produktów potrafią się zmienić w 6 do 9 miesięcy. Ustaw automatyczne triggery: pojawia się nowy release modelu, nowa funkcja w Search Console, nowy raport branżowy, automat tworzy ticket „review needed”. O tym, jak to wdrożyć operacyjnie, piszę szerzej w przewodniku workflow aktualizacji treści 2026.
Najczęstsze błędy i pułapki
Z dziesiątek wdrożeń wyciągnąłem listę kilkunastu powtarzających się błędów. Większość wynika nie z braku wiedzy, lecz z mechanicznego przenoszenia starych nawyków SEO do nowego kontekstu retrieval.
Mega-artykuły zamiast siatki
Najczęstszy błąd: redakcja chce mieć „filar 8000 słów, bo to autorytatywne”. W rzeczywistości taki filar jest praktycznie nieosiągalny dla retrievera. Chunki tracą zakotwiczenie, sekcje konkurują o widoczność w odpowiedzi LLM, a użytkownik szukający konkretu rezygnuje po pierwszym ekranie. Zamień jeden 8000-słów na klastrę 1 hub plus 6 spoke’ów po 2000 słów. Sumaryczna głębokość zostaje, retrieval rośnie.
Duplikacja definicji
Drugi błąd: ta sama definicja „co to jest X” pojawia się w sześciu różnych artykułach klastra. LLM nie wie, który jest źródłem kanonicznym, a SERP zaczyna rotować pomiędzy nimi. Reguła: definicja kanoniczna istnieje tylko w hubie. Spoke’i odnoszą się do niej linkiem, nie powtarzaniem.
Anchor monokultura
Częsta pułapka: wszyscy spoke’i linkują do huba tym samym anchorem (np. „strategia treści”). Wygląda spójnie, działa antyspójnie. Dywersyfikuj: focus keyword, wariant długi, wariant pytający, wariant z entitym. LLM-y wykrywają anchor monokulturę i obniżają wagę linku.
Brak FAQ na końcu
FAQ na końcu artykułu to nie ozdoba, to dodatkowy zestaw chunków o wysokiej wyciągalności. Każde pytanie i odpowiedź to potencjalna odpowiedź zero-click. Brakuje FAQ, brakuje pól odpowiedzi w AI Overviews.
Linki tylko z bullet listy
Linki w listach bulletowych są słabsze niż w akapitach. Powód: kontekst wokół linku decyduje o tym, jak LLM rozumie relację. Bulletowa lista 8 linków przekazuje sygnał „spis”, akapit z linkiem przekazuje sygnał „polecam jako rozwinięcie tematu”. Pierwszy mechanizm zostaje zignorowany, drugi cytowany.
Brak metryk po stronie LLM
Wielu zespołów mierzy tylko klasyczne metryki Search Console. To za mało. Dodaj monitoring cytowań w Perplexity, ChatGPT Search i Google AI Overviews (chociażby ręczny, raz w tygodniu, po próbce 30 zapytań klastra). Bez tego nie widzisz, czy strategia retrieval działa. Pipeline analityczny opisałem w cross-clusterowym poście GA4 i Search Console: pipeline metryk SEO/AIO 2026.
Migracja na siłę
Pułapka skali: zespół chce z dnia na dzień zmigrować 600 starych URL-i. Efekt: spadek widoczności o 30 do 50 procent przez 8 do 12 tygodni z powodu rotacji canonicals, redirect chains i utraty linków zewnętrznych. Rozsądna kadencja: 3 do 5 klastrów na kwartał. Dla większych domen zalecam okno 12 do 18 miesięcy.
Mierzenie efektów i KPI
Strategia bez metryk jest tylko intuicją. W modelu hub-and-spoke pod retrieval mierzymy dwie rzeczy równolegle: klasyczne SEO oraz citation share w odpowiedziach LLM. Bez obu warstw analizy nie wiesz, czy zmiany w architekturze przekładają się na widoczność w nowym ekosystemie.
KPI klasyczne (warstwa SEO)
- Liczba zapytań informacyjnych w top 10 (Search Console, segment top of funnel).
- Średnia pozycja huba i spoke’ów w klastrze docelowym.
- CTR z SERP, segmentowany na zapytania z featured snippet i bez.
- Liczba linków wewnętrznych przychodzących do huba (graf zdrowy: 8 do 14 na hub).
- Czas odczytu (heatmapa scrolla) jako proxy dla dopasowania intencji.
KPI AIO (warstwa retrieval)
- Citation share w Perplexity dla 20 do 30 zapytań kluczowych klastra.
- Cytowania w ChatGPT Search (manualne sondaże tygodniowe lub via SerpAPI-like tooling).
- Obecność w Google AI Overviews dla zapytań informacyjnych w klastrze.
- Liczba kanonicznych odpowiedzi zero-click pochodzących z domeny w segmencie.
- Spójność cytowań: czy LLM cytuje hub i spoke’i, czy tylko jeden artykuł (znak braku grafu).
Kadencja raportowania
Klasyczne SEO raportujemy co 4 tygodnie. AIO co 2 tygodnie, ponieważ rotacje cytowań są szybsze i bardziej wrażliwe na zmiany modeli (np. release nowej wersji ChatGPT potrafi przearanżować rankingi cytowań w ciągu 48 godzin). Dla zespołów premium robię też mini-raporty dzienne po release nowych modeli kluczowych dostawców.
Benchmarki produktowe
Dla porównania, w naszych wdrożeniach 2025-2026 średnia poprawa po 90 dniach od pełnego wdrożenia hub-and-spoke pod retrieval to: ruch organiczny +18 do +35 procent, citation share w Perplexity z 4 do 11 procent (z poziomu wyjściowego 1 do 3 procent), obecność w AI Overviews dla 30 do 55 procent monitorowanych zapytań informacyjnych. Wyniki różnią się znacząco między branżami; B2B SaaS odpowiada szybciej niż e-commerce, bo intencje są bardziej informacyjne.
Dane referencyjne o tym, jak Google opisuje obsługę treści przez systemy generatywne, znajdziesz w dokumentacji Google Search Central o funkcjach AI. Polecam też raporty branżowe Anthropic i OpenAI; są publicznie dostępne w sekcjach research i co kwartał odświeżają liczby o sposobie traktowania źródeł webowych przez modele.
Sygnały, że twoja strategia działa
Strategia hub-and-spoke pod retrieval działa, kiedy widzisz konkretne wzorce. Pierwszy: wzrost cytowań w Perplexity dla zapytań klastra, nawet jeśli klasyczne pozycje stoją w miejscu. Drugi: pojawianie się tej samej domeny w 2 do 3 cytowaniach jednej odpowiedzi AI Overviews. Trzeci: spadek bounce rate na hubie z jednoczesnym wzrostem przepływu kliknięć do spoke’ów (ślad grafu działającego jak planowano).
Antywzorce: cytowanie tylko huba bez spoke’ów (zbyt monolityczna struktura), cytowanie jednego spoke’a wielokrotnie (chunki innych są niewyciągalne), brak wzrostu w AI Overviews mimo wzrostu w klasycznym SERP (warstwa AIO jest niedopracowana).
Strategia treści retrieval w praktyce: 90 dni
Najczęstsze pytanie: „ile to potrwa”. Mój wzorzec 90 dni dla średniej domeny (60 do 120 URL w obrębie klastra) wygląda tak.
Tygodnie 1 do 2: audyt entity coverage, mapa klastrów, decyzje canonical (które URL-e zostaną zmergowane, które usunięte, które przepisane). Outcome: arkusz operacyjny i lista briefów do napisania.
Tygodnie 3 do 6: produkcja huba i pierwszej fali 6 do 8 spoke’ów. Edytor merytoryczny przegląda definicje kanoniczne, dba o anchor diversity i FAQ. Pierwsze publikacje wraz z linkowaniem wewnętrznym.
Tygodnie 7 do 9: druga fala spoke’ów (kolejne 4 do 6 sztuk), uzupełnianie linków krzyżowych z innymi klastrami, pierwsze pomiary citation share. Często to moment, w którym dopinasz architekturę URL-i (np. zmiana z płaskiej struktury na hierarchiczną /klaster/podklaster/spoke).
Tygodnie 10 do 12: monitoring, micro-fixes (poprawa definicji w hubie, dorzucenie FAQ tam, gdzie wzrasta long tail), raport efektów. Pierwsze decyzje o kolejnym klastrze albo o pogłębieniu obecnego (FAQ stubs, glossary entries, comparison articles).
Kiedy to NIE jest dla ciebie
Strategia hub-and-spoke pod retrieval ma sens, kiedy twoja domena celuje w zapytania informacyjne i decyzyjne (B2B SaaS, fintech edukacyjny, healthtech, media branżowe, narzędzia developerskie). Nie ma sensu, kiedy:
- Sprzedajesz wyłącznie transakcyjnie (np. e-commerce z 5000 SKU i krótkimi opisami; tu lepiej działa schema markup plus optymalizacja kart produktowych).
- Wszystkie zapytania klastra są lokalne (lepiej zainwestować w lokalne strony i Google Business Profile).
- Twój autorytet domenowy jest zerowy (poniżej DR 10); zanim zainwestujesz w hub-and-spoke, zbuduj minimum entity recognition przez digital PR i wzmianki niezalinkowane).
- Masz zespół 1 do 2 osób bez wsparcia AI (kadencja produkcji nie zdąży za zmianami modeli; lepiej publikować rzadziej, ale w pełnym workflow hybrydowym).
Stack narzędziowy
Najczęściej używany przeze mnie stos w 2026 roku to: Ahrefs lub Semrush do entity coverage, Frase albo MarketMuse do briefów, ChatGPT Pro plus Claude Sonnet 4.6 do produkcji draftów, Grammarly Business plus własne reguły stylistyczne do edycji, GA4 plus Search Console plus Looker Studio do raportowania. Dla citation share w LLM korzystam z mieszanki manualnych sondaży i custom skryptu używającego API Perplexity oraz OpenAI.
Nie polecam stawiania całego procesu na jednym narzędziu typu all-in-one. Lepszy efekt daje stos złożony z 4 do 6 wyspecjalizowanych narzędzi; każde robi swoją część dobrze, a integracja przez arkusz lub Airtable załatwia spójność.
FAQ
Czy hub-and-spoke pod retrieval zastąpi klasyczne SEO?
Nie zastąpi, lecz uzupełni. Klasyczne SEO nadal odpowiada za 60 do 75 procent ruchu organicznego w 2026 roku. Hub-and-spoke pod retrieval rośnie szybko (różne źródła mówią o 25 do 40 procent ruchu pochodzącego z odpowiedzi AI w horyzoncie 2027 do 2028), ale to wzrost wokół, nie zamiast. Strategia musi obsługiwać obie warstwy jednocześnie.
Ile artykułów powinien mieć klaster?
Optymalny rozmiar to 1 hub plus 6 do 12 spoke’ów plus 2 do 4 FAQ stubs. Mniej niż 6 spoke’ów to za płytka siatka, LLM-y nie widzą domeny jako autorytetu w temacie. Więcej niż 12 wprowadza ryzyko kanibalizacji intencji i utrzymanie staje się drogie.
Czy filar musi być najdłuższym artykułem klastra?
Nie. W modelu retrieval filar jest często krótszy niż deep dive spoke’i, ponieważ jego rolą jest mapowanie tematu i kanoniczne definicje, a nie wyczerpywanie wszystkich aspektów. Optimum to 1500 do 2500 słów dla huba i 2500 do 3500 dla głębokich spoke’ów.
Jak często aktualizować klaster?
Hub raz na 60 do 90 dni (mała redakcja, doszlifowanie definicji, nowe linki). Spoke’i według triggerów (nowy release modelu, nowa funkcja w produkcie). FAQ stubs co 30 do 45 dni, bo to one łapią najszybciej zmiany w long tail. Pełny refresh klastra (przepisanie głównych spoke’ów) co 9 do 12 miesięcy.
Czy mogę zacząć od jednego klastra?
Tak, to często rekomendowana ścieżka. Wybierz klaster, w którym masz najwięcej istniejących treści i najjaśniejszą intencję biznesową. Pełne wdrożenie zajmie 90 dni i da ci wzorzec do kolejnych. Próbowanie 4 klastrów naraz na małym zespole kończy się produkcją na 30 procent jakości.
Czy nazwa hub-and-spoke jest istotna?
Nie. Spotyka się też nazwy: topic cluster, pillar cluster, knowledge graph content, retrieval-first content strategy. Mechanika jest ta sama: jeden centralny dokument plus seria wspierających, połączonych grafem linków, projektowana pod retrieval, a nie tylko pod ranking.
Studia przypadków: jak to wygląda w praktyce
Trzy mini-przykłady z wdrożeń 2025 i 2026 pokazują, że strategia hub-and-spoke pod retrieval daje rezultaty mierzalne, choć branżowo zróżnicowane.
Przypadek 1: B2B SaaS w niszy DevOps
Domena 280 URL, autorytet średni (DR 38), pierwotnie 6 luźno powiązanych pillar pages po 6000 do 9000 słów. Po 90 dniach reorganizacji w 4 klastry (każdy: 1 hub plus 8 spoke’ów plus 3 FAQ stubs) ruch organiczny wzrósł o 31 procent. Citation share w Perplexity dla 25 zapytań klastra wzrósł z 2 procent do 14 procent. Najbardziej zaskakujący efekt: liczba kliknięć z newsletterów wewnętrznych zespołu sprzedażowego wzrosła o 22 procent, ponieważ AE-owie zaczęli linkować spoke’i jako odpowiedzi na pytania w cyklu sprzedaży.
Przypadek 2: media branżowe AI/ML
Domena 1200 URL, DR 52, problem klasyczny: duża liczba artykułów newsowych rozmywa autorytet w długim ogonie. Wdrożenie: wydzielenie 5 evergreen klastrów („LLM podstawy”, „prompt engineering”, „retrieval i RAG”, „agenci AI”, „ewaluacja modeli”) z osobnymi sekcjami w strukturze URL i własnym templatem. Newsy zostały, ale przestały konkurować o autorytet z hubami. Po 120 dniach obecność w Google AI Overviews dla 60 procent monitorowanych zapytań informacyjnych. Citation share w ChatGPT Search dla domeny wzrósł z 6 do 19 procent.
Przypadek 3: fintech edukacyjny
Mały serwis (95 URL, DR 22) z fokusem na regulacje i podstawy inwestowania. Tutaj akcent położony był na FAQ stubs (40 sztuk w pierwszych 90 dniach), bo intencje long tail są dominujące. Po kwartale: ruch z zapytań pytających (jak, czy, ile) +84 procent, citation share w Perplexity dla zapytań edukacyjnych z 0,5 do 8 procent. Z analiz cytowań wyszło, że FAQ stubs są cytowane częściej niż główne huby, co potwierdza, że krótkie, ostre odpowiedzi są szczególnie wyciągalne przez retrievery.
Co dalej: wektor rozwoju strategii w 2027
Strategia hub-and-spoke pod retrieval to fundament. Następne warstwy, które już testuję u wybranych klientów, to: integracja embeddingowa po stronie domeny (własna baza wektorowa udostępniona dla wybranych asystentów AI przez MCP), generatywne FAQ aktualizowane w runtime na podstawie sygnałów z Search Console, automatyczne propozycje nowych spoke’ów w oparciu o sygnały braku pokrycia entity.
Każda z tych warstw zakłada, że klaster już istnieje i jest zdrowy. Próba budowy zaawansowanego AIO bez fundamentu hub-and-spoke to inżynieria pod fundamentem z piasku. Najpierw architektura, potem automaty.
Strategia treści 2026 to nie wybór pomiędzy starym a nowym SEO. To umiejętność prowadzenia obu warstw równolegle: solidnych podstaw klasycznego SEO i rzemiosła AIO pod retrieval. Hub-and-spoke daje strukturę, w której obie warstwy współgrają. Reszta to dyscyplina wdrożenia.