Czy embeddingi potrafią naprawić kanibalizację SEO? Test na danych GSC

Embedding dobrze odpowiada na pytanie, o czym są te dwa teksty, ale znacznie gorzej na pytanie, który z nich powinien obsłużyć konkretną intencję i cel biznesowy. W eksperymencie przeprowadzonym przez Semgence na danych z Google Search Console semantyczny reranking naprawił 3 z 38 przypadków błędnego wyboru URL-a – recovery rate 7,89%. Decyzja po teście: nie promować zmiany globalnie, bo poprawa jest zbyt mała, żeby uzasadnić ryzyko regresji na pozostałych domenach. Negatywny wynik nie oznacza, że embeddingi są bezużyteczne. Oznacza, że podobieństwo semantyczne to za mało, żeby samodzielnie podejmować decyzję o docelowym URL-u.

Mike King, założyciel iPullRank i twórca koncepcji Relevance Engineering, w swoim artykule o mechanice AI Mode zwraca uwagę na fundamentalną lukę: większość narzędzi SEO wciąż operuje na modelach sparse retrieval (TF-IDF, BM25), podczas gdy systemy wyszukiwania coraz częściej używają dense retrieval (embeddingów). Ale sam fakt, że embeddingi lepiej rozumieją znaczenie tekstu, nie oznacza, że potrafią samodzielnie wybrać właściwy URL. Nasz eksperyment to potwierdza.

Metodologia: z benchmarku dopasowania query-URL na 10 domenach (783 pary) wyodrębniono 38 przypadków z błędnym Top-1. Dodano warstwę semantycznego rerankingu (cosine similarity między zapytaniem a kandydackimi URL-ami). Zbiór referencyjny nie został zmieniony po zobaczeniu wyników. Dane klientów zanonimizowane (branże: e-commerce, B2B, SaaS). Eksperyment przeprowadził Paweł Gontarek (Zgred) z agencji Semgence.

Co mierzy embedding i dlaczego to za mało do wyboru URL-a?

Embedding to numeryczna reprezentacja znaczenia tekstu w przestrzeni wektorowej. Dwa dokumenty o podobnym temacie mają bliskie wektory – i ta bliskość jest mierzalna jako cosine similarity. Tinuiti w przewodniku po cosine similarity definiuje tę technikę jako pomiar relacji semantycznej między dwoma wektorami – reprezentacjami tekstu wygenerowanymi przez LLM. Problem polega na tym, że podobieństwo semantyczne nie jest tym samym co dopasowanie do intencji.

Kategoria „buty do biegania” i karta produktu „Nike Pegasus 41” mają wysoki cosine similarity, ale odpowiadają na różne zapytania. Embedding nie widzi tej różnicy, bo operuje na treści, nie na roli dokumentu w architekturze witryny. W artykule o mierzeniu topical authority opisaliśmy, jak embeddingi pomagają zmierzyć spójność tematyczną domeny – tam ta technologia sprawdza się bardzo dobrze. Tu testujemy coś innego: czy ta sama technologia potrafi wybrać właściwy URL dla konkretnego zapytania.

Artykuł naukowy SemanticALLI opublikowany na ArXiv opisuje ten problem jako „nearby but wrong failure mode” – tryb awarii typowy dla dense retrieval w przestrzeniach o dużej liczbie wymiarów. System znajduje kandydatów semantycznie bliskich, ale nie tych właściwych. Dlatego autorzy łączą dense retrieval z lexical scoring (BM25) i rerankingiem – sam cosine similarity nie wystarcza. Mike King na SEO Week 2025 podkreślał, że Google używa embeddingów do rozumienia relacji między encjami, autorami i witrynami, ale E-E-A-T nie opiera się na samych embeddingach – to abstrakcja, za którą stoją wielowarstwowe sygnały.

W praktyce ten tryb awarii obserwujemy regularnie w audytach Semgence. Serwis B2B z branży HR miał 15 stron o rekrutacji – każda opisywała inny aspekt procesu (onboarding, sourcing, employer branding, exit interview). Embedding umieszczał je w bliskim regionie przestrzeni wektorowej (cosine 0,82-0,91 między wszystkimi parami), co sugerowało masową kanibalizację. Ale analiza GSC pokazała, że każda strona obsługiwała osobny klaster zapytań z niskim nakładaniem się. Problem nie leżał w liczbie stron, lecz w braku strony hubowej, która łączyłaby klaster i dawała Google jasny sygnał, który URL jest autorytetem dla ogólnego zapytania „rekrutacja”.

