Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Objaw jest charakterystyczny. Fraza, na której firmie zależy, kręci się na trzeciej albo czwartej stronie wyników i nie chce ruszyć, choć w serwisie są pod nią aż dwa dopracowane teksty. Pozycja skacze, a w Search Console widać, że raz wyświetla się jeden adres, raz drugi.
To nie jest problem z ilością treści. To problem z jej rozproszeniem. Zamiast jednej mocnej strony serwis ma dwie średnie, między które rozłożyły się linki, kliknięcia i sygnały o tym, że dokument jest dobrą odpowiedzią na zapytanie.
Kanibalizacja to jedna z niewielu rzeczy w SEO, którą można naprawić bez tworzenia czegokolwiek nowego. Wystarczy uporządkować to, co już jest.
Wyszukiwarka na jedno zapytanie prezentuje z jednej domeny zwykle jeden wynik, rzadziej dwa. Jeśli więc masz trzy strony celujące w tę samą frazę, konkurencją dla twojej najlepszej strony jesteś ty sam.
Sygnały rozkładają się między adresy. Jedna strona zdobyła kilka linków, druga ma lepsze zachowanie użytkowników, trzecia trafniejszy nagłówek. Żadna nie ma wszystkiego. Algorytm musi wybrać i ten wybór bywa niestabilny — dlatego pozycje skaczą.
Chcę jednak od razu ostudzić popularne przekonanie. Nie każde powtórzenie frazy to kanibalizacja. Kilkadziesiąt kart produktów w tej samej kategorii naturalnie zawiera te same wyrazy i to jest w porządku, dopóki każda z nich celuje w inne, węższe zapytanie. Problem zaczyna się wtedy, gdy dwie strony mają tę samą intencję i tego samego adresata.
Najczęściej z braku planu i upływu czasu, a nie z pojedynczej złej decyzji.
Serwis żyje kilka lat. W tym czasie powstaje strona usługowa, potem wpis na blogu o tej samej usłudze, potem druga strona usługowa napisana przez nową osobę, która nie wiedziała o pierwszej, a na koniec landing page pod kampanię, o którym po zakończeniu promocji nikt nie pamiętał. Wszystkie cztery mówią o tym samym.
W sklepach mechanizm jest inny. Kanibalizację generuje sama architektura: kategoria, podkategoria o niemal identycznej nazwie, strona z filtrem dającym ten sam zbiór produktów, wersja z parametrem sortowania. Do tego dochodzą wpisy blogowe o typie produktu, które konkurują z kategorią.
Trzecie źródło to nadprodukcja treści pod bliskoznaczne frazy. Ktoś zobaczył w narzędziu trzy warianty tej samej frazy z różnym wolumenem i napisał trzy teksty, po jednym na wariant. Google traktuje te warianty jako to samo zapytanie i konsekwentnie wybiera jeden z tekstów, a pozostałe zostają jako balast.
Najszybszą i darmową diagnostykę robię w raporcie skuteczności.
Wchodzę w raport, filtruję po konkretnym zapytaniu i przechodzę na zakładkę stron. Jeśli na jedno zapytanie wyświetla się kilka adresów i żaden nie dominuje wyraźnie, mam kandydata na kanibalizację. Jeśli jeden adres zbiera dziewięćdziesiąt procent kliknięć, sytuacja jest zdrowa.
Drugi sposób to sprawdzenie od strony adresu. Filtruję po stronie i patrzę na zapytania, na które się wyświetla. Dwie różne podstrony z bardzo podobnymi listami zapytań to sygnał ostrzegawczy.
Trzeci, najprostszy: sprawdzenie w wyszukiwarce z operatorem ograniczającym wyniki do własnej domeny plus szukana fraza. Widać wtedy, ile stron w serwisie w ogóle konkuruje o dane wyrażenie i którą Google uważa za najlepszą.
Pomaga też obserwacja niestabilności. Fraza, której pozycja regularnie skacze o kilkanaście miejsc, bez zmian w serwisie i bez aktualizacji algorytmu, bardzo często cierpi właśnie na to.
Mam cztery ruchy i wybieram między nimi w zależności od tego, jak wartościowe są kanibalizujące się strony.
Niezależnie od wybranego ruchu poprawiam linkowanie wewnętrzne. Jeśli w serwisie połowa odnośników z tekstem „naprawa pralek” prowadzi na jedną stronę, a połowa na drugą, sam podpowiadam algorytmowi, że nie wiem, która jest ważna. Ujednolicenie tego bywa wystarczającym lekarstwem, bez ruszania treści.
Kilka rzeczy potrafi zamienić porządkowanie w stratę ruchu.
Nie usuwam strony, która ma linki zewnętrzne, bez przekierowania. Odnośniki, które ktoś kiedyś zdobył, zostają wtedy w powietrzu.
Nie przekierowuję hurtowo kilkunastu adresów na stronę główną. To rozwiązanie wygodne technicznie i praktycznie równe usunięciu — Google traktuje takie przekierowanie jak stronę błędu, jeśli treść nie ma nic wspólnego z docelową.
Nie zmieniam wszystkiego w jednym dniu. Przy większym porządkowaniu robię to partiami, notując daty, żeby móc powiązać efekt ze zmianą. Wyniki widać zwykle po kilku tygodniach, bo Google musi ponownie odwiedzić i przeliczyć zmienione adresy.
I nie liczę na natychmiastowy skok. Realny efekt scalenia dwóch przeciętnych stron to zwykle stopniowe wejście jednego adresu wyżej niż którakolwiek z poprzednich, a nie przeskok na pierwsze miejsce.
Warto rozróżnić dwie rzeczy, które nazywa się tym samym słowem.
W Google Ads kanibalizacja oznacza sytuację, w której dwie moje grupy reklam albo dwie kampanie licytują to samo zapytanie. System wybiera wtedy jedną z nich — zwykle tę z wyższym rankingiem — a nie licytuje przeciwko sobie, więc stawki nie rosną z tego powodu. Problem jest inny: dane rozkładają się między jednostki, których nie chciałem porównywać, i trudniej ocenić, co działa.
Rozwiązanie jest mechaniczne, nie redakcyjne. Wzajemne wykluczenia między kampaniami i grupami, jasny podział na frazy markowe i pozostałe, świadome decyzje o tym, gdzie ma trafić jakie zapytanie.
Jest jednak jeden przypadek, w którym można stracić realne pieniądze: równoległe kampanie w różnych systemach albo kampania działająca na frazę, na której serwis i tak zajmuje pierwsze miejsce w wynikach bezpłatnych. To temat na osobne testy z wyłączaniem, ale warto mieć go z tyłu głowy przy planowaniu budżetu.
Kanibalizacji łatwiej nie tworzyć niż ją naprawiać, a wystarczy do tego jeden plik.
Prowadzę arkusz z mapą fraz: adres strony, główna fraza, intencja, data ostatniej aktualizacji. Przed napisaniem czegokolwiek nowego sprawdzam, czy w serwisie nie ma już strony celującej w to samo. Jeśli jest — decyzja brzmi „rozbuduj istniejącą”, nie „napisz nową”.
Ten jeden nawyk eliminuje większość problemu. Jest szczególnie ważny wtedy, gdy nad treścią pracuje kilka osób albo gdy część tekstów pisze zewnętrzna agencja, która nie zna całości serwisu.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |