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.
Kiedy tłumaczę klientowi, dlaczego jego strona z frazą w tytule, w nagłówku i w pierwszym akapicie nie wchodzi na pierwszą stronę, prawie zawsze dochodzę do tego samego punktu. Strona jest zoptymalizowana pod ciąg znaków, a wyszukiwarka od kilku lat pracuje na czymś więcej — na powiązaniach między rzeczami, o których ten ciąg mówi.
To rozróżnienie brzmi akademicko, ale ma bardzo praktyczne konsekwencje. Zmienia sposób, w jaki dobieram tematy, buduję strukturę serwisu i decyduję, czy dwie podstrony mają sens osobno, czy powinny być jedną.
Poniżej wyjaśniam, jak działa klasyczne indeksowanie oparte na słowach kluczowych, czym jest encja i dlaczego jedno nie zastąpiło drugiego. Bez obietnicy, że istnieje „optymalizacja pod encje”, którą można kupić jako usługę.
Podstawą każdej wyszukiwarki jest indeks odwrócony. Robot pobiera stronę, rozbija jej treść na wyrazy i zapisuje w tabeli: dla każdego wyrazu listę dokumentów, w których on wystąpił, plus informacje o pozycji i kontekście — czy był w tytule, w nagłówku, w linku prowadzącym do strony.
Zapytanie użytkownika jest wtedy obsługiwane jako operacja na zbiorach. Wyszukiwarka bierze wyrazy z zapytania, wyciąga dla każdego listę dokumentów, przecina te listy i dostaje kandydatów do rankingu. Dopiero potem sortuje ich według setek czynników.
Model jest szybki i przewidywalny, ale ma wbudowaną słabość: operuje na napisach, nie na znaczeniach. Dla takiego indeksu „zamek” w zapytaniu o zwiedzanie i „zamek” w zapytaniu o naprawę drzwi to ten sam token. „Adidasy” i „buty sportowe” to dwa różne tokeny, choć użytkownik ma na myśli to samo. Klasyczne rozwiązania — listy synonimów, sprowadzanie słów do form podstawowych, korekta literówek — łatały to punktowo, ale nie usuwały przyczyny.
Cała stara szkoła SEO wyrosła z tego modelu. Skoro liczy się obecność ciągu, to strategia jest oczywista: osobna podstrona na każdą wariację frazy, gęstość słów kluczowych, wyliczanie odmian w stopce. To działało, dopóki wyszukiwarka faktycznie tak liczyła.
Encja to pojedynczy, dający się jednoznacznie wskazać obiekt: osoba, firma, miejsce, produkt, wydarzenie, pojęcie. Kluczowa różnica względem słowa kluczowego polega na tym, że encja ma własny identyfikator, niezależny od nazwy. Ta sama encja może mieć wiele nazw w wielu językach, a dwie różne encje mogą nazywać się identycznie.
Google zbudowało na tym Knowledge Graph, ogłoszony w maju 2012 roku hasłem „things, not strings”. Fundamentem była baza Freebase, przejęta razem z firmą Metaweb — Freebase zamknięto w 2016 roku, a jego dane przeniesiono do Wikidanych. Graf przechowuje nie tylko obiekty, ale też relacje między nimi: kto założył firmę, w jakim mieście leży zabytek, jaki producent wypuścił dany model.
Do rozumienia zapytań doszły kolejne warstwy. Hummingbird w 2013 roku przeniósł ciężar z pojedynczych wyrazów na całe zapytanie. RankBrain, o którym dowiedzieliśmy się w 2015 roku, pozwolił radzić sobie z zapytaniami nigdy wcześniej nie widzianymi. BERT z 2019 roku — u nas dostępny od rozszerzenia na kolejne języki w grudniu tego samego roku — nauczył się czytać funkcję słów takich jak „do”, „dla”, „bez”, które w modelu opartym na tokenach były zwykle wyrzucane jako nieistotne. MUM Google zapowiedziało w maju 2021 roku i wciąż wprowadza je do wyszukiwarki punktowo, w wybranych zastosowaniach.
Najczęstsze nieporozumienie, jakie słyszę, brzmi: „Google już nie patrzy na słowa kluczowe”. Nieprawda i nie ma powodu, żeby tak było.
Indeks odwrócony nadal istnieje i nadal wyznacza zbiór kandydatów. Bez niego nie da się w rozsądnym czasie przeszukać sieci. Encje działają nad tym mechanizmem: pomagają rozstrzygnąć, o którą rzecz pyta użytkownik, rozszerzyć zapytanie o powiązane sformułowania, ocenić, czy dokument mówi o tym samym obiekcie, i zdecydować, jaki typ wyniku pokazać.
Praktyczny wniosek jest podwójny. Po pierwsze, słowa nadal mają znaczenie — jeśli na stronie ani razu nie ma nazwy tego, co sprzedajesz, żadna warstwa semantyczna tego nie zgadnie. Po drugie, samo wystąpienie nazwy już nie wystarcza, bo obok niej wyszukiwarka szuka sygnałów potwierdzających, że tekst dotyczy właściwego obiektu i faktycznie coś o nim mówi.
Wpływ encji najłatwiej zobaczyć nie w samej dziesiątce, a w tym, co ją otacza.
Ma to też drugą stronę. Jeśli twoja marka nosi nazwę pokrywającą się z popularnym słowem albo z inną, większą firmą, walczysz nie tylko o ranking, ale o to, żeby Google w ogóle przypisał zapytanie do właściwej encji.
Zmienia jednostkę planowania. Przestaję układać serwis wokół listy fraz i zaczynam wokół tematów oraz obiektów, których dotyczą.
Konkretnie: kilka podstron różniących się wyłącznie odmianą tej samej frazy nie ma dziś żadnego uzasadnienia. Dla wyszukiwarki opisują ten sam obiekt, więc konkurują ze sobą i rozpraszają sygnały. Zamiast tego robię jedną porządną stronę i pilnuję, żeby wyczerpywała temat — łącznie z pytaniami, które użytkownik zada po przeczytaniu.
Drugi nawyk to jednoznaczność. Pisząc o obiekcie, który może być z czymś pomylony, dokładam kontekst rozstrzygający: pełną nazwę, branżę, lokalizację, kategorię. Nie dla algorytmu, a dlatego że dokładnie te same sygnały czyta czytelnik, który trafił na stronę z niepewnością, czy jest w dobrym miejscu.
Trzeci to spójność nazewnictwa w całym serwisie i poza nim. Jedna forma nazwy firmy, ten sam adres, te same dane w wizytówce i w profilach zewnętrznych. Rozjazdy w tych miejscach widzę na większości kont, które przejmuję, i to jedna z tańszych rzeczy do naprawienia.
Nie ma znacznika „to jest encja”, ale jest kilka rzeczy, które realnie ułatwiają dopasowanie.
Weryfikacja jest prosta: wpisz nazwę firmy i sprawdź, co Google pokazuje obok wyników, jak wygląda autouzupełnianie i czy w wynikach nie mieszają się z tobą inne podmioty. To pierwszy sygnał, czy wyszukiwarka wie, o kim mowa.
Rozumienie tematu nie zwalnia z podstaw. Strona, do której robot nie może się dostać, nie zostanie zaindeksowana ani w jednym, ani w drugim modelu. Tekst bez treści nie zacznie rankować, bo dopisano do niego znaczniki.
Dane strukturalne same z siebie nie są czynnikiem rankingowym. Pomagają zrozumieć zawartość i kwalifikują do niektórych typów wyników, ale nie działają jak dźwignia pozycji.
Uważam też na modne obietnice. Krąży sporo ofert „optymalizacji encji”, które w praktyce sprowadzają się do sztucznego rozsiewania nazw i budowania profili w byle jakich katalogach. To wraca do tego samego błędnego myślenia co gęstość słów kluczowych, tylko w nowym opakowaniu.
Na koniec rzecz, którą warto mieć z tyłu głowy. W lutym tego roku Google zapowiedziało wprowadzenie generatywnej AI wprost do wyników wyszukiwania — bez nazwy, terminu i szczegółów interfejsu. Jeśli to pójdzie w zapowiadanym kierunku, znaczenie jednoznacznego opisania własnego podmiotu tylko wzrośnie, bo odpowiedź syntetyzowana z wielu źródeł musi najpierw ustalić, o czym mówi. Nie zmieniałbym z tego powodu strategii dzisiaj, ale porządek w danych o firmie robię już teraz.
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 |