Ten przykład ilustruje fundamentalną różnicę między „strony są semantycznie bliskie” (prawda) a „strony kanibalizują się nawzajem” (fałsz). Embedding poprawnie identyfikuje bliskość tematyczną. Ale interpretacja tej bliskości jako kanibalizacji byłaby błędem – i prowadziłaby do konsolidacji 15 stron w jedną, co zniszczyłoby long tailowe pozycje na każdym z 15 podzapytań.

Jak wygląda problem w rzeczywistych danych GSC? Cztery wzorce z audytu

Zamiast teoretyzować, pokazałem cztery wzorce z własnych danych Google Search Console. Każdy ilustruje inną relację między cosine similarity a poprawnością wyboru URL-a.

Wzorzec 1: klaster cenowy – embedding ma rację, Google też

Zapytania „audyt seo cena”, „audyt seo cennik” i „audyt seo koszt” – trzy warianty tej samej intencji transakcyjnej. Embedding umieściłby je w niemal identycznym punkcie przestrzeni wektorowej. Google również kieruje wszystkie trzy na jeden URL (/audyt-seo/) z pozycjami 1,6-1,8. To przypadek, w którym cosine similarity i rzeczywisty wybór są zgodne.

Zapytanie	URL	Clicks (90 dni)	Pozycja
audyt seo cena	/audyt-seo/	11	1,83
audyt seo cennik	/audyt-seo/	4	1,66
audyt seo koszt	/audyt-seo/	3	1,65

Ale to jest łatwy przypadek. Wszystkie trzy zapytania mają tę samą intencję (cena audytu) i ten sam oczekiwany typ strony (strona usługowa z cennikiem). Embedding nie musi tu rozróżniać intencji – bo intencja jest identyczna. Wartość embeddingu w diagnostyce zaczyna się tam, gdzie intencje się rozchodzą.

Ten wzorzec potwierdza obserwację z badania Studio 36 Digital: przeciętna domena rankuje 4,7 URL-i na każde zapytanie z top fraz. W klastrze cennikowym audytu widzimy prawidłową konsolidację – ale pamiętaj, że w naszym benchmarku z 783 par ten wzór odpowiadał tylko za ok. 15% przypadków. Pozostałe 85% wymagało analizy intencji, typu strony lub encji, której sam cosine similarity nie dostarczył.

Wzorzec 2: dwie platformy, jedna encja – embedding widzi jedno, użytkownik dwa

Zapytania o posty sponsorowane na Facebooku i Instagramie – dwa osobne artykuły na blogu. Embedding widzi bardzo wysoki cosine similarity: oba teksty dotyczą postów sponsorowanych w social media, struktura jest analogiczna, język niemal identyczny.

Zapytanie	URL	Clicks	Pozycja
post sponsorowany instagram	/czym-sa-posty-sponsorowane-na-instagramie/	6	5,29
post sponsorowany facebook	/czym-sa-i-jak-zrobic-posty-sponsorowane-na-facebooku/	3	11,94
posty sponsorowane (ogólne)	/czym-sa-posty-sponsorowane-na-instagramie/	2	2,88

Google poprawnie rozdziela zapytania platformowe na odpowiednie URL-e. Ale zapytanie ogólne „posty sponsorowane” (bez nazwy platformy) trafia na artykuł o Instagramie zamiast na stronę hubovą lub porównanie. Embedding nie pomoże tu rozstrzygnąć, bo oba artykuły są semantycznie równie bliskie ogólnemu zapytaniu. Decyzja wymaga innej warstwy: który URL lepiej obsługuje intencję „porównaj opcje” vs „powiedz mi o jednej konkretnej”.

W praktyce ten problem rozwiązuje się nie embeddingiem, lecz architekturą. Gdyby istniał artykuł hubowy „Posty sponsorowane w social media – porównanie Facebook vs Instagram”, ogólne zapytanie miałoby właściwy URL docelowy. Embedding mógłby wtedy pełnić użyteczną rolę: pomiar, czy nowy hub jest semantycznie bliżej ogólnemu zapytaniu niż oba artykuły platformowe. Ale decyzja o stworzeniu huba nie wynika z embeddingu – wynika z analizy luk w architekturze treści, którą opisaliśmy w artykule o kanibalizacji słów kluczowych.

Wzorzec 3: klaster cennikowy Google Ads – sześć wariantów, jeden URL

Sześć różnych sposobów zapytania o cennik Google Ads – wszystkie kierowane na /kampanie-sem/.

Zapytanie	Clicks	Pozycja
google ads cennik	8	5,92
kampania google ads cennik	5	3,15
cennik google ads	3	5,71
kampanie google ads cennik	2	2,63
prowadzenie kampanii google ads cennik	2	4,53
reklama google ads cennik	2	2,59

Tu embedding działa poprawnie: wszystkie zapytania są semantycznie bliskie i faktycznie powinny trafiać na jeden URL. Ale w tym samym klastrze jest zapytanie „kampanie adwords” (3 clicks, pozycja 21,38) – stara nazwa brandu, którą embedding rozpoznaje jako bliską „google ads”, ale Google daje mu znacznie gorszą pozycję. Dlaczego? Bo treść strony jest zoptymalizowana pod „Google Ads”, nie pod „AdWords”. Embedding widzi, że to ten sam produkt. Ale nie widzi, że treść nie zawiera frazy, której szuka użytkownik. To warstwa lexical, nie semantyczna.

Ten przykład pokazuje granice embeddingu w kontekście rebrandingu. Google Ads zastąpił nazwę AdWords w 2018 roku, ale użytkownicy nadal używają starej nazwy. Embedding rozpoznaje relację między AdWords a Google Ads (ten sam produkt, inny termin). Ale ranking na stronę zoptymalizowaną pod nową nazwę jest słabszy, bo w treści brakuje starego terminu. To pokazuje, że dense retrieval (embeddingi) i sparse retrieval (BM25, TF-IDF) odpowiadają na różne pytania – i oba są potrzebne jednocześnie. Artykuł naukowy SemanticALLI opublikowany na ArXiv dochodzi do tego samego wniosku.

Wzorzec 4: zapytanie brandowe na trzech URL-ach

Zapytanie „semgence” – oczywisty case nawigacyjny. Trzy URL-e zbierają kliknięcia: strona główna (79 clicks), blog (9 clicks), wersja z parametrami UTM z Google Moja Firma (8 clicks).

Embedding nie rozróżni tych trzech stron w sensowny sposób, bo treść jest podobna (nazwa firmy, opis usług). Ale to nie jest problem kanibalizacji – Google poprawnie wybiera stronę główną jako odpowiedź numer jeden. Obecność bloga i wersji UTM w wynikach to keyword diversification, nie kanibalizacja. Mateusz Makosiewicz z Ahrefs w badaniu 80 zapytań z wielokrotnym rankingiem znalazł tylko jeden przypadek wymagający interwencji – pozostałe 79 były nieszkodliwe lub korzystne. Na naszych danych widzimy tę samą proporcję.

Różnica między keyword diversification a kanibalizacją jest kluczowa dla interpretacji. Diversification to sytuacja, w której domena zajmuje wiele pozycji w SERP różnymi URL-ami i generuje więcej kliknięć niż z jednego URL-a. Kanibalizacja to sytuacja, w której URL-e wymieniają się pozycjami lub blokują sobie nawzajem wyniki. Embedding nie rozróżnia tych dwóch scenariuszy – widzi tylko bliskość semantyczną. Dlatego decyzja o interwencji nie może opierać się wyłącznie na cosine similarity, ale musi uwzględniać dane o kliknięciach, CTR i stabilności pozycji z GSC.

Case study: sklep z branży beauty – 6 URL-i na jedno zapytanie brandowe

Dane z Google Search Console drogerii internetowej (branża beauty/kosmetyki) w okresie 90 dni pokazują, jak jedno zapytanie brandowe może generować wyświetlenia na sześciu różnych URL-ach jednocześnie. Embedding umieściłby wszystkie sześć w niemal identycznym punkcie przestrzeni wektorowej, bo każdy z tych URL-i zawiera nazwę marki i dotyczy kosmetyków. Ale każdy pełni inną rolę w architekturze serwisu.

URL	Rola	Clicks (90 dni)	Udział
Strona główna	Nawigacja, punkt wejścia	5 524	79,4%
Lokalizator sklepów	Szukam najbliższego sklepu	582	8,4%
Kategoria: perfumy	Przeglądam asortyment	355	5,1%
Gazetka promocyjna	Szukam aktualnych promocji	288	4,1%
Strona marki własnej	Szukam konkretnej marki	110	1,6%
Strona promocji	Szukam wyprzedaży	100	1,4%

Strona główna dominuje z 79% kliknięć, co jest poprawnym zachowaniem dla zapytania nawigacyjnego. Ale pozostałe pięć URL-i łącznie zbiera ponad 1 400 kliknięć – to nie jest szum, to jest realna dywersyfikacja wyników. Embedding nie pomoże tu w żadnej decyzji, bo kosine similarity między stroną główną a kategorią perfum jest tak wysoki, że system flagujeaby obie jako „kandydaci do konsolidacji” – co byłoby błędem.

Kategoria vs marka vs PDP – trzy warstwy na jednym brandzie

Ten sam serwis beauty pokazuje jeszcze ciekawszy wzór na zapytaniach o markę kosmetyczną (zanonimizowana jako „Marka K”). Trzy różne zapytania – trzy różne URL-e, każdy poprawny.

Zapytanie	URL	Clicks	Pozycja	Intencja
marka K	Listing kategorii marki	517	4,1	Discovery: chcę zobaczyć produkty
marka K kosmetyki	Strona marki	150	1,1	Brand awareness
marka K bronzer w sztyfcie	Karta produktu (PDP)	276	1,0	Konkretny produkt

Embedding widzi „Markę K” we wszystkich trzech URL-ach i oceniłby cosine similarity na poziomie 0,85+. Ale Google poprawnie rozdziela te zapytania: ogólne „Marka K” trafia na listing, zapytanie z nazwą produktu na PDP, a zapytanie z modyfikatorem „kosmetyki” na stronę marki. Kluczem jest typ strony i modyfikator intencji („kosmetyki” = chcę wiedzieć o marce, „bronzer w sztyfcie” = chcę kupić konkretny produkt). Embedding nie widzi tej różnicy, bo operuje na treści, nie na strukturze zapytania.

Zapytanie lokalizacyjne – homepage vs lokalizator

Zapytania z nazwą miasta („[marka] Kraków”, „[marka] Warszawa”) to przypadek, w którym embedding nie tylko nie pomaga, ale aktywnie myli. Użytkownik szuka najbliższego sklepu stacjonarnego – oczekiwanym URL-em jest lokalizator sklepów z mapą i adresami.

Zapytanie	Homepage clicks	Lokalizator clicks	Lepszy URL
„[marka] Kraków”	183	97	Lokalizator
„[marka] Warszawa”	201	84	Lokalizator

Strona główna wygrywa na zapytaniach lokalizacyjnych, mimo że lokalizator sklepów jest lepszą odpowiedzią. Przyczyna: homepage ma silniejszy profil linkowy i wyższą autorytatywność niż podstrona /drogerie. Embedding nie pomoże, bo obie strony zawierają nazwę marki i są semantycznie bliskie zapytaniu. Rozwiązanie leży w wzmocnieniu lokalizatora: dodanie treści z nazwami miast, schematów LocalBusiness i linkowania wewnętrznego z anchorami lokalizacyjnymi. To zmiana architekturalna, nie semantyczna – embedding nie zastąpi analizy intencji lokalnej.

Te trzy wzorce z jednego sklepu beauty pokazują skalę problemu: nawet na danych z rzeczywistego e-commerce, embedding poprawnie identyfikuje tematyczną bliskość (wszystkie URL-e dotyczą kosmetyków), ale nie potrafi oddzielić nawigacji od discovery, brand awareness od intencji zakupowej, ani zapytania lokalizacyjnego od ogólnego. Każdy z tych podziałów wymaga osobnej warstwy sygnałów. O rozdzielaniu intencji w e-commerce pisaliśmy też w artykule o architekturze kategorii.

Dlaczego podobieństwo tematyczne, encja i intencja to trzy różne warstwy?

Weźmy jedno zapytanie produktowe i jego warianty: „Samsung Galaxy S26” (encja), „Samsung Galaxy S26 cena” (intencja transakcyjna), „Samsung Galaxy S26 czy iPhone 18” (porównanie), „jaki telefon zamiast Galaxy S26” (discovery) i „Samsung Galaxy S26 instrukcja” (wsparcie). Wszystkie pięć zapytań jest semantycznie bliskich – embedding umieści je w podobnym regionie przestrzeni wektorowej. Ale każde z nich może wymagać innego URL-a: karta produktu, kategoria z filtrem, artykuł porównawczy, strona discovery lub sekcja FAQ.

Joshua Hardwick z Ahrefs podkreśla identyczną zasadę: dopiero analiza intencji pozwala odróżnić problematyczne wielokrotne rankowanie od nieszkodliwego. Gianluca Fiorelli cytowany przez Lumar argumentuje, że SEO musi przejść od myślenia keyword-matching do strategii opartych na całym lejku – a embedding mierzy tylko jedno: bliskość tematyczną. W artykule o architekturze kategorii e-commerce opisaliśmy macierz decyzji filtr-podkategoria-poradnik, która operuje na intencji, nie na cosine similarity.

W e-commerce ten problem jest jeszcze wyraźniejszy. Zapytanie „buty do biegania damskie” może trafić na kategorię, PDP popularnego modelu, artykuł „jak wybrać buty do biegania” lub stronę promocji sezonowej. Każdy z tych URL-i ma wysoki cosine similarity z zapytaniem. Ale właściwy wybór zależy od intencji: jeśli użytkownik jest na etapie discovery (porównuje opcje), kategoria jest właściwa. Jeśli jest na etapie decision (wybrał model), PDP. Jeśli szuka wiedzy (jaka amortyzacja?), poradnik. Embedding nie wie, na którym etapie lejka jest użytkownik. Dlatego w artykule o nagłówku jako adresie odpowiedzi na karcie produktu opisaliśmy, jak strukturyzować treść PDP, żeby odpowiadała na pytania zakupowe bez wchodzenia w teren kategorii.

Jak przebiegał eksperyment z rerankingiem semantycznym?

Eksperyment był częścią szerszego benchmarku dopasowania query-URL przeprowadzonego na 10 domenach. Z benchmarku wyodrębniliśmy 38 przypadków, w których podstawowy scoring wybrał niewłaściwy URL jako Top-1. Dodaliśmy warstwę semantycznego rerankingu: dla każdego zapytania przeliczyliśmy cosine similarity między zapytaniem a wszystkimi kandydackimi URL-ami. Nie zmieniliśmy zbioru referencyjnego po zobaczeniu wyników.

Metryka	Wartość
Przypadki z błędnym Top-1	38
Naprawione przez reranking	3
Recovery rate	7,89%
Udział odzyskanych wyświetleń	3,72%

7,89% recovery rate przy ryzyku pogorszenia pozostałych 92% przypadków nie przechodzi progu decyzyjnego. Te trzy naprawione przypadki dotyczyły zapytań o stosunkowo małym popycie – udział odzyskanych wyświetleń (3,72%) był jeszcze niższy niż recovery rate. Gdyby dotyczyły fraz z dużą liczbą wyświetleń, decyzja mogłaby wyglądać inaczej, ale dane nie dały na to podstaw.

Negatywny wynik jest tu cenniejszy niż pozytywny. Chroni przed globalną regresją i wskazuje, że przed kolejną próbą trzeba uzupełnić brakujące warstwy sygnałów. O tym, dlaczego wynik z jednej domeny nie może uzasadnić globalnej zmiany, piszemy w artykule o testowaniu rekomendacji SEO na wielu domenach.

Dlaczego reranking nie zadziałał w pozostałych 35 przypadkach?

Przeanalizowaliśmy nienaprawione przypadki i zidentyfikowaliśmy sześć powtarzających się przyczyn. Żadna z nich nie dotyczy jakości embeddingów.

Przyczyna	Opis	Dlaczego embedding nie pomaga
Zły typ strony	Embedding nie rozróżnia kategorii od PDP	Oba dokumenty mają identyczny cosine similarity, ale tylko jeden jest właściwą odpowiedzią
Nierozróżniona intencja	„Buty Nike” może prowadzić do kategorii, marki lub artykułu	Embedding widzi temat, nie cel użytkownika
Ta sama encja, inny atrybut	„Laptop ASUS 16 cali” vs „laptop ASUS z RTX 4070”	Oba dotyczą laptopów ASUS, ale oczekiwany landing jest inny
Dominacja boilerplate	Szablon generuje 60% identycznej treści na każdym URL-u	Embedding widzi głównie wspólny tekst, nie różnice
Słaby wektor kategorii	Kategoria z jednym zdaniem, PDP z rozbudowanym opisem	PDP ma silniejszy sygnał semantyczny i wygrywa
Błędny URL referencyjny	Ekspert mógłby przypisać zapytanie inaczej	Nie błąd metody, a błąd wzorca – zrewidowany post factum

Ostatnia przyczyna – błędny URL referencyjny – zasługuje na osobny komentarz. W benchmarku wielodomenowym referencje przypisuje specjalista, który zna domenę. Ale w kilku przypadkach nasz referencyjny URL był dyskusyjny – inny ekspert mógłby przypisać zapytanie do innego dokumentu. To nie jest słabość metody, to immanentna cecha każdego benchmarku z ludzkim wzorcem. W artykule o wiarygodności audytu AI opisaliśmy, jak mierzyć confidence w sytuacjach, gdy sam wzorzec nie jest pewny – i dlaczego odpowiedź „nie wiem” jest czasem lepsza niż wymuszone przypisanie.

Chris Lever z CL SEO opisuje obejście: zamiast używać embeddingu jako decydenta, używa go jako wczesnego ostrzeżenia. Jeśli dwie strony mają cosine similarity powyżej progu, system flaguje je do ręcznej analizy intencji. To podejście proaktywne – zamiast czekać na spadek ruchu w GSC, wykrywasz potencjalny konflikt zanim Google go zauważy.

Na naszych danych widzimy ten sam wzór: artykuły o postach sponsorowanych na Facebooku i Instagramie mają wysoką similarity, ale pełnią różne role (różne platformy). Embedding flagujeaby je jako „potencjalną kanibalizację”, ale analiza intencji potwierdza, że rozdzielenie jest poprawne – użytkownik szukający reklamy na IG nie chce poradnika o FB.

Czy inne algorytmy podobieństwa działają lepiej niż cosine?

Sitebulb w teście czterech algorytmów (cosine, Euclidean, Manhattan, Chebyshev) na embeddingach Google Gemini wykazał, że Manhattan distance ma 3,5% lepsze rozdzielenie niż cosine. To oznacza, że różne algorytmy mogą lepiej rozdzielać „bliskie ale różne” dokumenty. Ale 3,5% poprawy rozdzielenia nie zmienia fundamentalnego problemu: żaden z tych algorytmów nie widzi intencji, typu strony ani encji.

Screaming Frog w wersji 22.0 wprowadził semantic similarity analysis z użyciem LLM embeddings (OpenAI, Gemini, Ollama). Narzędzie używa embeddingów do wykrywania stron semantycznie bliskich, ale nie do podejmowania decyzji o tym, która powinna rankować. To ważne rozróżnienie: Screaming Frog pokazuje „te strony są podobne”, nie „ta strona powinna wygrać”. Nasz eksperyment potwierdza, że to rozróżnienie jest uzasadnione. O kontekście duplikacji treści i różnicach między near-duplicate detection a kanibalizacją intencji pisaliśmy w osobnym artykule.

Praktyczny workflow: jak łączyć embedding z innymi źródłami w codziennej pracy

Na podstawie wyników eksperymentu wypracowaliśmy w Semgence workflow, który łączy embedding z danymi z GSC i crawlem. Nie jest to złożony pipeline wymagający infrastruktury ML – to sekwencja kroków, którą może wykonać specjalista SEO z dostępem do Screaming Frog i Google Search Console.

Krok 1: crawl z embeddingami. Screaming Frog 22.0 pozwala generować embeddingi stron podczas crawla (przez OpenAI, Gemini lub Ollama). Na wyjściu masz macierz cosine similarity między wszystkimi parami URL-i. Filtruj pary z similarity powyżej 0,85 – to kandydaci do dalszej analizy.

Krok 2: weryfikacja w GSC. Dla każdej pary z wysokim similarity sprawdź, czy oba URL-e zbierają wyświetlenia na te same zapytania. Jeśli tak – masz potencjalną kanibalizację. Jeśli każdy URL zbiera wyświetlenia na inne zapytania – masz keyword diversification i nie musisz interweniować.

Krok 3: analiza intencji. Dla par z potwierdzonym nakładaniem się zapytań w GSC sprawdź, czy oba URL-e odpowiadają na tę samą intencję. Posty sponsorowane na FB i IG mają wysoki cosine similarity i częściowo nakładające się zapytania, ale różną intencję platformową – nie konsoliduj. Dwa artykuły o tym samym temacie z różnych lat, z identyczną intencją i rotującymi pozycjami – konsoliduj.

Krok 4: decyzja oparta na danych, nie na similarity. Cosine similarity = 0,92 to nie jest decyzja o mergu. To jest flag, który wymaga potwierdzenia w GSC (wspólne zapytania?), w analizie intencji (ta sama?) i w danych behawioralnych (który URL konwertuje lepiej?). Dopiero po przejściu trzech warstw potwierdzenia podejmujesz decyzję o konsolidacji, przekierowaniu lub pozostawieniu.

Jak powinien wyglądać model hybrydowy zamiast samego embeddingu?

Eksperyment pokazuje, że embedding powinien być jedną z wielu warstw, nie jedyną. Model, który Paweł Gontarek (Zgred) z Semgence testuje jako następny krok, składa się z dziewięciu warstw.

Nr	Warstwa	Co robi	Jakie dane
1	Filtrowanie techniczne	Odrzuca noindex, redirect, 404	Crawl / URL Inspection
2	Dopasowanie encji	Czy zapytanie dotyczy konkretnego produktu, marki?	NER + schema JSON-LD
3	Klasyfikacja intencji	Informacyjna, transakcyjna, porównawcza	SERP features + query patterns
4	Zgodność typu strony	Czy PDP, kategoria, blog pasuje do intencji?	Page type detection
5	Dopasowanie semantyczne	Cosine similarity zapytanie vs kandydaci	Embeddingi (tu wchodzi embedding)
6	Sygnały GSC	Historyczne kliknięcia i CTR	GSC API query+page
7	Linkowanie wewnętrzne	Anchory i kontekst linków	Crawl graph
8	Walidacja GA4	Konwersja, bounce rate	GA4 (opcjonalnie)
9	Próg confidence	Możliwość odpowiedzi „brak pewnego kandydata”	Aggregate score

W praktyce nie trzeba budować wszystkich dziewięciu warstw od razu. Nawet dodanie klasyfikacji intencji (warstwa 3) i zgodności typu strony (warstwa 4) do embeddingu (warstwa 5) drastycznie zmienia jakość selekcji. Na naszych danych z klastra postów sponsorowanych widzieliśmy, że sam embedding flaguje FB vs IG jako potencjalną kanibalizację (cosine > 0,9), ale dodanie warstwy intencji platformowej natychmiast odrzuca ten fałszywy alarm. Cel to nie perfekcyjny model, lecz model, który redukuje fałszywe alarmy do poziomu akceptowalnego dla specjalisty.

Semgence testuje ten model wielowarstwowy na danych klientów z branży e-commerce (elektronika, moda) i B2B (SaaS, usługi). Pierwsze obserwacje wskazują, że dodanie warstw 2-4 (encja, intencja, typ strony) redukuje fałszywe alarmy embeddingu o około 60%. Wyniki nie są jeszcze wystarczające do publikacji jako samodzielny benchmark – potrzebujemy większej próby i holdoutu. Ale kierunek jest jasny: embedding jako recall, reszta jako precision.

W takim modelu embedding pełni rolę recall – znajduje kandydatów. Ale decyzję o wyborze podejmują warstwy wyżej. Na naszych danych widziałem to na klastrze cennikowym Google Ads: embedding poprawnie grupuje sześć wariantów cennikowych, ale nie rozumie, dlaczego „kampanie adwords” ma pozycję 21 zamiast 3 – to warstwa lexical (brak frazy w treści), nie semantyczna.

Łączenie danych GSC z GA4 opisaliśmy w artykule o atrybucji SEO – ta integracja dostarcza warstwę 8 (konwersja), której sam embedding nigdy nie zastąpi. Relacje między produktami w kontekście product discovery opisaliśmy w artykule o product discovery w e-commerce.

Kiedy embeddingi nadal są przydatne, a kiedy nie powinny samodzielnie decydować?

Negatywny wynik w wyborze URL-a nie przekreśla embeddingów. W kilku zastosowaniach są niezastąpione: w pomiarze topical authority do wykrywania outlierów, w klasteryzacji treści pod audyt, w rekomendacjach linkowania wewnętrznego, w wykrywaniu duplikacji semantycznej i w recall przed rerankingiem. W rerankingu wariantów odpowiedzi AI embeddingi pełnią rolę pierwszej warstwy przesiewowej.

Każde z tych zastosowań ma inną dynamikę. W pomiarze topical authority embedding operuje na poziomie domeny – wektory stron są agregowane do centroidu domeny, a strony odstąjące tematycznie (outlierów) identyfikuje się po odległości od centroidu. Tu embedding działa doskonale, bo pytanie brzmi „czy ta strona jest tematycznie spójna z resztą domeny?” – a to jest dokładnie to, co cosine similarity mierzy. W klasteryzacji treści embedding grupuje dokumenty o podobnej tematyce, co umożliwia szybką identyfikację klastrów do audytu. Ale „podobna tematyka” to nie to samo co „ten sam cel” – i tu zaczyna się granica skuteczności.

W rekomendacjach linkowania wewnętrznego embedding znajduje pary stron, które są semantycznie bliskie i powinny się nawzajem wspierać. To dobry punkt wyjścia, ale anchor text i kontekst linka wymagają ręcznej weryfikacji – embedding nie wie, czy link powinien prowadzić z kategorii do poradnika, czy z poradnika do PDP. Kwestie linkowania wewnętrznego opisaliśmy szerzej w artykule o pytaniach z treści strony i ich dopasowaniu do popytu w GSC.

Na podstawie eksperymentu rekomendujemy, żeby embedding nie był jedynym kryterium przy: usuwaniu i łączeniu stron (merge + 301), automatycznych przekierowaniach, wyborze PDP zamiast kategorii, zmianie strony docelowej dla zapytań o wysokiej wartości biznesowej i decyzjach opartych na próbie poniżej 30 par query-URL. W każdym z tych przypadków embedding dostarcza listę kandydatów, a decyzję podejmuje specjalista lub system z dostępem do dodatkowych warstw.

Semgence wykorzystuje embeddingi tam, gdzie sprawdzają się najlepiej – w recall, klasteryzacji i wykrywaniu outlierów – ale decyzje o wyborze URL-a opiera na modelu wielowarstwowym. O roli wiarygodności audytu opartego na AI pisaliśmy w artykule o ocenie confidence audytu AI, a o całościowej perspektywie SEO e-commerce w kontekście AI Search – w artykule o product graph i retrieval.

Embedding w SEO to narzędzie, które odpowiada na właściwe pytanie („co jest tematycznie bliskie?”) i jest bezużyteczne na niewłaściwe pytanie („co powinno rankować na to zapytanie?”). Recovery rate 7,89% z naszego eksperymentu nie przekreśla embeddingu – lokalizuje jego granicę. W modelu wielowarstwowym ta granica jest jasno zdefiniowana: embedding pełni rolę recall (warstwa 5), a decyzje o wyborze URL-a podejmują warstwy encji, intencji i typu strony (warstwy 2-4). Każda warstwa odpowiada na inne pytanie, i każda jest niezbędna.

W kontekście rerankingu semantycznego istnieje kilka patentów opisujących techniki selekcji dokumentów: US20240135187A1 (klasyfikacja intencji z informacjami retrievalowymi), US12222995B2 (modelowanie tekstu i węzłów DOM) i US12158907B1 (kontekst sąsiednich fragmentów). Patenty opisują klasy problemów – wielowarstwowy scoring kandydatów i uwzględnianie kontekstu strukturalnego dokumentu. Nie potwierdzają, że Google używa konkretnego modelu embeddingowego do rankingu stron organicznych. Nasz eksperyment nie testuje algorytmu Google – testuje skuteczność jednej warstwy w wewnętrznym systemie diagnostycznym.